Using Model-Based Design to Develop SOA Applications for In-Vehicle OS - MATLAB
Video Player is loading.
Current Time 0:00
Duration 15:53
Loaded: 1.03%
Stream Type LIVE
Remaining Time 15:53
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 15:53

    Using Model-Based Design to Develop SOA Applications for In-Vehicle OS

    Yiming Luo, ZEEKR Intelligent Technology

    With the growth of the service-oriented architecture paradigm in the automotive industry, several middleware options have emerged, along with the widely known AUTOSAR Adaptive Platform. Many powerful companies like ZEEKR are also looking to develop their own middleware for in-vehicle operating systems (OS). ZEEKR implements multiple function clusters for such an in-vehicle operating system for smart EVs. When we talk about how to develop software for SOA or do the actual coding, the first thing that comes to mind is handwritten C++ language, which puts forward high requirements not only on the programmer's ability but also on the accompanying toolchain. In contrast, Model-Based Design is the dominant approach in traditional onboard embedded system development and there are a lot of experienced engineers. Starting with R2022a, Simulink® provides some new features like a client-server interface, which enables modeling instead of handwriting SOA software. Companies can use the power of MATLAB® and Simulink to quickly transition from the embedded software era to the emerging SOA software era. There are two main challenges in using Model-Based Design to develop SOA software running on in-vehicle OS: how to model the software behavior and how to maintain complex software clusters. This talk focuses on solving these two problems. ZEEKR made full use of the powerful capabilities of MATLAB and Simulink for SOA software development, formulated many strategies according to local conditions, and facilitated the implementation of SOA application software running on in-vehicle OS.

    Published: 7 May 2023

    [MUSIC PLAYING]

    Hello, everyone. My name is Luo Yiming. I am a software engineer, a seasoned architecture developer, and of course, a deep user of MATLAB and Simulink. I have experience working with embedded software of light hybrid systems and air conditioning systems at ZEEKR, while currently developing an SOA software toolchain based on MATLAB and Simulink and how we establish best practice on in-vehicle OS.

    Today, I will introduce how ZEEKR use model-based design to develop SOA applications running on ZEEKR's in-vehicle OS. Software-oriented architectural SOA is a design methodology that enables organizations to create reusable and modular software services. In the automotive industry, SOA has become a key enabler for enhancing the flexibility, scalability, and interoperability of automotive systems.

    [INAUDIBLE] centralized EEA architecture is a new automotive architecture that integrates various electronic and electric systems into a centralized domain. It enables automotive manufacturers to design and develop more efficient, flexible, and scalable systems, while reducing the overall cost of system development and maintenance.

    An in-vehicle operating system is a software platform that manages the hardware and software resources of vehicle electric systems. It provides a common framework for integrating various systems, including infotainment, navigation, climate control, powertrain, and safety system. The in-vehicle operating system provides a modular and scalable architecture, which enables designers to develop and integrate new features and functions more quickly and efficiently.

    When you talk about how to develop a SOA software or do the actual coding, the first thing that comes to mind is handwritten C++ language, which puts forward high requirements not only to programmers' ability, but also to a corresponding toolchain. In contrast, model-based design, MBD, is the main approach in traditional embedded systems. And of course, there is a lot of experienced MBD users. Starting with 2022a, Simulink provides some new features like client server interface, which enables modeling instead of a high-writing of our SOA software.

    So we can use the power of MATLAB and Simulink to quickly transition from the embedded software era to the SOA software era. There are two main challenges if we want to use MBD to develop SOA software running on in-vehicle OS, how to model the software behavior and how to maintain complex software clusters. This report focused on solving these two problems.

    Here's the outline of our solution about how to model the software behavior. We took full advantage of Simulink's new features, built a model with SOA characteristics, and a supply state with middleware using wrapper code. About how to maintain complex software clusters, we introduced the idea of system engineering and the deeply customized System Composer to meet our special requirements.

    Part one, how to model the SOA behavior. The first thing to realize is that the modeling environment has changed a lot. In the past, we develop application software in the environment of AUTOSAR classic platforms, also known as CP. The application software runs on a real-time operating system and interact with each other through the RTE interface. The implementation of RTE interface is very simple. It's generally a C function that reads and writes local data.

    However, on the in-vehicle operating systems, the way how applications interact with each other has changed dramatically. Two typical approaches are introduced, remote procedure code and the message. In both way, application can be deployed more freely and communicate seamlessly.

    Let me show you a typical example of developing an application using model-based design in the AUTOSAR environment. Step one, use a Simulink model to represent a software component, also known as SWC. Step two, use input and output block to represent RTE interface. Use a function called Subsystem to represent a runnable. Then finish internal logic.

    Step three, after mapping Simulink model elements and AUTOSAR software elements, use AITOSAR.TLC to automatically generate C code from Simulink model. Step four, directly integrate the Simulink-generated code into AUTOSAR middleware. This process is straightforward and requires no actual steps because Simulink has generated the interface code exactly matching AUTOSAR standard.

    But how to model a non-standard in-vehicle OS, how to model the behavior matching new styles of communication. Let's put a query here. So how to model on in-vehicle OS? Through exploration and the trial, we finally find a suitable technical route for our own. Firstly, the new features of Simulink are the foundation of everything. Starting with 2022a, Simulink provides some new features like a client server interface, which enables modeling instead of handwriting of our SOA software.

    By this feature, a Simulink model is able to offer functions to another Simulink model, not only in the block diagram level, but also in the C++ generation level. Secondly, we have established modeling rules to guide our users to build modeling semantics that meets the requirements of in-vehicle OS interfaces, like a remote procedural interface, message broadcast publisher, and the persistent entry. Suddenly, we create a wrapper code generator based on certain rules, wrapper code connect, application layers, and the OS layer.

    Finally, we merge Simulink-generated code and the wrapper code as an application package, which will be deployed to OS environment like any other applications. Let's see what happens to the model on the in-vehicle OS. This is a simple example of SOA model. The Simulink function block represents a service provider, waiting for remote function code outside this model.

    The bus element in block subscribed message and receives data. The function called subsystem triggered by step represents a step function to maintain internal calculation. While the step function running, a function call request to remote service is sent. And the message is published. Obviously, modeling style has changed a lot.

    This is an example of our conditioning function in real case. This example connects mobile cloud and car. It shows where model-based design works. We develop SOA application through Simulink and deploy it on high-performance computer, also known as HPC.

    We also use Simulink to develop AUTOSAR embedded software and deploy it on the microcontrol unit, which is the most common way how we use Simulink. Last, the software on the MCU drives accurate-- the actuator or the [INAUDIBLE] in this case to do the final work.

    Let's look at the details of the workflow. Model development engineers undertake upstream software design. Development models generate a model code and generate wrapper code. As you can see here, the final deployment file includes typical Simulink-generated code and the wrapper code.

    Now that we have discussed part one, how to model SOA software, let's talk about part two, how to manage SOA software. So how to maintain complex software clusters. When the software reaches a certain level of complexity, it is necessary to introduce the idea of a software architecture which has the same meaning for both traditional embedded systems and the SOA systems.

    So what does software architecture do? In a simplified real code development process, the offspring of software design can be functional design. In the functional architecture, only the functionality and the interface of the service are defined. Then in software architecture design, it is necessary not only to design some software entities to realize these functions, but also to ensure that the interaction between these software entities is reasonable and robust.

    There are many [INAUDIBLE] of software architecture design and management tools on the market, which unfortunately are not compatible with our in-vehicle OS. It's a non-AUTOSAR standard system. So it is necessary to customize a software architecture design tool for our own. That's how System Composer plays a role.

    There are many things to be considered, like what kind of media file should be used to transfer design information? And the most important of all, how should we design architecture for a specific system? Fortunately, MATLAB and Simulink provides a model-based design system engineering solution. MATLAB, Simulink, and the System Composer together create a single environment for creating descriptive architecture models that are capable to do an architectural job.

    So we built our own software architecture tool, SOMOC, SOA Model Composer. It's made specifically for model-based design on our in-vehicle OS. It's mainly based on these toolbox or feature, System Composer, MATLAB programming language, and APP Designer. System Composer is the foundation. It provides architecture modeling semantics and a powerful visualization. MATLAB language provides powerful organization ability. APP Designer provides customized user interface, making the tool much easier to use.

    There are four different levels of component in SOMOC, architectural level, process level, SW-C level, and service level. Architecture level is a whole view of a specific system, like climate control system. Specific systems contains several processes. Processor level contains independent processes that can be run or killed in the operating system. Processes communicate with each other through standard middleware interfaces. And processes consist of one or multiple SW-Cs.

    SW-C level contains large components that integrate into a process. We call this logical component as SW-Cs. In Simulink view, one SW-C corresponds to one Simulink model. An SW-C implements one of multiple SOA services. In the end, service level contains functional service designed upstream.

    Each of the architectural components is reflected by one System Composer model. And the connectivity and the integration relationship between different levels are reflected by reference component. This is where we take advantage of the features of Simulink Composer to build our architectural modeling semantics.

    There are two features deserve to be mentioned. One of them is to enhance System Composer model by profile. Profile gives custom property to different architecture elements through which way we can define our specific system. For example, here, we defined a stereotype named Service Instance, which has properties of service instance name, service ID, version, and the namespace. After applied either by profile and stereotype, a System Composer model can be filled with customized property value and carry a lot of information.

    So as a practical feature is to link different level elements by reference component. By reference component, you can link other system component models in the kernel one. Through this way, we simulate the behavior of integrating low-level components into high-level components. You can inspect subcomponent by a double link of reference component.

    So with the support of SOMOC, we establish such a workflow for our SOA software development. The first thing is to receive upstream functional design and think carefully about how to design the software architecture, including how many processes are needed to run the system, what SW-Cs should be involved into a process, and which SOA surveys should be implemented in single SW-C.

    After the software architecture is finished, the corresponding design needs to be passed on downstream for detailed software development, like interface description for Simulink model, configuration for compile and deployed actions. Besides, we also built a GUI and a user toolbox to make it easier to use. You can create, design, and refine the architecture in a centralized view. You can avoid some tedious operations of System Composer. And you can export SW-C components and Simulink model. SOMOC GUI makes our work more efficient.

    So in conclusion, the automotive industry is undergoing a wave of change. And the SOA is the trend of this way. How to model SOA software behavior and how to maintain SOA software clusters became the top two challenges of our company. We made full use of the powerful capabilities of MATLAB and Simulink, and formulated the many strategies according to local conditions, and finally, facilitate the implementation of SOA applications. That's the presentation today. Thank you for listening.

    [MUSIC PLAYING]

    View more related videos