Follow our official account, click the “···” in the upper right corner of the homepage, set it as a star, and stay updated on the latest news in intelligent automotive electronics and software.
Source:CheduanAuthor: Jingwei HengrunThis article mainly explains what has caused the SOA trend in automotive electronics and electrical architecture, what SOA is, what benefits it brings, and how to implement SOA.Those of us in the automotive industry know that the application of new technologies or the introduction of new concepts is never without reason, often aimed at seizing the high ground of new technologies to better meet current and future automotive needs. Therefore, what has caused the SOA trend in automotive electronics and electrical architecture? What is SOA? What benefits does SOA bring? And how should SOA be implemented?
1. Why Do Cars Need SOA?
New experiences for old cars, quickly meeting market demands.We must break the static interaction model inside the car.In traditional architectures, vehicle internal controllers are connected via traditional buses to achieve communication interactions. However, the signal transmission relationships and routing information are usually static and unchangeable. If new nodes are suddenly added later, how do we modify the matrix and routing table? If we want to add a new feature to a controller after the vehicle is launched, OTA can download the software package to that controller, but how does this new “friend” obtain the necessary information from other nodes?We must establish a system architecture with flexible governance of functions.OTA is currently a good method for solving online upgrades in vehicles and continuously improving user experience. The era of one function per box is over, but… OTA is just a means. Can the vehicle’s electronic and electrical architecture and software design architecture support function updates? If the implementation of a new feature does not match or even conflicts with the vehicle’s original system architecture, driving methods, or communication methods, it is certainly infeasible. So how should we solve this?Everything is interconnected; cars need to enter the Internet of Things.In the near future, cars will occupy an important position in the Internet, the Internet of Things, and the energy Internet of Things. Therefore, cars must have openness, connectivity, even autonomy, and self-evolution. Autonomous driving, V2X, and edge computing are all visible application scenarios. How should the electronic and electrical architecture and software platform architecture respond to such demands?The existing electronic and electrical architectures and corresponding solutions find it difficult to address the challenges currently faced by vehicles, necessitating new methodologies to break the deadlock. Thus, the application of SOA in vehicles has been proposed as a solution.
2. Why Is It an Underestimation to Say SOA=SOME/IP?
First, what is SOA (Service-Oriented Architecture)?Jeff Davies, a senior SOA architect at BEA, said in his “Authoritative Guide to SOA” that SOA is not a specific technology but a guiding ideology at the architectural strategy level.OASIS (Organization for the Advancement of Structured Information Standards) defines SOA as “a paradigm that enables organizations to utilize distributed systems under different ownership controls.”Baidu Baike tells us that Service-Oriented Architecture (SOA) is a component model that splits different functional units of an application (called services) and connects them through well-defined interfaces and contracts. The interfaces are defined in a neutral way, independent of the hardware platform, operating system, and programming language that implements the services.The concept of SOA originates from the IT field, yet there is still no universally accepted definition. However, the goals and characteristics that SOA should have are clear:Purpose:To build a flexible and variable platform system.Characteristics:Loose coupling, stateless, and no dependencies between services.High cohesion and completeness within services, reusable, and flexible to reorganize.Standardized service communication.From this, we see that the focus of SOA implementation is:Standardized service communication, i.e., Service-Oriented Communication (SOC).Service division aimed at reuse and flexible reorganization, i.e., Service-Oriented Reuse-shared Design (SORS).Another invisible focus is the software implementation used to carry and adapt SOC and SORS, i.e., Service-Oriented Software Architecture (SOS).In the vehicle environment, SOME/IP basically solves SOC, but what about SORS? SOS? A SOA with only SOC lacks soul; it is incomplete and cannot achieve the goals of SOA. Therefore, if you think SOA=SOME/IP, you are truly underestimating SOA.Figure 1: SOA Schematic Diagram
3. How to Implement v-SOA?
v-SOA: vehicle SOA, that is, SOA applied to vehicles. SOA in the IT field is primarily implemented based on Ethernet, and the optimal implementation method in the vehicle environment should inherit mature technologies and implementation ideas. Fortunately, the development of in-vehicle Ethernet has accumulated several years, and a new generation of models using independently developed Ethernet technology has been successively mass-produced and sold. Implementing SOA on the shoulders of in-vehicle Ethernet is undoubtedly a good choice. Focusing on automotive electronics, we can introduce v-SOA’s implementation through SOC (Service Oriented Communication), SORS (Service-Oriented Reuse-shared Design), and SOS (Service-Oriented Software Architecture).SOC (Service Oriented Communication)SOC primarily aims to achieve communication standardization and dynamically establish communication relationships to connect information silos. The SOME/IP protocol architecture in in-vehicle Ethernet is defined as a communication middleware based on SOA principles. Those familiar with SOME/IP (Service-Oriented MiddleWare over IP) know that it defines a set of communication protocols for the in-vehicle environment, originating from AUTOSAR, which can mask system heterogeneity and achieve interoperability. Therefore, in terms of achieving SOC, we can fully accomplish this through SOME/IP (Of course, SOC can also be achieved through other transmission protocols, such as DDS, under certain conditions.).Communication behavior: SOME/IP adopts the RPC mechanism and smoothly inherits the Server-Client model. SOME/IP Service Discovery enables the Client to find the Server flexibly and reliably and subscribe to the services of interest. The Client can access services provided by the Server using Request-Response or Fire & Forget models; the Server can push the subscribed service content to the Client using Notification. Because Ethernet uses a switch-based networking method, the interaction of Ethernet nodes within the topology can be forwarded at layer 2, allowing nodes within the network to dynamically establish service provision and consumption relationships without relying on additional mechanisms and components. For example, in the subscription mechanism, a high-precision map Server provides high-precision map data (Offer Service), and the ADAS control unit wants to subscribe to lane line-related information (Subscribe EventGroup), and the high-precision map Server agrees to its subscription request (Subscribe EventGroup Ack), after which the Server begins to publish high-precision map lane line data to the ADAS control unit. In another example, in the request and response mechanism, the HU wants to obtain DVR memory information. At this time, DVR is the Server, and HU is the Client, where HU sends a request to DVR, and DVR replies based on its current state.Figure 2: SOME/IP Communication ExampleService Interface Description: A unified service interface description is an important part of cross-system communication. SOME/IP has its own serialization principles, and during system design, service interface descriptions should be uniformly designed based on the data types provided by SOME/IP, as shown in the table below, and further define addressing information.SORS (Service-Oriented Reuse-shared Design)The current overall vehicle architecture is mostly in a distributed stage (as shown in Figure 1), where all nodes capable of Ethernet communication are discretely connected to the gateway, without the concept of domain controllers, central processors, or high-performance processing nodes. Achieving SOC in this way is not a problem, but achieving SOA is challenging due to the dispersion of functions. Each node’s resources are unlikely to have been reserved for additional functions due to the initial planning of simple functions, making it difficult to achieve functional restructuring. This is one of the reasons for the emergence of the next generation of electronic and electrical architectures (e.g., Domain, Zone, as shown in Figure 2), which require new architectures to adapt to new development needs. Following the principle of logical migration, more implementation logic can be placed in high-performance, resource-rich central nodes.Figure 1: Distributed EE Architecture SchematicFigure 2: Next Generation EE Architecture SchematicSORS is implemented based on the next generation of intelligent connected architecture, primarily to complete service implementation and reflect service reusability in design, ensuring high cohesion within services, low coupling between services, and clarifying boundary concepts.So… at what stage should this be done? Who should do it?During the overall vehicle function concept design stage, the OEM’s electronic and electrical architecture department should handle this. This answer is not surprising; after all, who knows the vehicle’s functions better than the architecture department? As everyone knows, with the definition and sorting of overall vehicle function logic, the architecture will lead or participate in requirement development, function definition, function implementation, subsystem design, component design, etc. The implementation of SORS should ideally run through the entire process and will ultimately be reflected in the function implementation phase.So… how specifically should this be done?SORS has no technical standards or international norms, at most there are unverified methodologies for implementing SORS in the automotive field. Currently, there are two approaches: bottom-up and top-down.Bottom-up: Starting from the end hardware of the vehicle to organize and inventory towards the central hardware, specific hardware can provide the same or similar services. For example, a sunlight and rain sensor can provide information on light intensity and rainfall; thus, we can abstract a sunlight and rain service. As long as this hardware exists, our service will be available without any constraints. Afterwards, we can continue exploring towards the center, mining the functions and data provided by the hardware for service extraction.Top-down: Starting from the existing functions and business processes of the vehicle, for example, vehicle anti-theft certification will have various levels of anti-theft certification processes, during which many modules or algorithms will be invoked, such as randomization algorithms, anti-theft certification algorithms, etc. We can extract these algorithms to form different algorithm services. Starting from each functional business chain, we can differentiate and extract a service library, and finally reverse-engineer it, selecting service modules from the service library to restore the original functional business scenario without any loss.The design methodology of SORS has a huge impact on future function additions. In traditional development models, new functions can only be planned and deployed by the OEM, and may even require redeveloping the vehicle model, which is limited in creativity, long in cycle, and high in investment. In the SORS development model, the OEM can analyze all the software and hardware resources available in the vehicle during the platform/model development phase and provide the possibility for reuse. OEMs or authorized third parties can easily develop new functions based on the service library, quickly complete iterations, and deploy them to the vehicle through OTA technology, continuously improving user experience.SOS (Service Oriented Software Architecture)Concerning the service-oriented architecture system, the software architecture related to ECU, i.e., SOS, is also striving to adapt. The AUTOSAR Adaptive platform, abbreviated as AP, is a middleware based on service concepts and is a good example. It embodies the service-oriented architectural idea: the runtime environment (ara) is divided into Foundation and Service sections.Figure 3: AP Software Architecture SchematicFoundation:
CM (Communication Management) encompasses inter-node & inter-process communication.
EM (Execution Management) is responsible for process control execution.
REST (RESTful) reflects the connectivity of external communication.
PHM (Platform Health Management) manages the health of the system platform.
TimeSyn (Time Synchronization) time synchronization module, etc.;
Service:
SM (State Management) oversees the state transitions of all functional groups and processes running on AP.
DM (Diagnostic Management) can perform flashing and diagnostics at the AAP level.
NM (Network Management) is the network management module.
UCM (Update and Config Management) leads the overall update concepts for applications, AP self-updating, and OS updates, etc.;
AP, as middleware, needs to be used in conjunction with an operating system that supports the POSIX standard. The upper-layer applications (AAP) will be uniformly configured, managed, scheduled, and resource allocation by AP through the ARA runtime environment.So… AP is also launched by AUTOSAR; what is its relationship with CP? Why introduce the concept of AP? Can existing operating systems and architectures, such as Android, not meet the service-based implementation of SOA?AP and CP both belong to the AUTOSAR family and are like siblings. CP was launched earlier, while AP officially appeared in 2017 with the initial version of the AP specification set. As we know, CP occupies a significant proportion in the development and implementation of various vehicle ECUs, primarily addressing the development of embedded ECUs, which aligns well with the previously discussed distributed EE architecture’s demand for one box per function. Once specific functions are defined, ECU’s software and hardware development can be precisely controlled, and the modular approach of CP’s software architecture, along with the AUTOSAR OS, can fully meet the real-time requirements of specific functions for ECU operation.With the development of the next generation of architecture towards intelligent connectivity, it requires some nodes to have the ability to process massive data and execute large-scale high-frequency calculations, which inevitably requires these nodes to possess rich software and hardware resources while meeting safety requirements in the vehicle environment. In this context, CP, which is good for embedded ECUs, becomes insufficient.Of course, ordinary operating systems also cannot meet this demand; for example, Android cannot meet vehicle functional safety requirements in certain scenarios. At this time, AP takes the historical stage as an essential part of HPC (High Performance Controller) type ECUs. AP’s role is to manage subordinate OS and surrounding resources uniformly, so that all scheduling, state, and resource consumption during system operation remain within a controllable range to meet vehicle safety and determinism requirements. When resources are abundant, the options increase; for example, multi-core heterogeneous architectures can be fully utilized to handle complex scenarios, using hypervisor and other virtualization technologies to allow CP, AP, and non-AUTOSAR systems to coexist in HPC, which is also a typical implementation method, although everything starts from demand.
Follow our official account, click the “···” in the upper right corner of the homepage, set it as a star, and stay updated on the latest news in intelligent automotive electronics and software.
【Disclaimer】This article reflects the independent views of the author and does not represent the position of Wangcai Automotive Electronics. If there are issues related to content, copyright, etc., please contact Wangcai Automotive Electronics within 30 days of publication for deletion or copyright negotiation.
