Software-defined vehicles (SDVs) are characterized by AI, autonomy, connectivity, and electrification. Recently, the automotive industry has begun adapting a “service-based” approach in designing modern-day applications for SDVs. This approach, known as service-oriented architecture (SOA), offers a new paradigm for developing software applications that are characterized by high reusability, ease of updates, and loose coupling with hardware. SOAs are built on the principle that an application is composed of a collection of services that can be dynamically discovered, published, subscribed to, and reconfigured during run time. The concept of SOA has been widely incorporated into industry standards, including AUTomotive Open System ARchitecture (AUTOSAR).

Within an SOA framework, services are self-contained, modular, and loosely coupled, allowing for the creation of complex and distributed applications that are nonmonolithic in nature. SOA-based applications can be developed using either a top-down or bottom-up approach. In a standard SOA software stack, the application software consists of services, platform services, and middleware, all running on high-performance hardware or virtual machines.

Challenges in Migrating Legacy Application to SOA

Migrating a legacy application to a SOA can be challenging due to several properties of the legacy application. These include:

• Monolithic design: Legacy applications often have a monolithic design (Figure 1), where components are tightly coupled and interconnected. This makes it difficult to break down the application into separate services, as the functionality is intertwined and not modularized.

• Order of execution: Legacy applications typically have a predefined order of execution for their components. This sequential nature of execution can make it complicated to convert the application into independent services that can be dynamically discovered and reconfigured at runtime.
• Signal and time-based communication: Legacy applications often rely on signal-based or time-based communication between components. In an SOA, communication is typically based on service interfaces and exchanging messages. Adapting the communication mechanisms from the legacy application to a service-oriented approach requires careful consideration and potentially redesigning the communication protocols.

Overcoming these challenges often involves a comprehensive analysis of the legacy application’s architecture and carefully identifying the service boundaries and dependencies between components. It may require refactoring the application into more modular and loosely coupled units that can be encapsulated as services within the SOA framework.

Converting a legacy application composition into a service is a complicated task. For instance, a previously designed monolithic application composition like the highway lane-following application can be transformed into a single service or decomposed into multiple services such as camera service, vision service, radar, and lane guidance services.

System expertise along with Model-Based Design can help in decomposing the monolithic application design to service functions encapsulating and abstracting one logical component from the other. It can enable migration of signal-to-service interfaces and determination of the right order of execution. In this article, we will explain a Model-Based Design workflow to model new services or convert your traditional application composition to services based on AUTOSAR Adaptive concepts for SDVs.

Decomposition of Traditional Application Software Compositions into Services

Decomposing traditional application software compositions into services for SOA applications involves breaking down the monolithic architecture into smaller, more modular components (Figure 2). This enables greater flexibility, scalability, and adaptability in the context of SDV.

There are four steps involved in decomposing traditional application software compositions into services for SOA applications.

• Identify and analyze services: Identify the services, components, functionalities, order of execution, and dependencies that make up the SOA. This is the most difficult part for the engineers. Once completed, they must analyze services to decompose the traditional monolithic applications into smaller components (Figure 3).

• Define services and interfaces: Once the services are identified, it’s important to define the interfaces between them. This involves specifying the protocols and data formats used to communicate between services and defining service contracts that specify the terms and conditions of the interaction between services.
• Define service contracts: This step specifies the terms and conditions of the interaction between services. These concepts are introduced in the 22-11 schema of AUTOSAR, which specifies versioning of services, allowing for new versions of services to be released without breaking existing clients.
• Implement and deploy services: Implement the service and deploy it as a standalone application with its own artifacts including interface descriptions.

Migration to Services Using Model-Based Design

Model-Based Design has been used to develop applications for non-AUTOSAR and AUTOSAR Classic frameworks. It can also be used to develop SOA-based applications for AUTOSAR Adaptive and generic SOA frameworks. For SDV applications, the industry has commonly utilized either a generic SOA or one based on the AUTOSAR Adaptive platform. Model-Based Design has added value by providing a unified development platform that can effectively handle the entire development process for all types of platforms including SOA, AUTOSAR Classic, and AUTOSAR Adaptive, ensuring consistency and efficiency across the board.

Using Model-Based Design to decompose monolithic application components into services involves the following steps:

• Identify and analyze services: Understand the various components, their functionalities, order of execution, and the dependencies between them. In a monolithic application, all components are deployed together as a single executable (Figure 4). However, when decomposing into services, each individual service is deployed independently.

For example, in Figure 4 there is a highway lane-following application developed in Simulink^®, which is deployed as a monolithic application composition. To decompose such monolithic components into services using Simulink (Figure 5), the principles of single-responsibility and dependency inversion are used. By leveraging these principles, the highway lane-following model is decomposed into multiple services such as radar, vision, and lane. These services have well-defined responsibilities and loosely coupled dependencies, allowing changes made to one service to be isolated and have minimal impact on other services.

Figure 5. Decomposition of monolithic legacy applications to services using Model-Based Design (left). The monolithic app is broken down into SOA-based services and connects them with client-server ports (right).

• Define services and interfaces: A service defined using interfaces is part of a service boundary that serves as the communication channel through which the service interacts with other services. Additionally, service boundaries encapsulate functionality to achieve reuse, maintainability, version control, visibility, orchestration, and other benefits. With System Composer™, you can configure the ports of relevant service components for data consistency, representing how those services interact with each other along with stereotypes. This provides a visual representation of the dependencies and interactions between services (Figure 6).

Figure 6. Configuring service interfaces and ports of the service components in Simulink.

• Define service contracts: It is recommended to establish clear boundaries for services, defining their inputs, outputs, and behavior. This allows services to be developed, tested, and deployed independently, without being tightly coupled to other parts of the architecture. By defining service contracts, you can understand the capabilities and limitations of the service and can more easily integrate with them (Figure 7). Additionally, service contracts allow new versions of services to be released without breaking existing clients.

Figure 7. Each service is modeled with inputs, outputs, and its application logic. These models are simulated and observed interactions between the services.

• Implementation and deployment: Using client-server interfaces in Model-Based Design, you can author SOA software architecture models. The LaneGuidanceApp, DetectionApp, radar, and vision algorithms implemented as services in Simulink are shown in Figure 8.

Furthermore, C++ code can be generated for generic SOA applications using Embedded Coder^®.

Configuring Services to AUTOSAR Adaptive Applications

These services can be seamlessly configured for AUTOSAR Adaptive using Simulink modeling constructs. As depicted in Figure 9, we have successfully integrated all services to function as AUTOSAR Adaptive services using an intuitive AUTOSAR editor within System Composer. Subsequently, we have established the necessary mappings for each port and interface, ensuring their alignment with the corresponding AUTOSAR Adaptive properties.

Figure 9. Design, develop, and generate C++ code for an AUTOSAR Adaptive application (left).
Video showing how to generate C++ code for an AUTOSAR Adaptive application in Simulink (right).

For instance, consider the radar service, which is linked to a Simulink model that uses Simulink Function blocks at the root level of a model to create an Adaptive methods (3:50) service interface. Here, methods of an AUTOSAR service interface define the interaction between a software component modeled as a server providing an interface and another software component modeled as a client that requires an interface.

In Simulink, client-server communication can be modeled with either synchronous or asynchronous call behaviors. Synchronous client models produce blocked client execution, where the client sends requests to the server and waits for the response. Asynchronous client models produce nonblocking execution, which consists of clients sending requests, continuing their current execution after the request is sent, and processing the response from the server upon receipt.

Radar service is a server that uses client-server communication. In Figure 9, the code mappings UI shows the mapping of Simulink Function blocks and Function Element ports—radarCtrl.Adjust and radarCtrl.Calibrate with their respective Adaptive ports.

Furthermore, you can view and edit the AUTOSAR properties in the AUTOSAR dictionary for “Methods” service interfaces (Figure 10).

The LaneGuidanceApp service operates as a client and utilizes client-server communication through asynchronous calls (Figure 11). The client in this example uses asynchronous communication and benefits from nonblocking execution for continued execution after sending its request to the server. Within the Simulink model, it utilizes a Function-Call Subsystem block with a Message Triggered Subsystem block to execute a function call asynchronously. The code mappings UI shows the mapping of a Simulink function caller with the corresponding AUTOSAR Adaptive port.

Similarly, all other SOA services are configured according to AUTOSAR Adaptive concepts in Simulink.

After validation and simulation, each AUTOSAR Adaptive service can be deployed as a standalone application, with its own artifacts including C++ code and AUTOSAR interface descriptions containing Machine, Execution, and ServiceInstanceManifest files. Lastly, AUTOSAR Adaptive C++ code and corresponding software description and manifest files are generated using Embedded Coder for further integration in the workflow (Figure 12).

Conclusions and Future Works

Model-Based Design provides a structured approach to system development, allowing for the creation of models that represent the application’s architecture, components, and interactions. In this article, we showed how Model-Based Design can be used to decompose a traditional monolithic application using the highway lane-following reference example model into services and then configured them as AUTOSAR Adaptive applications. These modular services can be part of a blueprint enabling engineers to author, simulate, and generate C++ code along with manifest files for further integration in the workflow.