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.