Bridging System and Software: A Unified Approach for Feature Development of SDV Distributed Architectures

How can software-defined vehicle (SDV) development teams make the right architectural and software decisions early—and continuously validate them—when features span central computers, zonal controllers, and edge devices, blending service-oriented and signal-based architectures across complex integration boundaries?

SDVs are redefining automotive engineering—and not just by adding more code. They are reshaping where software runs, how features are composed, and what “integration” really means. As features stretch across compute domains, communication protocols, and even different organizations, teams need approaches that keep architectural intent and software behavior aligned from day one.

However, this architectural freedom comes with a cost: There are more interfaces, more timing paths, more failure modes, and more ways for small mismatches to surface late, especially when vehicles, suppliers, and schedules are already locked. In this environment, systems and software engineers must make the right decisions early and validate them continuously with models and simulation.

To help companies address this challenge, KPIT and MathWorks bring together the application of proven methodologies, deep automotive domain expertise, and an integrated toolchain that connects system intent to executable models. The result is an end-to-end, traceable workflow that supports early architectural and software decisions—and continuous validation through simulation—linking stakeholder intent (as a single source of truth) to architecture choices, deployable software, and verification evidence.

Key Challenges in Distributed SDV Features

SDV feature development rarely fails because one team wrote “bad code.” It fails because the feature crosses ECU boundaries, mixes service-oriented and signal-based interactions, and exposes gaps between design and implementation. Those gaps tend to hide until late integration—so the following challenges often determine whether a program can deliver complex features quickly and confidently:

• Requirements ambiguity at scale: Functional and nonfunctional requirements must account for distribution, timing, partial failures, safety, and cybersecurity.
• Architecture decisions propagate downstream: Service versus signal choices and ECU allocation drive interfaces, software partitioning, and verification effort.
• Cross-team alignment: Multidomain teams need shared, traceable models to avoid late rework.
• Toolchain fragmentation: Disconnected tools hinder traceability and “shift-left” validation; virtual integration requires consistent architecture and behavior models.

A Unified Model-Based Systems Engineering and Model-Based Design Workflow

This article presents a feature-driven engineering approach that unifies model-based systems engineering (system/feature intent, requirements, and architecture) with Model-Based Design (executable software models, simulation, and code generation). The workflow follows a systematic, top-down approach to architecture and requirements development, with the right level of abstraction applied at each stage. It can be applied to develop SDV features that span heterogeneous ECUs and mix service-oriented and signal-based interactions.

This approach accelerates feature delivery by integrating and validating distributed features in a simulated environment using connected ECU and software component models. It also improves end-to-end traceability for impact analysis and compliance, reducing late-stage rework when deploying across central, zonal, and edge ECUs.

In practice, teams need a way to make architectural decisions testable early: Can this feature meet timing demands across zones, survive partial failures, satisfy safety/cybersecurity constraints, and still be implemented consistently across AUTOSAR^® Classic/Adaptive targets? A unified model-based systems engineering and Model-Based Design workflow makes those questions explicit—and answerable—before hardware and full-vehicle integration.

Let’s go through the main workflow steps of the feature-driven approach:

1. Feature scoping: Capture stakeholder needs, define feature boundaries, actors, and dependencies.
2. Requirements: Define use cases and behavior, derive system requirements (functional and nonfunctional) with clear acceptance criteria.
3. System architecture: Create and validate functional architecture (functions and interactions), platform-independent subsystem identification and architecture, and platform-dependent system architecture (ECUs/networks and service versus signal decisions).
4. Software architecture: Derive software requirements and software architecture per ECU (HPC/zonal/edge), aligned with AUTOSAR Classic/Adaptive or custom needs.
5. Detailed software design: Develop executable models for algorithms and component behavior and reuse legacy assets where possible.
6. Functional verification: Run model-in-the-loop/closed-loop simulations to validate behavior before hardware is available.
7. Code generation and integration: Generate production-ready AUTOSAR Classic/Adaptive or custom code, with seamless integration into CI and verification workflows.

These are the key benefits provided by following the proposed approach:

• Early detection of defects: Executable models and simulation expose integration and timing issues before hardware and full vehicle integration.
• Faster iterations: Virtual integration testing reduces rework loops and accelerates feature delivery.
• Traceable engineering: Consistent links across artifacts enable coverage checks and efficient impact analysis when requirements change.
• Reusable architecture assets: Logical architecture provides a platform-independent reference for reusable systems across vehicle programs.
• Deployment-ready outputs: Software architecture and code generation are aligned with AUTOSAR Classic/Adaptive and mixed SOA/signal communication.

In the rest of the article, we’ll show the approach in action through a real use case.

Example: Developing a Charging-Flap Management Feature

To demonstrate this workflow, we walk through a real feature that touches users, hardware, networking, and safety constraints: the charging-flap management of an electrified vehicle. This example shows how a feature-driven process moves from scoping and requirements to architecture allocation, simulation, and production code generation, without losing traceability along the way.

A flap management system controls the vehicle’s charging inlet flap (Figure 1). It continuously reconciles the physical world (e.g., position sensing, actuator state, and latch/lock feedback) with charging context (e.g., vehicle state, onboard charger status) to decide when the flap can open, must close, or should lock. The system then publishes status updates and warnings to the driver and other vehicle functions. By spanning sensing, actuation, and ECU coordination, the flap management system provides a small but realistic proxy for broader SDV distributed feature development.

Feature Scoping

We define the feature boundary (actors, inputs/outputs, and dependencies) to establish a shared scope and to feed the requirements elicitation and analysis.

In this example, we assume the vehicle uses an existing electric/electronic (E/E) zonal architecture consisting of a high-performance central computer (HPC), a zonal ECU that also serves as a gateway, and edge ECUs responsible for real-time sensing and actuation.

At this stage, we perform an impact analysis and use System Composer™ to derive a feature boundary diagram that captures the features affected by the flap management and the information exchanged across those features. The boundary view clarifies which vehicle functions and external actors interact with the flap management feature and what information is exchanged (Figure 2).

Functional Level

We capture the main use cases and derive feature behavior through a use case diagram, then translate that behavior into clear system-level requirements. We identify two use cases: “Start a charging session” and “Stop a charging session” (Figure 3).

Once the two use cases have been identified, the next step is to define the different activities performed by the feature in each use case. This will help describe the feature’s behavior and capture an initial set of system-level requirements for flap management. Then, we use System Composer to create activity diagrams (Figure 4).

Based on the previous analysis and diagrams, we can now create the system-level requirements using the Requirement Editor, part of Requirements Toolbox™ (Figure 5). We have requirements related to the operations, such as opening and closing the flap and notifying the flap status.

Next, we create a functional architecture and allocate requirements to functions to maintain traceability. This includes the definition of:

• System functions: technical functional units that collectively realize the feature
• Interactions: how these functions communicate and work together

Based on the analysis of the system requirements, we decompose the charging-flap feature into four functions (Figure 6):

• Measure charging socket current
• Get flap status and notify user
• Close flap
• Open flap

As part of the definition of the functional architecture, we allocate each system requirement to the function(s) responsible for fulfilling it, and, where relevant, to the interaction that carries the needed information. This allocation ensures every requirement is covered by design elements, makes gaps/overlaps visible early, and provides traceability from requirements to functions for downstream logical/physical design and verification. Practically, this allocation can be performed efficiently via dragging and dropping requirements onto System Composer components (Figure 7).

Platform-Independent Subsystem Identification and Architecture

We allocate functions to logical subsystems and define the logical interfaces between them to create a reusable, platform-independent architecture view (Figure 8):

• A charging interface subsystem, responsible for opening and closing the flap and for notifying the flap status
• A charging control subsystem, responsible for orchestrating the requests coming from the communication interface and managing all the charging operations
• A charging communication subsystem, which manages communications with the user and the rest of the system

Platform-Dependent System Architecture

Now, we allocate the logical subsystems to a target E/E architecture (e.g., edge ECU, zonal controller, and central computer/HPC) and define the main interfaces, including which interactions are implemented as services or signals.

Once we have identified the different components, we can create a system architecture diagram in System Composer, which highlights the component boundaries and the information that the components must exchange to implement the flap management feature (Figure 9).

Software Architecture, Simulation, and Code Generation

From the system requirements and system architecture, we derive per-ECU software requirements and architecture (HPC, zonal, edge) and refine them into deployable software components. On the HPC, the feature is decomposed into services and applications (e.g., AUTOSAR Adaptive, where applicable), while zonal/edge nodes host time-critical sensing/actuation functions (e.g., AUTOSAR Classic or equivalent). Interfaces (services, signals, and data types) are carried consistently from the physical architecture into software ports and connectors, enabling early consistency checks, executable behavior modeling, and integration of simulation hooks (for MIL/SIL and closed-loop runs) before target hardware is available.

To get started, we create the top-level software architecture for HPC, zonal ECU, and edge ECU compositions, which are linked to the system architecture (Figure 10).

We defined and modeled software components for each architectural composition within the architecture modeling canvas in System Composer. The HPC composition comprises three AUTOSAR Adaptive service components implemented in Simulink^® using a SOA paradigm (Figure 11).

Once we have modeled the implementation of the feature across the three ECUs, we can create a closed-loop simulation model that connects the ECUs to a plant model of the flap—including models of the current sensor, position sensor, and actuator—thus enabling fast verification of functional behavior under realistic conditions. For example, we can use simulation to assess how the system responds to a user request to open the flap at different vehicle speeds (Figure 12).

Once verification is complete, the next step in the workflow is using Embedded Coder® to generate production-ready code for integration and deployment (Figure 13). Simulink provides out-of-the-box support for generating both AUTOSAR Classic and AUTOSAR Adaptive–compliant code, enabling further integration and deployment.

Furthermore, when a new requirement is introduced, it can be captured at the system-requirements level and subjected to impact analysis to identify affected elements. The resulting changes are visualized and propagated to the relevant system and software interfaces, after which the workflow is iterated to accommodate evolving requirements. This process is enabled through end-to-end traceability, using the traceability diagram (Figure 14) to manage dynamic change throughout the SDV development lifecycle.

Migration of Legacy Applications

Beyond greenfield feature development, the same integrated workflow also supports the systematic migration of legacy, signal-based functions toward service-oriented, distributed software architectures. In practice, existing functions originally implemented as tightly coupled runnable chains exchanging CAN signals or ECU-local data can be analyzed at the functional and logical levels, decomposed into clearer responsibilities, and refactored into service providers, consumers, and orchestration logic with explicitly defined interfaces, events, and data contracts. This makes it possible to preserve validated functional behavior while reallocating responsibilities across HPCs, zonal controllers, and edge ECUs. It also makes it possible to assess the impact of communication changes on timing, safety, and integration. Because requirements, architecture elements, software components, and verification artifacts remain traceably connected, teams can modernize legacy implementations incrementally—reusing test cases and compliance evidence while maintaining alignment between migrated services and original design intent.

Conclusion

Integrating model-based systems engineering and Model-Based Design provides a practical, end-to-end workflow for SDV feature development, enabling clearer system intent, earlier verification through simulation, and deployable software artifacts. This approach is explicitly feature-driven and structured to leverage traceability across all design stages, so engineering decisions stay consistent from intent to deployment. The payoff is tangible, as the workflow delivers faster iterations, fewer late-stage integration surprises, and more consistent implementation across heterogeneous ECUs and mixed SOA/signal architectures.

As the industry explores AI-driven development methodologies—including emerging agentic AI approaches—questions are arising about the role of established engineering practices. In this new context, the value of model-based systems engineering and Model-Based Design approaches becomes even clearer: In a development loop where humans and AI increasingly collaborate, these approaches provide the rigor needed to anchor requirements, clarify system intent, and keep architecture, behavior, and verification aligned. This makes them a critical foundation for delivering SDV software that is not only innovative, but also trustworthy and maintainable.

Using KPIT’s automotive expertise and toolchain continuity provided by MathWorks, the proposed framework strengthens collaboration among architects, software developers, and integration engineers, improves requirement-to-architecture traceability, and supports increasingly complex system definitions without sacrificing feasibility.

Learn More