At the core of AAOS SDV lies the Service Oriented Architecture (SOA), which provides modularity by decomposing the entire system into individual components called service bundles. These service bundles must be identified and authenticated to ensure safe and secure operation of the distributed system.
The native automotive service controller and registry (Service Discovery Agent) is a distributed system implemented within the AAOS SDV Core profile to facilitate services with identification and authentication.
A service bundle can have multiple instances in one or move VMs. Each service bundle instance receives a vehicle-unique identity from the Service Discovery Agent.
Service bundle instance identifiers
A running instance of a service bundle, which is an OS process, has two vehicle-wide unique identifiers:
- A fully qualified service bundle instance name (FQIN)
- A service bundle instance ID number (SID)
The FQIN remains the same across OS process restarts and system reboots. It is valid independently of the lifecycle state of the service bundle instance it refers to.
The SID is tied to the OS process lifetime of the service bundle instance. Therefore, every time a service bundle instance is started (or restarted), the Service Discovery Agent assigns it a different SID. It's an unpredictable, opaque value. Similar to an OS process ID, an SID becomes invalid as soon as the OS process of the service bundle instance it refers to stops. The two identifiers are not equivalent.
Because the SID is a transient identifier, in most situations where you specify a service bundle instance, use an FQIN.
Local identification
When a service bundle instance starts, it registers itself with the local Service Discovery Agent, which is the local authority that assigns service bundle identities (FQIN and SID) to OS processes. The Service Discovery Agent recognizes a local service bundle instance from its Linux user ID (UID).
Remote identification
A service bundle instance can create an asymmetric key pair and associate its public key with its FQIN in an X.509 certificate. It does so by sending a certificate signing request to its local Service Discovery Agent, which is the certificate authority for all service bundle instances in an SDV VM.
Along with the X.509 certificate signed by the local Service Discovery Agent, a service bundle instance also receives a list of the root public keys of all Service Discovery Agents in the vehicle.
With this information, two service bundle instances located in different SDV VMs can identify and authenticate each other to establish secure TLS connections.