Steering your design through the AUTOSAR transition

September 9, 2009  by  

By Rick Pier, Engineering Manager, Mentor Graphics Corporation

The emerging AUTOSAR (AUTomotive Open System ARchitecture) standard for vehicle software design, with its potential to deliver new economies and efficiencies to automotive design and manufacturing, is in the news and on the mind of many engineers responsible for designing vehicle platforms.

Developed and advocated cooperatively by a group of leading automotive OEMs and suppliers, AUTOSAR is beginning to transcend its origins in Europe and is finding allies among companies around the world. Although adoption of the standard is still far from universal, AUTOSAR is rapidly gaining acceptance and appears likely to become a cornerstone of automotive progress in the future.

There are various reasons for this trend. First, the automotive design community is very pragmatic. Fundamentally, it acknowledges that cost and complexity will make it impractical to rely on hardware components alone to differentiate vehicle brands and models in the future. Today, electronic content can approach 45% of the cost of a vehicle, and much of that content runs on embedded code. Software will enable differentiation among automobile platforms in the future, and AUTOSAR is poised to take the industry in that direction.

Secondly, the AUTOSAR environment fosters an unprecedented level of standardization. The protocol promises to commoditize control, communication and I/O functions that reside in every ECU and shift the emphasis to Software Components (SWC) that embody uniquely differentiated application features. Cost-sensitive manufacturers anticipate a time when today’s multiplicity of ECUs—up to 80 distinct types in some vehicles—can be condensed down to a far smaller number of commodity ECUs loaded with the manufacturer’s unique AUTOSAR-compliant software. This will result in tremendous savings without compromising innovation or sacrificing quality.

Lastly, AUTOSAR standards will simplify maintenance and updates throughout the service life of the platforms in which it is embedded. This addresses the troublesome and costly issue of warranty obligations.

AUTOSAR draws some of its basic software (BSW) components from an established architecture known as OSEK/VDX (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen/Vehicle Distributed eXecutive). This environment has its origins in a mutual effort by leading European car makers and suppliers, university researchers, and other interested parties. OSEK includes an operating system, a communications stack, and a network management protocol, all designed with the goal of creating standard software architecture for automotive ECUs.

Importantly, AUTOSAR re-uses certain OSEK specifications. The AUTOSAR operating system expands on OSEK capabilities while remaining back-compatible with OSEK and other predecessors. But AUTOSAR’s approach to Network Management (NM) is appreciably different from that of OSEK.  Consequently a special NM-Gateway is needed to ensure interoperability between new AUTOSAR ECUs and older OSEK-based ECUs connected to the same network.

The power of the AUTOSAR concept lies in its “stack” software model, a layered architecture that is conceptually similar to the telecom industry’s OSI communications stack. Figure 1 depicts this concept in very simplified form, with a CAN network port. The lower stacks are the result of industry-wide standardization efforts. The proprietary layer permits developers to focus their efforts on unique and innovative software components (SWC).  The layout embodies the words of the AUTOSAR Development Partnership: “Cooperate on standards—compete on implementation.” This is what makes AUTOSAR different from its predecessors.

D-E_Fig1_Final

 

 

 

 

 

Figure 1: The AUTOSAR ECU incorporates standardized elements developed with BSW tools, as well as software components (SWC)  designed for specific applications such as controlling brakes or door locks.

The AUTOSAR software topology encourages a top-down design approach. Rather than being concerned about designing an array of single-purpose ECUs, the engineer can focus on the system view. Almost any imaginable functional requirement can be met with software components installed in a “commodity” AUTOSAR-compliant ECU. The unique SWC applications are interfaced via the Runtime Environment, which is generated prior to compiling. AUTOSAR will take the trend toward software-intensive vehicle differentiation to its logical conclusion.

The AUTOSAR architecture includes a wealth of reusable generic software elements categorized as “Basic Software” (BSW). The BSW components include drivers configured for specific microprocessor hardware devices within a particular type of ECU.

For all its promise, the AUTOSAR standard is still a work in progress and many firms, for reasons of cost and caution, continue to rely on entrenched technologies. OSEK/VDX is prevalent among these, but Volcano™ and other protocols also have a presence. For now, many new vehicles will continue to leave the factory with the same embedded software environments they have used for years.

But that doesn’t mean designers can afford to postpone their transition to AUTOSAR. Compliant devices are on the market now, and today’s new vehicles frequently contain a mix of AUTOSAR and OSEK-based ECUs. To ignore this trend is to risk falling behind the competition and possibly missing important cost advantages as the transition gains momentum.

New solutions smooth the transition to AUTOSAR

Many vehicle manufacturers are today strategizing about the switch to AUTOSAR, pondering its technical benefits and cost-effectiveness. Both business planners and system designers want to steer their development projects through the transition cautiously.

Researchers at Mentor Graphics® Corporation, which offers the Volcano™ series of AUTOSAR-compatible design automation tools, have developed a CAN-compatible network management gateway solution that enables the new standard to join existing OSEK-based vehicular buses.  Designers can begin by replacing just a few network nodes at a time, substituting AUTOSAR ECUs for OSEK and similar automotive protocols.

This gateway element may reside within the AUTOSAR Communications Stack and it helps AUTOSAR and OSEK “talk to each other.” The successful implementation of this feature marks a milestone in AUTOSAR’s advancement. It is the first step toward the day when engineers can begin their transition to AUTOSAR without having to redesign their entire network around the new standard. They will be able to replace just a few modules at a time and steer their projects cautiously through the transition.

The main responsibility of the NM element is to coordinate the shut-down of specific ECUs on the network. After shutdown some of the ECUs will be in low power stop mode, while others will have their power completely turned off.

An ECU in low power stop (Sleep) mode can be waked up by specific external events such as the pressing of a remote button. The ECU wakes up other sleeping nodes via CAN messages to perform a requested command such as “Unlock All Doors.”

To understand why the gateway and related functions are necessary, consider the contrast between the OSEK and AUTOSAR network management approaches:

OSEK Network Management

The OSEK NM solution is based on the use of standard interfaces in ECUs served by the OSEK network. Each authorized ECU must:

  •  Be accessible to other authorized nodes
  • Be able to tolerate and handle temporary faults
  • Be able to support diagnostic network related features

There are two OSEK NM variants for network management. The “indirect” NM method uses existing application messages for monitoring and shut-down coordination. The other variant, direct monitoring, uses dedicated messages in token ring architecture. This discussion will focus on the direct OSEK NM environment to illustrate a “gateway” concept that enables OSEK to cooperate and communicate with ECUs that follow the  AUTOSAR protocol.

In a direct OSEK environment, a node on the network can send either of two types of messages: Alive and Ring messages. An Alive message originates with a node that wants to join the ring. The message signals this intent to other nodes. Ring messages circulate constantly to keep the ring up and running, and to identify active ring members. The network ring is automatically restructured if one node stops sending the Ring message or if a new node is introduced.

AUTOSAR Network Management

The AUTOSAR NM solution coordinates transitions between the Bus Active and Bus Sleep modes. Essentially it provides a means for interacting layers (refer again to Figure 1) to synchronize this critical transition. It also provides interfaces that potentially can be used for diagnostic purposes. The AUTOSAR generic NM interfaces are designed to ensure upper layers do not need to know the underlying AUTOSAR bus type.

A node running an AUTOSAR NM module transmits messages when its application requests the node be kept awake. Conversely it halts the AUTOSAR NM transmission when the application indicates its readiness to sleep. The AUTOSAR NM also detects, during a specified time interval, a key precondition: whether the network needs to be kept awake for another AUTOSAR NM node.

The latencies and response times of these two divergent protocols—AUTOSAR and OSEK—are bound to differ, potentially creating synchronization problems. The solution to this lies in a special Protocol Gateway (PGW) that has been developed to oversee and account for the differences among AUTOSAR and OSEK protocols.

Protocol Gateway enables synchronization among standards

The Protocol Gateway software implementation is a key to interoperability among diverse network management protocols. The gateway synchronizes the shutdown/wakeup timing among multiple protocols on one or more networks, using just one PGW-equipped ECU per system (Figure 2).

In automotive networking terminology, a node running a protocol is known as an NM “opponent.” Every opponent representing a network management protocol incorporates a set of preconditions. The PGW function residing in the Communication Stack is aware of these preconditions. It reacts to configurable callbacks controlled by the preconditions, and applies a configurable release mask. The preconditions for each specific type of opponent are integrated into the PGW module configuration.

D-E_Fig2

Figure 2: The bus employs a single Protocol Gateway ECU.

The preconditions are classified into two categories:

  •  Those indicating that the NM opponent and all other nodes using its protocol are ready to sleep
  • Those indicating event(s) that disrupt the remote nodes’ readiness to sleep

The PGW module maps the precondition to a callback function that the NM opponent uses when its identified precondition is met, and one release mask is defined per NM opponent. The release mask indicates to the GW module that an opponent is ready to be released. Whatever the number of NM opponents, their respective interface definitions and parameters must be configured within the gateway module.

Wrapper translation allows both protocols to follow instructions

As important as Protocol Gateway is, a second element is needed to ensure transparent interaction among diverse protocols. It is understood that each NM instance needs its own specific interface to the communication layer. But there must be a means to exchange intelligible information between these interfaces and the communication layer. The solution is a translator, or “wrapper,” intervening between the two. Figure 3 depicts the concept.

The wrapper looks at incoming Frame ID bits and depending on their content,  routes NM frames to a corresponding network manager instantiation. Looking at the example in Figure 3, assume that the communication layer in the Gateway ECU is designed for the OSEK NM. Application Programming Interface (API) calls originated by an AUTOSAR NM to transmit CAN frames are translated by the wrapper to become equivalent calls the communication layer can understand. The process enables two differing protocols, AUTOSAR and OSEK, to act and react as though they were the same. Note that callbacks go through the wrapper for both types of NM—AUTOSAR and OSEK.

To summarize the wrapper’s routing template:

  • Any Frame ID beginning with 0x5 will be routed to the OSEK NM
  • Frame IDs 0x120, 0x121, and 0x122 will be routed to the AUTOSAR NM

D-E_Fig3

 

 

 

 

 

Figure 3: The Wrapper translates instructions and directs traffic to either AUTOSAR or OSEK.

Two buses go to sleep

Figure 4 illustrates the result of a dialogue through the Protocol Gateway and wrapper when both OSEK and AUTOSAR network managers are sharing the bus. Here the Protocol Gateway module starts the synchronization routine after a Call for Shutdown notification. But because the notification arrived shortly after Ring Message 1, the OSEK NM cannot react immediately.  It can’t register a response until Ring Message 2. In contrast, the time remaining (TRemain) before the next ring message is sufficient for the AUTOSAR NM to start the sleep process.

 The Gateway node sends the OSEK NM sleep bit indication with Ring Message 2. The difference between the two NM intervals is equalized by the NM_TIMEOUT_TIME.

The equations for the shutdown timing are:

 T OSEK-Shutdown = t Remain – t typ – t MainProcessing

T AUTOSAR-Shutdown = t Remain – t NM_TIMEOUT_TIME

D-E_Fig4

 

 

 

 

Figure 4: Durations within each timeline are not drawn to scale

Conclusion

AUTOSAR is a promising new automotive network architecture that brings with it the challenge of migrating existing networks to the new standard. This article has demonstrated a framework that allows designers to integrate AUTOSAR network management functions with OSEK and legacy NM protocols still used in today’s vehicles.

The suggested framework gracefully handles synchronization, state-mapping, and module compatibility problems. The Protocol Gateway algorithm abstracts a set of configurable preconditions, callback functions, and release masks while the wrapper translates instructions passing between otherwise incompatible hardware interface layers.

The Protocol Gateway/wrapper approach lays the groundwork for future AUTOSAR exploration and for an expedient transition to an automotive standard whose star is on the rise.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

Spam protection by WP Captcha-Free