AAOS SDV provides a service-oriented and data-centric architecture. Users interact with the system through the middleware client library, assisted by the Vehicle Services Interface Definition Language (VSIDL). This hides low-level infrastructure details, allowing developers to focus on high-level communication and deployment entities.
Communication models
The logical communication in SDV is defined by topics and channels.
Topics
Topics are used for data-centric communication (Publish/Subscribe). Instead of discovering specific publishers, users interact with messages published on named topics.
- Identifier: A topic is identified by a unique string.
- Data type: Messages published on a topic are defined using protobuf.
- Decoupling: Subscribers care about the message type and topic name, not the identity or location of the publisher. Multiple publishers can publish to the same topic, enabling many-to-many communication.
Channels
Channels are used for communication based on remote procedure calls (RPCs). Users call service methods on a specific channel without needing to know which server is handling the request.
- Identifier: A channel is identified by a unique name (for example,
main-control). - Service type: RPC services are identified by their fully qualified protobuf service name.
- Abstraction: The middleware handles finding the appropriate server instance for a given service and channel.
Deployment and lifecycle
The entities in this section define how software is packaged, authorized, and instantiated within the SDV environment.
Service bundle
A service bundle is a group of related business logic that serves two primary roles:
- Unit of deployment: Service bundles are deployed as part of an
SDV package, which is an APEX file and the smallest
unit of software updatability.
- Each service bundle uniquely maps to a single Linux process on an SDV VM at run time and is referred to as a service bundle instance.
- Service bundles are referenced in the SDV package manifest, which contains metadata including name and authorization policies.
- Unit of authorization: Permissions are granted to the entire service
bundle. A service bundle is authorized to:
- Publish or subscribe to specific topics (for a given message type).
- Serve or call specific channels (for a given service type).
Service bundle instance
A service bundle instance is a runtime-loaded instance of a service bundle.
- Each service bundle instance is individually tracked and identified by the SDV Lifecycle Manager (LCM).
- Service bundle instance starts are triggered by the SDV Orchestrator and started and tracked by the SDV LCM.
SDV package
An SDV package is the smallest unit of software updatability and:
- An Android Pony EXpress (APEX) file.
- Contains one or more service bundles.
- Is updated all at once, which means that all service bundles in an SDV package are updated all at once.
All code in an SDV Package comes from the same source of trust (same software publisher).
Different versions of the same SDV package can exist in different SDV VMs.
Implementation details
The following sections describe implementation details of the SDV transport layer.
Background: Service units
While developers primarily interact with topics and channels, service units remain the underlying mechanism for registration and discovery within the SDV comms stack.
A service unit represents a single endpoint, such as an RPC server or a
publisher. The middleware client library (mw::clientlib) handles the
registration and discovery of these service units under the hood.