AUTOSAR provides a predefined standard approach for vehicle network and ECU design that is finding its way into every automotive OEM and Tier 1 organization. Here are some of the expected business benefits of an adoption strategy and a look at some of the basic terminology and design methods.
BY ANDREW PATTERSON, MENTOR GRAPHICS
Since its formation in 2003, the AUTomotive Open System ARchitecture (AUTOSAR) alliance has been changing the way vehicle networks and electronic control units (ECUs) are designed. AUTOSAR offers an industry standard approach for OEM manufacturers and their Tier 1 suppliers to design and develop ECUs that are at the heart of modern vehicles. The standard helps reduce the opportunity for human error in the design process and offers suppliers and manufacturers a well-defined, machine-readable data format for exchanging design information.
The AUTOSAR alliance has among its members automobile OEMs and a supporting ecosystem of component and service providers. The goal of the alliance is to create and establish global open standards for automotive Electrics & Electronics (E/E) architectures. The standard assists at the vehicle architecture level, allowing OEM network designers to design and manage the complex interaction of vehicle functions, and also at the supplier level where details of individual ECUs interfaces need to be specified prior to manufacture.
Why Make the Switch to AUTOSAR?
A modern luxury vehicle can contain up to 100 ECUs ranging in function from simple sensor interfaces to complex infotainment and telematics units. It would be high risk to move them all at once to an AUTOSAR methodology and standard, but there are wide ranging benefits for both OEMs and Tier 1 suppliers in making the transition. It is estimated that by 2020, all vehicles will have some AUTOSAR-based ECUs, so this standard cannot be ignored.
Some of the reasons and benefits for switching to AUTOSAR include:
• Improved reuse of ECUs in new car platforms and architectures
• Improved use of pre-validated and tested software components (representing vehicle functions)
• Reduced testing and safety certification costs
• Reduction in downstream design errors—an AUTOSAR methodology allows functions to be defined and verified at an architectural level
• Reduction in overall hardware cost by improved network efficiency and capacity utilization
• Reduced costs in overall network architecture analysis and design reviews
• Improved communication between OEMs and Tier 1 suppliers, by using a standardized digital exchange format (AUTOSAR XML or arxml)
The move to AUTOSAR can be used as a catalyst for change—whether it’s an ECU that needs to be redesigned, or improvements required in the overall in-house design cycle. A move to an AUTOSAR methodology can be introduced alongside other process changes, such as a new tooling workflow, or adoption of improved safety standards to help with ISO26262 conformance. However the change is implemented, the first AUTOSAR-based ECU design project will take longer than the existing/legacy design process, as engineers become familiar with the new methods. The cost savings and efficiency benefits will follow later. It is also possible to migrate legacy ECU assets to AUTOSAR—using the concept of an “AUTOSAR wrapper,” in this way valuable existing and proven ECU application code can be reused. The AUTOSAR-enabling wrapper is capable of interfacing to other pure AUTOSAR ECUs.
At its heart, AUTOSAR provides a standard ECU interface definition, and allows an engineer to specify standardized reusable software layers and components that need to exist in every automotive ECU. The standard is hardware-independent, which means a clear line is drawn between the application software and hardware platform. The application developer can specify the details of individual vehicle functions in the application software without worrying about underlying software services and hardware interfaces. In the past, software and hardware had been very tightly integrated, hindering portability and reuse (Figure 1).
Figure 1 Separating application software from hardware.
Abstracting the design away from hardware decisions opens up a freedom for top-down design by the vehicle manufacturer/OEM based on the required functions of the vehicle. For this stage of the design process, the concept of a Virtual Function Bus (VFB) exists, which allows all the software ECUs to be interconnected and tested. In addition, by using a VFB, the application software components (SWCs) do not need to know about other application software components. The software components present their output to the supporting VFB, which passes the information to the input ports of the destination components. AUTOSAR defines the input and output ports as well as the format of information exchanged. This abstracted approach makes it possible to validate the interaction of all vehicle software functions and interfaces before defining underlying hardware. It is also much easier to make design changes while all functions are defined as software elements on a VFB (Figure 2).
Figure 2 Testing software components (SWCs) on a Virtual Function Bus (VFB).
The VFB has no knowledge of how ECUs will later be distributed and interconnected in the real vehicle, but is a very useful testbench for the architectural design phase. Timing checks can be carried out and the interfaces defined for all the signals in the vehicle.
Once the designer is satisfied with the individual functions, the functions are mapped or grouped together into specific hardware ECUs. AUTOSAR supports the process of mapping and grouping of software components (SWCs). A complex ECU may contain many SWCs, which can be organized hierarchically if necessary (Figure 3).
Figure 3 Assigning software functions into actual ECUs.
The AUTOSAR Run-Time Environment (RTE)
Each individual ECU has its own customized run-time environment (RTE) implementation, which is normally automatically created by supporting design tools. The actual communication between real ECUs will be realized as part of a CAN or FlexRay bus, for example, and the RTE is configured by the generating tool to implement the communication paths required by its connected AUTOSAR components. The RTE becomes the “real-life” implementation of the communication and connectivity topologies from the VFB and architectural design process. Since the AUTOSAR standard supports many different types of software components, the RTE implementation must take into account the constraints and variations that a wide range of SWCs will introduce.
The Basic Software (BSW) is standardized software that does not contain vehicle application logic and ECU functions, but offers hardware-dependent and hardware-independent services to the RTE that sits on top of it. Examples of the services needed are memory services (NVRAM Manager), network communication management services, diagnostic services and state management. When an AUTOSAR SWC defined in the application layer requests services, it is the task of the RTE to complete the mapping on an actual ECU.
The RTE does not provide any mechanisms to access a service from a remote ECU, and this is not allowed by the AUTOSAR specification. All service requirements need to be fulfilled on the “local” ECU. The underlying operating system (OS or OSEK) that executes on the real ECU does not know about the concepts of AUTOSAR “runnables.” The operating system maintains a list of schedulable events that are under management of a scheduling algorithm.
The AUTOSAR layered software architecture decouples the application logic from the hardware to facilitate reuse and portability. The RTE and operating system interface to the Microcontroller Abstraction Layer (MCAL), which in turn provides access to the physical ports and devices on the host microcontroller. The MCAL is specific to each microcontroller and allows the operating system and BSW to have access to devices such as digital I/O, analog-to-digital conversion, FLASH and EEPROM support, etc. Figure 4 shows the relationship between the different hardware and software layers in an AUTOSAR ECU.
Figure 4 How the components fit together in a real ECU.
Enabling a New Methodology
With a top-down AUTOSAR design methodology, the automotive OEM can work with a complete model of the entire network. AUTOSAR design tools allow an individual ECU to be extracted, and the connectivity and interface information is defined in AUTOSAR XML (arxml). This interface definition can then be passed to a Tier 1 supplier for further detailing and implementation. Because the format is standardized, the same definition can be passed to several Tier 1s at the time of competitive tender. The standard description has the benefit of avoiding any design ambiguities in the ECU description, and as the AUTOSAR standard evolves, there is ever less room for misinterpretation. The standard is already hardware-independent so it is well placed to take advantage of new industry trends, such as Ethernet in the vehicle, mixed technology vehicle networks (CAN/Flexray), heterogeneous multicore platforms and in-vehicle gateway arrangements.
Several commercial organizations, including Mentor Graphics, offer evaluation kits for AUTOSAR design. These kits cover both architectural designs down to the configuration of individual ECUs. Mentor Graphics also has its VSX tool suite, as well as ECU hardware development boards with CAN, FlexRay, LIN and Ethernet support. The tools are Eclipse-based and make use of open source tool chains to take designs from source code through to run-time implementation. A low risk investigation and trial of AUTOSAR is preferable to a “big-bang” approach where ECUs in a vehicle are migrated all at once to an AUTOSAR methodology.
The AUTOSAR standard brings with it the opportunity for process improvement and component reuse, but also the challenge of learning a new ECU design process and tooling. The early adopters of AUTOSAR have been passing this knowledge into mainstream engineering, and resources and production-ready tools are now widely available. The adoption of AUTOSAR is also helping organizations meet their requirements of functional safety standard ISO26262, as it provides for a repeatable, well-defined, top-down design process.