textual-notation-of-model/packages/features/middleware/mw_increment_framing.sysml

Source

1/*2 * DE4SDV middleware increment framing model slice.3 *4 * INC-MW-002 frames the middleware integration increment only. It establishes5 * the question, scope shell, traceability shell, and assurance view for the6 * middleware integration story. It does not commit to AAOS SDV, Eclipse7 * S-CORE, AUTOSAR Adaptive, adapter realization, or any physical/software8 * implementation choice.9 */1011package DE4SDV_MWIncrementFraming {12  package Features {13    package Middleware {14      package IncrementFraming {15        private import Views::*;16        private import DE4SDV_Stakeholders::*;17        private import DE4SDV_MethodContext::*;18        private import SAF_Viewpoints::*;1920        part def MiddlewareIncrement :> EngineeringIncrement;2122        part incMW002 : MiddlewareIncrement {23          doc /*24           * INC-MW-002: middleware integration operational context and framing25           * shell.26           */27        }2829        requirement middlewareIntegrationProblemStatement : ProblemStatement {30          doc /* 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? */31          subject increment : MiddlewareIncrement;32          stakeholder platformEngineer : SystemsEngineer;33          stakeholder systemsEngineer : SystemsEngineer;34          stakeholder productLineEngineer : ProductLineEngineer;35          stakeholder safetyExpert : SafetyExpert;36          stakeholder maintainer : Maintainer;37          stakeholder verificationEngineer : VerificationEngineer;38          stakeholder reviewer : OpenSourceReviewer;39        }4041        part scopeMW002 : IncrementScope {42          doc /*43           * Scope: vehicle signals, lifecycle coordination, health monitoring,44           * diagnostics, update coordination, and the explicit emergency45           * intervention boundary.46           */47        }4849        part traceabilityShellMW002 : IncrementTraceabilityShell {50          doc /*51           * Traceability shell: increment framing -> concerns/views ->52           * operational context -> operational story -> assumptions/gaps.53           */54        }5556        part engineeringQuestionMW002 : IncrementEngineeringQuestion {57          doc /*58           * What operational scenarios require middleware integration between an59           * ADAS application and the vehicle platform, and who are the60           * operational actors?61           */62        }6364        part lifecycleDecisionMW002 : IncrementLifecycleDecision {65          doc /*66           * Decide whether the middleware operational context is correctly scoped67           * before deriving requirements or functional architecture.68           */69        }7071        part asmMW005 : IncrementAssumption {72          doc /*73           * ASM-MW-005: The operational scenarios assume the ADAS application is74           * already functionally complete. The middleware integration does not75           * change what the ADAS application does — it changes how the ADAS76           * application accesses vehicle platform services.77           */78        }7980        part asmMW006 : IncrementAssumption {81          doc /*82           * ASM-MW-006: The middleware provides vehicle signals, diagnostics,83           * lifecycle, health, and update coordination as distributed services.84           * The operational context does not assume a specific middleware85           * implementation.86           */87        }8889        part asmMW007 : IncrementAssumption {90          doc /*91           * ASM-MW-007: Multiple SDV Core instances may operate together (as92           * separate VMs on one SoC, on different SoCs, or across the vehicle93           * network). The operational context covers the distributed case, not94           * just a single instance.95           */96        }9798        part gapMW006 : IncrementGap {99          doc /*100           * GAP-MW-006: The specific vehicle signals that the ADAS application101           * needs from the middleware are not yet enumerated. This is deferred to102           * INC-MW-005 (requirements).103           */104        }105106        part gapMW007 : IncrementGap {107          doc /*108           * GAP-MW-007: The mapping between ROS 2 topics and middleware service109           * interfaces is not yet defined. This is deferred to INC-MW-006110           * (functional architecture) and INC-MW-008 (physical realization).111           */112        }113114        part gapMW008 : IncrementGap {115          doc /*116           * GAP-MW-008: The security and trust boundary for middleware117           * communication (DICE identity, attestation, VLAN segmentation) is not118           * yet modeled. This is deferred to a security-focused increment or119           * INC-MW-005 (requirements).120           */121        }122123        concern mwIncrementAssuranceConcern : ArgumentationAssuranceConcern {124          doc /*125           * Reviewers need the increment claim, scope, assumptions, gaps, and126           * traceability shell linked in an assurance argument for this127           * middleware framing slice.128           */129          subject;130          stakeholder systemsEngineer : SystemsEngineer;131          stakeholder reviewer : OpenSourceReviewer;132        }133134        view mwIncrementAssuranceView {135          viewpoint selectedIncrementAssuranceViewpoint : ArgumentationAssuranceViewpoint {136            frame mwIncrementAssuranceConcern;137          }138139          expose IncrementFraming::*;140          render asTreeDiagram;141        }142      }143    }144  }145}146