💡
AUTOSAR
Automotive Open System Architecture
: A standard software architecture developed by several automobile manufacturers, which standardizes the design of vehicle control systems and makes design of software independent of hardware. As a central standard, AUTOSAR enables reuse of software components as well as their interoperability.
- 개발자는 응용 SW를 SWC 단위로 모듈화하여 설계한다.
- SWC의 기능은 내부의 Runnable과 이를 작동시키는 Event로 설계된다.
- SWC 간의 통신은 port를 통해 데이터를 주고받는 방식인 interface를 정의함으로써 설계된다.
- Runnable은 개발자가 내부 코드를 작성할 수 있는 함수로 구현
- SWC 간의 통신은 RTE API로 생성되어 Runnable의 코드 내에서 호출
- Runnable은 운영체제의 Task에 mapping 된 후 Event가 발생했을 때 Task 내부에서 호출되어 실행
- 한 Task에 여러 Runnable이 mapping되면 수행 순서를 설정해야 함
- Runnable-Task mapping은 시스템 오버헤드 발생과 Runnable의 실제 수행 시점에 크게 영향을 미침AUTOSAR Classic
**CP : Classic Platform
A layered architecture for the integration of application and hardware.
RTE(Runtime Environment) is the core of AUTOSAR's CP. Communication between SWC is based on VFB (Virtual Functional Bus) therefore it is independent of ECU (electronic control unit).
Communication
Generally, CP adopts CAN (Controller Area Network) communication. In a communication based on CAN, all the involved nodes are connected to the same bus. The data transmission is completed by signal boradcast on the bus, which means the signal can influence every node connected to the bus. CAN communication generally uses twisted pair as a transportation medium, whose maximum bandwidth is 1Mbit/s.
Safety
CRC(Cyclic Redundant Check) field of a CAN frame is used to perform data error detection. Based on CRC verification result, receiver will give a corresponding ACK response in ACK field.
The identifier is used for arbitration and therefore cannt be encrypted while the data might be encrypted. As a result The identifier exposes information about the type of data to attackers due to the fixed coupling of identifiers and data in the automotive domain.
Since CAN communication is based on a shared medium, the traditional diagnostic can be carried out by monitoring bus traffic.
Encryption of data transmission can prevent cars using CAN networks from some attacks. The encryption of CAN frame must be considered in terms of payload and arbitration ID respectively. Recent developments towards CAN with flexible data rate(FD) increase the payload of a single frame up to 64 bytes, enabling security features like encryption and key exchanges.
As to the encryption of arbitration field, research suggests an approach that determines specific message ID per vehicle for CAN systems while still satisfying all real-time end-to-end latencies. Thus, the relation between identifier and data is different for each vehicle, and attackers have to face an additional obstacle when implementing exploits that are supposed to affect an entire fleet of vehicles.
OS
CP adopts OSEK OS as the core of the OS. It is a real-time operating system (RTOS). Compared with traditional RTOS, it provides additional functions, such as memory protection and time protection. Time protection can assign deadline to tasks, and when a certain task fails to be completed before its deadline, the time protection mechanism will be triggered. Basically, three kinds of time protection are supported by AUTOSAR OS: the Execution Budget, which prevents timing errors by using execution time protection to guarantee a statically configured upper bound ; the Lock Budget, which prevents timing errors by using locking time protection to guarantee a statically configured upper bound ; and the Time Frame, which prevents timing erros by using inter-arrival time protection to guarantee a statically configured lower bound.
Hardware
CP is generally implemented on 8/16/32 bit MCU (Micro Controller Unit), whose hash-rate is less than 1000 DMIPS (Dhrystone Millon instructions Per Secone).
👍 CP as a deeply embedded system cannot be replaced by an AP in some functions which require strict certainty of delay and time protection.
- ECM (Engine Control Module)
- VCU (Vehicle Control Unit)
- BMS (Battery Management System)
- MCU (Microcontroller)
AUTOSAR Adaptive
**AP : Adaptive Platform
AP provides a middleware called ARA (Runtime for Adaptive Application). ARA is composed of several FCs (Functional Clusters). Because ARA provieds APIs for the POSIX OS, any OS that adheres to the POSIX standard can be used to design the functions and services.
Communication
AP defines an API named ara::com to realize the communication between applications. It set several rules about communicationm, for instance, communication between applications must use ara::com module instead of IPC (Inter Process Communication) and communication between processes in an application must uses ara::com module instead of IPC.
AP is a SOA (Service Oriented Architecture). The SOA data transmission within the AP is realized through the Ethernet, based on SOME/IP (Scalable Service Oriented Middleware over IP) protocol. SOME/IP guarantees that data will only be transmitted when receiver have demands. In other words, SOME/IP communication makes ECUs servers and clients. SOME/IP is carried out through a switch, which allows simultaneous data transmission between several pairs of nodes (Maximum bandwidth 100Mbit/s).
Safety
Some/IP is above TCP/UDP layer in OSI (Open System Interconnection Model) seven-layer model, which means the SOME/IP frame is put in TCP/UDP payload field. The data verification method of TCP/UDP can also serve SOME/IP data transmission, including CRC and ACK.
As to encryption of SOME/IP data transmission, since the SOME/IP frame is put in TCP/UDP payload, it can be taken care of by encryption of TCP/UDP or other layers below TCP/UDP.
OS
AP an run on any OS which accords with POSIX (Portable Operating System Interface) standard.
Hardware
AP hardware is generally implemented on 64bit MPU(Microprocessor Unit) (MPU == CPU), whose hash rate is larger than 2000 DMIPS.
👍 Connectivity + Vision of Autonomous Driving
=> high hash rate to support data transmission through Ethernet and complicated functions such as real-time path planning will be required.
=> AP for these tasks will b enecessary
👍 Flexibility for reuse of SW components
=> APIS for basic software components, for instance, ara::com, ara::exec, ara::rest are not divided by strict layers.
=> AP can use any POSIX OS
=> AP can support frequent updates saving efforts in coding and transplantation.
=> Some sportful applications require high bandwidth when running, which cannot be satisfied by the CP.
Integration of CP & AP
The communication within the CP is based on signal, while the communication within the AP is service-oriented, transmitting through SOME/IP.
Because of the inconsistencies in communication methods, communication between the CP and AP cannot be carried out directly. One possilbe solution for this problem is to design an extra module for converting siganl to service. Another option is to combine the traditional and adaptive platforms on the same hardware. However, both should take into account the encryption of CAN frame and SOME/IP frame.
✔ Many OEMs are using both the two platforms in car system design.
✔ AUTOSAR's classic platform is used in control system.
✔ AUTOSAR's adaptive platform is used in the entertainment field.
✔ Since there will be much more functions in future cars, a generalized guideline for applying which platform in a certain scenario is required.
✔ Making choice between CP & AP is trading off between certainty and flexibility.
- Safety & certainty -> CP
- Flexibility and Performance -> AP
📑
DOI :
10.2991/978-94-6463-036-7_249
https://www.atlantis-press.com/proceedings/icedbc-22/125983659
📑
러너블-태스크 매핑 규칙을 통한 AUTOSAR 기반 차량 시스템의 성능 최적화
