Hi, I'm Mazen, a software engineer at MathWorks.
When authoring software architectures
using model based design, we need the ability
to define interfaces and data types,
and share their definitions across components
in the architecture.
I will show you how to use the interface dictionary
and AUTOSAR Blockset to create and manage
definitions like interfaces and data types,
use them in the model for simulation, cogeneration,
and finally ARXML export.
Here we have an AUTOSAR architecture model,
which defines the throttle position control composition.
We've not yet defined any interfaces for these ports.
So let's get started and create an interface dictionary,
which will contain the definitions
for the port interfaces.
We will use the standalone Interface Dictionary Editor.
This is an intuitive editor that can also be used independently
from the model context.
With these tabs, we can clearly see the different types of data
this dictionary can manage.
Let's start by adding a data interface
for the throttle position sensor output.
We can also set the AUTOSAR properties, for example
the interface kind.
Now, let's define the elements for my interface.
In this case, we'll have one data element, called value.
We can also define the design data
for example the implementation data type,
and also the AUTOSAR information for my element.
This ensures that the design data and the platform
information is always in-sync and contained
in the same dictionary.
Now, let's define the data types required
by the interface elements.
Now, since I have few sensor inputs and outputs that
are reading and writing data to the hardware I/O,
I will define a common data type that will be shared by them.
This data type will have an implementation type,
unsigned in 16, and a specific min and max value.
We can go back to the interface element
and set this data type that we just created.
Well, we can clearly see that the data type
specification is no longer owned by this element.
Now, let's add the software address method,
which will define a memory section
in the AUTOSAR platform.
We can now use the Software Address
Method on the data elements.
We will now create the rest of the interfaces and data
types required by the design.
The Interface Editor also allows me
to link the interfaces and data types to requirements
using the traceability matrix.
Here, I'm linking the interfaces to requirements
that I've already authored.
The interface dictionary also allows
me to define platform specific workflows,
like defining XML options in a centralized location, that
can be used by the dictionary elements
in any model linked to the dictionary.
I can also export the contents of the dictionary
to ARXML independently from the model context.
Now, let's go back to the architecture model
and use these interfaces to assign them to ports.
We can view and edit the content of the dictionary
in the Model Editor.
Here, we're using the Property Inspector
to assign the interface to the selected port.
Or we can right-click on the Interface Editor to do so.
The bidirectional traceability helps
us navigate from port to interface, and vise versa.
Let's now compile the model to make
sure we've not made any mistakes with port interface
compatibility.
And indeed, here, looks like I've
made a mistake with assigning the wrong interface.
Let's fix that and try again.
Now, we're ready to create behavior models
for my components.
We can see that the ports and implementation
model are assigned to the expected interface
and linked to the same dictionary.
We can now continue to implement the models, apply simulation,
and finally we can generate code in ARXML
for the whole composition.
The output of this process is a .zip file that contains both
the ARXML and the source code for the components.
In this video, I showed you how to create
an interface dictionary from the architecture model,
use the standalone Interface Editor to author interfaces
and data types, then assign those interfaces to ports
in the architecture model, and then finally simulate,
generate code in ARXML.
Thanks for listening.