Déploiement de modèles Simulink sur plates-formes AUTOSAR multi cœurs Projet ELA (Electronique et Logiciel pour l’Automobile)
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
Déploiement de modèles Simulink sur plates-formes AUTOSAR (AUTomotive Open System ARchitecture) multi cœurs
ELA: Tâche 3
6
Objectif:
Proposition d’une méthode et de l’outillage pour la conception d’algorithmes dans l’environnement Autosar et multicœur
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:
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
Système Opérant: Pile
Environnement Véhicule
Système Contrôle 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 démarche
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
Activités/tâches périodiques uniquement
Atomicité des traitements des runnables
WCETs maitrisés
19
Démarche
1. Recherche de intervalles « consommation/production »
2. Placement sur les cœurs, load balancing
3. Regroupement des runnables dans les tâches
4. Ordonnancement Périodicités, offsets de démarrage
Priorités
Trois publications
Synchronous Data Flow Graph (SDFG)
20
1 2 2 3 2
3 3 2
5 1
2
• Acteurs • Messages • Filles d’attente
Modélisation SDFG d’un system Simulink
Activités/tâches périodiques uniquement
21
Bloc périodique Simulink Acteur SDFG runnable Autosar
3 modes de communication entre acteurs Communication avec délai
Communication sans délai
Rapide vers Lent
Lent vers Rapide
Production/Communication dépendent des périodes
Fonctions de marquage initial: formules simples Dépendent du mode
Périodes
3 publications
Perspectives
En cours Data flow, ordonnancement, placement, WCET fixé
En développement, publications en cours
A planifier Industrialisation
Variabilité des WCETs
Ordonnancement optimiste
Tolérances
Mode dégradé
22
Merci
23