Using Model-Based Design to Develop and Test SOA Applications for In-Vehicle Operating Systems
By Wei Min, ZEEKR Intelligent Technology Holding Limited
“We are refining and expanding our workflow based on Model-Based Design with MATLAB, Simulink, System Composer, and Embedded Coder. This workflow has already proven its value by accelerating development and minimizing challenges inherent in handwriting code.”
The automotive industry is undergoing a profound transformation as vehicles evolve from traditional mechanical systems to software-defined vehicles (SDVs). This shift demands new approaches to software development, with service-oriented architecture (SOA) emerging as the preferred paradigm for designing flexible, scalable automotive applications. At ZEEKR, we’ve embraced this transition by establishing a comprehensive workflow based on Model-Based Design for developing SOA applications that run on our in-vehicle operating system.
Traditional automotive software development using Model-Based Design has focused primarily on AUTOSAR® Classic Platform implementations, where software components (SW-Cs) interact through standardized run-time environment (RTE) interfaces. However, SOA introduces new communication patterns such as client-server calls and message-based interactions, requiring significant adjustments to established development practices. The challenge lies not only in modeling these new communication patterns but also in managing the increased complexity of software architectures within a non-AUTOSAR standardized environment.
Our group at ZEEKR has addressed these challenges with a workflow based on Model-Based Design for SOA application development. This article describes three key areas of this workflow:
- Modeling SOA behavior using the client-server interface capabilities of Simulink®
- Maintaining complex software architectures through customized tools based on System Composer™
- Implementing effective verification and validation for SOA applications
Our experience demonstrates how engineers can use Model-Based Design to accelerate the transition from traditional embedded systems to modern SOA-based software architectures for SDVs.
Modeling Service-Oriented Applications in Simulink
SOA introduces new communication patterns that differ fundamentally from those of traditional embedded systems. Classic AUTOSAR applications communicate through simple RTE interfaces, which facilitate tightly coupled, statically defined interactions between software components. In contrast, SOA communication patterns—such as remote procedure calls and message-based interactions—are more flexible and sophisticated. They also enable the decoupling of both hardware and software, as well as software hierarchical design. To take full advantage of these patterns, we follow a development workflow built upon Model-Based Design that includes modeling the SOA applications in Simulink, generating C++ code with Embedded Coder®, creating middleware integration code with a wrapper generator that we built, and merging both application and integration code into deployable application packages. This automated workflow doesn’t need any handwritten C++ code. The automatically generated wrapper code bridges the application code that we generated from our Simulink models with the run-time environment—ZEEKR ARK OS.
A typical SOA model in our workflow includes service providers and clients, both modeled in Simulink (Figure 1). This structure captures essential SOA behavior: decoupled service invocation, explicit message exchange, and a clear separation between communication and computation. It enables us to express SOA concepts clearly within Simulink and prepare those models for deployment in a distributed, service-based environment.
Figure 1. A simple client and server modeled in Simulink. The client includes a receiver block triggered periodically by a control signal (“Step”) and a sender block.
Our deployment scenarios span both central and distributed computing environments (Figure 2). The service-oriented applications, modeled in Simulink, run on a high-performance central computing unit. Meanwhile, Classic AUTOSAR components—also developed in Simulink—execute on a microcontroller, directly interfacing with vehicle actuators. This mixed deployment reflects the broader trend toward centralized domain architectures, where domain controllers manage high-level processing while edge nodes handle low-level control. With Simulink, we can support both aspects of this architecture, using a unified development environment to model, simulate, and generate code for heterogeneous automotive systems.
Figure 2. A real-world air conditioning application developed in Simulink, combining SOA software deployed to a central processor node with an AUTOSAR Classic SW-C running on a microcontroller to drive the actuator.
Managing Complex Software Architectures with System Composer
As service-oriented applications grow in scope and complexity, managing their structure becomes a critical challenge. With multiple services interacting across multiple software units, it’s no longer sufficient to treat each model in isolation. Instead, we need a clear architectural representation of how software components relate to one another, including how they’re grouped, how they communicate, and where they are deployed. Many commercially available automotive software architecture tools, including AUTOSAR authoring tools, often assume an AUTOSAR-based environment and don’t support the flexibility of deploying service-based communication models for custom operating systems. To meet the needs of our SOA framework and in-vehicle OS, we built our own architecture modeling environment. SOA Model Composer—or SOMOC—builds on the model-based systems engineering capabilities and architectural design elements of System Composer, as well as the object-oriented programming capabilities of MATLAB®. For ease of use, we created a custom user interface with MATLAB and App Designer (Figure 3).
Figure 3. The SOMOC user interface, including the architecture tree view (left) and the component composer interface (right).
SOMOC supports a structured approach to defining and managing SOAs across four key levels: system architecture, process, software component, and service definition (Figure 4). This hierarchical organization uses the reference component capabilities of System Composer to establish clear traceability from high-level systems down to individual services.
Figure 4. Component hierarchy in SOMOC, showing architecture, process, SW-C, and service levels.
SOMOC extends the architecture models with custom profiles and stereotypes that capture SOA-specific metadata such as service identifiers, namespaces, and version information. ZEEKR system architects use SOMOC to translate functional requirements (imported from ARXML files generated during system design) into deployable architectures by defining process boundaries, service interfaces, and software components. From these architecture models, SOMOC automatically generates shell Simulink models with consistent interfaces, providing developers with a reliable starting point for implementing internal behavior or logic (Figure 5). This automation standardizes the architecture-to-implementation workflow, keeps interfaces synchronized, and gives our teams a shared reference point throughout the development.
Figure 5. Different layers being designed and tested within the SOMOC framework.
Multilevel Testing for SOA Applications
At ZEEKR, we validate our service-oriented applications through a combination of model-level and code-level testing. We begin with unit and model testing in Simulink with Simulink Test™, using test harnesses to isolate individual components and verify service interactions (Figure 6). For each model, engineers can simulate communication with counterpart components—such as a simulated provider for a consumer model—and verify the expected responses and interface behavior. This early-stage validation helps identify logic errors or interface mismatches before code is generated.
Figure 6. The test sequence of a test harness shown in the Test Sequence Editor.
After generating application code and integrating it with our in-vehicle OS, we perform run-time testing using our Service Verification Toolkit (SVT), a lightweight plugin within Visual Studio Code (Figure 7). SVT enables teams to import service interface definitions from ARXML files and then test both method and topic interfaces by simulating service communication at the application level. It can act as either a consumer or a provider—sending method requests, handling responses, publishing topic data, or subscribing to messages. SVT displays the values exchanged across service interfaces, helping engineers confirm that the deployed application behaves correctly under different interaction scenarios.
Figure 7. The SVT plugin in Visual Studio Code.
Looking Forward
As we continue to develop new service-oriented applications for our in-vehicle deployment, we are also refining and expanding our workflow based on Model-Based Design with MATLAB, Simulink, System Composer, and Embedded Coder. This workflow has already proven its value by accelerating development and minimizing the challenges inherent in handwriting code. With the ability to perform architecture modeling, service modeling, simulation, code generation, and testing of service-oriented and AUTOSAR-based applications in one environment, we have a scalable software foundation to support SDV development as it continues to reshape the automotive landscape.
Published 2025
