FROM EDN EUROPE: Automotive design sets RTOS cost and performance challenges

Continually tightening "green" legislation and increasing consumer sophistication are driving up in-vehicle-electronics content. As stand-alone systems mature into distributed network-based architectures, developers need environments and tools that meet hard real-time requirements.

By David Marsh, Contributing Technical Editor -- EDN, September 2, 1999

The combination of the geography and climate of the Los Angeles region, which traps pollutants from millions of inefficient car exhausts and turns the pollutants into notorious photochemical smogs, directly led to the first sophisticated electronic systems in mass-production vehicles. Under a yellowish-brown atmospheric layer of noxious pollutants, the California Air Resources Board introduced and continues to pioneer the toughest vehicle-emissions legislation in the world. Authorities elsewhere are increasingly adopting this legislation. But under the bonnet, early California-spec vehicles resembled a plumber's nightmare—with pipes everywhere that strangled mechanical carburetors and recycled unburned hydrocarbons—and only just met the first phase of ever-tightening emissions legislation.

Manufacturers soon introduced electronically controlled fuel-injection systems to boost efficiency and restore performance, giving vehicles their first real electronics content other than a radio. Industry analysts now predict that by 2001, electronics will comprise as much as 30% of a vehicle's components, increasing in value from today's average of $940 to $1720 by 2005. More and more vehicle architectures link the engine-management system to peripheral controllers, such as automatic gearboxes, antilock-braking, and traction- and stability-control systems. Systems as diverse as climate control, occupant safety, and satellite navigation complicate the overall design.

As the design challenge toughens, auto manufacturers are finding that it's impractical to develop complete systems in-house. These manufacturers simply don't have sufficient personnel with the wide skill base necessary to develop and integrate diverse system elements. Auto manufacturers are now pressuring their component suppliers to take a larger part in the design and development process, leading to engineering teams from multiple suppliers co-developing the vehicles' electrical and electronic systems. The result is that auto designers are facing a transition that's similar to moving from the steam age to the nuclear age in one step, and they urgently need reliable, cost-effective environments and tools to smooth their ride.

Assembly language suits single tasks

Assembly-language and standard high-level-language (HLL) compilers provide a cost-effective, hardware-efficient environment for developing stand-alone automotive systems. These tools have dominated the auto industry's software departments for two decades and still play a role today. The Lotus 88 Formula One car was the first automotive-electronics project to attract widespread attention, with an active suspension system that decoupled the vehicle's aerodynamic qualities from its critical ride-height settings. Lotus electronics designer Dave Williams started the project using classic analogue control loops to manipulate hydraulic actuators.

According to Williams, the first prototype had a single central controller with potentiometers that set loop gain. But because that approach wasn't going to survive in a Formula One car, Lotus developed a hybrid controller that used multiplying DACs and an 8-bit microprocessor to set loop gain. However, race engineers still needed to make some adjustments with a soldering iron, so they adopted the TMS32010 DSP for digital control and for its ability to download data over a serial link. Williams recalls that he developed the software in TurboPascal and assembly language but that the real trick lay with the system timing: "By continuously clocking ADCs that updated a dual-port RAM, we could interrupt the processor at 1-msec intervals. Loop gain remained high by constraining transport delays to around 150 ?sec." Williams took the simplest possible approach: He wrote the algorithms first, then rearranged them to suit the system's overall timing constraints—but it worked!

Many developers still code application software for stand-alone systems using assembly language and standard HLL compilers, particularly in the conservative US auto industry. With careful timing analysis and optimal use of on-chip peripherals, such as counter/timer blocks, a round-robin scheduler can meet all CPU load conditions in an electronic control unit (ECU) using a commodity 8-bit machine, such as Motorola's billion-selling 68HC05 microcontroller. But software complexity tends to grow exponentially with increasing control features, making it more and more difficult to guarantee that the correct event sequence executes on time. And, as designs mature into distributed systems, the development challenges multiply.

Distributed systems drive autos

Most of the engine-management systems in today's vehicles are stand-alone, closed-loop systems developed using methods analogous to Lotus' active-suspension project. When the engine-management system links into other systems, such as gearbox controllers, antilock- braking systems, and traction controllers, control distributes across time-critical system elements. The wiring harness quickly grows to more than 1 km of expensive, heavy conductors and connectors (Figure 1). A bus-based system, such as a Controller Area Network (CAN), targets robust, real-time in-vehicle communications and drastically reduces wiring requirements (Reference 1). ISO-11898 parts 1 and 2 formalise CAN; part 3 is forthcoming and will contain a fault-tolerant low-speed physical-layer specification. It will also include a time-triggered communication option (see CAN in Automation's Web site, www.can-cia.de).

Volvo's 1998 model S80 is an example of how new vehicle architectures have matured into complex distributed systems. Two CANbuses and four proprietary low-speed buses link the S80's 18 ECUs (Figure 2). The red bus in the figure carries 250-kbps CAN traffic that services the most critical system elements, such as the engine ECU and antilock-braking-system controllers; the green bus operates at 125 kbps and services less time-critical peripherals, such as dashboard displays.

A central electronic module acts as a gateway, connecting mission-critical and peripheral CANbuses. The four proprietary low-speed buses don't appear in the figure but provide a cost-effective method of servicing switch arrays. As a rule, each auto-harness wire end costs $1, so a cheap microcontroller quickly pays for itself by multiplexing switch arrays and hosting serial communications with the central system controller. The control software is distributed among the system elements and has 2 Mbytes of ROM code. Each ECU runs Volcano Communications' networking software, and most ECUs contain real-time operating-system (RTOS) code from Northern Real Time Applications (Reference 2).

RTOSs simplify distributed designs, and their support tools automate parts of the design process. You can choose from more than 100 commercially available RTOSs, but, as EDN technical editor Warren Webb reported last year, embedded-software developers write most of today's RTOSs for themselves, either by accident or by design (Reference 3). Underestimating hardware and software complexity can lead to project escalation, but the bigger driving force for custom code development is the need for I/O concurrency. Webb observes that many programmers who write their own RTOSs encounter subtle and difficult-to-fix concurrency errors that justify considering a commercial RTOS, even for as few as two or three concurrent interrupts.

But in automotive applications, off-the-shelf commercial RTOSs often fail to meet three essential requirements: guaranteed determinism, memory-usage efficiency, and testability. Guaranteed determinism means hard real-time response, which is the ability to define the OS' response to both scheduled and sporadic events under all conditions. One problem area is priority inversion, which is when a low-priority task executes ahead of a high-priority one. The potential for priority inversion is intrinsic within many OSs; results can range from delaying a task from executing, to system crashes due to corruption of shared data. Microcontrollers that nest interrupts are prone to this behaviour. You may have extreme difficulty observing such behaviour, because it's almost certain to happen due to random, aperiodic events.

Demand for memory-usage efficiency has its roots in cost-reduction concerns, which current-generation microcontroller hardware largely alleviates. For typical automotive applications, memory is unlikely to be a significant part of the hardware cost, and paring down the application to the fewest possible bytes no longer saves you on the bill of materials. But auto developers still emphasise this requirement, and their main reason is code reliability; systems with thousands of lines of code are hard to verify. And testability is critical, because the operating time for an engine-management system is typically around 4 billion hours for a fleet of 1 million vehicles. It's simply impossible to test a new system for more than a few thousand hours, and during that time elusive bugs may not appear.

A new way to work

A key reason for adopting an RTOS is its ability to help partition software development; it also permits teams to work on parts of the project. Recognising that the company needed additional software effort for its 1996-model 318i's engine-management system, BMW decided to gain experience by working with expert partners to develop the BMS43 ECU. (To read about how team leaders from BMW and Softing Automotive describe their underlying philosophy and development strategy, see Reference 4.) To ensure that software teams work efficiently in parallel, guidelines stipulate modular design with transparent style and documentation; testability; lack of interaction with other software modules; the ability modify, update, and expand modules; and reusability with portability (hardware independence).

A hierarchical v-shaped model functionally partitions BMS43's development, defining documentation production, plus module checking and reviewing points (Figure 3). Supporting software tools include standard C-language compilers; I-Logix's Statemate for an overall system functional description; Integrated Systems' Matrix-X for control-engineering modelling and simulation; and Intersolv's PVCS for version control management. The RTOS that underpins the BMS43 project has a priority-controlled, fully pre-emptive core; dynamic priorities that can automatically vary; angular functions that synchronise with crankshaft position; a RAM requirement of less than 1 kbyte; a ROM requirement of less than 5 kbytes; and less than 10% load (overhead for the OS) on the CPU. The RTOS environment also includes a symbolic debugger that monitors task states.

Because no commercial RTOS was available to satisfy the team's requirements, Softing Automotive developed BSKA, an operating-system core for power-train electronics. This RTOS provides no I/O-driver tasks; in the BMS43 ECU, drivers combine with tasks, or, where time is critical, operate separately on interrupt levels outside the RTOS core. By partitioning development and guaranteeing freedom from software-module interactions, individual teams can work without permanent links, updating common elements from a central database server at predefined milestones. The BSKA implementation occupies 4.1 kbytes of ROM and 138 bytes of RAM and requires 38 bytes of RAM for each task. It switches tasks in 98 ?sec on a 16-MHz 6833x-series CPU.

Auto manufacturers demand standards

Despite its success and the partners' willingness to licence the technology, BSKA has not emerged as a commercial product. A consortium of mainly European auto manufacturers, including BMW, is now participating in a formal standardisation effort. The OSEK/VDX (open system and corresponding interfaces for automotive electronics/vehicle distributed executive) project carries into its kernel many of BSKA's objectives and much of its functionality. OSEK's fundamental aim is to support software portability and reusability across multiple projects and to thus save the high recurring cost of developing and redeveloping ECU software. The University of Karlsruhe (Karlsruhe, Germany) serves as a project-coordination point. You can download the specifications at www-iiit.etec.uni-karlsruhe.de/~osek/.

According to Keith Potter, European marketing manager at Wind River Systems, auto manufacturers are compelling their component suppliers to develop interoperable systems, opening up the supply chain to greater competition. This development is impossible without standards. Potter also points out that auto manufacturers have become the driving force in computer-aided software-engineering (CASE) tool development: "Software vendors need standards in order to invest sufficiently in the highly advanced code generation, simulation, and other CASE tools that the auto industry demands. Simulation, which auto manufacturers previously separated from software development, now converges with code generation. Witness efforts such as the Esprit Drive project, which aims to link OSEK with CASE tools."

The OSEK specifications comprise three main parts: the operating-system core (the OSEK OS), the communications module, (COM), and the network-management module (NM) (see sidebar "OSEK scales to suit applications"). These specifications support applications from a stand-alone ECU to a full-blown network system and provide compiler writers with the framework for developing OSEK-specific products. Related specifications include the OSEK Implementation Language (OIL), which formally describes an OSEK system in a C-like language syntax that suits automation tools, such as code generators. An OIL-format file describes the application's implementation-specific features and structure, enabling an OIL tool to scale the operating system to the application's demands. By calculating data requirements offline, the tool optimises ROM and RAM usage requirements, permitting a cheaper microcontroller. Byte for byte, ROM is typically eight to 16 times cheaper than embedded RAM.

Currently, at least 11 vendors offer products that suit OSEK applications, including kernels, code generators, and a host of development tools. See the manufacturer's table for a list of vendors who have available or soon-to-be-available OSEK products; you'll find more vendors from the University of Karlsruhe's products link. The table also lists non-OSEK-compliant RTOSs that suit hard real-time requirements and the automotive environment, such as Keil's RTX family with CAN support. The table includes only guide prices. For simplicity, the table shows the price for a typical one-seat, entry-level environment, but not all vendors' price structures match this model. For example, Motorola bases its licensing on a one-time fee that is independent of volume and includes development seats. Due to variable project-pricing methods, you'll find that li- censing arrangements are almost always negotiable.

Some products target CPU families, and others generate intermediate HLL code. Originally developed by consulting company 3Soft as ProOSEK, Wind River's MotorWorks directly generates object code for specific CPUs. Products such as I-Logix's Rhapsody generate C-language code that you compile for your target using your favourite tool. Both approaches have merits and disadvantages. Object-code generators produce code directly and free you from considering the compiler's implementation. You rely on the compiler writer to produce an implementation that meets hard real-time requirements. A tool that produces intermediate code in an HLL frees you from being tied into specific processor families, promoting portability. You can see the logical programme flow, but, to preserve that flow, you need to properly understand your compiler.

Andy Rice, head of electronics and control systems at the Stewart Grand Prix Formula One team, uses a custom operating system along with standard assembly- and C-language compilers. He says, "Unlike a production auto manufacturer, the most important thing for us is the ability to quickly change something. We can have very little time between a race and the next test session." Rice says that his team must be confident that a single change won't affect other parts of the software and that the RTOS helps them achieve some of that confidence. But, he warns that it's absolutely critical to fully understand your language compiler: "We've done a massive amount of work to ensure that our tools produce exactly what we expect, and we continuously check the results to ensure that the tool chain always performs as we predict."

Tools verify embedded software

Software vendors have numerous code-generation tools, but the bigger challenge is to test prototype software for correct behaviour under real-time conditions. Wind River's WindView is a software diagnostic tool that tightly couples with the company's Tornado/OSEK environment. Also developed with 3Soft, WindView provides a window into an OSEK system's dynamic operation. A graphical user interface displays in real time the interactions among tasks, interrupt service routines, and an application's system objects (Figure 4). WindView accommodates complex triggering, which you can set up to capture events in the same way a logic analyser does. Wind River's Keith Potter observes, "Most developers are used to trace debugging at source level. That's fine for simple code, but it can take a lot of time to correlate multiple system interactions with task execution. WindView works at task level and provides a picture that reflects the high-level system design."

Northern Real-Time Applications designed its SSX5 operating system to support a timing-compiler tool that addresses real-time test-validation issues at the application's design stage. The building process starts by declaring information, such as task details, how tasks share data, and stack requirements. A configuration tool uses this information to construct a description of how the application uses the operating system. A "time-line" tool schedules periodic events offline; a runtime activator uses the code to start tasks and to control wait periods. Three build levels provide error-checking capabilities from comprehensive (initial debugging) to minimal (final building). The middle level is the timing-build step, which uses instrumentation code to measure task and interrupt-service-routine execution times. A calibration package compares these times with target hardware measurements to match real-world conditions. The SSX5 timing compiler (STC) then analyses the schedule to determine worst-case timing performance. The operating system is now available; the STC tool will be available in the fourth quarter of 1999.

Applied Microsystems Corp takes a universal approach to system debugging with its CodeTest tool set. These tools debug deeply embedded systems at source level, enabling you to trace the code execution through processor pipelines and caches. The basic technique relies on inserting instrumentation code to provide trace histories, avoiding the hardware-level test problems that arise from trying to reconcile bus activity with execution. The host tool reads the instrumentation code, capturing data operations and variables on the fly. LiveCode adds to CodeTest's automated source-level-instrumentation technique by directly instrumenting an executable image. You can view the execution trace and edit code at runtime, eliminating multiple compile, link, and load sessions. You can even step forward and backward through execution flow. The initial LiveCode release targets Motorola's PowerPC architecture and Wind River's Tornado/VxWorks environment.

OSEK isn't the only European-auto-industry research effort to receive widespread manufacturer collaboration. The European Union-funded time-triggered- architecture (TTA) project brings together groups representing academic institutions, aerospace and automotive manufacturers, and software houses (Reference 5). With its origins in the aerospace industry, TTA and its time-triggered protocol (TTP) provide a highly robust, fault-tolerant, real-time environment for critical applications, such as fly by wire. In the automotive context, this x-by-wire concept substitutes electronic control systems and electrically operated actuators for mechanical and hydraulic linkages in applications such as steering and braking systems.

You can see details of the automotive industry's x-by-wire project and download project documents and the 68-pgfinal report from the Technical University of Vienna's (Vienna, Austria) Web site (www.vmars.tuwien.ac.at/projects/xbywire/). System requirements include fully deterministic behaviour, real-time testability, and support for error-tolerant redundancy. X-by-wire technology is slowly coming to fruition; Motorola recently announced a technology alliance with Viennese spin-off company TTTech (www.tttech.com). Motorola intends to manufacture microcontrollers with onboard TTP/communications modules, and TTTech develops software-development and -validation tools. Visit TTTech's Web site for details on upcoming seminar programmes.

No stranger to fly by wire, former Lotus Formula One designer Dave Williams' drive-by-wire experience includes developing a prototype vehicle with 13 electrically operated actuators. These actuators control elements such as active suspension, brakes, and front- and rear-axle steering. They also supply artificial "feel" for components such as the steering wheel. But Williams sees more immediate challenges for auto manufacturers, such as efficiently manufacturing and servicing the complex systems that are now taking to the road. He foresees that the entire process will become automated: "You can't have electronics engineers at every service shop," he reasons, "so there will inevitably be some type of module-exchange programme. And you can't tie up a whole vehicle if one module fails. Independent modules with built-in self-test capabilities inevitably lead you toward distributed systems."

Author info

REFERENCE

1.Marsh, David, "CANbus ICs marry mechanics with electronic supervision and control," EDN Europe, March 1997, pg 117.

2. "Volcano—A Revolution in On-Board Communications," Volvo technical report, January 1998.

3. Webb, Warren, "Embedded operating-system software—build or buy?" EDN, Aug 3, 1998, pg 43.

4. Merkle, Heinz and Dr Christoph Dallmayr, "Software Sharing—New Ways of Collaboration," First International Conference on Control and Diagnostics in Automotive Applications, Genova, Italy, Oct 3 to 4, 1996.

5. Time-Triggered Architecture, Espirit Open Microprocessor Systems Initiative, project number 23396.

Talkback

We would love your feedback!

Post a comment

» View All Talkback Threads

• Resource Center
• Browse Categories
• Browse Companies

Featured Company

• Mill-Max Mfg. Corp.

  

  The leading US manufacturer of machined interconnect components. Product line includes spring-loaded contacts, SIP, DIP, PGA and BGA sockets, board-to-board interconnects and pin headers, surface mount and application specific products, PCB pins... more

• Rohde & Schwarz

  

  Rohde & Schwarz is an independent group of companies specializing in electronics. It is a leading supplier of solutions in the fields of test and measurement, broadcasting, radiomonitoring and radiolocation, as well as secure communications... more

• ON Semiconductor

  

  ON Semiconductor provides you with the products, solutions and design resources to meet all your power management design needs... more

• Agilent Technologies

  Agilent Technologies Inc. (NYSE: A) is the world's premier measurement company and a technology leader in communications, electronics, life sciences and chemical analysis... more

• Aeroflex

  

  Aeroflex is a leading worldwide provider of highly specialized test and measurement equipment and microelectronic solutions... more

---

Most Recent Resources

• Atmel's QTouch Library 2.0
• Mill-Max Pin Receptacles
• Mill-Max .050" Pitch SMT & Through-Hole Spring-loaded Connectors
• The Impact of Digital Oscilloscope Blind Time on Your Measurements
• LTE-Advanced Technology Introduction