eSOL has been a member of the AUTOSAR Consortium since 2016 and, as a Premium Member, the company is heavily involved in the latest standardization activities, including specification development.
To name just one example: eSOL is the owner of AUTOSAR’s "Explanations of Adaptive Platform Design" document. Therefore, eSOL is in an ideal position to explain the differences between the two AUTOSAR platforms here; while the first AUTOSAR (Automotive Open System Architecture) platform continues to be maintained under the label "AUTOSAR Classic Platform", a new "AUTOSAR Adaptive Platform" is emerging in parallel.
Content
- AUTOSAR history
- Requirements for next generation vehicles and in-vehicle software
- The difference between AUTOSAR Classic Platform and AUTOSAR Adaptive Platform
- eSOL products for AUTOSAR Adaptive Platform
1. AUTOSAR history
In recent years, software development has become increasingly important in automotive development, and it is expected that the requirements will continue to increase in the future.
To meet the challenges of vehicle software development, which is becoming increasingly large and complex, AUTOSAR, a partnership to develop standard specifications for vehicle software platforms, was established. The goal was to reuse previous software assets, automate the development process, and create standards essential to this reuse and automation.
In addition to the Classic Platform (CP), which is a standard based on a static operating system (OSEK/VDX OS based), AUTOSAR also released the Adaptive Platform (AP) in 2017 based on a dynamic operating system (POSIX based). AP is not a higher version of CP to replace CP; both will coexist and cooperate in the right places respectively to form an integrated system.
2. Requirements for next generation vehicles and in-vehicle software
The motivation for the Adaptive Platform is based on new requirements in next generation vehicles and their in-vehicle software development platforms. The acronym C.A.S.E. summarizes these new requirements:
- Connectivity
- Autonomous / automated driving
- Mobility sharing services
- Electric Vehicle
Tomorrow’s car is being reinvented and redefined around these four key words. The automotive industry environment is changing dramatically in the process, and new solutions are needed to solve new software problems.
There are four key challenges for the next in-vehicle software platforms in this process:
- New E/E architecture
- Embedded high-performance computing (HPC)
- Safe and secure connection
- Shorter time to market
To meet these requirements, which cannot be realized with the conventional Classic Platform based on static operating systems, AP has been introduced based on dynamic operating systems that allow a high degree of coordination between different domains and dynamic expansion of functions as required for automated driving.
3. The difference between AUTOSAR Classic Platform and AUTOSAR Adaptive Platform
CP is based on the static OSEK/VDX operating system and is intended for ECUs that require real-time performance but do not require large computing power.
AP, on the other hand, is based on the dynamic POSIX operating system and is optimized for greater computing power, such as for automated driving.
The following table summarizes the differences between CP and AP:
| Classic Platform (CP) | Adaptive Platform (AP) | |
| Operating system to use | OSEK/VDX OS based | POSIX-based (Minimal Realtime System Profile in IEEE Std 1003.13-2003: PSE51) |
| Language of development | C | C++ |
| Application execution (App.) | Code is executed directly from ROM | App. is loaded from ROM etc. into RAM and then executed |
| Memory requirements | ・All operations are performed in a single address space ・MMU is rearly used, MPU is used only when needed, mainly for security reasons |
・Each application is executed in its own (virtual) address space ・Use of the MMU is assumed |
| Commissioning time | Short | Medium |
| Real-time requirements | High | Medium to high |
| Available computing power | Low | High |
| Process execution scheduling procedures | (Essentially) fixed task scheduling | Scheduling changes dynamically as the services provided and their requirments change |
| Communication | ・Focus on relatively slow, signal-oriented, connectionless communication (CAN/CAN FD, LIN, FlexRay between ECUs) ・SOME/IP support allows some communication with AP-based ECU groups |
・Service-oriented communication (e.g. SOME/IP protocol between ECUs) ・In some cases, signal-oriented communication is also supported, enabling communication with CP-based ECU groups |
| Assumed safety requirements | Up to ASIL D | ASIL B to D, depending on the requirments |
| Use of OTS/OSS | Communication is mainly in the form of Simulink models and the code/objects generated from them | Yes many, however, there are some concerns about its use as a black box, and opinions are devided |
| Results of standardization | Standard documents | Standard documents and codes |
| Degree of stability of standards, markets, etc. | High | Low |
| Intended use | Conventional control systems ECUs | Additional ECUs for gateways/domain controllers used for AD/ADAS |
CP is intended for ECUs running at a few dozen MHz, while AP requires high computing power. So, while CP is for conventional ECUs, AP is for additional ECUs, such as gateways and domain controllers for automated driving and integrated control.
In addition, AP has the following features:
C++
The ability to develop in C++ makes it possible to create designs (*) that are difficult to implement in C, using assets already created in C. In doing so, the use of an object-oriented design clarifies the role of each module and reduces the degree of coupling between modules.
Security and protection
Distributed computing based on a "service-oriented architecture" (SOA) increases the independence of individual modules and prevents unintended interference. The use of unique C++ coding guidelines provides the necessary security and reliability at the implementation level.
Planned dynamics
The architecture already considers continuous software updates, which is supported by dynamic management of application and communication resources. This reduces software validation and integration efforts by localizing the impact of changes due to updates.Appropriate scheduling and resource management using the execution manifest to reduce the risk of security threats. The execution manifest is created for each adaptive application and contains information to automate the configuration required for it to function.
4. eSOL products for AUTOSAR Adaptive Platform
Understanding and implementing AUTOSAR is becoming increasingly important for the future of automotive software development. eSOL offers its safe RTOS platform eMCOS for use with AUTOSAR AP. eMCOS POSIX is based on modern multikernel architecture (aka "distributed microkernel") and thus offers superior performance compared to traditional microkernel RTOSes. In addition, eMCOS POSIX provides a virtualization option to develop systems with mixed criticality. All eMCOS releases are tested during development for use with the latest AP releases.
S.A
Marketing team
