Foreword, background
This article refers to the address: http://
Since its inception in 2003, the AUTOSAR (Automotive Open Systems Architecture) Alliance has been working to change the way in-vehicle networks and electronic control units (ECUs) are designed. AUTOSAR provides original equipment manufacturers (OEMs) and their Tier 1 suppliers with industry-standard methods for designing and developing ECUs in modern vehicle centers. This standard can help reduce the possibility of human error in the design process and provide suppliers and manufacturers with a clear and machine-readable data format to exchange design information. This article explores some of the expected business benefits of the strategy employed by AUTOSAR and explains some of the basic terms and design approaches.
Members of the AUTOSAR Alliance include automotive OEMs and a support ecosystem of parts and service providers. The Alliance's mission is to create and establish global open standards for automotive electrical/electronic (E/E) architecture. The standard provides support at the vehicle architecture level, allowing OEMs network designers to design and manage complex relationships between vehicle functions, and also supports the vendor's detailed definition of the individual ECUs interface prior to manufacturing.
1. Why use AUTOSAR instead?
A modern luxury car may contain up to 100 ECUs, ranging from simple sensor interfaces to sophisticated entertainment information and telematics units. The risk of switching them all at once to AUTOSAR methods and standards is high, but original equipment manufacturers and Tier 1 suppliers make such changes and gain broad benefits. It is expected that by 2020, all vehicles will have some AUTOSAR-based ECUs, so this standard cannot be ignored.
Some of the reasons and benefits of switching to AUTOSAR include:
Better reuse of electronic control units in new automotive platforms and architectures
Better use of pre-verified and tested software components (representing vehicle functionality)
Reduce test and safety certification costs
Can reduce downstream design errors -- a set of AUTOSAR methods allows functions to be defined and verified at the architectural level
Reduce overall hardware costs by improving network efficiency and feature utilization
Reduces the cost of overall network architecture analysis and design review
Improves communication between original equipment manufacturers and Tier 1 suppliers, using a standardized data exchange format (AUTOSAR XML or arxml)
Switching to AUTOSAR speeds up design adjustments, whether or not the ECU needs to be redesigned or improved throughout the internal design cycle. Switching to the AUTOSAR method can be adjusted with other processes such as the workflow of new tools or by adopting higher safety standards to maintain consistency with the ISO26262 standard. Regardless of how the adjustments are implemented, the first AUTOSAR-based electronic control unit design project takes longer than the existing/traditional design process because designers need time to become familiar with the new approach. This is followed by an increase in cost savings and benefits. It is also possible to convert traditional ECU assets to the AUTOSAR standard, and by using the “AUTOSAR package†concept, important existing and recognized electronic control unit application codes can be reused. Enable AUTOSAR packaging to be imported into other pure AUTOSAR ECUs.
2. What is AUTOSAR?
Essentially, AUTOSAR provides a standard ECU interface definition that allows designers to identify reusable standardized software layers and components that are required in every automotive ECU. This standard is not affected by hardware, which means that the application software and hardware platform are independent of each other. Application software developers can clarify the details of each car function in the application software without worrying about the relevant software services and hardware interfaces. In the past, software and hardware were tightly integrated, making portability and reusability difficult (Figure 1).
Figure 1: Separating application software from hardware.
Separating design from hardware decisions enables vehicle manufacturers/OEMs to design top-down based on the required vehicle functionality. The Virtual Function Bus (VFB) concept that exists at this stage of design enables all software electronic control units to be interconnected and tested. Application software components (SWCs) are also independent of other application software components through the use of virtual function buses. The software component sends an output signal to the virtual function bus, which in turn transmits the information to the input port of the target component. AUTOSAR provides definitions for input and output ports and exchange information formats. This separation method makes it possible to implement all vehicle software functions and interface interaction verification before defining the relevant hardware. Design adjustments are therefore much easier, and all functions are defined as software components on the virtual function bus (Figure 2).
Figure 2: Testing software components on a virtual function bus.
The virtual function bus does not provide information on how the ECUs are distributed and interconnected in real vehicles, but is a useful benchmark for the architectural design phase. Timing checks and interface definitions are available for all vehicle signals.
Once the designer is satisfied with the features, these features are mapped or aggregated into a specific hardware electronic control unit. AUTOSAR provides support for the mapping and aggregation of software components. A complex ECU may contain many software components and can be hierarchically organized if necessary.
Figure 3: Assigning software functions to a real electronic control unit.
3, AUTOSAR operating environment
Each ECU has its own custom operating environment (RTE), which is usually created automatically with the accompanying design tools. The actual communication between the real electronic control units will be implemented as part of the CAN or FlexRay bus, and the operating environment is configured by the generation tool to perform the communication paths required for the connected AUTOSAR components. The operating environment can effectively implement the communication and connection topology of the virtual function bus and architecture design flow. Since the AUTOSAR standard supports many different types of software components, the operating environment must consider the limitations and variations of various software components.
4, Serving the AUTOSAR components -- the underlying software layer and operating system
The Base Software (BSW) is a standardized software that does not include vehicle application logic and electronic control unit functionality, but provides hardware-dependent and hardware-independent services for the operating environment. The services required include memory services (NVRAM Manager), network communication management services, diagnostic services, and status management. When the AUTOSAR software component defined in the application layer requires service, the task of the runtime environment is to complete the mapping on the real electronic control unit.
The operating environment does not provide any mechanism to obtain services from remote ECUs, nor is the AUTOSAR specification allowed to do so. All service requirements must be met on the "local" electronic control unit. The basic operating system (OS or OSEK) running on a real electronic control unit does not know the concept of AUTOSAR "operable entities". The operating system has a list of schedulable activities that are managed by a scheduling algorithm.
5, about hardware
The AUTOSAR layered software architecture separates hardware application logic for reuse and portability. The operating environment and operating system are connected to the microcontroller abstraction layer (MCAL) to access the physical ports and devices on the primary microcontroller. The microcontroller abstraction layer is specific to each microcontroller, enabling the operating system and underlying software to access devices such as digital input/output, analog-to-digital conversion, FLASH, and EEPROM support. Figure 4 shows the relationship between the different hardware and software layers in the AUTOSAR electronic control unit.
Figure 4: How components are assembled together in a real electronic control unit.
6, support new methods
Automotive OEMs can operate a complete model of the entire network through a top-down AUTOSAR design methodology. The AUTOSAR design tool allows the extraction of a single ECU, and connectivity and interface information is defined in AUTOSAR XML (arxml). This interface definition will then be passed to the Tier 1 supplier for further detail design and implementation. With a uniform format, the same definition can be passed to several Tier 1 suppliers at the same time as the open bid. The advantage of the standardized description is that any design uncertainty can be avoided in the ECU description, and with the development of the AUTOSAR standard, the possibility of misunderstanding is getting smaller and smaller. Because this standard is hardware-independent, it makes good use of the benefits of new industry trends such as in-car Ethernet, hybrid technology vehicle networks (CAN/Flexray), heterogeneous multi-core platforms, and vehicle gateway arrangements.
7, want to give it a try?
Some commercial organizations, including Mentor Graphics, provide evaluation kits for AUTOSAR designs. These kits include architectural design to a single ECU configuration. Mentor Graphics also has its VSX tool suite and ECU hardware development boards supporting CAN, FlexRay, LIN and Ethernet. These tools are based on Eclipse and leverage the open source toolchain for a range of designs from source code to operational implementation. Low-risk surveys and AUTOSAR trials are preferable to the large-scale change of the in-vehicle ECU to the AUTOSAR method on a large scale.
Summary of research report
AUTOSAR provides pre-defined standard methods for in-vehicle networking and ECU design, finding ways to enter each automotive OEM and Tier 1 organization. The AUTOSAR standard offers opportunities to improve processes and reuse components, but there are challenges in learning a new ECU design process and tools. Early adopters of AUTOSAR have been passing this knowledge to mainstream design and resources, and tools for mass production are now widely available. The adoption of AUTOSAR will also help organizations meet the functional safety standard ISO26262 because it supports a repeatable, well-defined, top-down design flow.
Guangzhou Ehang Electronic Co., Ltd. , https://www.ehangmobile.com