Hello, I'm Shwetha, product manager for AUTOSAR Blockset at MathWorks. In this video, I'm going to talk about execution order for AUTOSAR runnables in Simulink. As you are aware, the complexity of automotive issues are growing as it includes two to three cores, probably 15 to 20 tasks, hundreds of RTEE events to task relationships. Some tasks may be mapped to five to 60 runnables or two events.
So the integration becomes essential and crucial tasks that needs to map runnables to tasks and allocate tasks to cores. Therefore, AUTOSAR introduced timing extensions to provide timing requirements that guide the construction of systems, and to analyze, and validate the temporal behavior of a system. At, the same time it preserves functional behavior and timely execution. The question here is, what order should the runnables be executed?
I have created a software component modeled in Simulink. It has two runnables. How do you know what order have you evaluated or simulated this model? So it is hard to tell with data dependency. Let me try this to figure out how the execution order affect the end result.
So here, the output is connected to a scope to check the end results. If I run the simulation, when the runnable, R1, before runnable two, you would get a graph like this, but I flip the execution order, the result would change. As you notice here, the delay is completely different with different values.
So once we are happy with this implementation so you can export the execution order to preserve for future use. So in Simulink you can import and export execution order constraints using schedule editor modifications to runnable execution order and then to ARXML files.
All right, now let's invite Caroline Brandberg is one of the developers of AUTOSAR Blockset to show you their demo of support for execution order constraints.
Let's start with an example of a classic software component. The model consists of six entry point functions mapped to AUTOSAR runnables. If we open Schedule Editor, we can see the entry point functions, the order they will be invoked in during simulation, and their data dependencies. Schedule editor also allows us to modify the order using drag and drop. We can also see the type of the data connection, which is both graphically indicated by the error, where a straight line indicates a data connection of type dependency and a dotted line of type delay.
The Property Inspector also displays the type. Runnable E and runnable F both have a data dependency towards each other, where one is subtype delay. If we modify the order of these runnables, then the type of the dependencies will change. I have attached a scope to one of the outputs of runnable F. I will now simulate the model and observe the data.
If we then modify the execution order, the functional behavior might change. Let's change the order between runnable E and runnable F and simulate our model again. As you can see, the data has now changed. I will change the original order back because that satisfy my requirements.
When our model has been verified and validated, we can go ahead and generate code. We will first ensure that our model is configured correctly by performing AUTOSAR validation. Validation succeeded, we can now go ahead and generate code. The generated code will consist of a set of ARXML files describing our component.
One of these files will contain a timing model. The timing model holds the execution order displayed in schedule editor, expressed as execution order constraints according to the AUTOSAR time extension specification. The integrator can later use these constraints to guide a construction of the system to ensure that the simulated behavior is preserved when mapping our runnables to an operating system task.
I hope you all enjoy this video. For more information, please visit our AUTOSAR Blockset page on mathworks.com Thank you for watching.
