Click here to load reader

Déploiement de modèles Simulink sur plates-formes AUTOSAR · PDF fileDéploiement de modèles Simulink sur ... Safe algorithms for Autosar multicore architectures T4: ... Déploiement

  • View
    217

  • Download
    4

Embed Size (px)

Text of Déploiement de modèles Simulink sur plates-formes AUTOSAR · PDF...

  • Dploiement de modles Simulink sur plates-formes AUTOSAR multi curs Projet ELA (Electronique et Logiciel pour lAutomobile)

    June 2013 June 2016

    Team : 16 FTEs, 25 people

    Project leader: [email protected]

  • SystemX: An integrated collaborative environment

    Key scientific competences Markets and uses-oriented

    research activities Technological platforms

    Usages and Collaboration Understand the system

    components Models and Optimisation

    Model the system Simulation and Infrastructure Simulate and implement the

    system

    Systems Engineering Support the digital transformation of

    the engineering activities Autonomous transport

    Secure the aunomous vehicle embedded intelligence

    Smart territories Building the tomorrow smart

    territories Internet of Trust

    Deploying an Internet of Everything

    2

  • SystemX: Key figures

    3

    3 7

  • T1: virtualization

    Projet ELA

    T2: Image processing

    T3: Safe algorithms for Autosar

    multicore architectures

    T4: Cybersecurity

    Project objectives

    Create architectural patterns ensuring the tradeoffs between scalability, safety, security and cost

    Propose methods and tools to control the costs of design and validation

    Create the technological components for "affordable architectures

  • Projet ELA: Partenaires

    5

  • Dploiement de modles Simulink sur plates-formes AUTOSAR (AUTomotive Open System ARchitecture) multi curs

    ELA: Tche 3

    6

    Objectif:

    Proposition dune mthode et de loutillage pour la conception dalgorithmes dans lenvironnement Autosar et multicur

  • Multi-core Hardware architecture

    T3: Safe algorithms for Autosar multicore architectures

    7

    Methods & tools Verification

    Implementation and configuration

    Test defnition

    Tests & monitoring

    Objective

    - Methods and tools for Autosar

    application design

    - Validation on multicore ECUs

    Functional/operational requirements

    Hard real-time constraints

    System model (Simulink)

    Challenge

    - Ensure deterministic behavior in the

    multicore execution environment

    - Overcome the limitation of execution model

    of Simulink

  • AUTOSAR Project Objectives

    8

    Improved complexity management through an increased

    reuse of SW modules between OEM and suppliers

  • AUTOSAR partnership

    9

    10 Core Partners

    48 Associate Members

    52 Premium Members

    OEM

    Tier 1

    Standard

    Software

    Tools

    Semi-

    conductors

    CapeWare

    Source:

    file:///P:/http://www.vector-informatik.de/index.htmlhttp://www.delphi.com/http://www.dspace.de/ww/en/pub/home.htmhttp://www.renault.com/gb/home/accueil.htmhttp://www.volvo.com/http://www.st.com/stonline/index.htmhttp://www.hitachi.com/index.htmlhttp://www.johnsoncontrols.com/http://www.mando.com/http://worldwide.hyundai-motor.com/http://www.tnisoftware.com/http://www.fev.com/index3.htmhttp://www.alpine.de/alpine/cms/index.php?sid=d324dcfe02ed2a5df5f82f2986b8777e&language=english

  • AUTOSAR Layered Architecture

    10

    ECU-Hardware

    AUTOSAR Runtime Environment (RTE)

    Actuator Software

    Component

    AUTOSAR Interface

    Application Software

    Component

    Sensor Software

    Component

    Application Software

    Component

    ..............

    AUTOSAR Software

    Basic Software

    Standardized Interface

    AUTOSAR Interface

    AUTOSAR Interface

    AUTOSAR Interface

    Microcontroller Abstraction

    AUTOSAR Software

    Component

    Interface

    ECU Firmware

    Standard Software

    Standardized AUTOSAR Interface

    Services

    Standardized Interface

    ECU Abstraction

    AUTOSAR Interface

    Standardized Interface

    Complex Device Drivers

    AUTOSAR Interface

    API 2 VFB & RTE relevant

    Standardized Interface

    Communication

    Standardized Interface

    Standardized Interface

    Operating System

    API 1 RTE relevant

    API 0

    Sta

    nd

    ard

    ized

    In

    tefa

    ce

    API 3 Private Interfaces inside Basic Software

    possible

  • AUTOSAR SW-C (Software Component)

    11

    Application is divided into SW-Cs.

    Software Components consist of

    - Ports

    Interface to other SW-Cs

    - Runnable Entities (or Runnables)

    Procedures which contain the actual implementation

    Triggered cyclically or on event (e.g. data reception)

  • Autosar RTE (Runtime Environment)

    12

    Interface between SW-Cs and Basic Software

    All calls to basic software pass through the RTE

    Communication method : Send/Receive signals, Client/Server functionality

    Triggering of runnables : Cyclically or On event

    Virtual Functional Bus

  • Industrial use case: Fuel Cell

    13

    Superviseur PAC

    Superviseur Elements Pile

    Pilotage ligne AIr

    Pilotage ligne H2

    Pilotage ligne Fluide Caloporteur

    Systme Oprant: Pile

    Environnement Vhicule

    Systme Contrle commande PAC

    Pilotage Module

    Puissance

  • Val

    idat

    ion

    Validation process

    14

    Hardware In the Loop

    System In the Loop

    Script cmm

    Flow monitoring

    Real-time analysis

    Model In the Loop

    Application: Hydrogen Fuel Cell

    System verification and

    validation

    Integration tests and

    verification

    Non-regression tests

    Formal methods

    (e.g. runtime verification)

  • Simulink => Autosar

    15

    1 2

    3

    4 5

    6 7

    Simulink model (discrete systems)

    atomic subsystem

    RT(1)

    AUTOSAR software architecture

    SW-C 1 SW-C 2 SW-C 3 SW-C n

    Virtual Function Bus (VFB)

    Dataflow Temps logique

    RTE communications Real time scheduling

    Simulink execution model Autosar execution model

    1. Code generation, worst-case execution time evaluation (WCET)

    2. RTE configuration

    3. SWC placement

    4. Scheduling definition

  • But multi-core change the development tasks

    16

    SW-C 1 SW-C 2 SW-C 3 SW-C n Application Description

    Allocation of SWCs to cores

    Mapping runnables to tasks

    Sequencing runnables

    Runnable

    Runnable

    Runnable

    Runnable Runnable

    Runnable

    Runnable Runnable

    Runnable Runnable

    Task 1 Task m

    r1(1,10,0) r2(1,15,0) r3(1,15,0) r4(1,30,5)

    F

    TCycle

    Ttic

    Task Core1

    Core 1

    Core 2

    Processor

    Runnable

    Runnable

    Runnable

    Runnable

    Runnable

    Runnable Runnable

    Application

    Operating System configuration

    Allocation challenge

    Synchronization challenge

    r1(1,10,0) r2(1,15,0) r3(1,15,0) r4(1,30,5)

    F

    TCycle

    Ttic

    Task Core2

    Parallelism introduces new complexity.

  • Standard Autosar Development workflow

    17

    OS&Rte configuration synthesis

    *.c;*.h

    Simulink model

    Arxml swc description

    EcuC xml files for Os & Rte

    configuration (Task, ScheduleTable,

    Runnable to Task mapping)

    Configure

    Swc source code Configure additional BSW

    modules and System description *.c;*.h

    Rte &Os source code

    Generate

    Generate

    Generate

    Import

    Import

    Import Import

    Generate

    Compiler *.elf Binary file

    Generate

    Configure

    allocation

    constraints

  • ELA development process for Autosar multi-core

    18

    SW-C 1 SW-C n

    Software view

    SWC-1

    SWC-2

    Operating System

    RTE

    BSWs

    SWCs, Inferfaces

    Dynamic architecture

    Static architecture

    Model view

    N cores ECU

    Import

    Implicit specifications of the flow

    Runnables order ?

    Triggering ?

    ELA objectives

    Dataflow

    model extract

    OS/RTE configuration

    Implementation

  • Data flow, ordonnancement, placement: notre dmarche

    Simulink => Synchronous Data Flow Graph (SDFG) Structure des bloques Simulink => Topologie SDFG

    Simulink multi rate communications =>

    Production, consommation des messages SDFG

    Marquage initial des filles des messages SDFG

    Activits/tches priodiques uniquement

    Atomicit des traitements des runnables

    WCETs maitriss

    19

    Dmarche

    1. Recherche de intervalles consommation/production

    2. Placement sur les curs, load balancing

    3. Regroupement des runnables dans les tches

    4. Ordonnancement Priodicits, offsets de dmarrage

    Priorits

    Trois publications

  • Synchronous Data Flow Graph (SDFG)

    20

    1 2 2 3 2

    3 3 2

    5 1

    2

    Acteurs Messages Filles dattente

  • Modlisation SDFG dun system Simulink

    Activits/tches priodiques uniquement

    21

    Bloc priodique Simulink Acteur SDFG runnable Autosar

    3 modes de communication entre acteurs Communication avec dlai

    Communication sans dlai

    Rapide vers Lent

    Lent vers Rapide

    Production/Communication dpendent des priodes

    Foncti