Skip to content
MathWorks - Mobile View
  • Inicie sesión cuenta de MathWorksInicie sesión cuenta de MathWorks
  • Access your MathWorks Account
    • Mi Cuenta
    • Mi perfil de la comunidad
    • Asociar Licencia
    • Cerrar sesión
  • Productos
  • Soluciones
  • Educación
  • Soporte
  • Comunidad
  • Eventos
  • Obtenga MATLAB
MathWorks
  • Productos
  • Soluciones
  • Educación
  • Soporte
  • Comunidad
  • Eventos
  • Obtenga MATLAB
  • Inicie sesión cuenta de MathWorksInicie sesión cuenta de MathWorks
  • Access your MathWorks Account
    • Mi Cuenta
    • Mi perfil de la comunidad
    • Asociar Licencia
    • Cerrar sesión

Vídeos y webinars

  • MathWorks
  • Vídeos
  • Vídeos-Inicio
  • Buscar
  • Vídeos-Inicio
  • Buscar
  • Comuníquese con ventas
  • Software de prueba
4:57 Video length is 4:57.
  • Description
  • Full Transcript
  • Related Resources

Designing Software Architectures Using AUTOSAR Blockset

Design software architectures by modeling AUTOSAR architectures in Simulink. It allows you to author software compositions, components, and interfaces in Simulink and link them to requirements (requires Requirements Toolbox™). You can also specify behavior for the components in the architecture model by creating a new Simulink component model, linking to an existing component model, or importing one from ARXML.

You can add Basic Software (BSW) blocks, including Diagnostic Service Component and NVRAM Service Component blocks, to the architecture model to simulate calls to BSW services. Additionally, you can schedule and specify the execution order of component runnables for simulation using Schedule Editor. This allows you to verify your AUTOSAR ECU software without leaving Simulink.

Once you are happy with your design you can export composition and component ARXML descriptions, generate component code, and package build artifacts for integration with an AUTOSAR run-time environment.

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.

Related Products

  • AUTOSAR Blockset
  • Embedded Coder
  • Requirements Toolbox
  • System Composer

Bridging Wireless Communications Design and Testing with MATLAB

Read white paper

Feedback

Featured Product

AUTOSAR Blockset

  • Request Trial
  • Get Pricing

Up Next:

6:01
Simulation of AUTOSAR Software Components

Related Videos:

5:38
AUTOSAR Client-Server SIL Simulation
2:46
AUTOSAR Code Generation for Multiple Runnable Entities
5:16
From Simulink to AUTOSAR Production Code
32:32
Simulink to AUTOSAR Code Made Easy

View more related videos

MathWorks - Domain Selector

Select a Web Site

Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .

  • Switzerland (English)
  • Switzerland (Deutsch)
  • Switzerland (Français)
  • 中国 (简体中文)
  • 中国 (English)

You can also select a web site from the following list:

How to Get Best Site Performance

Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.

Americas

  • América Latina (Español)
  • Canada (English)
  • United States (English)

Europe

  • Belgium (English)
  • Denmark (English)
  • Deutschland (Deutsch)
  • España (Español)
  • Finland (English)
  • France (Français)
  • Ireland (English)
  • Italia (Italiano)
  • Luxembourg (English)
  • Netherlands (English)
  • Norway (English)
  • Österreich (Deutsch)
  • Portugal (English)
  • Sweden (English)
  • Switzerland
    • Deutsch
    • English
    • Français
  • United Kingdom (English)

Asia Pacific

  • Australia (English)
  • India (English)
  • New Zealand (English)
  • 中国
    • 简体中文Chinese
    • English
  • 日本Japanese (日本語)
  • 한국Korean (한국어)

Contact your local office

  • Comuníquese con ventas
  • Software de prueba

MathWorks

Accelerating the pace of engineering and science

MathWorks es el líder en el desarrollo de software de cálculo matemático para ingenieros

Descubra…

Explorar productos

  • MATLAB
  • Simulink
  • Software para estudiantes
  • Soporte para hardware
  • File Exchange

Probar o comprar

  • Descargas
  • Software de prueba
  • Comuníquese con ventas
  • Precios y licencias
  • Cómo comprar

Aprender a utilizar

  • Documentación
  • Tutoriales
  • Ejemplos
  • Vídeos y webinars
  • Formación

Obtener soporte

  • Ayuda para la instalación
  • MATLAB Answers
  • Consultoría
  • Centro de licencias
  • Comuníquese con soporte

Acerca de MathWorks

  • Ofertas de empleo
  • Sala de prensa
  • Misión social
  • Casos prácticos
  • Acerca de MathWorks
  • Select a Web Site United States
  • Centro de confianza
  • Marcas comerciales
  • Política de privacidad
  • Antipiratería
  • Estado de las aplicaciones

© 1994-2022 The MathWorks, Inc.

  • Facebook
  • Twitter
  • Instagram
  • YouTube
  • LinkedIn
  • RSS

Únase a la conversación