What this is

A practice model showing where EE&S plugin artifact types naturally land on the ASPICE process grid, using a Collision Avoidance System (ADAS) as the reference system. The point isn't the system — it's demonstrating that the tool's native constructs map directly to ASPICE work products, and that the chain doesn't stop at architecture.

ASPICE Process → EE&S Artifact Mapping

SYS.1 — Requirements Elicitation: Stakeholder Needs table with user story structure per actor (Driver, Passenger, Pedestrian, Cyclist) and design constraints referencing ISO 26262, ISO 21434, ISO 14229. Native model view — not a document.

SYS.2 — System Requirements Analysis: System Requirements table using sysml:Requirement stereotype, organized into functional and non-functional categories. 40+ requirements, all traceable to stakeholder needs via Derive/Satisfy. Requirements exist as model elements with bidirectional traceability.

SYS.3 — System Architectural Design: Three synchronized views — Functional Use Case, Functional Architecture (EEFunction + EEFunctionalFlow + EEFunctionalPort), Hardware Architecture (ElectronicControlUnit, Sensor, Actuator, CANBus, Switch, VirtualLocalAreaNetwork). Full EV ADAS topology: Front/Rear Camera, LIDAR, Radar → LANSeries Ethernet switches → Zonal ECUs → Central ADAS ECU over CAN ADAS, VLAN 10/20.

SYS.4 — System Integration: Component allocations, signal-based allocations (CAN_ADAS + ETH_ADAS matrices), end-to-end signal routing (producer → physical path → consumer), SOME-IP service deployment on Ethernet, Ethernet port IP configuration matrices.

SWE.1 — Software Requirements Analysis: Software Requirements derived from SYS.2 via sysml:DeriveReqt. 55+ SW-level requirements (Lane Detection, Object Detection, Perception Data Aggregation, Collision Risk Analysis, Perception Algorithm Control, Driver Warning, Vehicle Actuation Control). Parent changes propagate automatically — no manual sync.

SWE.2 — Software Architectural Design: Software block diagram using SoftwareArchitecture:SoftwareComposition and SoftwareAtomicComponent stereotypes, with SenderReceiverPort interfaces and behavioral state machines. Key capability here: EE&S software architecture is AUTOSAR compliant. The model exports a native ARXML file from SWE.2, which can be imported directly into any AUTOSAR-compliant tool — Vector DaVinci Developer, EB tresos, Mentor Volcano, or equivalents — for ECU configuration, OS integration, and code generation. The architecture isn't just modeled, it feeds your production toolchain.

SWE.3 — Software Detailed Design and Unit Construction: Covered by the Software Producer (SOP) plugin for CATIA Magic, which is available with the platform at no additional license cost. SOP enables detailed design and unit construction directly in CATIA Magic, extending the traceability chain from system requirements all the way to code — without exiting the tool or breaking the model. This closes the loop: end-to-end from stakeholder need to deployable software, fully within the CATIA Magic ecosystem, with unbroken traceability at every level.

The value proposition in one sentence

EE&S gives you the right modeling construct at every ASPICE process level, AUTOSAR compliance at SWE.2 with native ARXML export, and a path to SWE.3 code generation via SOP — all within CATIA Magic, all traceable.

Built on CATIA Magic 2026x. Happy to share the .mdzip or go deeper on the AUTOSAR export workflow or SOP integration in the comments.

#CATIAMagic #EES #MagicSystemsEEArchitect #AUTOSAR #ARXML #ASPICE #MBSE #SysML AutomotiveEngineering SystemEngineering ADAS-AD