When we talk about SDV OS we often perceive a middleware, offering a set of standardized capabilities. In automotive we may first thing about service oriented architecture (SOA) and Adaptive Autosar (ARA), providing API definitions for e.g.,
- Update Management (ARA::UCM)
- Time Management (ARA:TSYNC)
- Diagnostic (ARA:DIAG)
- Service Oriented Communication (ARA::COM)
- Persistency (ARA::PER)
A common question is “do we really need all of this?”. Usual answer is “it depends!”.
Let us try to find a more formalized answer. When we talk about SOA, we talk about distributing software components with a well defined API. If the domain is generically addressed it remains the question of “ho do the software components” interact. This directly lead to the question zero: What is the used communication model, with related protocol, with …. IMHO Autosar Adaptive (ARA) derives its communication model from SOME/IP, adapted to different other such as DDS or Inter-Process-Communication (IPC) via i.e. shared memory (SHM). We can conclude that today’s approaches often start with publish-subscribe (aka messaging, loosely coupled) approaches and later on demand for RPC, Shared State, File etc. integration styles. Also compare this resource here (external link). For the moment I do see DDS as the most promising approach (also read the following external resources link 1, link 2).
Next appearing question comes with clock synchronization. Time is one of the key pillars for reliable, distributed systems. Often clock synchronization (“the time”) is mixed up with the Time Sensitive Networking (TSN, external resource link) capabilities, defined in the IEEE 802.1 TSN Task Group – it it complementary but not equal. TSN is a “tool set” which includes high precision time synchronization i.e. via the PTP protocol. TSN capabilities on layer 2 (data link layer , external resource) of the ISO/OSI network stack are
- IEEE 1588-2008-Precision Time Protocol and IEEE 802.1AS-2011 – Time
- IEEE 802.1Qav – Credit Based Shaper and IEEE 802.1Qav – Time-Aware Scheduler
DDS happens on layer 5&6 (presentation & application layer, external link). Due to that the capabilities and related QoS capabilities are complementary. A whitepaper on this can be found here (external link).
Next important questions appears if we ask for the required POSIX compliance and real-time operating system (RTOS) demands. IMHO modern general purpose operating systems (GPOS) such as Linux demanded to have a rich API and toolset available. The POSIX compliance is described by so called layouts, in short PSE:
Also compare how i.e. Zephyr RTOS describes its POSIX compatibility: https://docs.zephyrproject.org/latest/services/portability/posix.html
In dependency to that some ARA capabilities such as ARA::PER is just a matter of requirement. ARA strives to comply to PSE 51, what requires that the e.g., file system access for persisting data demand its own API definition. IMHO a not so well considered approach. Why are we not going with existing and well developed definitions (question mark). Sure for some cases we require specific I/O handling i.e. ARA::DIAG, ARA::UCM or record-replay. IMHO a definition beyond APIs is required e.g., bag formats as SQLLite3 (ROS2) or the new upcoming de-facto standard MCAP. MCAP directly allows to serialize DDS message down into files, accessible by many tool provider.