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 system 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_AEBSConceptualArchitecture::*;51  private import DE4SDV_Stakeholders::*;52  private import SAF_Viewpoints::*;53  private import Views::*;5455  part def AEBSAutowareReferenceProduct {56    doc /*57     * Composite AEBS reference member product.58     *59     * Platform: Autoware on Linux, no vehicle-level middleware, no hypervisor.60     * Sensing: LiDAR + camera perception sensors, IMU + wheel odometry common.61     * AEBS: Vehicle-target forward collision mitigation only.62     *63     * This product composes the platform stack with the sensing boundary64     * and the AEBS physical software realization. It makes the traceability65     * from physical sensors through ROS 2 topics to the AEB node visible66     * in a single product-level view.67     */6869    /* Platform stack — shared-asset superset. Variant selections are70     * resolved in the generated projection71     * (aebs_autoware_linux_lidar_camera.sysml). */72    part platformStack : SDVPlatformStack;7374    /* Sensing boundary — common motion sensors + selected perception sensors. */75    part sensingAssembly : VehicleSensingAssembly;7677    /* AEBS physical software — the Autoware AEB node and its required boundaries. */78    part aebsSoftware : VehicleTargetAEBSPhysicalSoftwareBoundary;7980    /* AEBS logical system — the technology-neutral system architecture. */81    part aebsLogicalSystem : VehicleTargetAEBSSystem;8283    /*84     * Product-level traceability: sensing assembly resides in the hardware85     * layer of the platform stack.86     */87    dependency productSensingToPlatformStack from sensingAssembly to platformStack;8889    /*90     * Product-level traceability: the AEB node's ROS 2 topic inputs trace91     * back to sensors and the perception pipeline. Key links (declared in92     * DE4SDV_VehicleSensingBoundary, visible through import):93     *94     *   LiDARSensorBoundary -> PointCloud2Message (AEB node port pointCloudIn)95     *   IMUSensorBoundary -> ImuMessage (AEB node port imuIn)96     *   WheelOdometrySensorBoundary -> VelocityReportMessage (AEB node port velocityIn)97     *   PerceptionPipelineBoundary -> PredictedObjectsMessage (AEB node port predictedObjectsIn)98     */99100    /*101     * Product-level traceability: the AEBS logical-to-physical allocation is102     * declared in DE4SDV_AEBSPhysicalSoftwareRealization. The logical103     * system's responsibilities are allocated to the AEB node with typed104     * coverage records (available, partial, missing).105     */106  }107108  /*109   * SAF physical-domain concerns and views.110   *111   * Uses SAF PhysicalLogicalMappingViewpoint (P8_PLOM) for the112   * product-level traceability view — not an invented viewpoint. The113   * composite product maps system architecture to physical software114   * realization, which is exactly what P8_PLOM addresses.115   *116   * Uses SAF PhysicalStructureDefinitionViewpoint (P2_PSTD) for the117   * product structure view showing the composition of platform stack,118   * sensing boundary, and AEBS software.119   */120121  concern productStructureConcern : PhysicalStructureConcern {122    doc /*123     * Reviewers need the product-level composition visible: platform stack,124     * sensing boundary, AEBS physical software, and their structural125     * relationships.126     */127    subject;128    stakeholder systemsEngineer : SystemsEngineer;129    stakeholder reviewer : OpenSourceReviewer;130  }131132  concern productMappingConcern : PhysicalLogicalMappingConcern {133    doc /*134     * Reviewers need the product-level traceability visible: which physical135     * elements (sensors, AEB node, required boundaries) realize which logical136     * responsibilities, and where the gaps are.137     */138    subject;139    stakeholder systemsEngineer : SystemsEngineer;140    stakeholder reviewer : OpenSourceReviewer;141  }142143  view productStructureView {144    viewpoint selectedPhysicalStructureViewpoint : PhysicalStructureDefinitionViewpoint {145      frame productStructureConcern;146    }147148    expose AEBSAutowareReferenceProduct;149    expose SDVPlatformStack;150    expose VehicleSensingAssembly;151    expose VehicleTargetAEBSPhysicalSoftwareBoundary;152    expose VehicleTargetAEBSSystem;153    render asTreeDiagram;154  }155156  view productMappingView {157    viewpoint selectedPhysicalLogicalMappingViewpoint : PhysicalLogicalMappingViewpoint {158      frame productMappingConcern;159    }160161    expose AEBSAutowareReferenceProduct;162    render asTreeDiagram;163  }164}165