model-based-product-line-engineering/product-models/aebs_autoware_reference_product.sysml

Source

1/*2 * DE4SDV AEBS Autoware reference member product — composite projection.3 *4 * This is a hand-authored composite product model that ties together the5 * platform-stack shared asset, the vehicle sensing boundary, and the AEBS6 * physical software realization into a single AEBS-equipped member product.7 *8 * The platform-stack variant selections for this product are documented in9 * the bill-of-features (aebs-autoware-linux-lidar-camera.yaml) and resolved10 * in the generated projection (aebs_autoware_linux_lidar_camera.sysml).11 * This composite model references the shared-asset definitions directly and12 * composes them with the sensing boundary and AEBS physical software to make13 * the full product-level traceability visible:14 *15 *   platform stack (Autoware on Linux)16 *     -> sensing boundary (LiDAR + camera + IMU + wheel odometry)17 *       -> perception pipeline (raw sensor data to object-level output)18 *         -> AEBS physical software (AEB node consuming ROS 2 topics)19 *20 * The sensing selections (LiDAR + camera) match the bill-of-features.21 * The common motion sensors (IMU, wheel odometry) are present in all member22 * products per the feature model (mandatory, not a feature).23 *24 * Scope:25 *   - Composition of platform stack, sensing boundary, and AEBS software26 *   - Product-level traceability dependencies (sensors to AEB node, AEBS27 *     required boundaries to platform elements)28 *   - Allocation links from AEBS logical architecture to physical software29 *30 * Out of scope:31 *   - Vehicle-level middleware integration (S-CORE, Android SDV) — this32 *     product selects no vehicle-level middleware33 *   - Brake actuation, vehicle command gate, MRM handler34 *   - Runtime deployment configuration (INC-AEBS-008)35 *   - Evidence generation (INC-AEBS-009)36 *37 * Relationship to PLE:38 *   The platform-stack projection is generated from the bill-of-features.39 *   The sensing boundary is a shared-asset superset (150% model) with40 *   independent include/exclude variation points per perception sensor.41 *   This composite model does not resolve those variations in SysML —42 *   it references the sensing assembly and its traceability dependencies43 *   as the structural context for the AEB node's ROS 2 topic inputs.44 */4546package DE4SDV_AEBSAutowareReferenceProduct {47  private import DE4SDV_SDVPlatformStack::*;48  private import DE4SDV_VehicleSensingBoundary::*;49  private import DE4SDV_AEBSPhysicalSoftwareRealization::*;50  private import DE4SDV_AEBSLogicalArchitecture::*;51  private import DE4SDV_AEBSProductLineScope::*;52  private import DE4SDV_Stakeholders::*;53  private import SAF_Viewpoints::*;54  private import Views::*;5556  part def AEBSAutowareReferenceProduct :> StandaloneAutowareAEBSReferenceMember {57    doc /*58     * Composite AEBS reference member product. Specializes the governed59     * planned-member decision (StandaloneAutowareAEBSReferenceMember in60     * DE4SDV_AEBSProductLineScope), so this composite carries the61     * ProductLineMemberProduct lineage that product-line queries resolve.62     *63     * Platform: Autoware on Linux, no vehicle-level middleware, no hypervisor.64     * Sensing: LiDAR + camera perception sensors, IMU + wheel odometry common.65     * AEBS: Vehicle-target forward collision mitigation only.66     *67     * This product composes the platform stack with the sensing boundary68     * and the AEBS physical software realization. It makes the traceability69     * from physical sensors through ROS 2 topics to the AEB node visible70     * in a single product-level view.71     */7273    /* Platform stack — shared-asset superset. Variant selections are74     * resolved in the generated projection75     * (aebs_autoware_linux_lidar_camera.sysml). */76    part platformStack : SDVPlatformStack;7778    /* Sensing boundary — common motion sensors + selected perception sensors. */79    part sensingAssembly : VehicleSensingAssembly;8081    /* AEBS physical software — the Autoware AEB node and its required boundaries. */82    part aebsSoftware : VehicleTargetAEBSPhysicalSoftwareBoundary;8384    /* AEBS logical system — the technology-neutral logical architecture. */85    part aebsLogicalSystem : VehicleTargetAEBSSystem;8687    /*88     * Product-level traceability: sensing assembly resides in the hardware89     * layer of the platform stack.90     */91    dependency productSensingToPlatformStack from sensingAssembly to platformStack;9293    /*94     * Product-level traceability: the AEB node's ROS 2 topic inputs trace95     * back to sensors and the perception pipeline. Key links (declared in96     * DE4SDV_VehicleSensingBoundary, visible through import):97     *98     *   LiDARSensorBoundary -> PointCloud2Message (AEB node port pointCloudIn)99     *   IMUSensorBoundary -> ImuMessage (AEB node port imuIn)100     *   WheelOdometrySensorBoundary -> VelocityReportMessage (AEB node port velocityIn)101     *   PerceptionPipelineBoundary -> PredictedObjectsMessage (AEB node port predictedObjectsIn)102     */103104    /*105     * Product-level traceability: the AEBS logical-to-physical allocation is106     * declared in DE4SDV_AEBSPhysicalSoftwareRealization. The logical107     * system's responsibilities are allocated to the AEB node with typed108     * coverage records (available, partial, missing).109     */110    doc /*111     * Canonical-architecture binding: the composite usages above are112     * product-level instances, while the canonical allocation and evidence113     * records bind the canonical usages114     * DE4SDV_AEBSLogicalArchitecture::system and115     * DE4SDV_AEBSPhysicalSoftwareRealization::physicalSoftware. The116     * explicit dependencies below record this product's instances as bound117     * to those canonical elements. These are model-native reference118     * dependencies only: no executable semantic query maps them yet, so119     * reachability through the revision-bound API is not claimed by this120     * binding, and the composite does not own the canonical records.121     *122     * Bounded projection limitation (unchanged): importing the packages123     * does not transfer instance-level identity, and the explicit reference124     * dependencies do not restate the canonical allocations at product125     * level. Platform-stack variant selections are resolved only in the126     * generated projection (aebs_autoware_linux_lidar_camera.sysml), and127     * sensing-boundary perception-sensor selections live in the128     * bill-of-features, not in this composite. Product-level trace claims129     * must still cite the canonical allocation records; these dependencies130     * make the binding path explicit, they do not make this composite a131     * resolved configured product.132     */133    dependency aebsLogicalSystemBindingToCanonicalSystem134      from aebsLogicalSystem135      to DE4SDV_AEBSLogicalArchitecture::system;136    dependency aebsSoftwareBindingToCanonicalPhysicalSoftware137      from aebsSoftware138      to DE4SDV_AEBSPhysicalSoftwareRealization::physicalSoftware;139  }140141  /*142   * SAF physical-domain concerns and views.143   *144   * Uses SAF PhysicalLogicalMappingViewpoint (P8_PLOM) for the145   * product-level traceability view — not an invented viewpoint. The146   * composite product maps logical architecture to physical software147   * realization, which is exactly what P8_PLOM addresses.148   *149   * Uses SAF PhysicalStructureDefinitionViewpoint (P2_PSTD) for the150   * product structure view showing the composition of platform stack,151   * sensing boundary, and AEBS software.152   */153154  concern productStructureConcern : PhysicalStructureConcern {155    doc /*156     * Reviewers need the product-level composition visible: platform stack,157     * sensing boundary, AEBS physical software, and their structural158     * relationships.159     */160    subject;161    stakeholder systemsEngineer : SystemsEngineer;162    stakeholder reviewer : OpenSourceReviewer;163  }164165  concern productMappingConcern : PhysicalLogicalMappingConcern {166    doc /*167     * Reviewers need the product-level traceability visible: which physical168     * elements (sensors, AEB node, required boundaries) realize which logical169     * responsibilities, and where the gaps are.170     */171    subject;172    stakeholder systemsEngineer : SystemsEngineer;173    stakeholder reviewer : OpenSourceReviewer;174  }175176  view productStructureView {177    viewpoint selectedPhysicalStructureViewpoint : PhysicalStructureDefinitionViewpoint {178      frame productStructureConcern;179    }180181    expose AEBSAutowareReferenceProduct;182    expose SDVPlatformStack;183    expose VehicleSensingAssembly;184    expose VehicleTargetAEBSPhysicalSoftwareBoundary;185    expose VehicleTargetAEBSSystem;186    render asTreeDiagram;187  }188189  view productMappingView {190    viewpoint selectedPhysicalLogicalMappingViewpoint : PhysicalLogicalMappingViewpoint {191      frame productMappingConcern;192    }193194    expose AEBSAutowareReferenceProduct;195    render asTreeDiagram;196  }197}198