Vehicle software architecture evolves from “central gateway” approaches, where each function has its own processor (ECU) interconnected through gateways, to “domain centered” approaches beginning in 2025. Domain centricity logically group or merge multiple ECUs by requirements similarity. Domains may also be interconnected through bridging gateways. Both approaches reflect a hardware focused supplier model. Each function or even group of functions gets shipped in a physical box, connected via “global” wiring harness.
At least through “zonal” (front right, front left, roof, etc.) approaches “central computing units” are introduced, expected from 2030 on. These central computing units allow the shift to continuously updated software functionality using the domain controller as I/O handling agents. As a matter of fact the feature and development cycle-time reduces dramatically, because of less upfront
- quality assurance and
- supplier alignment
demand.
Furthermore the role of today’s tier 1 will be redefined. The sensing and actuating hardware will become commodity and the innovation will shift to software defined (only). Due to that, specific subjects will develop ubiquitous languages (syntax, meaning), sharing a (common) notation to describe
- the process model with isolated services,
- express states with informational entities and value objects,
- interact through well defined commands and,
- express the state changes with respective events.
This will be mandatory at least to isolate the (product) liability contexts. Many suppliers interact, orchestrating (not each by its own decomposing) a solution, which must be maintained over 10 to 15 years of usage. Orchestration demands a white box system rather than a black boxed system approach to handle the obligations caused by e.g., ISO 26262 (Safety) and ISO 21434 (Cyber-Security).
The today’s monolithic system, usually spanning an ACID (Atomicity, Consistency, Isolation, Durability) processing, allows either all steps complete or no steps complete – the control loop thing. Service oriented systems break down into self-encapsulated functions with well-defined and carefully managed API but without overarching ACID. The best transactional state the system can reach is called BASE (Basically Available, Soft state, Eventually consistent). The most confusing part is the “eventual consistency”. It does not mean that it may or even not get consistent, it simply tells us that we can not precisely define the exact time when a distributed function service reaches a durable state, but it will.
Under these conditions the strategic concept of the system design, on an architectural level, must be reconsidered. The “Reactive Manifesto” forms a cornerstone to react to the changed E/E architecture, distribution conditions. It demands an overall (vehicle) system that forces Responsive in terms of detecting issues quickly and deal with effectively, Resilient in terms of responsiveness and availability in the case of failed operation, Elastic in terms of reaction to changes in the input rate (increase or decrease) and Message Driven (events and commands). It is also stated as a Reactive Systems. ISO26262 denotes the same consideration with availability – in trade off to integrity.
When we take “domain driven design” (DDD) into account, the so called “aggregates” represent an entity or group of entities that is to keep in an consistent state.
- For write operations the common model (expressed via “value object” that does not change after construction) is called “event sourcing”. An event source persists the state of an entity as a sequence of state-changing events.
- For read operations the common model (expressed via “value object” that does not change after construction) is called “CQRS” (command query request segregation). A service subscribes to events and continuously constructs the query result (set).
Having the toolset for write and read BASE consistency the functional integrity could be constructed in an adaptive, case oriented manner. The commonly applied pattern is called “SAGA”. A SAGA is a sequence of local, per service, transactions (write or read consistency). Each successful or event not successful, local transaction emits an event message. Each service locally decides on (per case) positive or negative event messages e.g., performs compensation operations as a kind of rollback.
But what if the message passing can’t be guaranteed or gets unexpectedly corrupted or causes more latency and jitter issues e.g., caused by hardware failures. Two pattern become standard
- The “outbox pattern” where the consumer pulls messages (events and commands) proactively and/ or
- The “global data space pattern” where caches on the sender and on the receiver side make (optional) handshakes e.g., as provided by the DDS protocol.
Having all the aforementioned aspects in place, a ubiquenes modeling language could be introduced, like industry standards such as UML activity diagrams, Business Process Model Notation are. In case of message driven systems the Petri nets offer a well defined notation including e.g., choices, iterations, and concurrent executions.
The basic elements of Petri nets are
- states (circle) may with a max weight of markers,
- transitions (boxes and arrows) may with a max weight of markers and,
- (named) markers itself.
The Petri net transitions represent the “functional services” which are interconnected via Petri net states representing the passed “messages” (events, commands). Each logical clock tick lets the markers move through the states and allows
- timing simulation and
- timing analysis.
Or in other words
- Service t1 triggered by message p1
- Service t2 triggered by message p3
- Service t3 triggered by message p2 and p4
Both can happen in an algebraic manner via e.g., matrizes.
| t1 | t2 | t3 | |
| 0 | 0 | 0 | p1 |
| 0 | 0 | 0 | p2 |
| 0 | 0 | 0 | p3 |
| 0 | 0 | 0 | p4 |
| 0 | 0 | 0 | p5 |
After the first clock tick the matrix locks like the following.
| t1 | t2 | t3 | |
| 0 | 0 | 0 | p1 |
| 1 | 0 | 0 | p2 |
| 1 | 0 | 0 | p3 |
| 0 | 0 | 0 | p4 |
| 0 | 0 | 0 | p5 |
In other words service t1 triggers messages p2 and p3.