The Evolution of Simulink for Service-Oriented Architecture (SOA) - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 27:35
Loaded: 0.59%
Stream Type LIVE
Remaining Time 27:35
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 27:35

    The Evolution of Simulink for Service-Oriented Architecture (SOA)

    The automotive industry has embraced a service-based approach, known as service-oriented architectures (SOA), to design applications for software-defined vehicles (SDVs). SOA introduces a paradigm shift, emphasizing high reusability, streamlined updates, and reduced hardware dependencies in software development. It revolves around the concept of dynamic service discovery, publisher, subscriber, and runtime reconfiguration. The concept of SOA has been widely incorporated into industry standards, including AUTOSAR Adaptive, DDS, and ROS.

    Join an insightful presentation on the evolutionary journey of Simulink® in developing SOA-based applications, highlighting the following key capabilities:

    • Advanced Simulink semantics for service development
    • Software architecture for SOA, AUTOSAR Classic, and AUTOSAR Adaptive
    • Seamless migration from traditional applications to SOA and AUTOSAR Adaptive applications

    Published: 13 Dec 2023

    And for that, I would like to invite Shwetha to share her views on that. Shwetha is a Senior Product Manager at MathWorks, focusing on software-defined vehicles, service-oriented architecture, AUTOSAR, vertical, DDS, and Simulink coder product. Please, welcome Shwetha on the stage.

    Thank you, Aravind Good afternoon, everyone. OK. Nice to see you all after a delicious lunch. I'll try my best to keep you awake and more engaging. All right, let's get started. So I'm going to talk about how Simulink has evolved for signal and service-oriented based applications for developing software-defined vehicle applications.

    All right. So do you all agree that are we in the era of software-defined vehicle? Raise your hands if you agree with me. All right. It's no more a grand vision.

    We are already in the era of developing the software-defined vehicle applications. So the automotive industry is embracing this service-oriented architectures, along with the signal-based architectures, to develop modern applications, like software-defined vehicles. So like my colleague Aravind mentioned, it's all about customer experience.

    All right. So what is service-oriented architectures? So the service-based approach is all about service-oriented architecture. It has self-contained units called Services, where each individual application interacts with other application with services. As you can see with this layered architecture, these services are loosely coupled with the hardware level and also the basic software services. So which makes it easy to update frequently, selectively and over the air, so that you can provide latest features on the car as and when there is availability.

    All right. Let's take a moment and look at traditional vehicle, where it has controls-based algorithms to develop powertrain, body control, instrument clusters, and so forth. So historically, the C code was developed by hand, and with model-based design, you all know that you can develop your applications more faster and generate code, which helps you to deploy on the hardware as soon as possible. Right?

    So now, with software-defined vehicle, it's changing. It's going to be service-based approach. For the software-defined vehicle it doesn't require just the service oriented but also signal based. So that will make our car more autonomous and also help you connect with the outside world, even when you are behind the wheels, while leveraging AI.

    So there are several SOA-based software standards available in the market, including AUTOSAR Adaptive or ROS, Robotic Operating Systems, for prototyping and DDS as a communication middleware. So how many of you here are familiar with AUTOSAR? OK. That's a pretty good, decent number.

    OK. So the question is, how do we develop these algorithms? Right? So the Simulink platform, you know well, it can be used for developing your legacy engine control unit applications and also configure for AUTOSAR classic, which is used for the traditional automotive applications. And then also reconfigure for AUTOSAR Adaptive, ROS, or DDS, which are service based, which can be deployed on microcontrollers, FPGAs, GPUs, and high-performance computers.

    All right. Here is our agenda I have for today. So first, I'll give you a sneak peek of what are the advanced Simulink semantics we have developed for the services, and how do we model the software architectures? Mainly geared towards AUTOSAR classic as well as adaptive. At the end, I'll conclude with the key takeaway.

    All right. So you must be familiar with this traditional function called subsystem modeling for the control systems algorithms, and in the Simulink palette, you will see port, subsystems, reference models, and so forth. But for developing the service-oriented applications, we know that these applications communicate with each other over messages, which carries events and data. So how do we develop such applications in Simulink? So the Simulink palette, the library browser, looks a little different. It has messages, events block, sequence viewer, queuing, and also the sender and receiver blocks, which will help convert your signals to services, so our services to signal for processing in the signal mode within the Simulink ecosystem.

    And here, I have a Simulink model which has two model reference blocks. One is for the sender, and the other one is for the receiver, where it is communicating via the Simulink message bus. That's why you can see the double line, where it has information related to events and the data, which will help generate C++ code for these service-based applications. Furthermore, you can view how these data are being transferred using the sequence viewer.

    All right. So additionally, we have introduced a new Simulink semantic called Function Ports. So where a function port can be used within a reference model, which can invoke the Simulink function available in another Simulink reference model. So I have a sneak peek of this reference model I have a function caller block here and then a Simulink function, which will help develop your client server-based services within Simulink platform. And again, you can generate C++ code for this algorithm.

    All right. So we have introduced two new blocks, mainly to enable those blocks as and when the message is available for the message trigger subsystem. And the other block is message polling system, which will be invoked periodically by checking if there is polling has been done. So this will, again, be designed and generate C++ code for the production projects.

    All right. So that's about synchronous. How do we model a synchronous? Again, we are using a function called Subsystem, along with a message-triggered subsystem, which makes it more asynchronous in nature. Where it will return the function into a bundled messages.

    So client would request. That's through the function caller, which will enable it to be asynchronous. And then server would respond with the Simulink function in it, and it will invoke the client using the message-triggered subsystem.

    All right. So and we have a new UI, which is called Schedule Editor, which was introduced a few years ago but enabled for service-oriented behavior. As you can see on the left, so there are events, and on the right, you will see the execution order of those events. And you can drag this order of this execution of events and do the simulation to see whether your algorithm is working as per your requirement, or you can play with it by changing the order as well. So this is a sequence viewer, which I talked about before. Here, it will help you visualize how a function is calling and how a Simulink function called subsystem is responding with messages or the data.

    So we have a couple of user presentations and talk about how they are using model-based design for developing service-oriented applications. So one is from Zeekr, and the other one is from KPIT. So I definitely encourage you to go through this to learn more about how you can leverage your knowledge of model-based design to develop the service-oriented applications.

    All right. Now, I'm moving on to AUTOSAR architecture modeling. First, I'll cover AUTOSAR Classic. Then, I'll switch on to AUTOSAR Adaptive, which is services based.

    So AUTOSAR, for those of you who don't know, stands for an open, standardized, automotive software architecture. So here, I'm showing you the AUTOSAR classic layers on top, right here. You can see that it is pretty modularized, so that application software is abstracted from the below level layers, which makes it easy to update and upgrade. But it is based on signal-oriented applications, geared towards traditional automotive applications, like powertrain or instrument clusters.

    So in order to enable services-based development AUTOSAR introduced Adaptive platform, a few years now since it's available. And you can see that it also has got layered architecture, but here, all the applications will be services, which will run on high-performance hardware and the code implementation is in C++, whereas, in Classic it's C. So in a near future car-- or it's happening today, because we are already in the world of SDV-- you will see both Classic and Adaptive AUTOSAR ECUs in a car.

    All right. So now, the question is, how do we interact this AUTOSAR Classic and Adaptive applications? So we have written a technical article to showcase how you can implement that and how you can communicate between the Classic and Adaptive AUTOSAR IP. So this is how the proof of concept looks like.

    Under phase 1, we have developed a AUTOSAR Classic example, mainly on the server side. Follow the top-down workflow, where I would import ARXML that has AUTOSAR descriptions. When you import that into Simulink, it will create a skeleton model and add a Simulink logic into it, then integrate it with the RTE and the BSW stack. So then, I generated the DLL file and tested that by creating a virtual client to make sure my server is working fine.

    So that's phase 1, and in the phase 2, I implemented a server, as well as the client, following the AUTOSAR Adaptive standard, and then integrated that with the ARA::COM and the BSW stack for the AUTOSAR Adaptive, tested the communication between the server and the client using SOME/IP Daemon. Once I'm happy with that, I tested the communication between Classic AUTOSAR and the Adaptive AUTOSAR using ethernet, physical ethernet cable, which is communicating via SOME/IP mechanism. All right. So we worked with Elektrobit, and Elektrobit developed the driver monitoring system based on the service-oriented architecture, that's AUTOSAR Adaptive with model-based design, and they deployed on the Raspberry Pi 2, and that was a prototyping project, and they realized that model-based design could accelerate the development of these applications pretty quickly.

    All right. So in the morning session, you heard about CI/CD workflow, the cloud deployment workflow, and so forth. Right? So yeah, it is applicable for AUTOSAR Classic as well as Adaptive. So we did a project with Elektrobit as well as Amazon. There is a booth up there, outside, which is showing this demo, and after me, there will be a talk on this topic as well. So I would ask you to stay tuned for that, but I'll touch upon this.

    What we did was we implemented both AUTOSAR Classic and Adaptive applications in Simulink and integrated with the EB carbos, provided from Elektrobit, and deployed it on Amazon Graviton for the Classic side and the EC2 on-- the x86 on the-- sorry. Graviton on the Adaptive side, and x86 on the Classic side.

    All right. So many people, or many engineers, are already used to developing the signal-based applications. Now, the services are being very popular, especially for the software-defined vehicle. So the customers are trying to migrate the signal-based applications to services-based applications. So we worked on a project and talked about how you can migrate such traditional applications, where the traditional applications, the final code would be single DLL file. Right? So that's not enough for the services, application services.

    So we use the AUTOSAR Adaptive standard principles and methodologies to rip apart this legacy architecture into services and then generated files for each individual services. So yeah, we explained that in this tech article. I'm not going to cover this, but if you're interested, I would definitely encourage you to see how you can migrate your traditional automotive application that can be an AUTOSAR Classic and then to AUTOSAR Adaptive applications.

    All right. Now, let's take a look at the AUTOSAR workflow, how it look like. An engineer either can start from an AUTOSAR architecture or from Simulink platform. So if you're starting from Simulink platform, you can architect your Simulink algorithm using the System Composer, or you can just start from the Simulink model, where the architecture model and the Simulink model interacts with each other seamlessly, without even generating any ARXML files. So once the application logic is done, you can generate C code, as well as C + or C++ code, depending on is it Classic or Adaptive, and also generate ARXML files. So that's bottom-up workflow.

    If you're starting from an AUTOSAR architecture, export, and ARXML, and import that into Simulink, so that will create a skeleton model and then add in your logic. So once that is done, you can generate the C or C++ code, also the ARXML. That's called top-down workflow. The combination of this is called round tripping

    All right. So now, let's try to build the AUTOSAR Classic-based application in System Composer using AUTOSAR Blockset. So those are two products we provide to develop such signal-based applications, following the AUTOSAR standards. So here I'm building a throttle position control system. As you can see, it has got six components.

    So how do we start that? System Composer provides multiple templates. One is a standard template, mainly to develop your system-level architecture, then the software template, which will help you develop your generic software design that can have client-server interfaces or function editors. So if you want to start with AUTOSAR, yeah, there is a template for AUTOSAR as well.

    So we support two workflows for modeling AUTOSAR architectures. One workflow is you can directly start from a AUTOSAR architecture template, or if you had developed the architecture model using the standard or a software architecture template, you can export that as an AUTOSAR architecture model. So as you can see on this side, you have options to choose.

    So for the sake of this presentation, I'll use the first workflow, where I would model AUTOSAR architectures directly in System Composer. We support this since the release 2019b, and the exporting existing architecture model to AUTOSAR, that feature has been supported like three weeks ago. That is 23b.

    All right. So here, I am using the AUTOSAR System Composer architecture template. So inside that, you can see that I have architected six AUTOSAR software components. You can see there are sensor actuator components, application components, and as you can see, the entire components is called Compositions here, which is a aggregation of multiple software components.

    So components which are in pink or red can be aggregated as a single component, which is a composition. I'm grouped together. I'm calling it a sensor. This will help in modularizing your compositions within components, and you can save this as a composition architecture model as well. And you can see that this is how I grouped these four components into one-sensor compositions.

    And then you can also create a Simulink data dictionary. In this case, I already have an open data dictionary that are plugged with these components. As you can see, you can edit your data interfaces and elements and then change the interface kind, is if you want it to be service interface or client server, and also you get to edit or add the data types. As you can see here, we support several data types as well. And then once you're done with this data dictionary configuration, you can export that into an ARXML format, which can be further used.

    All right. So also, you can simulate this AUTOSAR architecture model, and if there are exposed calls to the diagnostics or NVRAM Manager within the AUTOSAR basic software. So we do provide reference implementation blocks for diagnostics, inhibition manager, function inhibition manager, diagnostic event manager, as well as NVRAM Manager. So this will help simulate your algorithms which are making calls to this basic software services related to NVRAM, as well as diagnostics, which will help understand and visualize how your algorithm is working through the simulation mechanism.

    OK. Now, I'm switching to the AUTOSAR Adaptive platform, where I would like to plug my Simulink service-oriented architecture models to AUTOSAR Adaptive, because it follows service-oriented architecture. All right. Again here, I'll start with the System Composer, where I can choose, as you can see here, it can be a Classic platform or Adaptive platform, but I'm going to choose Adaptive platform. And I have a LightsManager that's an Adaptive service component I'm developing, and it has got UserLightSwitch, which is using the events-based, service-oriented communication, and HeadLight, which uses the methods-based, service-oriented communication.

    Yeah. As you can see, LightSwitch is a methods communication, and the LightService is using the event space communication. And again, you can, for these components, you can create a Simulink behavior, like an internal behavior of your application software components, if you don't have it. Or if you already have a model ready, you can just link to it, or you can create a component model from using this ARXML.

    All right. Once the applications are developed in the Simulink platform for LightsManager and HeadLight controller, you can run it for simulation, and then export the ARXML files and generate C++ code for this. So here, I have a really high-level demo of developing this Adaptive application services in the architecture model. So I'm using the Adaptive platform, and I already have a Simulink dictionary ready. I'm just going to load it, instead of creating a brand new here, and you can see the interfaces for LightSwitch and LightService, which I showed in the previous slide.

    And you can see that it's using event based and this light service is using the methods based. So it has-- using the clients and services and which can be asynchronous or synchronous in nature. This, on the right, you can choose whether-- by checking that box, it will show you whether you want to be asynchronous.

    All right. I'm dragging our Adaptive component into this AUTOSAR architecture template, and similarly, I have linked a Simulink model here, because it was already there for me. Yeah, and I'm creating another component for the HeadLight controller. Yeah, and again, there I had a Simulink model. I just connected it. That's the function port I was talking about before, which will help invoke the Simulink function available in the other reference model.

    All right. Once the application logic is done, you can generate C++ code and ARXML files for it, and additionally, you will get the ARXML files for the component descriptions for both HeadLight controller and the LightsManager, which we just developed. And then the composition, which is the aggregation of these two components, which we called as LightSystem. And the data types and interfaces files for that and also the deployment configurations files, which is ExecutionManifest and ServiceInstanceManifest ARXML files for both the components which we just developed.

    All right. So how do we deploy these architecture models? I have here a Linux target. It's a host-based virtual machine.

    So you can create a deployable file from the same LightSystem model, the architectural model which we created. So it is creating a deployable file which can be deployed on the Linux host machine, which will help you to monitor and tune the data. It's mainly testing the software in the loop type of testing, right in the Simulink ecosystem, before you go for the final integration as well as deployment.

    All right. So I gave a lot of information which was really, really high level about the AUTOSAR Classic, Adaptive, and also generic SOA Simulink semantics, which we provide to develop your software-defined vehicles. So if you have any questions or for deep technical questions, feel free to stop by and ask. So to conclude this presentation, there are several challenges involved in developing the software service-oriented applications. So it required a really change of mindset.

    So used to developing the C code for the traditional applications. Right? So this signals-the-service transitions requires a skill set upgrade and also change of mindset. And also you need to centralize and re-architect the existing applications and then partition the processes, as well as services. So the solution is the platform you know really well, that's Simulink, which can be used to design, simulate, and generate code to deploy both the signal-based AUTOSAR Classic and then service-oriented AUTOSAR Adaptive in Simulink. And also you can reuse your expertise in Simulink for developing your application algorithms to mitigate this risk of developing your service-oriented AUTOSAR Adaptive applications.

    Yeah. Thanks for listening in. Now, I'll open up for questions.

    How do you test these applications?

    Do you mean the workflow?

    Yes, how to test these models?

    Yeah. We do have a product called Simulink Test based on these algorithms we provide, and if you give them the input, it will create test cases. With Simulink test, yes, we have to feed in all the right requirements, and that will create test cases, which will help in the back-to-back testing as well. Yeah. Do you have any more questions?

    Can you elaboarte on the design workflow?

    Right. So in the bottom-up workflow, when you are developing your like the application logic, either for AUTOSAR Classic or Adaptive, you will have the AUTOSAR-specific descriptions, for example, how you have configured your Simulink ports to AUTOSAR properties. So the Simulink ports represents the data interface and then the data element associated with that. Right? So those specifications will all be included in the ARXML files. The data interfaces, elements, and the runnables, like the internal behavior of the application logic is called runnables, the runnable entities. Right?

    And also does the runnable need to be event based or the client operation invoked based or external triggered based? We specify everything in that Simulink. Excluding the logic, all the architecture information are generated in the form of AUTOSAR XML. That's called ARXML. Yeah. And that workflow is applicable for both AUTOSAR Classic as well as AUTOSAR Adaptive. Yeah. All right, thank you.

    [APPLAUSE]

    View more related videos