Interesting....Japanese and European automakers are trying to standardize on a RTOS. Not sure what this means for Wind....it sounds like multiple vendors will support OSEK.
techweb.com
March 13, 2000, Issue: 1104
Section: News
--------------------------------------------------------------------------------
Euro-based auto OS gets new spin, Japan support
Chris Edwards and Rick Merritt
DETROIT - The OSEK-VDX committee, which is trying to define a standard operating system for automotive designs, has submitted the latest version of the specification to public review to try to solve any remaining problems. Separately, promoters of OSEK-VDX said at the Society of Automotive Engineers meeting here last week that support for the operating system is growing outside its European roots and that an Internet-based compliance testing system is in the works.
Two Japanese companies are edging closer to acceptance of OSEK, and the European companies backing the operating system will vote by the end of the month on whether to set up a Web-based test program.
One Japanese auto components company is already designing yet-to-be-released products using OSEK, said Uwe Kiencke, a coordinator for the OSEK effort and a professor at the Institute of Industrial Information Technology at the University of Karlsruhe. In addition, one Japanese car maker is now taking part in OSEK working group meetings, although it has not decided whether to use the software. Also, U.S. companies such as Wind River Systems are now offering commercial versions of OSEK.
"This is no longer just a European effort now," Kiencke said of OSEK, which was founded by eight European car and auto-component companies. "This is not a guarantee it will become a standard, but you can sense the momentum we are gaining."
OSEK-VDX (www.osek-vdx.org) is a largely European industry forum. Its steering committee comprises representatives from Adam Opel AG, BMW AG, DaimlerChrysler AG, the University of Karlsruhe, Citroen-Peugot-PSA, Renault SA, Robert Bosch GmbH, Siemens AG and Volkswagen AG, although technical subcommittee members are drawn broadly from U.S and European chip and software companies.
Kiencke would not name the two Japanese companies forging tighter links to the group. OSEK is also discussing with the iTRON consortium in Japan a plan to create a working group to define a debugging interface for the operating system.
Meanwhile, OSEK has coalesced support around a new testing scheme for the operating system. A compliance system is a key requirement for OSEK because of the way the product is defined and sold. An OSEK coordinating group specifies the application programming interface for the OS, and commercial software companies then produce and sell versions of the operating system and associated tools.
Under the current plan, when a system maker decides to use OSEK and picks a particular version running on a specific processor, it will use a single Web site to request the software vendor to submit its code for testing on that CPU. OSEK will seek a neutral party to run the Web site and act as a testing clearinghouse. The results of the tests would be available free on the site to any future users.
By using the Web as a single point of contact, the group hopes to speed the process of making available compliance information on multiple versions of the operating system running on multiple processors. OSEK members have agreed to the plan in principle. A formal vote is slated for the end of the month.
"If many companies work in this way, there will be a larger benefit for the certification of many versions of the software on many processors, and that could speed the growth of use of OSEK," said Kiencke.
The plan is the group's second attempt to find a means of speeding the job of compliance testing for the operating system. Members recently voted down a plan to fund the creation of a compliance testing lab supported by the group.
New release
Version 2.1 of OSEK-VDX was a reaction to the disclosure of several flaws in the design of its predecessor. Once this version has been approved, expected by the end of May, the committee will be free to go on to create a version with new features, such as real-time support.
Three main fixes have been introduced in version 2.1 along with one that should speed the job of disabling and enabling interrupts on low-end microcontrollers.
One potential problem with kernels built to the version 2.0 specification was that if an error was generated, the handler used to process it could go into an infinite loop and lock up the system. This was because any further errors would cause the error handler to be invoked again.
In version 2.1, this has been changed so that the operating system does not attempt to invoke an error handler if one is already running.
On some processors, it is impossible to implement one type of interrupt-service routine safely. Under the old specification, it was possible for interrupts to be delayed indefinitely or even repeated several times.
The new specification makes this category-three interrupt optional rather than force writers of operating systems to implement unsafe code.
Further changes to the specification include a cleanup of the way the priority-ceiling protocol is defined. The protocol is intended to prevent high-priority tasks from being delayed indefinitely by lower-priority ones that have locked key resources.
The new version is designed to prevent a problem caused when multiple tasks attempt to lock the same resource. The earlier version effectively allowed tasks to access the same resource that should have been locked for use by one exclusively. The specification has been changed to prevent that.
CHRIS EDWARDS IS A CONTRIBUTING EDITOR FOR ELECTRONICS TIMES, EE TIMES' SISTER PUBLICATION IN THE UNITED KINGDOM.
|
