Summary:
One of the software design principles of SOA (Service Oriented Architecture) is modularity.
Preface
One of the software design principles of SOA (Service Oriented Architecture) is modularity. Modularization can improve the maintainability and code reusability of software systems, and can isolate faults. For example, an autonomous driving system can be decomposed into specific task modules, such as data collection, state estimation, and mission planning. In order to complete their respective tasks, these modules need to exchange information with each other. In modern operating systems, it is very convenient to map individual modules into independent software processes, which may reside on the same computing device or on physically separate computing devices. This makes inter-process communication a deeply researched issue, since information exchange is achieved through inter-process communication.
1. Communication middleware
In software-defined cars, cross-process or cross-core communication between applications is a problem that needs to be solved. Modular architecture provides convenience to developers, but also introduces the need for communication middleware.
Without the use of communication middleware, developers need to define the format, sender, and receiver of data themselves. However, using service/data-based publish and subscribe patterns (such as SOME/IP and DDS), developers only need to be clear about what data is needed and where the data should be delivered, without paying attention to who and how the data is sent.
Data-centric is compared to traditional message-centric. The essential difference is that the communication middleware knows what data is stored and can control how to share the data. With traditional message-centric middleware, programmers have to write code for sending messages, while with data-centric middleware, programmers only need to write code for how to share data, and then the data values can be shared directly.
Communication middleware can adopt three working modes: point-to-point, message queue and publish/subscribe . Both SOME/IP and DDS adopt the publish/subscribe mode.
In the publish/subscribe model, publishers and subscribers are related through topics, and both parties do not need to know where the other is, nor do they need to be online at the same time. This achieves multi-dimensional loose coupling of communication parties in time, space and data communication.
In addition, compared with signal-oriented CAN, DDS and SOME/IP are both service-oriented communication protocols. The difference between the two is that signal-oriented data transfer is always sent in a loop, while service-oriented communication differs in that data is exchanged in a client-server configuration only when the client requests it or when the server notifies a specific subscriber. This ensures that bandwidth is never wasted and data is communicated/exchanged only when and where it is needed. Therefore, service-oriented communication protocols can greatly reduce network load and improve communication efficiency.
In the era of software-defined cars, all callable functions in the car are regarded as services and provide different types of calling interfaces, which can be classified in the following ways:
1. API interface : Provide various function call interfaces, so that the application program can call the internal function realization function of the system. Application programs can provide and use functional services by calling related API interfaces.
2. File mode : Provide the calling capability inside the system in the form of configuration files or device files. These files can be automatically generated through configuration, contain valid configuration information, and can be read and recognized by specific programs in the operating environment to achieve specific services.
3. System native service : the operability provided by the operating system and basic class library, including the monitoring of system CPU and memory, application monitoring, system resource division, etc. In addition, basic class libraries such as C++ and boost can also be called.
4. IPC interface : Various IPC mechanisms provide the ability to call between processes in the system, including the use of inter-process communication methods such as sockets and shared memory, as well as the use of specific cross-core communication methods such as IPCF.
5. Protocol stack interface : Provide cross-platform calling capabilities through the network protocol stack, including scheduling services, interface encapsulation and protocol conversion of SOME/IP, DDS, MQTT, HTTP and other network protocols.
Although SOA (Service Oriented Architecture) has been used for a long time in the Internet field, it is a relatively new concept in the automotive industry. In the Adaptive AutoSAR framework, the communication management module includes inter-process communication and network protocol stack.
In view of the particularity of automotive application scenarios and communication requirements, many Internet SOA technologies cannot be directly applied to the automotive field. Generally speaking, all levels of the SOA communication middleware system need to meet the following requirements:
1. Communication between local services and remote services should use files defined in a unified interface description language (IDL) as contracts . IDL is a neutral interface description language that has nothing to do with specific operating systems and programming languages.
2. The underlying core functions of the SOA framework should have the following features: service discovery, message serialization, internal event/message processing and transmission functions . Applications, services and operating systems can communicate or access each other through standard communication protocols or service interfaces, especially to meet the large data throughput transmission requirements of sensing data. Typical in-vehicle communication protocols must be supported, such as SOME/IP protocol, DDS specification, etc. The service discovery function should have access control functions to prevent unauthorized users from eavesdropping and intrusion; the transmission function should have data encryption and signature functions to ensure the security of communication data.
In the future, cars will be connected to more infrastructure, and in order to connect to them, different communication protocols will need to be used.
Automotive SOA communication architecture
Protocols such as HTTP, MQTT, SOME/IP, and DDS are all used to implement communication in the SOA architecture, but they only bear different responsibilities in different scenarios. For example, the SOME/IP protocol is used for service communication between nodes in the car, while HTTP and MQTT are used for communication with the Internet module. Although they have slight differences in implementation mechanisms, they can be used interchangeably.
Protocols such as MQTT, DDS, AMQP, REST, and CoAP are all widely used, and each protocol has at least 10 different code implementations. They all claim to support real-time publish/subscribe IoT protocols. However, in the specific system architecture design, it is necessary to consider the communication requirements in the actual scenario and select an appropriate protocol. The characteristics of various protocols are shown in the table.
2. Introduction to SOME/IP
In 2011, BMW designed and proposed the SOME/IP (Scalable Service-oriented Middleware over IP) protocol. SOME/IP adopts a server-client service communication model and is highly scalable. The SOME/IP protocol is an application layer protocol that runs on top of the TCP/UDP transmission protocol (vehicle Ethernet layer 4 or above). As the middleware of Ethernet communication, it realizes the data interaction between the application layer and the IP layer, making it independent of the operating system, and compatible with AUTOSAR and non-AUTOSAR platforms. Therefore, SOME/IP can be independent of hardware platform, operating system and programming language.
SOME/IP protocol architecture
SOME/IP has the characteristics to meet the needs of vehicles, mainly including the following aspects: service-based communication, small footprint, compatible with AUTOSAR (other middleware does not have compatibility), scalability (suitable for small and large platform), and compatibility (can be applied to various operating systems used in vehicles, such as AUTOSAR, OSEK, QNX and Linux).
SOME/IP supports communication and interaction between AUTOSAR CP, AUTOSAR AP and non-AUTOSAR platforms. After BMW designed the SOME/IP protocol, it was incorporated into the official standard by AUTOSAR and was widely used in automotive Ethernet with the release of the CP specification. Therefore, it can be said that AUTOSAR CP promoted the widespread use of SOME/IP.
In the AUTOSAR architecture, the SOME/IP-SD module is located between the AUTOSAR BSW Mode Manager module (BswM) and the AUTOSAR Socket Adapter module (SoAd). The BswM module provides the connection between common mode requests and service requests, while the SoAd module handles service requests between the Ethernet stack and the SD module. By configuring the Socket Connection table in SoAd, you can receive unicast and multicast messages sent by the SD modules of other ECUs.
With the help of the high platform scalability of the SOME/IP protocol, data interaction between different platforms can be realized, and a unified SOME/IP communication mechanism is the prerequisite for communication between different platforms. In order to run SOME/IP on different software platforms and realize the SOA architecture communication mechanism on the vehicle Ethernet, SOME/IP is also introduced into the AP specification synchronously. Therefore, in the AUTOSAR system, SOME/IP communication between CP and AP is relatively easy.
In order to promote the interaction between the non-AUTOSAR software platform and the in-vehicle CP and APECU, GENIVI system also developed a set of open source vSOME/IP software source code to interact with CP/AP. However, since vSOME/IP is open source, the performance may be slightly different, so a unified specification is required for in-depth secondary development. Currently, the world's largest supplier of commercial SOME/IP products is Vector, and the open source version of vSOME/IP is maintained by the GENIVI Association.
3. Introduction to DDS
DDS (Data Distribution Service) is a distributed communication specification published by OMG (Object Management Group). Founded in 1989, OMG is an international, open, non-profit technical standards consortium driven by suppliers, end users, academic institutions and government agencies. The OMG working group is committed to formulating enterprise integration standards and developing technical standards that can provide real value to thousands of vertical industries, including unified modeling language SYSML, UML, and middleware standards CORBA, DDS, etc.
DDS was first applied to the US Navy system to solve the compatibility problem when a large number of software upgrades were performed in the complex network environment of the warship system. With the introduction of DDS by ROS2 and AUTOSAR, it has been widely used in aviation, aerospace, shipbuilding, national defense, finance, communications, automobiles and other fields.
Features of DDS:
1. Data Centricity
The most important feature of DDS is that it is data-centric, which is different from many other communication middleware. The data sharing of DDS uses Topic as the unit, and the application can determine the data type contained by Topic without having to rely on other context information. At the same time, DDS can automatically store, publish or subscribe to data in a user-defined manner, allowing applications to write or read data as if they were accessing local data.
DDS data center
2. Global Data space
The data sharing implemented by DDS can be understood as an abstract global data space. No matter which development language the application is written in or which operating system it runs on, this global data space can be accessed in the same way, just like Same as accessing local storage space. Of course, the global data space is just an abstract concept. In actual implementation, data is still stored separately in the local space of each application. When the system is running, data is transmitted or stored on demand. The data publisher only sends the data that the subscriber needs, and the subscriber only receives and stores the data currently needed by the local application.
global data space
3. Quality of service
DDS also provides highly flexible QoS (Quality of Service) policies to meet users' different needs for data sharing methods, such as reliability and fault handling. For systems with higher data security requirements, DDS also provides refined data security controls, including application identity authentication, permission control, and data encryption.
4. Dynamic Discovery
Similar to SOME/IP-SD, DDS provides a dynamic discovery mechanism for data publishers and subscribers, which means that users do not need to manually configure the addresses or other attribute information of communication nodes because they will automatically discover each other during operation and automatically Complete the relevant configuration and realize the plug-and-play function.
5. Scalable Architecture
DDS can be applied in edge computing, fog computing and cloud computing fields. In edge computing, DDS can achieve high-speed, real-time communication between devices. In the intermediate system, DDS provides robust and reliable QoS and content-aware information flow. DDS provides scalable information access and data distribution means for integrating information systems and connecting each system to the cloud.
OMG DDS has a wide range of applications, ranging from small devices to very large systems such as cloud computing systems. DDS can transmit data at ultra-high speed and manage thousands of data objects simultaneously, providing extremely high availability and security, making it very suitable for the Internet of Things. By providing a standard communication layer, DDS shields the underlying complexity and simplifies the development of distributed systems.
Scalable architecture
6. Security
DDS provides a comprehensive security protection mechanism for mission-critical industrial IoT environments, across systems and vendors, covering security needs from edge devices to the cloud.
DDS provides security mechanisms such as authentication, access control, data encryption, and data integrity to ensure the security of data distribution. These security mechanisms are implemented on a peer-to-peer architecture and do not affect the performance of real-time communications.
Currently, DDS has been introduced by multiple vehicle middleware platforms. AUTOSAR AP has completely integrated the DDS standard network binding. In addition, although the standard specification of AUTOSAR CP itself does not support DDS, DDS can also be integrated on the CP through some workarounds. The bottom layer of both ROS2 and CyberRT uses open source DDS as the most important communication mechanism. SOC chips for autonomous driving, such as Xavier and Orin, also reserve DDS interfaces. As a member of the OMG organization's board of directors, RTI led the formulation of the DDS standard and developed the DDS brand called Connext, so it is also called Connext DDS.
Compared with commercial RTI DDS, open source DDS is developed according to OMG official standards, but the source code is open, mainly including Fast DDS and Open DDS.
In the field of autonomous driving, eProsima, a company founded in Europe by members of the original core team of RTI, has launched an influential open source DDS called Fast DDS. After eProsima opens the source code of Fast DDS, users can download it directly on GitHub for free. Using Fast DDS requires paying a fee to eProsima for support.
Open DDS was developed by the ACE/TAO team of Object Computing in St. Louis and Phoenix. It has certain similarities with Fast DDS. Both are based on RTPS implementation, are data-oriented communication frameworks, and follow the same standard. Typical features of this type of framework are decentralization, support for QoS mechanisms and real-time communication, and are usually bound to serialization tools such as protobuf.
Although open source DDS competes with RTI's commercial DDS, open source DDS also has some shortcomings: the threshold for using open source DDS is relatively high. For example, RTI DDS has more than 50 service strategies, while open source DDS only has 23. Complete The performance is far less than the former; RTI's DDS has passed ASIL-D certification, while open source DDS has not yet reached this certification level.
4. Comparison between SOME/IP and DDS
SOME/IP and DDS are currently the two most commonly used types of communication middleware in domain control. They are both service-oriented communication protocols and adopt a data-centric publish/subscribe model.
However, SOME/IP and DDS also differ in many ways, the main differences are as follows:
1. The main application fields are different : SOME/IP is specially developed for the automotive field, defines a set of communication standards for the needs of the automotive field, and has been deeply involved in the automotive field for a long time; while DDS is an industrial-level strong real-time communication standard with adaptability Strong, but requires special tailoring when applied to the automotive/autonomous driving field.
2. Different flexibility and scalability : Compared with SOME/IP, DDS introduces many standard built-in features, such as content and time-based filtering, transmission-independent reliability, persistence, survivability, delay/deadline monitoring , extensible types, etc. When AUTOSAR AP works with DDS to build a communication framework, the framework is not only compatible with existing APIs and applications, but also provides important benefits in terms of reliability, performance, flexibility, and scalability.
3. The degree of coupling between the subscriber and the publisher is different : in SOME/IP, the subscriber needs to establish a network connection with the publisher before normal data transmission and ask the publisher whether to provide the required service. From this perspective, the nodes There is still some coupling. Under the DDS standard, each subscriber or publisher only needs to subscribe or publish sensor data in its own program and does not need to care about any connections. Therefore, in DDS, the subscriber and publisher sides of the service are more completely decoupled.
4. Different service strategies : Good quality of service (QoS) is the most important feature of the DDS standard compared to SOME/IP. SOME/IP has only one QoS, while RTI DDS and open source DDS provide more than 50 and 20 QoS respectively. These QoS basically cover most foreseeable intelligent driving scenarios.
5. Different application scenarios : From the perspective of application scenarios, SOME/IP is more suitable for vehicle-mounted networks and can only be used in IP-based network environments; while DDS has no special restrictions on transmission methods and can support Non-IP type networks, such as shared memory, cross-core communication, PCIe, etc. In addition, DDS also provides a complete Internet of Vehicles solution. Its unique DDS Security and DDS Web functions provide users with a one-stop "car-cloud-mobile" solution.
In commercial implementation, there is a direct competitive relationship between SOME/IP and DDS. However, due to their differences in application fields, flexibility and service strategies, OEMs can choose suitable communication middleware according to their needs, and even Use both at the same time. This is why AUTOSAR AP supports both SOME/IP and DDS.
Source | Che terminal