textual-notation-of-model/packages/architecture/aaos_sdv_middleware_boundary.sysml

Source

1/*2 * DE4SDV AAOS SDV middleware boundary architecture model slice.3 *4 * This package models the internal structure of the Android Automotive OS5 * Software Defined Vehicle platform as visible from DE4SDV's integration6 * perspective. It is NOT a vendored implementation of AAOS SDV — it models7 * the boundary elements that the DE4SDV adapter layer connects to.8 *9 * Source reference:10 *   https://source.android.com/docs/automotive/sdv/workstreams/core/integration-guide11 *   Page last updated: 2026-06-1712 *   License: Apache 2.0 (AOSP)13 *14 * Scope:15 *   - SDV Core boundary definition (headless Android-derived OS guest)16 *   - Core services (Orchestrator, Service Lifecycle Manager, Health Monitor,17 *     Update Manager, Connectivity Manager)18 *   - VSIDL and SDV Middleware (vehicle signal abstraction)19 *   - Communication stack (Service Discovery, RPC, Data Tunnel, SOME/IP)20 *   - Automotive services (Diagnostics, Configuration, Calibration,21 *     Vehicle Power Mode, User Profile)22 *   - Platform software boundary (GKI, virtualization, networking)23 *   - Traceability dependencies to AEBS physical realization required boundaries24 *25 * Out of scope:26 *   - AAOS SDV internal implementation (code, APEX packages, service bundles)27 *   - VM image generation, APEX signing, bootloader integration28 *   - Detailed communication protocol schemas (VSIDL definitions, SOME/IP mappings)29 *   - OEM-specific automotive service logic30 *   - SDV Media and SDV IVI (separate VMs, not in the AEBS integration path)31 *32 * Relationship to SDV platform stack:33 *   AAOS SDV is a middleware variant (AndroidSDVMiddleware) in the SDV platform34 *   stack. This model defines the internal structure of that variant. The35 *   AutowareToAAOSSDVAdapter connects to the boundary ports defined here.36 *37 * Relationship to AEBS:38 *   The AEBS physical software realization defines required boundaries39 *   (RequiredROS2ApplicationRuntimeBoundary, RequiredVehicleInterfaceBoundary,40 *   RequiredHealthSupervisorBoundary, RequiredDiagnosticFailureBridgeBoundary,41 *   RequiredEmergencyMRMHandlerBoundary). Product-level traceability showing42 *   which AAOS SDV elements satisfy these boundaries is declared in the43 *   composite product model (aebs_autoware_reference_product.sysml), not here.44 *45 * Architectural notes:46 *   SDV Core is a minimal, headless operating system derived from Android.47 *   It excludes the JVM, Java-based services, Android applications, and GUI48 *   functionality. Vehicle functionality is implemented as native distributed49 *   services. It is primarily designed to run as a VM on a hypervisor.50 *51 *   The architecture has four layers (bottom to top):52 *     1. Platform software (GKI, virtualization, storage, time sync, logging,53 *        power management, networking, security, runtime)54 *     2. Communication stack (Service Discovery, RPC, Data Tunnel, SOME/IP)55 *     3. Core services and frameworks (Orchestrator, Lifecycle Manager,56 *        Health Monitor, Update Manager, VSIDL/Middleware, Connectivity Manager)57 *     4. Automotive services (Diagnostics, Configuration, Calibration,58 *        Vehicle Power Mode, User Profile)59 *60 * Semantic basis:61 * - SysML v2 specification: part def composition, port defs, dependency62 * - DE4SDV increment workflow INC-MW-00263 * - AAOS SDV integration guide (source.android.com, 2026-06-17)64 */6566package DE4SDV_AAOSSDVMiddlewareBoundary {67  private import DE4SDV_SDVPlatformStack::*;68  private import DE4SDV_Stakeholders::*;69  private import SAF_Viewpoints::*;70  private import Views::*;7172  /* ──────────────────────────────────────────73   * SDV Core boundary74   * ────────────────────────────────────────── */7576  part def SDVCoreBoundary {77    doc /*78     * Headless, native Android-derived operating system guest that hosts79     * distributed vehicle services. Runs on a hypervisor. Excludes JVM,80     * Java services, Android applications, and GUI functionality.81     *82     * One SDV Core instance is one VM. Multiple instances may run on one83     * SoC, on different SoCs, or communicate across the vehicle network.84     * Functions are implemented as distributed services, not permanently85     * tied to a particular processor or ECU.86     */8788    /* Core services and frameworks */89    part orchestrator : OrchestratorBoundary;90    part lifecycleManager : ServiceLifecycleManagerBoundary;91    part healthMonitor : HealthMonitorBoundary;92    part updateManager : UpdateManagerBoundary;93    part connectivityManager : ConnectivityManagerBoundary;9495    /* VSIDL and SDV Middleware — span the entire platform as a common abstraction */96    part vsidlMiddleware : VSIDLMiddlewareBoundary;9798    /* Communication stack */99    part serviceDiscovery : ServiceDiscoveryBoundary;100    part rpc : SDVRPCBoundary;101    part dataTunnel : DataTunnelBoundary;102    part someIp : SomeIpInteropBoundary;103104    /* Automotive services */105    part diagnostics : AutomotiveDiagnosticsBoundary;106    part configuration : AutomotiveConfigurationBoundary;107    part calibration : AutomotiveCalibrationBoundary;108    part vehiclePowerMode : VehiclePowerModeBoundary;109    part userProfile : UserProfileBoundary;110111    /* Platform software */112    part platformSoftware : SDVPlatformSoftwareBoundary;113114    /* Boundary ports exposed to the adapter and other systems */115    port middlewarePort : MiddlewareAdapterPort;116    port vehicleSignalAccessOut : VehicleSignalAccessPort;117    port diagnosticAccessOut : DiagnosticAccessPort;118    port lifecycleCoordinationOut : LifecycleCoordinationPort;119  }120121  /* ──────────────────────────────────────────122   * Core services and frameworks123   * ────────────────────────────────────────── */124125  part def OrchestratorBoundary {126    doc /*127     * Coordinates services and dependencies across the distributed system.128     * Decides which services run where, manages inter-service dependencies,129     * and coordinates distributed system state.130     */131    port coordinationPort : ServiceCoordinationPort;132  }133134  part def ServiceLifecycleManagerBoundary {135    doc /*136     * Starts, stops, and supervises services. Manages APEX-based service137     * deployment units. Services in the same APEX package and certificate138     * may share a process; others are isolated.139     */140    port lifecyclePort : ServiceLifecyclePort;141  }142143  part def HealthMonitorBoundary {144    doc /*145     * Observes whether services are functioning correctly. Produces146     * health status that can be consumed by safety-relevant supervisors.147     */148    port healthStatusOut : HealthStatusPort;149  }150151  part def UpdateManagerBoundary {152    doc /*153     * Coordinates software changes using Android's A/B system update154     * concepts and APEX packages. Updates are treated as distributed-system155     * transactions, not single-ECU file replacements. Coordinates service156     * dependencies, safe vehicle states, shared partitions, and rollback157     * consistency across VMs.158     */159    port updateCoordinationPort : UpdateCoordinationPort;160  }161162  part def ConnectivityManagerBoundary {163    doc /*164     * Native replacement for Android's Java-based connectivity service.165     * Provides centralized network policy, interface selection, and166     * connection management. Prevents every service from independently167     * implementing network policy.168     */169    port networkPolicyPort : NetworkPolicyPort;170  }171172  part def VSIDLMiddlewareBoundary {173    doc /*174     * Vehicle Services IDL and SDV Middleware. VSIDL supplies a common175     * definition language for vehicle signals and interfaces. The middleware176     * hides differences between underlying communication technologies177     * (shared memory, vsock, Ethernet, SOME/IP). Together, they provide a178     * source of truth for vehicle data and reduce direct dependencies179     * between applications and individual protocols.180     */181    port signalAccessPort : VehicleSignalAccessPort;182    port serviceInterfacePort : ServiceInterfacePort;183  }184185  /* ──────────────────────────────────────────186   * Communication stack187   * ────────────────────────────────────────── */188189  part def ServiceDiscoveryBoundary {190    doc /*191     * Finds available services and contributes authentication and192     * authorization. Service discovery is not only a naming directory —193     * it also participates in deciding whether a client is permitted194     * to use a discovered service.195     */196    port discoveryPort : ServiceDiscoveryPort;197  }198199  part def SDVRPCBoundary {200    doc /*201     * Request-response remote procedure calls based on predefined APIs.202     * Maps onto different transports (shared memory, vsock, Ethernet)203     * depending on caller and provider location.204     * Semantic: "perform this operation and return a result."205     */206    port rpcPort : RPCPort;207  }208209  part def DataTunnelBoundary {210    doc /*211     * Publish-subscribe mechanism. A producer publishes data to a topic;212     * one or more consumers subscribe. Maps onto shared memory (inside VM),213     * vsock (between local VMs), or Ethernet (across systems).214     * Semantic: "publish this data for any interested consumers."215     */216    port topicPublishPort : DataTunnelPort;217    port topicSubscribePort : DataTunnelPort;218  }219220  part def SomeIpInteropBoundary {221    doc /*222     * SOME/IP interoperability stack for communication with non-SDV223     * automotive systems. Operates over TCP or UDP. Drawn separately224     * from the native SDV communication abstractions because it is an225     * established automotive protocol, not an SDV-native mechanism.226     */227    port someIpPort : SomeIpPort;228  }229230  /* ──────────────────────────────────────────231   * Automotive services232   * ────────────────────────────────────────── */233234  part def AutomotiveDiagnosticsBoundary {235    doc /*236     * Vehicle diagnostics service. OEM-specific UDS diagnostic libraries237     * and persistent storage rules are expected here. Provides diagnostic238     * access for external tools and internal health monitoring.239     */240    port diagnosticPort : DiagnosticAccessPort;241  }242243  part def AutomotiveConfigurationBoundary {244    doc /*245     * Vehicle configuration service. OEM-specific configuration logic246     * and persistence are expected here.247     */248  }249250  part def AutomotiveCalibrationBoundary {251    doc /*252     * Vehicle calibration service. OEM-specific calibration persistence253     * is expected here.254     */255  }256257  part def VehiclePowerModeBoundary {258    doc /*259     * Vehicle power mode service. Manages power states, suspend/resume260     * coordination, and vehicle-level power policy.261     */262  }263264  part def UserProfileBoundary {265    doc /*266     * User profile service. Manages early availability of user profiles267     * for personalization.268     */269  }270271  /* ──────────────────────────────────────────272   * Platform software273   * ────────────────────────────────────────── */274275  part def SDVPlatformSoftwareBoundary {276    doc /*277     * Lowest software layer inside SDV Core. Contains:278     * - GKI (Android Generic Kernel Image, currently 6.1 kernel)279     * - Drivers (vsock, Virtio)280     * - HALs (minimal — KeyMint for hardware-backed cryptography)281     * - Core libraries, service runtime282     * - Logging and tracing283     * - Power management284     * - Storage285     * - Time synchronization286     * - Networking (IPv4/IPv6, VLAN, TCP/UDP)287     * - Security and trust (DICE identity, attestation)288     *289     * Virtio is the preferred hardware abstraction. HALs are only used290     * where a standardized virtual device is unavailable.291     */292  }293294  /* ──────────────────────────────────────────295   * Port definitions296   * ────────────────────────────────────────── */297298  port def ServiceCoordinationPort {299    inout item coordinationRequests;300    inout item coordinationResponses;301  }302303  port def ServiceLifecyclePort {304    inout item lifecycleCommands;305    inout item lifecycleStatus;306  }307308  port def HealthStatusPort {309    out item healthStatus;310  }311312  port def UpdateCoordinationPort {313    inout item updateCommands;314    inout item updateStatus;315  }316317  port def NetworkPolicyPort {318    inout item networkPolicy;319    inout item interfaceSelection;320  }321322  port def VehicleSignalAccessPort {323    inout item vehicleSignals;324    inout item signalRequests;325  }326327  port def ServiceInterfacePort {328    inout item serviceCalls;329    inout item serviceResponses;330  }331332  port def ServiceDiscoveryPort {333    inout item discoveryQueries;334    inout item discoveryResults;335    inout item authorizationDecisions;336  }337338  port def RPCPort {339    inout item rpcRequests;340    inout item rpcResponses;341  }342343  port def DataTunnelPort {344    inout item topicData;345  }346347  port def SomeIpPort {348    inout item someIpMessages;349  }350351  port def DiagnosticAccessPort {352    inout item diagnosticRequests;353    inout item diagnosticResponses;354  }355356  port def LifecycleCoordinationPort {357    doc /* Port type for vehicle lifecycle coordination (suspend, resume, power state). */358    inout item lifecycleEvents;359    inout item powerStateCommands;360  }361362  /* ──────────────────────────────────────────363   * Communication transport model364   * ──────────────────────────────────────────365   * The middleware hides transport differences. Applications interact366   * with Middleware, Data Tunnel, or RPC without needing to know whether367   * the underlying transport is shared memory, vsock, or Ethernet.368   */369370  item def VsockTransport {371    doc /* Optimized for local host-to-VM and VM-to-VM communication. */372  }373374  item def SharedMemoryTransport {375    doc /* Efficient IPC between processes or between host and guest. */376  }377378  item def EthernetTransport {379    doc /* Transport for communication between SoCs, to vehicle network, and to legacy ECUs. Supports IPv4 and IPv6, VLAN, TCP and UDP. */380  }381382  /* ──────────────────────────────────────────383   * Traceability to AEBS physical realization384   * ──────────────────────────────────────────385   * These dependencies show which AAOS SDV elements can satisfy the386   * AEBS physical software realization's required boundaries. The387   * The adapter (AutowareToAAOSSDVAdapter from the SDV platform stack)388   * connects to this boundary through the MiddlewareAdapterPort. The389   * adapter translates Autoware ROS 2 topics to AAOS SDV VSIDL service390   * calls and Data Tunnel publications.391   *392   * Key assumption (INC-MW-001, ASM-MW-003): the AEBS emergency393  * intervention path (AEB node -> emergency intervention request ->394   * vehicle command gate -> brake actuation) does NOT go through the395   * adapter or the middleware. The adapter carries vehicle signals,396   * diagnostics, and lifecycle, not safety-critical brake commands.397   *398   * Product-level traceability (which AAOS SDV elements satisfy which399   * AEBS required boundaries) is declared in the composite product model400   * (aebs_autoware_reference_product.sysml), not here. This boundary model401   * defines what the AAOS SDV elements ARE, not what they satisfy.402   */403404  /* ──────────────────────────────────────────405   * Network topology boundary406   * ──────────────────────────────────────────407   * SDV Core instances communicate via vsock (same SoC, host-guest),408   * Ethernet (between SoCs, to vehicle network), and shared memory409   * (efficient local IPC). VLAN-capable Ethernet switch provides410   * security segmentation. Optional DMZ for externally exposed systems.411   */412413  part def VehicleNetworkBoundary {414    doc /*415     * Vehicle network boundary connecting SDV Core instances, legacy ECUs,416     * and external connectivity. Contains:417     * - VLAN-capable Ethernet switch for security segmentation418     * - Optional DMZ for less trusted or externally exposed systems419     * - Telematics control unit (TCU) with gateway and modem for420     *   controlled Internet access421     *422     * External connectivity passes through the TCU gateway, not directly423     * from every VM.424     */425    port internalNetworkPort : EthernetTransport;426    port externalGatewayPort : EthernetTransport;427  }428429  /* ──────────────────────────────────────────430   * SAF physical-domain concern and view431   * ──────────────────────────────────────────432   * Uses SAF PhysicalStructureDefinitionViewpoint (P2_PSTD) — not an433   * invented viewpoint. The AAOS SDV boundary is a physical/software434   * structure that needs to be visible for integration review.435   */436437  concern aaosSdvStructureConcern : PhysicalStructureConcern {438    doc /*439     * Reviewers need the AAOS SDV middleware internal structure visible440     * for the middleware integration increment: core services, communication441     * stack, automotive services, platform software, and network topology.442     */443    subject;444    stakeholder systemsEngineer : SystemsEngineer;445    stakeholder reviewer : OpenSourceReviewer;446  }447448  view aaosSdvBoundaryView {449    viewpoint selectedPhysicalStructureViewpoint : PhysicalStructureDefinitionViewpoint {450      frame aaosSdvStructureConcern;451    }452453    expose SDVCoreBoundary;454    expose OrchestratorBoundary;455    expose ServiceLifecycleManagerBoundary;456    expose HealthMonitorBoundary;457    expose UpdateManagerBoundary;458    expose ConnectivityManagerBoundary;459    expose VSIDLMiddlewareBoundary;460    expose ServiceDiscoveryBoundary;461    expose SDVRPCBoundary;462    expose DataTunnelBoundary;463    expose SomeIpInteropBoundary;464    expose AutomotiveDiagnosticsBoundary;465    expose AutomotiveConfigurationBoundary;466    expose AutomotiveCalibrationBoundary;467    expose VehiclePowerModeBoundary;468    expose UserProfileBoundary;469    expose SDVPlatformSoftwareBoundary;470    expose VehicleNetworkBoundary;471    render asTreeDiagram;472  }473}474