DE4SDV Model Viewer Revision
Model / Needs & Requirements

Needs & Requirements

127 record(s) · 103 with a controlled ID · extracted from the SysML v2 textual model — read-only, nothing inferred. Every record links to its declaration; IDs in text form the trace network.

acceptance criterion

AC-AEBS-S2-001

subject: bench : VisualizationVerificationBench

The visualization test system shall retain source, transport, ingress, and guest identity, sequence, timestamp, log, and guest-native capture records for each rendered state so that each rendered state can be correlated with its observed source event, with consecutive accepted callbacks and zero sequence gaps over the retained take.

AC-AEBS-S2-001; bounded verification of source-to-screen correlation.

traces: AGT-AEBS-S2-01

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:161

acceptance criterion

AC-AEBS-S2-002

subject: bench : VisualizationVerificationBench

The visualization test system shall present the reducer-driven MONITORING, WARNING, INTERVENTION, and RELEASED dispositions from accepted frames of one uninterrupted real-time take, with the release disposition accompanied by a verified zero-speed stop observation and no edited or older-generation footage presented as part of the take.

AC-AEBS-S2-002; bounded verification of the four-state arc in one take.

traces: AGT-AEBS-S2-02

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:167

acceptance criterion

AC-AEBS-S2-004

subject: bench : VisualizationVerificationBench

The visualization test system shall render obstacle geometry only from the display-derived filtered point cloud, shall not present coordinator-derived distance values or any display-derived scalar as a native Autoware decision metric, and shall state in the public interface that AEB decision distances are not visualized.

AC-AEBS-S2-004; display-derived versus native decision semantics separation.

traces: AGT-AEBS-S2-04

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:179

acceptance criterion

AC-AEBS-S2-005

subject: bench : VisualizationVerificationBench

When the filtered obstacle-cloud source stops updating, the visualization test system shall suppress the expired display-derived obstacle geometry while accepted live frames continue, and no interpolation, smoothing, or prediction shall substitute for missing fresh data.

AC-AEBS-S2-005; fail-closed staleness verification.

traces: AGT-AEBS-S2-05

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:185

acceptance criterion

AC-AEBS-S2-006

subject: bench : VisualizationVerificationBench

Under deterministic closed-loop frame injection, the visualization test system shall render the stale, unavailable, and invalid degraded dispositions with live geometry cleared and the health chip identifying the degraded condition, with color never the sole state cue.

AC-AEBS-S2-006; degraded-state rendering verification (fixture path).

traces: AGT-AEBS-S2-06

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:191

acceptance criterion

AC-AEBS-S2-008

subject: bench : VisualizationVerificationBench

Every retained verdict shall bind the configured test article, execution environment, wire contract, raw observation artifacts, and independent observer identities, and missing evidence shall be recorded as planned, partial, blocked, or not claimed, never as an observed runtime pass.

AC-AEBS-S2-008; evidence integrity and claim-boundary criterion.

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:203

acceptance criterion

AC-MW-010-01

subject: bench : MiddlewareIntegrationVandVBench

The selected contract shall preserve Vehicle.Speed [km/h] semantics, map 36 km/h to 10 m/s and 72 km/h to 20 m/s through division by 3.6, reject invalid/non-finite samples, and expose the resulting VelocityReport field to an independent observer.

AC-MW-010-01; bounded verification of the selected Vehicle.Speed slice.

traces: AGT-MW-010-01

textual-notation-of-model/packages/features/middleware/middleware_verification_evidence.sysml:149

acceptance criterion

AC-MW-010-05

subject: bench : MiddlewareIntegrationVandVBench

An update/OTA scenario shall retain pre-update and post-update identities and observations and shall detect, rather than silently accept, loss or incompatible change of the required signal, lifecycle, health, discovery, or consumer contracts.

AC-MW-010-05; validation of integration update behavior.

traces: AGT-MW-010-05

textual-notation-of-model/packages/features/middleware/middleware_verification_evidence.sysml:181

acceptance criterion

AC-MW-010-07

subject: bench : MiddlewareIntegrationVandVBench

Every retained verdict shall bind the configured member, execution environment, contract identities, raw observations, and independent observer evidence. Missing target-runtime evidence shall be inconclusive or blocked, never a runtime pass.

AC-MW-010-07; evidence integrity and claim-boundary criterion.

textual-notation-of-model/packages/features/middleware/middleware_verification_evidence.sysml:197

claim

CLM-AEBS-S2-001

subject: claimSubject : VisualizationVerificationBench

The claim requires retained EVID-AEBS-S2-001 through EVID-AEBS-S2-006 evidence bound to the configured test article, exact wire contract, execution environment, and independent observer identities. It excludes restoration behavior, live degradation beyond the retained take, inter-VM transport without the bounded bench route, signed- policy enforcement, post-release re-approach, safety, certification, homologation, and production-readiness claims.

CLM-AEBS-S2-001: for AEBS-CONFIG-010-001 on the retained campaign environment, the read-only visualization instrumentation observed the live pinned-Autoware chain into the AAOS guest, rendered the complete reducer-driven four-state arc in one uninterrupted take, preserved the display-derived versus native decision-semantics separation in every public frame, suppressed expired display-derived geometry fail-closed, and rendered degraded dispositions under deterministic fixture injection. The scenario-safety outcome remains deferred_not_proven: this claim is about the instrumentation, never about AEBS safety.

references: AEBS-CONFIG-010-001 · EVID-AEBS-S2-001 · EVID-AEBS-S2-006

textual-notation-of-model/packages/features/aebs/aebs_visualization_verification_evidence.sysml:630

claim

CLM-MW-010-01

subject: claimSubject : MiddlewareIntegrationVandVBench

The claim requires retained E-MW-011 through E-MW-014 evidence bound to the configured member, exact contracts, execution environment, and observer identities. It excludes complete lifecycle ordering, update/OTA, reverse-path, production, full-stack Autoware, safety, and certification claims.

CLM-MW-010-01: for MW-CONFIG-001 on the retained two-VM execution environment, the forward Vehicle.Speed slice was observed from the AAOS provider through the direct adapter path to ROS 2, where one real Autoware consumer produced the expected converted output. Invalid envelopes were rejected and provider loss/restoration produced explicit degraded/restored health dispositions.

references: MW-CONFIG-001 · E-MW-011 · E-MW-014

textual-notation-of-model/packages/features/middleware/middleware_verification_evidence.sysml:642

evidence contract

EC-AEBS-009B-01

subject: bench : NominalMovingVehicleTargetBench

The replayed collector-monotonic warning request shall precede the exact native intervention diagnostic by at least 0.8 s.

EC-AEBS-009B-01; System 2 evidence contract; method: retained evaluator replay.

textual-notation-of-model/packages/features/aebs/aebs_evidence.sysml:194

evidence contract

EC-AEBS-009B-02

subject: bench : NominalMovingVehicleTargetBench

Nominal 009B intervention evidence shall include a source-stamped false override sample that remains within the 0.2 s freshness bound at intervention. Conscious true override behavior is deferred to INC-AEBS-009D.

EC-AEBS-009B-02; System 2 evidence contract; method: source-stamp and receipt-freshness analysis.

references: INC-AEBS-009D

textual-notation-of-model/packages/features/aebs/aebs_evidence.sysml:202

evidence contract

EC-AEBS-009B-03

subject: bench : NominalMovingVehicleTargetBench

Runtime graph evidence shall periodically sample the coordinator as the sole nominal gate-input publisher and no MRM publishers from the accepted pre-intervention topology snapshot through verified-stop release, reject any contradictory sample, and reject any sampling gap above 1.0 s; the observed direct EmergencyBrakingRequest shall follow the paired exact native intervention diagnostic.

EC-AEBS-009B-03; System 2 evidence contract; method: runtime-graph and command replay.

textual-notation-of-model/packages/features/aebs/aebs_evidence.sysml:210

evidence contract

EC-AEBS-009B-04

subject: bench : NominalMovingVehicleTargetBench

Braking shall remain latched until each ego-odometry source stamp is replayed against a collector stamp from the same ROS clock and remains within 0.2 s, speed stays at or below 0.1 m/s for at least 0.5 s, and no receipt gap exceeds 0.2 s; release shall be absorbing for the one-shot scenario and independent of diagnostic retention.

EC-AEBS-009B-04; System 2 evidence contract; method: source-stamped odometry and lifecycle replay.

textual-notation-of-model/packages/features/aebs/aebs_evidence.sysml:218

evidence contract

EC-AEBS-009B-05

subject: bench : NominalMovingVehicleTargetBench

For the retained run, replay shall compute the oriented footprint relation from preserved map poses, reject overlap or touching, require positive then opening separation, and require a fresh footprint relation covering release.

EC-AEBS-009B-05; System 2 evidence contract; method: retained map-pose oriented-footprint analysis.

textual-notation-of-model/packages/features/aebs/aebs_evidence.sysml:226

problem statement

INC-MW-010

subject: increment : VisualizationIncrement

stakeholders: systemsEngineer · productLineEngineer · verificationEngineer · maintainer · reviewer

How can DE4SDV demonstrate a bounded, stakeholder-visible AEBS threat and intervention visualization on a real AAOS SDV display, consuming live native Autoware AEB output and existing DE4SDV AEBS coordination state, with explicit source provenance, freshness, invalid-input, and provider-loss behavior, without making production driver-HMI, safety, or compliance claims and without altering the closed INC-MW-010 baseline?

textual-notation-of-model/packages/features/aebs/aebs_visualization_framing.sysml:36

need

N-AEBS-001

InDevelopment

subject: productLine : SDVProductLine

stakeholders: roadUser · occupant

Road users and vehicle occupants need the SDV product line to define AEBS as a common capability required across member products to reduce forward rear-end in-lane collision risk with a vehicle target under defined operating conditions.

N-AEBS-001 draft System 1 need.

rationale: Road-user and occupant collision-risk expectation established in the operational slice; AEBS is a common capability required across member products.

source: INC-AEBS-001 framing and INC-AEBS-002 operational context

traces: REQ-AEBS-001REQ-AEBS-002REQ-AEBS-003REQ-AEBS-004

references: INC-AEBS-001 · INC-AEBS-002

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:54

need

N-AEBS-002

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: systemsEngineer

Systems engineers need the DE4SDV AEBS increment to keep its operational boundary, assumptions, source constraints, and out-of-scope cases explicit while draft requirements are derived.

N-AEBS-002 draft System 2 need.

rationale: Boundary and assumption visibility is a review precondition for derived requirements.

source: DE4SDV method increment workflow

traces: REQ-AEBS-S2-001

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:236

need

N-AEBS-003

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: productLineEngineer

Product-line engineers need the DE4SDV AEBS increment to keep AEBS classified as a common capability, with native SysML v2 variation and variant choices modeled separately without weakening the System 1 capability.

N-AEBS-003 draft System 2 need.

rationale: Common-capability vs variant classification must stay explicit for product-line derivation.

source: DE4SDV method increment workflow; MBPLE feature-model conventions

traces: REQ-AEBS-006

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:245

need

N-AEBS-004

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: complianceEngineer

Compliance engineers need the DE4SDV AEBS increment to keep regulatory assumptions, controlled source references, and open applicability and interpretation gaps visible without implying compliance or type approval.

N-AEBS-004 draft System 2 need.

rationale: Regulatory applicability must be visible and unresolved without implying compliance.

source: DE4SDV compliance workflow; SRC-UNECE-R152 controlled source identity

traces: REQ-AEBS-007

references: SRC-UNECE-R152

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:254

need

N-AEBS-005

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: verificationEngineer

Verification engineers need the DE4SDV AEBS increment to maintain a separate controlled V&V planning attachment for each draft AEBS requirement without changing the product obligation.

N-AEBS-005 draft System 2 need.

rationale: V&V planning attachments are kept separate from normative requirement text.

source: DE4SDV verification and assurance workflow

traces: REQ-AEBS-007

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:263

need

N-AEBS-006

InDevelopment

subject: productLine : SDVProductLine

stakeholders: pedestrian

Pedestrians need the SDV product line to provide a common AEBS capability that reduces forward collision risk with a pedestrian target under defined applicable operating conditions.

N-AEBS-006 draft System 1 need; source identity is controlled and applicability remains open.

rationale: Pedestrian forward-collision risk is a distinct stakeholder concern; applicability remains open per GAP-AEBS-REQ-013 and GAP-AEBS-REQ-015.

source: INC-AEBS-002 operational context; controlled public-safe source metadata E/ECE/TRANS/505/Rev.3/Add.151/Rev.2 (SRC-UNECE-R152)

traces: REQ-AEBS-010REQ-AEBS-014

references: INC-AEBS-002 · SRC-UNECE-R152 · GAP-AEBS-REQ-013 · GAP-AEBS-REQ-015

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:64

need

N-AEBS-007

InDevelopment

subject: productLine : SDVProductLine

stakeholders: cyclist

Cyclists need the SDV product line to provide a common AEBS capability that reduces forward collision risk with a bicycle target under defined applicable operating conditions.

N-AEBS-007 draft System 1 need; source identity is controlled and applicability remains open.

rationale: Cyclist forward-collision risk is a distinct stakeholder concern; applicability remains open per GAP-AEBS-REQ-013 and GAP-AEBS-REQ-016.

source: INC-AEBS-002 operational context; controlled public-safe source metadata E/ECE/TRANS/505/Rev.3/Add.151/Rev.2 (SRC-UNECE-R152)

traces: REQ-AEBS-011REQ-AEBS-015

references: INC-AEBS-002 · SRC-UNECE-R152 · GAP-AEBS-REQ-013 · GAP-AEBS-REQ-016

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:73

need

N-AEBS-008

InDevelopment

subject: memberProduct : ProductLineMemberProduct

stakeholders: roadUser · occupant

Road users and vehicle occupants need each SDV product-line member product to manage AEBS degradation so that behavior remains bounded and AEBS availability is apparent when required inputs or AEBS functions are not healthy.

N-AEBS-008 draft System 1 safety and availability need.

rationale: Unavailable or unhealthy AEBS inputs must not present misleading availability to the driver.

source: INC-AEBS-002 operational context degraded-mode scenarios

traces: N-AEBS-014REQ-AEBS-005REQ-AEBS-009REQ-AEBS-013

references: INC-AEBS-002

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:82

need

N-AEBS-009

InDevelopment

subject: increment : VisualizationIncrement

stakeholders: systemsEngineer · reviewer

Systems engineers and reviewers need live AEBS threat and intervention state visible on an actual AAOS SDV display so that stakeholder-visible AEBS behavior can be reviewed without a host-side substitute.

N-AEBS-009 draft System 2 need.

rationale: Stakeholder-visible AEBS behavior must be reviewable on a real AAOS display, not a host substitute.

source: INC-AEBS-010 increment framing; GCP AAOS runtime proof environment

traces: REQ-AEBS-S2-002REQ-AEBS-S2-003REQ-AEBS-S2-004REQ-AEBS-S2-010REQ-AEBS-S2-012REQ-AEBS-S2-013

references: INC-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:49

need

N-AEBS-010

InDevelopment

subject: increment : VisualizationIncrement

stakeholders: systemsEngineer · verificationEngineer

Systems engineers need source provenance, units, coordinate frame, timestamps, rate and freshness, validity, and bounded displayed cardinality preserved between native Autoware output, DE4SDV AEBS coordination state, and display-derived presentation.

N-AEBS-010 draft System 2 need.

rationale: Displayed values must remain traceable to their source identity and context.

source: INC-AEBS-010 increment framing

traces: REQ-AEBS-S2-002REQ-AEBS-S2-014

references: INC-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:59

need

N-AEBS-011

InDevelopment

subject: increment : VisualizationIncrement

stakeholders: systemsEngineer · maintainer

Systems engineers and maintainers need stale, unavailable, invalid, and restored display behavior so that a lost or invalid source cannot be misread as current AEBS state.

N-AEBS-011 draft System 2 need.

rationale: A lost or invalid source must never be misread as current AEBS state.

source: INC-AEBS-010 increment framing

traces: REQ-AEBS-S2-006REQ-AEBS-S2-007REQ-AEBS-S2-008REQ-AEBS-S2-009

references: INC-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:69

need

N-AEBS-012

InDevelopment

subject: increment : VisualizationIncrement

stakeholders: verificationEngineer

Verification engineers need source-to-screen correlation and replayable evidence so that displayed states can be traced to observed source events.

N-AEBS-012 draft System 2 need.

rationale: Verification needs source-to-screen correlation and replayable evidence.

source: INC-AEBS-010 increment framing

traces: REQ-AEBS-S2-010REQ-AEBS-S2-011

references: INC-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:79

need

N-AEBS-013

InDevelopment

subject: increment : VisualizationIncrement

stakeholders: maintainer · verificationEngineer

Maintainers and verification engineers need assurance that visualization instrumentation cannot command or modify AEBS detection, warning, intervention, or release behavior.

N-AEBS-013 draft System 2 need.

rationale: Visualization instrumentation must not influence the behavior it observes.

source: INC-AEBS-010 increment framing

traces: REQ-AEBS-S2-005

references: INC-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:88

need

N-AEBS-014

InDevelopment

subject: memberProduct : ProductLineMemberProduct

stakeholders: roadUser · occupant

Road users and vehicle occupants need each SDV product-line member product to keep AEBS intervention decisions trustworthy so that neither a collision warning nor emergency braking occurs when AEBS controlled non-activation criteria determine that imminent collision risk is absent under defined operating conditions.

N-AEBS-014 draft System 1 need; non-activation and false-reaction parent derived from N-AEBS-008 review findings.

rationale: Non-activation silence constraints need a System 1 parent whose intent they preserve; nuisance warning/braking erodes driver trust in AEBS.

source: Requirements QA gate review of the INC-AEBS-003 baseline

traces: N-AEBS-008REQ-AEBS-008REQ-AEBS-012

references: INC-AEBS-003

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:92

need

N-MW-001

InDevelopment

subject: productLine : SDVProductLine

stakeholders: platformEngineer

Platform engineers need the SDV product line to provide middleware integration connecting the ADAS application with a vehicle-level platform middleware for signal access, diagnostic access, lifecycle coordination, health monitoring, and update coordination.

N-MW-001 draft System 1 need.

rationale: ADAS application capability depends on signal, diagnostic, lifecycle, health, and update access through platform middleware.

source: INC-MW-002 operational context and INC-MW-003 feature classification

traces: REQ-MW-001REQ-MW-002REQ-MW-003REQ-MW-004REQ-MW-005

references: INC-MW-002 · INC-MW-003

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:39

need

N-MW-002

InDevelopment

subject: productLine : SDVProductLine

stakeholders: platformEngineer

Platform engineers need the SDV product line to ensure the ADAS application is not coupled to a specific middleware implementation so that middleware selection remains a product-line feature choice.

N-MW-002 draft System 1 need.

rationale: Middleware selection must remain a product-line feature choice, not an application property.

source: INC-MW-003 feature classification

traces: REQ-MW-007

references: INC-MW-003

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:49

need

N-MW-003

InDevelopment

subject: productLine : SDVProductLine

stakeholders: productLineEngineer

Product-line engineers need the SDV product line to treat middleware platform selection as a feature that distinguishes member products, with the adapter layer as a common capability derived from the application-middleware feature pair.

N-MW-003 draft System 1 need; derived requirements are owned by the PLE configuration increment INC-MW-009 rather than INC-MW-005.

rationale: Adapter-layer commonality derives from the application-middleware feature pair.

source: INC-MW-003 feature classification

references: INC-MW-009 · INC-MW-005 · INC-MW-003

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:59

need

N-MW-004

InDevelopment

subject: memberProduct : ProductLineMemberProduct

stakeholders: safetyExpert

Safety experts need each SDV product-line member product to ensure that the emergency intervention path is isolated from middleware failures, whether routed through a safety-certified middleware partition or via a direct vehicle-command path.

N-MW-004 draft System 1 need; isolation and containment criteria remain open per GAP-MW-029.

rationale: Emergency intervention must survive middleware failure regardless of selected architecture; criteria open per GAP-MW-029.

source: INC-MW-002 operational context emergency-intervention scenario

traces: REQ-MW-006

references: GAP-MW-029 · INC-MW-002

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:69

need

N-MW-005

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: maintainer

Maintainers need the DE4SDV middleware increment to engage upstream middleware maintainers before deeper integration, vendoring, or presenting borrowed methods as settled DE4SDV practice.

N-MW-005 draft System 2 need; moved from System 1 because upstream engagement is a DE4SDV project obligation, not a product-line capability.

rationale: Upstream maintainers must be involved before deeper integration or vendoring.

source: DE4SDV governance policy on external methodology adoption

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:81

need

N-MW-006

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: systemsEngineer

Systems engineers need the DE4SDV middleware increment to maintain trace links from stakeholder needs to the operational context scenarios defined in INC-MW-002 and the feature classifications defined in INC-MW-003.

N-MW-006 draft System 2 need.

rationale: Needs must trace to the operational scenarios that justify them.

source: DE4SDV method increment workflow

traces: REQ-MW-009

references: INC-MW-002 · INC-MW-003

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:100

need

N-MW-007

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: systemsEngineer

Systems engineers need the DE4SDV middleware increment to keep its engineering boundary, assumptions, source constraints, and out-of-scope cases explicit while needs are derived.

N-MW-007 draft System 2 need; satisfied by the increment framing and gap records rather than a derived requirement.

rationale: Boundary, assumptions, and out-of-scope cases stay explicit while needs are derived.

source: DE4SDV method increment workflow

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:110

need

N-MW-008

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: reviewer

Reviewers need the DE4SDV middleware increment to maintain a separate controlled V&V planning attachment for each stakeholder need without changing the product obligation.

N-MW-008 draft System 2 need; satisfied by the separate verification_planning attachment in the INC-MW-004 and INC-MW-005 artifacts rather than a derived requirement.

rationale: Per-need V&V planning attachments stay separate from product obligations.

source: DE4SDV verification and assurance workflow

references: INC-MW-004 · INC-MW-005

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:120

need

N-MW-009

InDevelopment

subject: increment : NeedsRequirementsIncrement

stakeholders: securityExpert

Security experts need the DE4SDV middleware increment to define the trust boundary that middleware service bindings must authenticate across before the ADAS application accepts service data or commands.

N-MW-009 draft System 2 need; parents REQ-MW-008, trust-boundary details remain deferred per GAP-MW-012.

rationale: Service-binding authentication needs a defined trust boundary to authenticate across; details deferred per GAP-MW-012.

source: Requirements QA gate review of the INC-MW-005 baseline

traces: REQ-MW-008

references: GAP-MW-012 · INC-MW-005

textual-notation-of-model/packages/features/middleware/middleware_stakeholder_needs.sysml:91

requirement

REQ-AEBS-001

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall realize the common AEBS capability by detecting imminent forward collision risk with a vehicle target under defined operating conditions.

REQ-AEBS-001 candidate.

rationale: Detection is the enabling behavior for every downstream AEBS intervention.

source: Derived from N-AEBS-001

traces: N-AEBS-001

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:103

requirement

REQ-AEBS-002

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall realize the common AEBS capability by providing a collision warning to the driver when defined warning conditions are met.

REQ-AEBS-002 candidate.

rationale: Driver warning precedes autonomous braking and is required before intervention.

source: Derived from N-AEBS-001

traces: N-AEBS-001

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:113

requirement

REQ-AEBS-003

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall realize the common AEBS capability by commanding emergency braking when defined activation conditions are met and no overriding condition prevents intervention.

REQ-AEBS-003 candidate.

rationale: Collision-risk reduction ultimately requires braking intervention when warning is insufficient.

source: Derived from N-AEBS-001

traces: N-AEBS-001REQ-AEBS-014REQ-AEBS-015

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:123

requirement

REQ-AEBS-004

InDevelopment

subject: memberProduct : ProductLineMemberProduct

When a valid, fresh, and unambiguous driver input is classified as a conscious override under controlled override criteria during AEBS intervention, each SDV product-line member product shall apply the intervention response selected by the controlled override-response mapping.

REQ-AEBS-004 draft; controlled override-response mapping remains a blocker.

rationale: Driver authority over intervention is expected behavior; the controlled override-response mapping is unresolved.

source: Derived from N-AEBS-001

traces: N-AEBS-001

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:133

requirement

REQ-AEBS-005

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Under controlled failure-detection criteria, each SDV product-line member product shall detect AEBS-related failure conditions.

REQ-AEBS-005 failure-detection draft derived from N-AEBS-008; carries the bounded-behavior envelope of N-AEBS-008 pending safe-operation criteria, see GAP-AEBS-REQ-007.

rationale: Degradation management presupposes failure detection.

source: Derived from N-AEBS-008; carries the bounded-behavior envelope pending safe-operation criteria (GAP-AEBS-REQ-007)

traces: N-AEBS-008

references: GAP-AEBS-REQ-007

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:143

requirement

REQ-AEBS-006

ReadyForReview

subject: increment : NeedsRequirementsIncrement

The DE4SDV AEBS increment shall keep common-capability, feature, and native SysML v2 variation and variant classifications explicit for each AEBS behavior or scope element in its model baseline.

REQ-AEBS-006 System 2 candidate.

rationale: Makes the classification need enforceable on the increment baseline.

source: Derived from N-AEBS-003

traces: N-AEBS-003

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:272

requirement

REQ-AEBS-007

ReadyForReview

subject: increment : NeedsRequirementsIncrement

The DE4SDV AEBS increment shall maintain separate trace links from each draft AEBS requirement to its source, stakeholder need, unresolved gaps, validation reference, and controlled V&V planning attachment.

REQ-AEBS-007 System 2 candidate.

rationale: Traceability is the mechanism that keeps regulatory assumptions and V&V planning visible.

source: Derived from N-AEBS-004 and N-AEBS-005

traces: N-AEBS-004N-AEBS-005

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:282

requirement

REQ-AEBS-008

InDevelopment

subject: memberProduct : ProductLineMemberProduct

When controlled non-activation criteria determine that imminent forward collision risk is absent under defined operating conditions, each SDV product-line member product shall not issue an AEBS collision warning.

REQ-AEBS-008 warning-silence draft derived from N-AEBS-014; criteria, window, and tolerances remain gaps.

rationale: Prevents nuisance warnings when controlled non-activation criteria rule out imminent risk.

source: Derived from N-AEBS-014

traces: N-AEBS-014

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:153

requirement

REQ-AEBS-009

InDevelopment

subject: memberProduct : ProductLineMemberProduct

When a required AEBS input is stale, missing, malformed, inconsistent, or unavailable under controlled input-health criteria, each SDV product-line member product shall enter the AEBS state selected by the controlled degraded-state mapping.

REQ-AEBS-009 state-transition draft; state mapping, ownership, and timing remain gaps.

rationale: Unhealthy inputs must drive a controlled degraded state rather than silent misbehavior.

source: Derived from N-AEBS-008

traces: N-AEBS-008

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:163

requirement

REQ-AEBS-010

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall detect imminent forward collision risk with a pedestrian target under defined applicable pedestrian-target operating conditions.

REQ-AEBS-010 pedestrian detection draft; stable usage name retained for imports.

rationale: Pedestrian targets require distinct detection behavior from vehicle targets; criteria open per GAP-AEBS-REQ-015.

source: Derived from N-AEBS-006

traces: N-AEBS-006

references: GAP-AEBS-REQ-015

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:173

requirement

REQ-AEBS-011

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall detect imminent forward collision risk with a bicycle target under defined applicable bicycle-target operating conditions.

REQ-AEBS-011 bicycle detection draft; stable usage name retained for imports.

rationale: Bicycle targets require distinct detection behavior from vehicle targets; criteria open per GAP-AEBS-REQ-016.

source: Derived from N-AEBS-007

traces: N-AEBS-007

references: GAP-AEBS-REQ-016

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:183

requirement

REQ-AEBS-012

InDevelopment

subject: memberProduct : ProductLineMemberProduct

When controlled non-activation criteria determine that imminent forward collision risk is absent under defined operating conditions, each SDV product-line member product shall not command AEBS emergency braking.

REQ-AEBS-012 braking-silence draft derived from N-AEBS-014.

rationale: Prevents nuisance braking when controlled non-activation criteria rule out imminent risk.

source: Derived from N-AEBS-014

traces: N-AEBS-014

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:193

requirement

REQ-AEBS-013

InDevelopment

subject: memberProduct : ProductLineMemberProduct

When a required AEBS input is stale, missing, malformed, inconsistent, or unavailable under controlled input-health criteria, each SDV product-line member product shall provide the status indication selected by the controlled degraded-state indication mapping.

REQ-AEBS-013 status-indication draft.

rationale: Availability must be apparent to the driver when AEBS inputs or functions are not healthy.

source: Derived from N-AEBS-008

traces: N-AEBS-008

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:203

requirement

REQ-AEBS-014

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Under defined applicable pedestrian-target operating conditions, each SDV product-line member product shall apply the controlled AEBS response to classified pedestrian-target collision risk.

REQ-AEBS-014 pedestrian response draft; specializes the braking-command response family of REQ-AEBS-003 for classified pedestrian-target risk.

rationale: Classified pedestrian-target risk needs a defined response; specializes the REQ-AEBS-003 response family.

source: Derived from N-AEBS-006

traces: REQ-AEBS-003N-AEBS-006

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:213

requirement

REQ-AEBS-015

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Under defined applicable bicycle-target operating conditions, each SDV product-line member product shall apply the controlled AEBS response to classified bicycle-target collision risk.

REQ-AEBS-015 bicycle response draft; specializes the braking-command response family of REQ-AEBS-003 for classified bicycle-target risk.

rationale: Classified bicycle-target risk needs a defined response; specializes the REQ-AEBS-003 response family.

source: Derived from N-AEBS-007

traces: REQ-AEBS-003N-AEBS-007

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:223

requirement

REQ-AEBS-S2-001

ReadyForReview

subject: increment : NeedsRequirementsIncrement

The DE4SDV AEBS increment shall maintain trace links from each AEBS evidence contract to its controlled operational boundary, assumptions, source constraints, and exclusions.

REQ-AEBS-S2-001 System 2 evidence-contract candidate derived only from N-AEBS-002.

rationale: Evidence contracts are only reviewable against their controlled operational boundary.

source: Derived from N-AEBS-002

traces: N-AEBS-002

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:292

requirement

REQ-AEBS-S2-002

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall preserve source identity, timestamp, units, coordinate frame, freshness, validity, and bounded cardinality for each displayed AEBS value or state.

REQ-AEBS-S2-002 System 2 candidate derived from N-AEBS-009 and N-AEBS-010.

rationale: Preserves provenance for each displayed value.

source: Derived from N-AEBS-009 and N-AEBS-010

traces: N-AEBS-009N-AEBS-010

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:101

requirement

REQ-AEBS-S2-003

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall consume live output from the pinned native Autoware AEB component: RSS threshold data and the exact native intervention diagnostic.

REQ-AEBS-S2-003 System 2 candidate derived from N-AEBS-009.

rationale: Anchors the display to the pinned native Autoware AEB component.

source: Derived from N-AEBS-009

traces: N-AEBS-009

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:109

requirement

REQ-AEBS-S2-004

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall consume live DE4SDV AEBS warning request, braking request, and intervention lifecycle state from the existing AEBS coordinator.

REQ-AEBS-S2-004 System 2 candidate derived from N-AEBS-009.

rationale: Displays the DE4SDV coordinator's own warning, braking, and lifecycle state.

source: Derived from N-AEBS-009

traces: N-AEBS-009

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:125

requirement

REQ-AEBS-S2-005

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall expose no command path from display, bridge, or transport into Autoware, the AEBS coordinator, or vehicle control.

REQ-AEBS-S2-005 System 2 candidate derived from N-AEBS-013.

rationale: No command path from instrumentation into AEBS or vehicle control.

source: Derived from N-AEBS-013

traces: N-AEBS-013

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:133

requirement

REQ-AEBS-S2-006

ReadyForReview

subject: increment : VisualizationIncrement

When no valid frame is accepted for the selected bounded timeout, the visualization test system shall suppress threat geometry and present an explicit stale disposition.

REQ-AEBS-S2-006 System 2 candidate derived from N-AEBS-011.

rationale: Stale input must suppress threat geometry rather than display it.

source: Derived from N-AEBS-011

traces: N-AEBS-011

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:141

requirement

REQ-AEBS-S2-007

ReadyForReview

subject: increment : VisualizationIncrement

When no visualization source or service is available, or before the first valid frame arrives, the visualization test system shall present an explicit unavailable disposition.

REQ-AEBS-S2-007 System 2 candidate derived from N-AEBS-011.

rationale: Unavailable sources need an explicit disposition, not silence.

source: Derived from N-AEBS-011

traces: N-AEBS-011

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:149

requirement

REQ-AEBS-S2-008

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall reject unsupported schema, malformed, non-finite, out-of-range, stale-timestamp, and non-monotonic frames without displaying their payload values.

REQ-AEBS-S2-008 System 2 candidate derived from N-AEBS-011.

rationale: Malformed frames must be rejected without displaying payload values.

source: Derived from N-AEBS-011

traces: N-AEBS-011

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:157

requirement

REQ-AEBS-S2-009

ReadyForReview

subject: increment : VisualizationIncrement

After a failure disposition, the visualization test system shall present a bounded restored indication after the selected consecutive-valid-frame criterion is met, without application restart.

REQ-AEBS-S2-009 System 2 candidate derived from N-AEBS-011.

rationale: Recovery must be bounded and observable without application restart.

source: Derived from N-AEBS-011

traces: N-AEBS-011

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:165

requirement

REQ-AEBS-S2-010

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall render AEBS state in a native application inside a booted display-capable AAOS SDV guest.

REQ-AEBS-S2-010 System 2 candidate derived from N-AEBS-009 and N-AEBS-012.

rationale: The rendering surface must be the real AAOS guest application.

source: Derived from N-AEBS-009 and N-AEBS-012

traces: N-AEBS-009N-AEBS-012

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:173

requirement

REQ-AEBS-S2-011

ReadyForReview

subject: increment : VisualizationIncrement

The visualization test system shall retain source, transport, ingress, and guest identity, sequence, timestamp, log, and guest-native capture records for each rendered state so that each rendered state can be correlated with its observed source event.

REQ-AEBS-S2-011 System 2 candidate derived from N-AEBS-012.

rationale: Each rendered state must be correlatable with its observed source event.

source: Derived from N-AEBS-012

traces: N-AEBS-012

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:197

requirement

REQ-AEBS-S2-012

ReadyForReview

subject: increment : VisualizationIncrement

While AEBS state is rendered, the visualization test system shall observe the AAOS SDV guest package manager, system server, display composition, vehicle service, and SDV gateway within the same rendered session.

REQ-AEBS-S2-012 System 2 candidate derived from N-AEBS-009.

rationale: Runtime environment evidence must come from the same rendered session.

source: Derived from N-AEBS-009

traces: N-AEBS-009

textual-notation-of-model/packages/features/aebs/aebs_visualization_needs_requirements.sysml:181

requirement

REQ-MW-001

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall provide the ADAS application access to the vehicle signals required by its selected operational use cases through the selected middleware integration boundary.

REQ-MW-001 draft design-input requirement.

rationale: Signal access is the core middleware integration service for the ADAS application.

source: Derived from N-MW-001

traces: N-MW-001

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:42

requirement

REQ-MW-002

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall provide the ADAS application access to middleware and vehicle diagnostic status from which the health of the selected integration boundary can be determined.

REQ-MW-002 draft design-input requirement.

rationale: Boundary health determinations require diagnostic visibility.

source: Derived from N-MW-001

traces: N-MW-001

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:51

requirement

REQ-MW-003

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall coordinate middleware integration lifecycle state with the ADAS application so that startup, readiness, degraded operation, and shutdown transitions are observable at the integration boundary.

REQ-MW-003 draft design-input requirement.

rationale: Lifecycle transitions must be observable at the integration boundary.

source: Derived from N-MW-001

traces: N-MW-001

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:60

requirement

REQ-MW-004

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall monitor the health of the selected middleware integration boundary and provide an observable indication when a required integration service is stale, missing, inconsistent, or unavailable.

REQ-MW-004 draft design-input requirement.

rationale: Degraded integration services must be detected and indicated.

source: Derived from N-MW-001

traces: N-MW-001

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:69

requirement

REQ-MW-005

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall coordinate middleware integration updates with the ADAS application lifecycle so that an update does not silently invalidate required signal, diagnostic, lifecycle, or health interfaces.

REQ-MW-005 draft design-input requirement.

rationale: Updates must not silently invalidate required interfaces.

source: Derived from N-MW-001

traces: N-MW-001

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:78

requirement

REQ-MW-006

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall prevent a failure of the non-safety middleware integration path from causing an uncontrolled emergency intervention command, whether the selected realization uses a safety-certified middleware partition or a direct vehicle-command path.

REQ-MW-006 draft safety-constraint requirement; architecture choice and containment criteria remain open per GAP-MW-029.

rationale: Middleware failure must not cause uncontrolled emergency intervention; containment criteria open per GAP-MW-029.

source: Derived from N-MW-004

traces: N-MW-004

references: GAP-MW-029

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:87

requirement

REQ-MW-007

ReadyForReview

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall discover and bind the middleware services required by the selected ADAS application integration configuration before those services are used.

REQ-MW-007 draft design-input requirement.

rationale: Services must be bound before use for decoupled integration.

source: Derived from N-MW-002

traces: N-MW-002

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:96

requirement

REQ-MW-008

InDevelopment

subject: memberProduct : ProductLineMemberProduct

Each SDV product-line member product shall authenticate a middleware service binding before accepting service data or commands across a trust boundary defined for the selected integration configuration.

REQ-MW-008 draft security constraint derived from N-MW-009; trust-boundary details remain deferred per GAP-MW-012.

rationale: Service data and commands across a trust boundary must be authenticated; boundary details deferred per GAP-MW-012.

source: Derived from N-MW-009

traces: N-MW-009

references: GAP-MW-012

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:105

requirement

REQ-MW-009

ReadyForReview

subject: increment : NeedsRequirementsIncrement

The DE4SDV middleware increment shall maintain trace links from each middleware requirement to its stakeholder need, operational-context source, feature/common-capability classification, unresolved gap, and planned verification record.

REQ-MW-009 System 2 traceability requirement.

rationale: Trace links are the increment's assurance backbone.

source: Derived from N-MW-006

traces: N-MW-006

textual-notation-of-model/packages/features/middleware/middleware_requirements.sysml:116

problem statement

aebsNeedsRequirementsProblemStatement

subject: increment : NeedsRequirementsIncrement

stakeholders: roadUser · occupant · systemsEngineer · productLineEngineer · complianceEngineer · verificationEngineer

How can DE4SDV define partitioned AEBS product and assurance needs and draft requirements while preserving boundaries, gaps, and controlled source constraints without making realization or compliance claims?

textual-notation-of-model/packages/features/aebs/aebs_needs_requirements.sysml:41

evidence contract

evidenceContractClosedInputHealthScenario

subject: bench : DegradedInputMatrixBench

The bench shall inject exactly one closed stale, missing, malformed, inconsistent, or unavailable input condition after any required healthy baseline. A degraded state is accepted only while its observation age stays within 0.2 s, detection is closed within a 0.25 s window, and runtime-graph sampling gaps stay at or below 0.2 s.

textual-notation-of-model/packages/features/aebs/aebs_degraded_input_verification.sysml:42

evidence contract

evidenceContractConfigurationBoundedVerdict

subject: bench : RegulatoryCriterionBench

The bench shall limit the verdict to one exact tested configuration. Missing applicability, prescribed conditions, target fidelity, uncertainty, repetitions, source control, or provenance shall be inconclusive or error. Compliance, certification, homologation, and type approval remain withheld.

textual-notation-of-model/packages/features/aebs/aebs_regulatory_criterion_verification.sysml:78

problem statement

middlewareIntegrationProblemStatement

subject: increment : MiddlewareIncrement

stakeholders: platformEngineer · systemsEngineer · productLineEngineer · safetyExpert · maintainer · verificationEngineer · reviewer

How can DE4SDV model middleware integration between a domain-specific ADAS application and a vehicle platform so that platform decoupling, product-line variability, safety-path boundaries, upstream engagement, and evidence traceability remain explicit without selecting a concrete realization?

textual-notation-of-model/packages/features/middleware/middleware_increment_framing.sysml:29