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 alloca
te 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 ord
er 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 Sch
edule 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 dep
endency 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 ba
ck 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 execu
tion 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.
Comments