The principles underlying Vehicle Service Architectures (VSA) bear significant overlap with those in cloud computing, with the primary distinctions being in terminology and domain-specific considerations.
Let’s explore some foundational concepts and considerations that shape the design and deployment of vehicle services, and how they align with cloud architecture principles.
Deployable Units
The distinction between monolithic services and microservices revolves around the number of independent deployable units. Transitioning from a monolithic architecture to a microservice-based approach often follows the “two pizza” rule: a small team of 6-10 individuals should be able to manage, develop, and test a service autonomously.
This approach minimizes organizational interdependencies and simplifies testing processes.
Rule 1: A service must be small enough to be developed by a small team and easily tested.
Service decomposition considerations
The service decomposition follows the UML diagram slicing.
Due to UML Behavioral Diagrams (e.g., activity, interaction, state, use case diagrams):
- Use Case View: Services should follow the Single Responsibility Principle (SRP), ensuring that state changes are as localized as possible.
- Activity/Interaction View: Domain-Driven Design (DDD) offers guidance by focusing on subdomains within an application’s problem space. Services should implement cohesive functions that are tightly related.
Due to UML Structural Diagrams (e.g., class, component, package, deployment diagrams):
- Component View: Services must be loosely coupled. Encapsulation through APIs ensures that internal changes do not ripple through to multiple clients.
- Deployment View: Following the Common Closure Principle (CCP), elements that change together should be packaged together to localize changes. This is critical for maintaining availability and low response times, even when employing complex patterns like CQRS (Command Query Responsibility Segregation e.g., virtual sensors which fuse multiple information to a fact) and SAGA (localizing transactions, often split a big transaction into multiple e.g., actuators).
Rule 2: A service must be cohesive, loosely coupled, and straightforward. Teams should be autonomous, handling maintainability, testability, and deployability independently.
Architectural Transition
In automotive applications, Software-defined Vehicles (SdVs) necessitate a reevaluation of deployability, often framed as update- or upgradability. Ultimately, this is a question of deployment.
Modernizing software applications, particularly for granular deployability, often involves adopting a “strangler” pattern—incrementally evolving from monolithic to microservices. A common trend is to “middleware everything,” with middleware acting as an anti-corruption layer to prevent legacy domain models from contaminating new service models.
Simultaneously, automotive domains are undergoing a “domain fusion” process, merging technologically adjacent domains. Common Patterns are:
- Cause-Effect Chain Package: Groups all elements from a driver’s request to the associated response.
- Feature Package: Groups all elements associated with a specific, identifiable characteristic.
For example, in automotive scenarios, “vehicle speed” serves as a common reference. Variants such as the following introduce significant complexity:
- “is the vehicle stationary?” or
- “are the wheels rotating?”
This parallels cloud concerns about “state.” Automotive services are inherently stateful, as they operate within a huge “control system”.
Rule 3: Transactional systems are never stateless. Always ensure observability, reliability, and consistency across the system.
Collaboration
Collaboration has become a central theme in automotive architecture, transitioning from traditional supply chains to supply networks. This shift is akin to the transition from tiered software architectures to distributed systems in IT. The orchestration of solutions now requires dynamic collaboration among varied supply objects and subjects.
Common Architecture Types:
- Event-Driven Architectures (Signals from sensors/actuators): Event Sourcing: For query handling or Transactional Outbox Pattern: For commands, often called arbitration chains/cascades in automotive. Multiple requests are jointly evaluated to determine resulting transactions (e.g., actuator changes).
- Data-Driven Architectures (Diagnosis of sensors/actuators): Shared Database: A single data source (e.g., vehicle speed) is shared across concerns or Database per Service: Distinct databases for different services, such as automated driving and motion management.
- Function-Driven Architectures (Control logic at sensors/actuators): Event Sourcing: centralized arbitration queries and Request Prioritization (CQRS or SAGA patterns) maintain logical consistency across services.
Rule 4: Define the primary subject of collaboration—event, data, or function—as it determines the orchestration approach.
Deployment
Deployment targets and frequencies are critical for service architectures, both in vehicles and in the cloud. These considerations include:
| Deployment context … | Vehicle | Cloud |
| where | – per ECU – per domain – per vehicle region | – per resource – per resource group – per region |
| how often | … | .. |
Cross-Cutting concerns
- Execution Management: Frequency (e.g., every 5 milliseconds) and runtime independence (e.g., standardization in terms of describing the containerization with aspects such as description of workload container via Docker markup or the AUTOSAR meta model which includes the whole runtime considerations which is somehow similar to the infrastructure as code (short IAC) approach).
- Configuration:Parametrization, calibration, and coding to enable/disable functions.
- Monitoring: Logging and tracing.
- Tracing records the journey of a request or transaction traversing system components.
- Logging records events, activities, or operations that occur within a stem, containing details such as the timestamp and source.
Conclusion
In conclusion, Vehicle Service Architectures (VSA), like cloud architectures, demand careful consideration of modularity, deployability, and collaboration.