AUTOSAR's hierarchical architecture design, used to support complete software and hardware module independence (Independence), the intermediate RTE (Runtime Environment) as a virtual The implementation of the functional bus VFB (Virtual Functional Bus) isolates the upper application layer (Application Layer) from the lower basic software (Basic Software), and gets rid of the dependence on the hardware system in the past ECU software development and verification.
The layered design of the separation of software and hardware improves the integration capability of the system for OEMs and suppliers. In particular, the definition of standardized interactive interfaces and software component models improves the software reuse capability of each layer, thereby reducing Development costs have greatly increased the speed of system integration and product launch.
AUTOSAR architecture is divided into three software layers at the highest level of abstraction: application layer, runtime environment layer and the foundation running on the microcontroller Software layer.
application software layer
AUTOSAR software is organized in independent unit software components (software-component), Atomic Software component (ASWC), including hardware-independent Application Software Component, Sensor Software Component, Actuator Software Component, etc. It encapsulates part or all of the functions and behaviors of automotive electronics, including the realization of specific module functions and corresponding descriptions, but only a defined interface is opened to the outside world, called PortPrototypes, and all ECU internal components communicate and The actions of obtaining other ECU resources must be completed by accessing RTE through the interface.
The communication relationship in the application software layer is as follows:
The software component can communicate with other software components on the same ECU
The software component can communicate with other software components located on different ECUs
The software component can communicate with the basic software (BSW) with ports and located on the same ECU
Virtual function bus VFB and operating environment RTE
Virtual function bus (VFB) Yes The abstraction of the underlying basic software and the network topology is a collection of all communication mechanisms provided by AUTOSAR. In the process of information and data interaction, applications are modeled as composite components. When the system is configured, the software components will be mapped to the designated ECU, and at the same time the virtual connections between components are also mapped to CAN, FlexRay, MOST and other buses. Finally, the software component uses the pre-defined ports to realize communication through VFB.
Operating environment RTE is the implementation of the VFB interface on a specific single ECU, which can be understood as the creation of objects in an object-oriented programming language.
Direct communication between software components is not allowed. After the lower communication layer BSW such as OESK and COM is encapsulated by RTE, the upper layer provides the RTE API required for data communication, and then uses the port or Sender-Receiver communication Interact with Client-Server communication. RTE provides basic communication services and supports communication between Software Component and Software Component to BSW (including program calls inside ECU, bus communication outside ECU, etc.).RTE makes the software architecture of the application layer completely separated from the specific single ECU and BSW.
AUTOSAR basic software (BSW) is further divided into service layer, ECU abstraction layer, microcontroller abstraction layer and complex driver Floor.
As shown in the figure, including the Complex Device Drivers, there are six layers in the AUTOSAR architecture:
Application Layer (Application Layer)
Running Environment RTE (Runtime Environment)
Services Layer
ECU Abstraction Layer
Microcontroller Abstraction Layer
Complex Device Drivers
Basic Software Layer (BSW) Division and Functions
Basic Software Layer (BSW) is divided into Service, ECU Abstraction, Microcontroller Abstraction and Complex Drivers. Each layer of BSW includes different functional modules.
The service layer is divided into 3 parts (Services Layer) ：
1. Communication Services
The access within the vehicle network system, ECU network and software components including CAN, LIN, and FlexRay is unified encapsulated, and the module is abstracted through the communication hardware Layer communication:
hides the protocol and message attributes from the upper application software layer
provides a unified bus communication interface supply software layer call
provides a unified network management service
provides a unified diagnostic communication interface
2. Memory Services
uniformly encapsulates the access to the internal and external memory of the microcontroller, and the NVRAM manager provides a RAM mirror to support data Fast reading.
uses a unified format to transmit non-volatile data to the upper application software layer
abstracts memory addresses and attributes
provides data preservation, loading, verification protection, verification and safe storage A unified mechanism
3. System Services
Provides RTOS services, including interrupt management, resource management, task management, etc.
Provides function prohibition management, communication management, ECU status management, Watchdog management, synchronous clock management, basic software mode management and other services.
The ECU abstraction layer is divided into 4 parts
1. I/O Hardware Abstraction
Access different I/O devices through the signal interface in the I/O hardware abstraction
Encapsulate and transmit I/O signals such as current, voltage and frequency
Hide the lower ECU hardware from the upper application software layer
2. Communication Hardware Abstraction
The communication hardware abstraction encapsulates the microcontroller and all communication channels on the board, and abstracts the definition of communication modes such as CAN, FlexRay, LIN, and MOST.
3. Memory Hardware Abstraction
uniformly encapsulates the on-chip and on-board memory resources, such as providing a unified access mechanism for both on-chip EEPROM and off-chip EEPROM.
4. On-board Hardware Abstraction
encapsulates some special peripherals on the ECU, such as WatchDog and clock.
Microcontroller Abstraction Layer is divided into four parts
1. I/O Drivers
is used to drive analog and digital I/O signals, such as ADC, PWM, DIO.
2. Communication Drivers
is responsible for vehicle modules and vehicle communications, SPI, CAN, etc.
3. Memory Drivers
Control device chip memory (such as on-chip Flash, EEPROM) and external mapping devices (external Flash).
4. Microcontroller Drivers
drives such as Watchdog and Clock Unit and is responsible for RAM testing and microcontroller abstraction layer internal devices and mapping micro Controller abstraction layer external device memory access and other functions.
Complex Device Drivers
The CCD layer spans between the microcontroller hardware layer and the RTE. The main task is to integrate non-standard function modules that have special purposes and cannot be configured with MCAL, and embed this part of the functions into the AUTOSAR basic software layer, so as to realize the specific functions and time requirements of processing complex sensors and actuators. Complex drivers are closely related to the microcontroller and ECU hardware. The upper program interface is specified and implemented according to AUTOSAR; the lower program interface is restricted by the standard interface program. Complex drivers can use specific interrupts or complex microcontroller peripherals (such as PCP/TPU) to directly access the microcontroller, thereby realizing the evaluation of complex sensors and the control of actuators, using interrupts, TPU, PCP, etc. Realize real-time sensor sampling, actuator control and other functions.
AUTOSAR architecture unifies the software organization structure, so that when the underlying hardware configuration is upgraded, the entire system does not need to be changed, which is conducive to the future update of the vehicle system software. At present, all OEMs are focusing on the development of smart cars and autonomous driving And other technologies have put forward higher requirements on the existing automotive architecture, so the promotion of AUTOSAR has also become a trend in the automotive electronics industry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-