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

Source

1/*2 * DE4SDV SDV platform stack architecture model slice.3 *4 * This package models the layered architecture of a software-defined vehicle5 * as a product-line variation structure. It defines the stack layers, their6 * boundary interfaces, and the variation points where configurable choices7 * select between open-source realizations.8 *9 * Scope of this slice:10 *   - Stack layer definitions (vehicle applications, middleware, OS, hypervisor, hardware)11 *   - Boundary interface definitions between adjacent layers12 *   - Variation points with candidate variant realizations, inlined13 *     as structural variation points on the stack's layer parts14 *   - Compatibility constraints between layers15 *16 * Out of scope for this slice:17 *   - Internal architecture of any specific OSS project (Autoware, S-CORE, etc.)18 *   - Allocation of functional responsibilities to execution platforms19 *   - Timing/safety/security property binding to specific stacks20 *   - Compliance or type-approval claims21 *   - Physical/mechanical domain modeling22 *23 * Conventions:24 *   - Layer definitions use `part def` with doc annotations25 *   - Boundary interfaces use `interface def` with directional ports26 *   - Variability uses native SysML v2 `variation` / `variant` notation27 *   - Candidate realizations are `part def` specializations of layer defs,28 *     marked as candidates with doc-only provenance (no compliance claim)29 *   - Compatibility constraints use `constraint def`30 *   - File uses a flat top-level package name (DE4SDV_SDVPlatformStack)31 *     to avoid cross-file sibling-package import issues in SysIDE32 */3334package DE4SDV_SDVPlatformStack {35  private import SAF_Viewpoints::*;36  private import DE4SDV_Stakeholders::*;37  private import Views::*;383940  /* ──────────────────────────────────────────41   * Stack layer definitions42   * ──────────────────────────────────────────43   * Each layer is an abstract part def. Concrete realizations44   * specialize these defs and appear as variants in the variation45   * section below.46   */4748  part def SDVPlatformStack {49    doc /*50     * Complete layered architecture of a software-defined vehicle51     * computing platform. A configured member product selects one52     * realization from each variation, subject to compatibility53     * constraints.54     */5556    variation part vehicleApplication : VehicleApplicationLayer {57      /* ADAS domain candidates shown; other domain applications (body,58       * chassis, telematics, IVI) to be added in domain-specific increments. */59      variant part autoware : AutowareStack;60      variant part openpilot : OpenpilotStack;61      variant part apollo : ApolloStack;62    }6364    variation part middleware : MiddlewareLayer {65      variant part eclipseSCORE : EclipseSCORE;66      variant part androidSDV : AndroidSDVMiddleware;67      variant part autosarAdaptive : AUTOSARAdaptive;68      variant part none[0]; /* single-domain architecture, no vehicle-level middleware */69    }7071    variation part applicationMiddlewareAdapter : ApplicationMiddlewareAdapterLayer {72      variant part autowareToSCORE : AutowareToSCOREAdapter;73      variant part autowareToAAOSSDV : AutowareToAAOSSDVAdapter;74      variant part autowareToAUTOSAR : AutowareToAUTOSARAdapter;75      variant part openpilotToSCORE : OpenpilotToSCOREAdapter;76      variant part apolloToSCORE : ApolloToSCOREAdapter;77      variant part none[0]; /* no adapter when no vehicle-level middleware */78    }7980    variation part osPlatform : OSPlatformLayer {81      variant part linux : LinuxPlatform;82      variant part android : AndroidHLOS;83      variant part qnx : QNXPlatform;84    }8586    variation part hypervisor : HypervisorLayer {87      variant part qvm : QNXQVM;88      variant part acrn : ACRNHypervisor;89      variant part kvm : KVMHypervisor;90      variant part none[0]; /* single-domain architecture, no hypervisor */91    }9293    part hardware : HardwareLayer;9495    /*96     * Inter-layer boundary interfaces.97     * Each boundary is a bidirectional interface between adjacent layers.98     * The contracts at these boundaries are what DE4SDV models; the99     * concrete realizations either conform or don't.100     */101    interface applicationMiddlewareBoundary : ApplicationAdapterInterface102      connect vehicleApplication.middlewarePort to applicationMiddlewareAdapter.applicationPort;103104    interface adapterMiddlewareBoundary : AdapterMiddlewareInterface105      connect applicationMiddlewareAdapter.middlewarePort to middleware.applicationPort;106107    interface middlewareOSBoundary : MiddlewareOSInterface108      connect middleware.osPort to osPlatform.middlewarePort;109110    interface osHypervisorBoundary : OSHypervisorInterface111      connect osPlatform.hypervisorPort to hypervisor.guestPort;112113    interface hypervisorHardwareBoundary : HardwareHypervisorInterface114      connect hypervisor.hypervisorPort to hardware.hypervisorPort;115  }116117  /* ──────────────────────────────────────────118   * Layer abstractions119   * ──────────────────────────────────────────120   * Each layer def declares the boundary ports it exposes to adjacent121   * layers. Internal structure is deliberately not modeled.122   */123124  part def VehicleApplicationLayer {125    doc /*126     * Vehicle domain-specific application layer.127     * Provides domain-specific applications such as ADAS (perception,128     * planning, control), body, chassis, powertrain, IVI, telematics,129     * connectivity, and diagnostics.130     *131     * Candidate realizations shown: Autoware, Openpilot, Apollo Auto (ADAS domain).132     * Domain-specific application stacks typically ship their own internal middleware133     * (ROS 2, Cyber RT, custom) for ADAS-internal communication.134     * The boundary port to the vehicle-level middleware handles135     * vehicle signal access, diagnostics, and lifecycle coordination.136     */137138    port middlewarePort : ApplicationAdapterPort;139  }140141  part def ApplicationMiddlewareAdapterLayer {142    doc /*143     * Adapter between domain-specific application stacks and vehicle-level middleware.144     * Each application stack ships its own internal communication (e.g. Autoware uses ROS 2/DDS);145     * the vehicle-level middleware uses a different communication paradigm (e.g. S-CORE uses LoLa,146     * Android SDV uses VSIDL service bundles, AUTOSAR uses SOME/IP). The adapter translates147     * between these.148     */149150    port applicationPort : ApplicationAdapterPort;151    port middlewarePort : MiddlewareAdapterPort;152  }153154  part def MiddlewareLayer {155    doc /*156     * Vehicle-level middleware / runtime platform.157     * Provides IPC, lifecycle management, service discovery,158     * diagnostics, persistency, and timing orchestration for159     * vehicle applications running on the same compute domain.160     *161     * Candidate realizations: Eclipse S-CORE, Android SDV,162     * AUTOSAR Adaptive (ARA).163     *164     * Note: AGL is a full platform (OS + IVI + app framework),165     * not a middleware layer. It is modeled at the OS platform layer.166     */167168    port applicationPort : MiddlewareAdapterPort;169    port osPort : MiddlewareOSPort;170  }171172  part def OSPlatformLayer {173    doc /*174     * Operating system / platform layer.175     * Provides scheduling, memory management, driver support,176     * and POSIX or Android framework services.177     *178     * Candidate realizations: Linux (AGL, generic), Android HLOS,179     * QNX, AUTOSAR Adaptive platform.180     */181182    port middlewarePort : MiddlewareOSPort;183    port hypervisorPort : OSHypervisorPort;184  }185186  part def HypervisorLayer {187    doc /*188     * Virtualization / hypervisor layer.189     * Provides partition isolation for mixed-criticality systems190     * where multiple OS domains share the same SoC.191     *192     * Optional: single-domain architectures do not use a hypervisor.193     * The variation below includes a "none" variant for this case.194     *195     * Candidate realizations: QNX QVM, ACRN, KVM (Linux).196     */197198    port guestPort : OSHypervisorPort;199    port hypervisorPort : HardwareHypervisorPort;200  }201202  part def HardwareLayer {203    doc /*204     * Physical compute hardware: SoC, MCU, sensors, actuators.205     * DE4SDV does not model physics, thermodynamics, or mechanics206     * at this layer — only the compute platform boundary that207     * the software stack executes on.208     *209     * Candidate realizations: Qualcomm, NVIDIA, Renesas, NXP, etc.210     * This layer is deliberately abstract; concrete hardware modeling211     * is out of scope for the SDV platform stack slice.212     */213214    port hypervisorPort : HardwareHypervisorPort;215  }216217  /* ──────────────────────────────────────────218   * Boundary interface definitions219   * ──────────────────────────────────────────220   * Each interface def declares the contract surface between221   * two adjacent layers. These are abstract contracts; specific222   * timing, safety, and security properties will be added in223   * the reference-contract-packages increment.224   */225226  port def ApplicationMiddlewarePort {227    doc /*228     * Port type for the Vehicle Application ↔ Middleware boundary.229     * Carries vehicle signal access, diagnostics, lifecycle230     * coordination, and service-binding interactions.231     */232    inout item vehicleSignals;233    inout item diagnosticCommands;234    inout item lifecycleEvents;235    inout item serviceRequests;236  }237238  interface def ApplicationMiddlewareInterface {239    doc /*240     * Contract between the vehicle application layer and the241     * vehicle-level middleware. The application stack expects signal242     * access, timing-aware scheduling, and fault containment243     * from the middleware. The middleware expects the application244     * stack to register as a managed application with defined245     * lifecycle hooks.246     */247    end adasSide : ApplicationMiddlewarePort;248    end middlewareSide : ApplicationMiddlewarePort;249  }250251  port def ApplicationAdapterPort {252    doc /*253     * Port type for the Vehicle Application ↔ Adapter boundary.254     * Carries application-native communication (e.g. ROS 2 topics for Autoware).255     */256    inout item applicationNativeMessages;257    inout item applicationLifecycleEvents;258  }259260  port def MiddlewareAdapterPort {261    doc /*262     * Port type for the Adapter ↔ Middleware boundary.263     * Carries middleware-native communication (e.g. LoLa for S-CORE, VSIDL for Android SDV, SOME/IP for AUTOSAR).264     */265    inout item middlewareNativeMessages;266    inout item middlewareLifecycleEvents;267  }268269  interface def ApplicationAdapterInterface {270    doc /*271     * Contract between the vehicle application layer and the adapter. The application stack publishes/subscribes in its native protocol; the adapter translates.272     */273    end applicationSide : ApplicationAdapterPort;274    end adapterSide : ApplicationAdapterPort;275  }276277  interface def AdapterMiddlewareInterface {278    doc /*279     * Contract between the adapter and the vehicle-level middleware. The adapter translates application-native messages to middleware-native service calls/signals.280     */281    end adapterSide : MiddlewareAdapterPort;282    end middlewareSide : MiddlewareAdapterPort;283  }284285  port def MiddlewareOSPort {286    doc /*287     * Port type for the Middleware ↔ OS boundary.288     * Carries scheduling requests, memory allocation,289     * power management, and watchdog/timeout interactions.290     */291    inout item schedulingRequests;292    inout item memoryAllocation;293    inout item powerManagement;294    inout item watchdogSignals;295  }296297  interface def MiddlewareOSInterface {298    doc /*299     * Contract between the middleware runtime and the300     * operating system. The middleware expects preemptive301     * scheduling, memory isolation, deterministic timing302     * support, and driver access from the OS. The OS expects303     * the middleware to respect resource limits and304     * scheduling policies.305     */306    end middlewareSide : MiddlewareOSPort;307    end osSide : MiddlewareOSPort;308  }309310  port def OSHypervisorPort {311    doc /*312     * Port type for the OS ↔ Hypervisor boundary.313     * Carries partition configuration, inter-VM communication,314     * resource allocation, and isolation properties.315     */316    inout item partitionConfig;317    inout item interVMCommunication;318    inout item resourceAllocation;319  }320321  interface def OSHypervisorInterface {322    doc /*323     * Contract between an OS domain and the hypervisor.324     * The OS expects CPU/memory/I/O allocation, partition325     * isolation, and inter-VM communication channels from326     * the hypervisor. The hypervisor expects the OS to327     * operate within its allocated partition.328     */329    end osSide : OSHypervisorPort;330    end hypervisorSide : OSHypervisorPort;331  }332333  port def HardwareHypervisorPort {334    doc /*335     * Port type for the Hypervisor ↔ Hardware boundary.336     * Carries hardware resource access, interrupt routing,337     * and platform initialization.338     */339    inout item hardwareResources;340    inout item interruptRouting;341  }342343  interface def HardwareHypervisorInterface {344    doc /*345     * Contract between the hypervisor and the physical346     * compute hardware. The hypervisor expects access to347     * CPU cores, memory regions, interrupt controllers,348     * and I/O devices. This is the lowest software-visible349     * boundary; below it is hardware only.350     */351    end hypervisorSide : HardwareHypervisorPort;352    end hardwareSide : HardwareHypervisorPort;353  }354355  /* ──────────────────────────────────────────356   * Candidate realizations — vehicle application layer (ADAS domain shown)357   * ────────────────────────────────────────── */358  part def AutowareStack :> VehicleApplicationLayer {359    doc /*360     * Autoware (Autoware Foundation).361     * Open-source autonomous driving stack based on ROS 2.362     * License: Apache 2.0.363     * Status: candidate realization — no assumption of364     * conformance to DE4SDV boundary contracts without365     * evidence.366     */367  }368369  part def OpenpilotStack :> VehicleApplicationLayer {370    doc /*371     * Openpilot (comma.ai).372     * Open-source driver assistance system (L2).373     * Ships its own internal middleware; the boundary port374     * captures vehicle-level integration only.375     * License: MIT / comma.ai custom.376     * Status: candidate realization.377     */378  }379380  part def ApolloStack :> VehicleApplicationLayer {381    doc /*382     * Apollo Auto (Baidu).383     * Open-source autonomous driving stack using Cyber RT384     * as internal middleware.385     * License: Apache 2.0.386     * Status: candidate realization.387     */388  }389390  /* ──────────────────────────────────────────391   * Candidate realizations — application-middleware adapter layer392   * ────────────────────────────────────────── */393  part def AutowareToSCOREAdapter :> ApplicationMiddlewareAdapterLayer {394    doc /*395     * Adapts Autoware ROS 2 topics to Eclipse S-CORE LoLa IPC.396     */397  }398399  part def AutowareToAAOSSDVAdapter :> ApplicationMiddlewareAdapterLayer {400    doc /*401     * Candidate boundary between Autoware ROS 2 and AAOS SDV service402     * interfaces. A configured product may select a direct VSIDL-to-ROS 2403     * realization or a separately justified brokered realization. This404     * definition does not claim generated bindings, transport, deployment,405     * runtime behavior, or interoperability evidence.406     */407  }408409  part def AutowareToAUTOSARAdapter :> ApplicationMiddlewareAdapterLayer {410    doc /*411     * Adapts Autoware ROS 2 topics to AUTOSAR Adaptive SOME/IP services.412     */413  }414415  part def OpenpilotToSCOREAdapter :> ApplicationMiddlewareAdapterLayer {416    doc /*417     * Adapts Openpilot internal communication to S-CORE LoLa.418     */419  }420421  part def ApolloToSCOREAdapter :> ApplicationMiddlewareAdapterLayer {422    doc /*423     * Adapts Apollo Cyber RT to S-CORE LoLa.424     */425  }426427  /* ──────────────────────────────────────────428   * Candidate realizations — Middleware layer429   * ────────────────────────────────────────── */430  part def EclipseSCORE :> MiddlewareLayer {431    doc /*432     * Eclipse S-CORE (Safe Open Vehicle Core).433     * Open-source automotive middleware (C++ / Rust).434     * Modules: communication (LoLa), orchestration, persistency,435     * time, lifecycle, diagnostics, baselibs.436     * Targets: Linux, QNX. Not designed for Android HLOS.437     * License: Apache 2.0.438     * Status: candidate realization. S-CORE maintainers have439     * not been engaged on SysML v2 model integration.440     */441  }442443  part def AndroidSDVMiddleware :> MiddlewareLayer {444    doc /*445     * Android SDV (Google / AOSP).446     * Headless, native Android-derived platform for distributed vehicle447     * services. Runs as a VM on a hypervisor. Excludes JVM, Java services,448     * Android applications, and GUI functionality.449     *450     * Internal structure modeled in:451     *   textual-notation-of-model/packages/architecture/aaos_sdv_middleware_boundary.sysml452     * (DE4SDV_AAOSSDVMiddlewareBoundary package).453     *454     * Key elements: Orchestrator, Service Lifecycle Manager, Health Monitor,455     * Update Manager, VSIDL/Middleware, Service Discovery, RPC, Data Tunnel,456     * SOME/IP interoperability, Automotive Services (Diagnostics, Configuration,457     * Calibration, Vehicle Power Mode, User Profile).458     *459     * Runs on Android HLOS, Linux, and as QNX QVM guest.460     * License: Apache 2.0 (AOSP).461     * Status: candidate realization. Upstream AAOS SDV maintainers have462     * not been engaged on DE4SDV model integration (GAP-MW-005).463     */464  }465466  part def AUTOSARAdaptive :> MiddlewareLayer {467    doc /*468     * AUTOSAR Adaptive Platform (ARA).469     * Automotive middleware standard with functional safety470     * focus (ASIL).471     * This entry is a placeholder for the standard interface472     * contract, not a specific open-source implementation.473     * License: varies by implementation.474     * Status: candidate realization — interface contract only.475     */476  }477478  /* ──────────────────────────────────────────479   * Candidate realizations — OS platform layer480   * ────────────────────────────────────────── */481  part def LinuxPlatform :> OSPlatformLayer {482    doc /*483     * Generic Linux platform (POSIX, preemptive scheduling).484     * Includes AGL and custom Linux distributions.485     * License: GPL (kernel) + Apache 2.0 / varies (user space).486     * Status: candidate realization.487     */488  }489490  part def AndroidHLOS :> OSPlatformLayer {491    doc /*492     * Android High-Level OS (Google / AOSP).493     * Linux kernel (GKI) + Android framework.494     * License: Apache 2.0 (AOSP) + GPL (kernel).495     * Status: candidate realization.496     */497  }498499  part def QNXPlatform :> OSPlatformLayer {500    doc /*501     * QNX Neutrino RTOS (BlackBerry / QNX).502     * Real-time POSIX OS, ASIL-D certified.503     * License: commercial (not open-source).504     * Status: candidate realization — included for mixed-criticality505     * architectures; acknowledged as non-OSS.506     */507  }508509  /* ──────────────────────────────────────────510   * Candidate realizations — Hypervisor layer511   * ────────────────────────────────────────── */512  part def QNXQVM :> HypervisorLayer {513    doc /*514     * QNX Virtual Machine (QVM) hypervisor.515     * Host for mixed-criticality: QNX + Linux + Android guests.516     * License: commercial (QNX).517     * Status: candidate realization.518     */519  }520521  part def ACRNHypervisor :> HypervisorLayer {522    doc /*523     * ACRN (Project ACRN, Linux Foundation).524     * Open-source hypervisor for automotive and IoT.525     * Supports Linux and Android guests.526     * License: BSD-2-Clause.527     * Status: candidate realization.528     */529  }530531  part def KVMHypervisor :> HypervisorLayer {532    doc /*533     * KVM (Kernel-based Virtual Machine, Linux).534     * Open-source virtualization in the Linux kernel.535     * License: GPL / LGPL.536     * Status: candidate realization.537     */538  }539540  /* ──────────────────────────────────────────541   * Compatibility constraints542   * ──────────────────────────────────────────543   * These constraints encode which combinations of layer544   * realizations are architecturally valid. They are the545   * product-line decision rules that enable trade-off analysis.546   *547   * Constraint bodies are documented as doc comments in this548   * increment. Future increments may formalize them as549   * require constraint bodies when validation confirms the550   * SysML v2 constraint expression syntax.551   */552553  constraint def MiddlewareOSCompatibility {554    doc /*555     * Middleware ↔ OS compatibility.556     *557     * Valid combinations:558     *   Eclipse S-CORE  ↔ Linux, QNX (not Android HLOS)559     *   Android SDV     ↔ Linux, Android HLOS, QNX (as QVM guest)560     *   AUTOSAR Adaptive ↔ Linux, QNX561     *562     * Invalid:563     *   Eclipse S-CORE ↔ Android HLOS (architecturally incompatible)564     */565  }566567  constraint def HypervisorOSCompatibility {568    doc /*569     * Hypervisor ↔ OS compatibility.570     *571     * Valid combinations:572     *   QNX QVM  ↔ QNX (native), Linux, Android, AGL (all as guests)573     *   ACRN     ↔ Linux, Android, AGL (all as guests; not QNX)574     *   KVM      ↔ Linux, AGL (guests; QNX guest support varies)575     *   none     ↔ any single OS (no virtualization)576     *577     * Invalid:578     *   ACRN ↔ QNX (not supported)579     *   KVM ↔ QNX (community-only, not production)580     */581  }582583  constraint def ApplicationMiddlewareCoexistence {584    doc /*585     * Application ↔ Middleware coexistence.586     *587     * Domain-specific application stacks (e.g. Autoware, Openpilot, Apollo for ADAS) each588     * ship their own internal communication middleware. They589     * coexist with the vehicle-level middleware (S-CORE, Android SDV,590     * AUTOSAR Adaptive) as separate layers — not as alternatives591     * at the same layer.592     *593     * The application stack handles domain-internal pipelines594     * (e.g. ADAS perception→planning→control).595     * The vehicle middleware handles vehicle signal access,596     * diagnostics, lifecycle, and inter-domain communication.597     *598     * No invalid combination exists at this boundary in principle,599     * but integration effort varies significantly:600     *   Autoware + S-CORE: ROS 2 IPC must bridge to LoLa IPC601     *   Openpilot + anything: custom device model, limited integration602     *   Apollo + anything: Cyber RT must bridge to external middleware603     */604  }605606  constraint def ApplicationMiddlewareAdapterCompatibility {607    doc /*608     * Adapter compatibility across application and middleware selections.609     *610     * The adapter variation must match both the selected application stack611     * and the selected vehicle-level middleware. The adapter is present only612     * when a non-none vehicle middleware is selected; when middleware = none,613     * the adapter is also none and the application↔adapter and adapter↔middleware614     * boundaries are absent.615     *616     * Intended pairings:617     *   Autoware ↔ AutowareToSCOREAdapter ↔ EclipseSCORE618     *   Autoware ↔ AutowareToAAOSSDVAdapter ↔ AndroidSDVMiddleware619     *   Autoware ↔ AutowareToAUTOSARAdapter ↔ AUTOSARAdaptive620     *   Openpilot ↔ OpenpilotToSCOREAdapter ↔ EclipseSCORE621     *   Apollo ↔ ApolloToSCOREAdapter ↔ EclipseSCORE622     */623  }624625  constraint def AGLPlatformScope {626    doc /*627     * AGL (Automotive Grade Linux) scope note.628     *629     * AGL is a full platform (OS + IVI framework + app framework +630     * compositor), not just an OS kernel. When AGL is selected as631     * the OS platform variant, it includes its own application632     * framework and does not simultaneously run S-CORE or633     * Android SDV middleware — AGL is an alternative to that634     * combination, not a layer beside it.635     *636     * This is a modeling note, not a hard constraint. AGL could637     * coexist with a domain application stack on a separate compute domain638     * via a hypervisor, but not on the same domain as S-CORE.639     */640  }641642  /* ──────────────────────────────────────────643   * Configured member product base644   * ──────────────────────────────────────────645   * ConfiguredSDVVariant is the abstract base for configured member646   * products. Concrete configured variants are generated from647   * Bill-of-Features YAML by the PLE configurator648   * (tools/configure_variant.py), not hand-written here.649   *650   * See:651   *   model-based-product-line-engineering/feature-models/sdv_product_line.yaml652   *   model-based-product-line-engineering/feature-configurations/653   *   model-based-product-line-engineering/product-models/654   */655  part def ConfiguredSDVVariant :> SDVPlatformStack {656    doc /*657     * A configured member product of the SDV product line.658     * Selects one variant from each variation, subject to659     * compatibility constraints.660     *661     * Concrete configured variants are generated from Bill-of-Features662     * by the PLE configurator (tools/configure_variant.py).663     */664  }665666  concern physicalStructureConcern : PhysicalStructureConcern {667    subject;668    stakeholder systemsEngineer : SystemsEngineer;669    stakeholder reviewer : OpenSourceReviewer;670  }671672  view sdvPlatformStackStructureView {673    viewpoint selectedPhysicalStructureViewpoint : PhysicalStructureDefinitionViewpoint {674      frame physicalStructureConcern;675    }676677    expose DE4SDV_SDVPlatformStack::*;678    render asTreeDiagram;679  }680}681