Hi. I am Philipp Diersing, a software engineer in the AUTOSAR Blockset team at MathWorks. I'll show you how to use AUTOSAR Blockset to design software architectures and leverage model based design for AUTOSAR. This process starts from an architecture level and goes right down to the component level, thus reducing the need for additional AUTOSAR authoring tools.
We can start our design right here, from the Simulink start page. The AUTOSAR Blockset comes with a set of predefined template models that allow you to jump straight into the AUTOSAR designs. There's templates for both AUTOSAR Classic and Adaptive platform component models, but we'll start with the AUTOSAR classic platform software architecture template.
In this canvas, we design assemble and analyze AUTOSAR software architectures by dragging blocks, creating skeleton models, linking existing models or important components and compositions from ARXML. In this example, we will focus on creating a design top down. Or using existing component models without any need to import from ARXML. These workflows are now supported by a powerful programmatic API that allows you to automate these processes via Matlab scripts.
Spotlite views allow focusing on individual components their and the context within an architecture model. Free-form architecture views can be used to create custom queries and narrow down on specific aspects of complex architectures. Software architecture designs are driven by requirements. With the requirements manager, we can link our implementation to these requirements to get enhanced traceability. You can highlight the links to see exactly where requirement is implemented. And you can check the descriptions of the requirements and the rationale to see if our requirement is implemented correctly.
Let's now implement the census composition. We have two redundant throttle position sensors. The redundancy is important for the safety critical sensor. A monitor checks the sensors for faults, and chooses the signal to be used by the controller. We also have a pedal sensor for the driver's input. In just a few seconds we have added the necessary components for this sensor composition.
We already have qualified component implementations in the form of Simulink models. We can now easily and quickly link these to the respective component blocks, and connect their ports to each other. We can also adjust port placement and export ports to the upper level of the hierarchy.
We also want to add an accelerator to react to the sensory input as processed by the controller. Again, we can quickly link these components to our implementation models and link them up. We expose hardware inputs and outputs to the outside of the top level composition. At the end of this process, a quick Auto Arrange gives us a neat overview of the signal flow in our architecture, and arranges the component blocks property.
With our model based design environment, we can now go straight to simulation and to play on this composition. This allows us to verify the implementation models are correctly configured. We can simulate component interactions with the RTE and basic software using several provided basic software blocks.
We now want to test our software architecture inside a test harness to provide some input and simulate the response with a plant model in the system. We've got some simulated pedal input for the pedal sensor as well as a simulated throttle body to react to the actuator signal and feedback the current position of the throttle to the redundant sensors. We can simulate the test times and look at the throttle position as compared to the simulated pedal input stimulus provided here. We can see that the shoulder position follows the request nicely.
Once we have tested and verified our design and implementation, we want to generate code for our component models as well as ARXML, describing the components, compositions, and connections and interfaces, and the implementation of the architecture. These artifacts can be brought to an RTW for deployment. We generate C code for all the software components individually, as we do in component workflows. Let's have a look at the generated ARXML files.
We can see that we have to ARXML files per component, one containing the component description, and one for the implementation. Additionally, we have XML files containing the compositions and also files describing the accumulated data types and interfaces shared between the components and compositions in this architecture. And this is how you can use AUTOSAR Blockset and model based design to design AUTOSAR architectures from compositions over components, and generate C-code as well as ARXML. Thank you very much for listening. This Phillip Diersing from MathWorks.
