Author: Aimee

Autonomous driving applications have requirements for high reliability, high performance, high concurrency, and modularity. A real-time, secure, and open autonomous driving platform is one of the keys to achieving these requirements, as well as an important basis for promoting “software-defined cars.” We promote an autonomous driving system solution that realizes the software-defined car advocated by SOA.

In the vehicle development environment, SOA is a model that separates and manages discrete logical units (services) from design, development, deployment, and management. For the entire SOA development process, the most important thing is to involve the development of the vehicle characteristics, system requirements, system development, subsystem development, and sensor controller assembly development. In the SOA model, all functions are defined as independent services, and the services complete the overall logic of the business by interacting and coordinating with each other. All services are connected through a service bus or a process manager. This loosely coupled architecture enables services to interact without considering each other’s internal implementation details and deployment platforms. The fine-grain, loosely coupled, reusable and standardized service interfaces of SOA are conducive to OEMs to quickly launch new functions, flexible iteration, and support for software-defined cars. It is conducive to the participation of more parties in software development and the establishment of an automotive ecosystem with OEM as the core. In addition, the convenient cloud-based access serves accurate encapsulation and effectively ensures data security, making the vehicle no longer an information island but a node in the Internet of Things, which establishes a real vehicle-cloud channel.

It can be said that SOA perfectly solves the various challenges faced by automotive software architecture, and lays the necessary foundation for welcoming changes in the automotive industry.

Key elements of SOA vehicle-side E/E architecture design

Compared with traditional development models, the development process of SOA is still based on requirements as input, refining the requirements into comprehensive services, and finally mapping the defined services to software and hardware architecture.

As shown in the above figure, the basic workflow of the SOA-based service-oriented architecture design process includes service design, service grouping, and service mapping based on objects in the bottom design process. Services need to be designed according to the service list and service interface, and then mapped to different models based on functional logic. Finally, the service component is mapped to the software component (SWC) and the service interface is mapped to the software interface.In the design of autonomous driving architecture, SOA needs to focus on the integrity of service design and functional safety design. Based on the standard ASPICE software certification development process, the traditional development process has the system verification as the SOP node, and there will be no more software updates after operation, maintenance, and launch. However, the software development model based on SOA needs to continuously update the software after system acceptance, iterate more practical functions, and improve the performance of existing software. SOP Release needs to include all possible Basic Services, not all Services need to be developed at once.

By using the SOA architectural thinking in the autonomous driving design process, it is necessary to define service interfaces based on the SOA design principles, develop a unified hardware and software platform, and improve software reusability. In the development process, implementation principles from the system level to the component level needs to be considered, such as encapsulating functional submodules and self-containment between functions.

The entire SOA is mainly implemented in its hardware design, from modularization, single domain controller, redundant computing platform to central computing platform. They are reflected in various aspects as follows:

1) Modular segmentation: Clarify the functions of each sub-function module of autonomous driving to form a modular segmentation architecture model;

2) Domain controller unit: Merge the ECUs in the above-mentioned segmented architecture model into the central domain controller to reduce cost, weight, and power consumption, and optimize domain control ability using semiconductor and software technology innovations.

3) Redundant computing platform: SOA can directly access storage units, parallel computing carriers provide redundant and secure algorithms, and can be deployed on an open, customizable platform;

4) Central computing platform: SOA injects blade-service design strategies through network access, dynamic configuration, and seamless redundancy to achieve true autonomous driving evolution.

Regarding the application mode of SOA development, a more flexible software architecture is realized, which integrates third-party ecosystem partners’ applications and makes service expansion and updates more convenient, achieving plug-and-play software design. The ultimate goal is to decouple the relationships of multiple interacting entities, as follows:

I/O interface and computing decoupling, computing platform and regional architecture decoupling, software and hardware decoupling, vehicle-level abstraction ability, software and software decoupling, microservice-based software architecture, configuration data and code decoupling, and data-driven I/O devices.

Application considerations of security design in SOAWhen SOA reconstructs the software ecosystem, implementing functional safety becomes significantly more difficult. OEMs open up 3rd party development platforms but how do they ensure it does not affect the overall vehicle’s functional safety? Cascade failure of other existing services due to new services developed by 3rd parties and uncertainties in ASIL levels of service clients are all critical factors that restrict efficient implementation of SOA.

Regarding SOA system design, service layering should be considered, as shown in the diagram below. The design of functional safety in SOA should be considered throughout the entire layering process.

SOA system design needs to fully consider service layering. By reasonably dividing services based on security factors and determining different restriction strategies for different development subjects, efficient categorization of services based on security relevance of services should be implemented. Plus, security audit mechanisms should be strictly considered throughout the process. To achieve physical isolation, high-performance computing and secure computing partitions should be implemented.

Furthermore, SOA security mechanisms can be divided into 3-layer architecture design where dynamic monitoring during software runtime is essential.

Overall, constructing a secured analysis flow and framework for service-based operation includes several critical parts such as first, modeling an effective service process (BPMN), followed by service hazard analysis (SHA) and service failure analysis (SFA) in security analysis, and finally classifying SOA errors. In the subsequent development stage, a security guarantee system is established primarily through security cases and consistency of service layer to achieve a highly automated model integration environment.

SOA software application limitations and coping strategies

As SOA penetrates into intelligent driving, automotive software competitiveness will become its core strength, affecting all critical business indicators such as TTM, productivity, cost, and innovation. However, the software development process presents enormous challenges due to its complexity. How to effectively apply software management and core integration tools for system integration and make efficient use of multi-core performance while fulfilling functional and information security requirements, degrading software complexity, increasing software reuse, and decoupling software and hardware. By degrading complexity, it is possible to decouple software via zero-code modifications, improving system integration effectiveness. Health monitoring makes software visible and manageable.

Key Link in SOA Design – Middleware

The next generation of autonomous driving is focused on developing software architecture based on services (SOA). The most intuitive feeling for developers is that the software system is becoming larger and the number of lines of code is rapidly increasing, which is presented from sensors, controllers to actuators due to the explosive growth. The types, quantities, and specifications of hardware are significantly improved, and the complexity of electronic systems increases exponentially. The challenges that software and hardware combinations need to overcome are also greatly magnified, like doing multiplication. This greatly increases the requirements of automotive software and hardware architecture. In fact, this type of software architecture needs to solve the current system development problems while having sufficient forward-looking, compatibility, and scalability. It can effectively achieve software upgrades, hardware replacements, and module additions and replacements in the future.

The middleware of autonomous driving can adjust according to the needs, and meet the development needs of various autonomous driving processes. It can provide the environment needed for development and operation of upper-layer application software, and facilitate developers to develop and integrate autonomous driving software quickly, efficiently, and flexibly. The middleware of autonomous driving also belongs to the broad sense of the operating system, but it is different from bottom-layer systems such as QNX and Linux. Essentially, it is a set of software frameworks between upper-layer applications and bottom-layer systems. It is a platform for managing, allocating, and scheduling software and hardware resources, playing a key role in decoupling software and hardware.

Specifically, the middleware usually abstracts resources such as sensors and computing platforms, and manages algorithms, subsystems, and functions in a modular way. By providing a unified interface, developers can focus on their own business-level development without having to understand irrelevant details. The most direct benefit of this is that the development efficiency of the entire system is improved, software deployment is simplified, and overall scalability is also improved.

Regular computer operating systems manage computer hardware and software, involving processor management, storage management, device management, file management, and process management. Examples of such systems include Android, iOS, Windows, and Linux. But what about the middleware for autonomous driving? What content is involved in managing software and hardware? Autonomous driving requires the reception of different sensor signals, which are then perceived, planned, and controlled by the hardware systems of steering, throttle, and braking, in order to complete the entire process. Therefore, the middleware for autonomous driving involves ECU management, sensor management, vehicle model management, communication management, task management, data management, security management, diagnostic management, OTA management, and visualization management.

For SOA, a typical example is that different vehicle models have significant differences in configurations. We can use the middleware platform, with a plug-and-play design, to expand to different degrees according to needs during the system development process. It mainly includes the following three aspects:

• In the system design phase, effectively adapt to different sensors, domain controller chips, and vehicle-side platforms, and other hardware entities.
• In the software development phase, improve development efficiency and optimize various software algorithm modules in a timely manner, and upgrade low-level autonomous driving functions.
• In the system verification phase, perform rapid and efficient software iterations and provide different optimization solutions, without relying on any third-party components.

Summary

SOA strives to create popular vehicle models, develop iterative software to achieve effective profit growth, and ensure functional safety and information security capabilities for the entire vehicle, along with a high degree of reliability in the safety architecture system. The flexible software iteration mode can effectively shorten the development cycle, and hardware implementation can significantly expand computing power, while the sensor/actuator is plug-and-play. Ultimately, low-cost, high-quality architecture design and software development benefit both automakers and suppliers.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.