Author AUTOSAR Software Interfaces and Types Using the Interface Dictionary - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 4:48
Loaded: 0%
Stream Type LIVE
Remaining Time 4:48
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 4:48

    Author AUTOSAR Software Interfaces and Types Using the Interface Dictionary

    R2022b introduces a new dictionary called the interface dictionary. It is dedicated to managing shared interfaces and data types across AUTOSAR components and compositions modeled in Simulink®. The interface dictionary enables better data ownership and encapsulation within a component while still enabling data types and interfaces to be shared across components. The interface dictionary can formally manage shared element definitions like interfaces and data types across components and compositions so that modeled design data and AUTOSAR properties are easier to scale in Simulink.

    Published: 10 Nov 2022

    Hi, I'm Mazen a software engineer at MathWorks. When authoring software architecture is 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 in AUTOSAR Blockset to create and manage definitions like interfaces and data types, use them in the model for simulation, cogeneration, and finally, RXML 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 contacts. 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, it will have one data element called Value. We can also define the design data. For example, the implementation Data Type and also the AUTOSAR information from 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 IO, 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 in 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 RXML independently from the model contacts. Now let's go back to the architectural 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, it looks like I 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 ports and the 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 our XML for the whole composition. The output of this process is a zip file that contains both the RXML 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 on RXML. Thanks for listening.

    View more related videos