.

[Technical Insights] mainly shares forward-looking and in- depth technical views and industry insights, aiming to build a professional, high-quality technical sharing and exchange community for practitioners . The writers are all practitioners and thinkers who have been on the front line of the industry for a long time. Due to the limitation of perspective, there are inevitably omissions or debatable points in the article's opinions. We sincerely look forward to your pointing out and comments. Provoking thought and in-depth discussion is our original intention and our goal.

This article is written by Growth Hacking. The author explains what " characteristics " a complete and reliable automotive software platform needs to have. The full text has a total of more than 3,200 words. The following is the text:

01.

Vision Overview

A complete, powerful and reliable software platform, the goal setting is based on multi-dimensional considerations such as vehicle performance, safety and real-time, taking into account the hardware limitations of supporting multi-core heterogeneous HPC. (It must be emphasized here that security and real-time are not absolute)

In order to achieve what others don’t have, I have an excellent software platform, and there are several macro considerations that need to be made:

1. Cope with multi-domain integration, integration of applications with different complexity and threat levels.

2. Respond to the highest safety (ASIL-D) and security levels to ensure autonomous driving under various working conditions.

3. Provide an integrated, scalable tool environment that supports rapid feedback loops from system design to verification.

4. Use continuous integration (CI), continuous verification (CV) and continuous delivery (CD) methods to deal with the complexity of large-scale software.

5. Provide seamless solutions from simple microcontrollers to complex microprocessors, and the platform will be built based on open standards. It will include non-general-purpose CPUs such as graphics processing units (GPUs) and deep neural network (DNN) engines. Standards will include AUTOSAR and Robot Operating System (ROS).

6. Provide an efficient and scalable operating scheduling environment for systems built from microcontrollers and high-performance computing platforms.

02.

Related technologies

The development of software platforms requires attention to the following technologies:

1. High performance is the first indicator

2. The most advanced user experience

3. Open standards

4.Safety and Security

5. Deterministic execution and real-time performance

6. Support cross-domain heterogeneous architecture

03.

High level requirements

1. High performance

• Supports high-performance microprocessors and parallel overlays.

• Supports multi-core computing and multi-threading.

• High-performance communication is achieved through methods such as shared memory.

• Coping with hardware acceleration integration, such as special accelerators provided by GPUs.

2. User experience

• Streamlined, minimal middleware API and tool interface.

• Effectively supports system modeling and architecture.

• Fast round-trip time from idea to prototype to validation, including system evaluation, in virtual and real drives.

• Virtualization and scalability allow for the integration of CI/CD work styles like DevOps, with DevOps deployment frequency > 1 per day.

3. Open standards

• Using service-oriented architecture, dynamic deployment is possible.

• Flexible deployment to software-in-the-loop/hardware-in-the-loop simulation environments as well as target hardware.

• Multi-API support with modular and extensible architecture.

• Multiple COM stack support and COM stack extensibility.

• Must be compatible with AUTOSAR.

• Considering the emergence of ROS-based, ROS-compatible, for rapid prototyping and tool reuse.

• It must be compatible with SOMEIP and take into account DDS.

4. Functional safety

• Can reach ASIL-D safety level

• Implement FFI within a certain domain value

• Supports function-level failure execution and graceful degradation.

• Supports early verification through simulation and regression testing in a SOTIF environment.

• The Zero Work idea reduces the security-related development work of functional developers.

5. Information security

• Security abstraction layer, and security features provided by the BSW layer.

• Observe the safety requirements of surrounding systems.

• Confidentiality.

6. Determinism and real-time

• Supports event-triggered and time-triggered scheduling methods.

• Deterministic design of data domain and time domain, real-time guarantee of E2E computing chain across SOC and ECU.

04.

System overview

An overview of the software platform system modules, including all self-developed and third-party components, is shown in the figure below (abstract examples from different perspectives, you will find a lot of overlap after exposure to different architectures).

(Backend reply: AES19 , obtain high-definition pictures)

Extracting the "sameness" and "difference" in software platforms is the top priority in the requirements clarifying stage.

05.

ECU architecture reference

The ECU corresponding to the software platform is usually multi-core, as shown in the figure above.

HPC is a combination of the following components:

• Microcontrollers with ASIL levels up to ASIL-D. (The microcontroller can be the real-time security core of the SOC device.)

• Microprocessor, usually an SoC with ASIL level ASIL-B or ASIL-C. In this area, software platform solutions should focus on enhancing and improving microprocessors to adapt them to new requirements.

• Communication backbone network, high-speed communication backbone is the main communication channel between all software platform hosts on the ECU. The assumed communication backbone is:

Ethernet : The default communication backbone is assumed to be Ethernet. Complements TSN functionality to provide certainty.

PCIe : Higher bandwidth and lower latency compared to Ethernet backbone. PCIe can be used to meet these requirements, but the cost-effectiveness ratio has not yet been verified by actual cases to prove its necessity.

Microcontroller & Software Platform

On a safe island, a software platform is designed as a combination of software functional applications (also called software components, applications...) and complex device drivers. Follow the AUTOSAR method.

The microcontroller software architecture is based on AUTOSAR Classic.

Microprocessor & Software Platform

The microprocessor software architecture will be based on a POSIX-compliant operating system. This architecture will focus on improving the functionality of microprocessor systems.

The software platform will support Linux/QNX, etc.

06.

Application API

The software platform will provide a runtime environment that abstracts users from the underlying software mechanisms and hardware. Technology points to consider in this abstract context include multi-core, memory, timestamps, and determinism.

The API follows open standards, including:

• Classic AUTOSAR

• Adaptive AUTOSAR

• Deterministic subset API based on AUTOSAR adaptation.

• ROS

• High-level application API, customizable.

07.

Software Platform and Adaptive AUTOSAR

On the performance core, the software platform should provide an Adaptive AUTOSAR (hereinafter referred to as AP) compatibility layer. AP consists of the modules shown in the figure below.

The software platform can use a commercial stack and needs to extend the specifications (regarding the required functions) to cover the technical requirements at the vehicle level and support deployment on the target system.

First of all, some detailed requirements need to be put forward for the selection of AP. This is a relatively complex and core content. Only after the detailed requirements for AP, CP, OS, etc. are clear, can we clearly know the parts that need to be expanded and developed. This is also related to the legacy The architecture and software are strongly related. If it becomes empty later, consider publishing a separate issue.

Broadly speaking there will be three categories of extension modules:

• Core modules: These modules will be the focus of development.

• Third-party modules: The focus is on adaptation and integration.

• Project Specific Modules: These modules will be developed based on project specific needs.

08.

ROS

In order to support AD, many developers are now beginning to consider providing a ROS compatibility framework.

In the early stages, it is recommended that ROS support be provided in two stages:

• Phase 1: ROS 2 supports prototype.

• Phase 2: ROS 2 supports SOP. So who is the first to eat crabs?

It is necessary to take into account the existing: ROS 2 client library, ROS 2 middleware interface (DDS binding), interoperability with the ROS tool suite... There is still a lot that needs to be developed and integrated before mass production. .

09.

Hardware Acceleration

This topic is listed separately because in projects that consider the overall software platform, dependence on hardware cannot be avoided and ignored. My point is: In the era of software-defined cars, hardware is still extremely important.

For example, the intelligent driving domain software platform should strengthen its support for non-general-purpose CPUs such as GPUs and neuron processing units (NPUs). For example:

• Supports communication and scheduling of functional components executing on hardware accelerators.

• Abstract access requests from general-purpose CPUs for management.

10.

communication

One of the key points of the software platform is to provide a communication middleware that abstracts all communication-related content. This includes communication between platform software, functional applications, non-software platform ECU components, and vehicle components such as sensors or actuators. (The whole vehicle is a complete system, weakening the concept of domain. This is also strongly related to the subsequent scheduling part)

Communication middleware technology will be based on:

• signal based communication

• Service-oriented architecture (SOA), supporting service discovery and publish/subscribe paradigms.

• SOMEIP, DDS...

Software platform communication bindings/transport layer

The software platform needs to provide the following communication binding/transport layers (optional but not limited to):

• Shared memory

• Ethernet

• PCIe

• Vehicle-level communication

There are some characteristics that need to be followed:

• Unified and universal API abstraction, interface is a focus of the entire platform.

• High-performance communications.

• Secure and reliable communications.

1 shared memory

The platform needs to provide a high-performance shared memory management system.

2 Ethernet

The platform will be compatible with Ethernet network technology for in-car and out-of-car communications. At the same time, compatibility with TSN equipment is explored to provide deterministic communication based on Ethernet with reserve capabilities.

3PCIe

The platform needs to consider providing a PCIe-based communication backbone to support high bandwidth and low latency requirements. The scope of this work is limited to enabling communications over a PCIe-based backbone and providing the software stack required to connect the shared memory management layer and PCIe drivers. Reserve technology with no commercial value.

4 Vehicle-level communication

The platform offers the possibility of communication on classic buses such as CAN, CAN-FD and Ethernet via gateway components. This will enable communication between the platform ECU (HPC) and other vehicle components such as non-platform ECUs, actuators and sensors.

signal based communication

The platform will support signaling-based safety-related communications. This communication can occur between platform-hosted applications, or between platform applications and external components such as non-platform ECUs, actuators, sensors, etc.

service-oriented communication

The platform's default communication options will include service-oriented communication with a dynamic publish/subscribe mechanism. Service-oriented communications capabilities will comply with the technology inventory. Access to the underlying communication technology will be completely abstracted by the provided application API.

Service-oriented communication requires Scalable Service-Oriented Middleware Over IP (SOME/IP) and Data Distribution Service (DDS). The solution supports both SOMEIP and DDS.

The large-scale use of DDS remains to be verified.

11.

Scheduling

First, clarify a purpose. The core of scheduling is to simplify the development process and improve the reliability of platform development.

The platform will provide functional application (content) and network (path) scheduling mechanisms. These will be used to meet requirement requirements and simplify the integration and validation process of functional applications.

Basics of Scheduling

The platform scheduling basics will follow the following approach:

• Global Scheduling: A global scheduling method that allows the complete system behavior to be described

• Event-driven scheduling: The execution of task/computation chains can be triggered based on external triggers, such as sensor inputs with significant jitter.

• Data-driven scheduling

• Time-driven scheduling: Create/adjust schedules based on experience.

• Hardware engine scheduling: manages access to hardware such as accelerators.

Tool support

The platform provides a scheduling suite that enables users to create, configure and verify custom schedulers.

The scheduling suite will follow the following principles:

• User-friendliness.

• Complexity hidden from end users.

• Tight CI/CD integration, tool performance.

• Offline and online visualization.

To summarize , there are several elements of the software platform topic:

• The general architecture design and the Spec of each module have clear requirements.

• The integration of various technologies,

• Make or Buy,

• Integration work

author:

Growth Hacking SUN

Special writer for automotive electronics and software, automotive software practitioner.

Finally, Automotive Electronics and Software is a neutral, open community that sincerely welcomes heroes from all walks of life to discuss issues over wine. To submit articles, please contact WeChat: 18918250345