Loria

AEE
Une Architecture Electronique Embarquée pour les

systèmes embarqués dans l’automobile
* Françoise Simonot-Lion (simonot@loria.fr)
INPL - LORIA (UMR CNRS 7503) – Nancy
* Jean-Pierre Elloy (elloy@irccyn.ec-nantes.fr)
* Yvon Trinquet (Yvon.Trinquet@irccyn.ec-nantes.fr )
ECN - IRCCyN (UMR CNRS 6597) – Nantes
GDR ARP – thème STRQDS

16 janvier 2003
http://aee.inria.fr
Constructeurs : Laboratoires de recherche :
Equipementiers :
+ EADS Launch Vehicles
Financé par le Ministère de l’Industrie (septembre 1998 - décembre 2001)
GDR ARP – STRQDS / 16 janvier 2003 1

Françoise Simonot-Lion - LORIA
Jean-Pierre Elloy – Yvon Trinquet - IRCCyN
Plan
■ 1 - Le contexte
■ 2 - La problématique
■ 3 - L’atelier de développement
■ 4 - La construction d’un système
◆ Couche « Projet »
Objets
◆ Couche « Fonctionnelle »
◆ Les composants architecturaux
Activités
◆ Couche « Logicielle »
◆ Couche « Matérielle »
◆ Couche « Opérationnelle »
■ 5 - Conclusions, points durs et … la suite
1 - Le contexte
1.1 - Le contexte du marché
Quelques chiffres
• Production de véhicules dans le monde :

40 millions (1998) 60 millions (2010)
• Coût de l’électronique embarquée

37 000 M$ (1995) 60 000 M$ (2000) +10% by year
Coût de l’électronique
• = 20%
Coût du véhicule
• Augmentation du confort et de la sécurité

• Les nouvelles normes de pollution
• Prestations nouvelles (impossibles en technologie classique)
• Fonctions X-by-wire
1.2 - Le contexte technologique
Des fonctions
critiques
Architecture de
communication
Crédit photographique PSA Peugeot - Citroën

Calculateurs

Complexité fonctionnelle
• Lois de commande multivariable
• Nombre de grandeurs d’influence
• Nombre de modes de fonctionnement
Complexité architecturale
• Nombre et hétérogénéité des calculateurs et réseaux
• Diversité des contraintes comportementales et temporelles
Complexité inter-systèmes
Accroissement de la criticité

1.3 - Le contexte de développement
Acteurs du développement
• Cycle de développement partagé entre

• équipementiers
• constructeurs
• Echanges constructeurs / équipementiers
• échange de documents ou de produits
• boîte noire / boîte grise / boîte blanche
• cahier des charges (exigences) / test
• Relations constructeurs / équipementiers

• propriétés intellectuelles

2 - La problématique
2.1 - La demande … du client
• Personnalisation des véhicules

… du constructeur • Diversification de l’offre
• Sortie fréquente de modèles
• Intégration rapide de services
• Réduction des coûts
… du produit Flexibilité
des
• Qualité architectures
• Sûreté

Flexibilité de l’allocation du logiciel
Flexibilité
des
architectures
F1 F2 F3
c ECU c ECU ECU c ECU ECU c

a a a a
• Réutilisation
• Intégration
• Allocation
F1 F2 F3
ECU : calculateur
c : capteur c ECU c ECU c ECU c
a a a ECU a
a : actionneur
2.2 - Le processus
… d’intégration
• Système = assemblage de composants

• Cahier des charges -> suivi des exigences
… d’échange
• Délimitation de sous-architectures
• Négociation de compatibilité d’exigences
• Modélisation externe de prestations
• Fourniture de boîtes blanches, grises ou noires

3 - L’atelier
3.1 - L’ossature
Outil - Validation
Outil - Gén. test Spécification Validation
Outil système système Testeur
Spécification
Conception Intégration
Outil - Validation Système système
Outil - placement Outil - calibration
Outil - développement
Evaluation de
performances
Code
Analyseur de
Générateur
code
de code
Description de
GDR ARP – STRQDS / 16 janvier 2003
l’architecture 10
3.2 - Le dénominateur commun
Description de
l’architecture
AIL_Transport :
AIL Architecture Implementation Language
pour les applications dans le domaine du transport
• Définit un référentiel commun pour modéliser tout ou partie

d’une architecture électronique embarquée
• Facilite les échanges entre acteurs
• Est utilisé à toutes les étapes du processus de développement
Diagrammes de classes UML

4 - La construction d’un système
… s’appuie sur des niveaux d’abstraction qui …
… définissent des points de vue sur tout ou partie
d’une architecture électronique embarquée
… sont des descriptions différentes du même système,

et utilisées pour des fins différentes :
• une vue de haut niveau

(spécification du produit - spécification fonctionnelle)
• une vue intermédiaire décrivant les aspects logiciel et matériel
• une vue de bas niveau décrivant le système tel qu’il est
GDR ARP – STRQDS / 16 janvier 2003 Descriptions de l’implantation 12

… se décline en couches :
Couche projet
Couche fonctionnelle
Logiciel
support Architecture
matérielle
Logiciel Couche
applicatif
Architecture Couche
logicielle d’instrumentation matérielle
Couche opérationnelle

AIL Classes de la couche « Projet »
… modélisent la variété de la gamme des produits

(véhicules) du projet, en fonction :
• du niveau de confort et de prestation de chaque produit
• des alternatives des mêmes services à chaque niveau
• des options offertes au client
• Un véhicule est la réalisation d’un ensemble de prestations

• Suivant le type du véhicule, des prestations sont fournies ou en options
• Une prestation peut se décliner en plusieurs versions
• Suivant le type du véhicule, une prestation possible est fournie dans une version
imposée, ou choisie par le client parmi des versions proposées

se décline
prestation Service en ...
version d’une prestation Variant
sera vendu
sous
plusieurs ...
projet véhicule Project
type de véhicule SystemType
véhicule System

est un
prestation Service ensemble
possible
de ...
version d’une prestation Variant
projet véhicule Project
type de véhicule SystemType
ce que peut
véhicule System acheter un
client
v 2.5

Activités sur la couche
« Projet »
• Vérification de cohérence
exemple: tout système électronique possible (objet System) embarqué
dans un véhicule d’une gamme donnée (objet Project)
réfère des prestations (objet Service) existantes
dans une version (objet Variant) existante et possible pour
le type du véhicule (objet SystemType) et la prestation
choisie
• Documentation
-- > Gestion de configuration, historisation

AIL Classes de la couche « Fonctionnelle »
… modélisent la spécification fonctionnelle des prestations

attendues de l’architecture embarquée, indépendamment de leur
réalisation et de leur localisation dans l’architecture réelle
• chaque version d’une prestation est réalisée par une fonction
• il peut y avoir (lors des études) plusieurs solutions alternatives
• à chaque véhicule correspond plusieurs organisations d’un
ensemble de fonctions
• toute fonction peut consommer des données fonctionnelles en entrée
et en produire en sortie
• les capteurs et actionneurs sont des sources et des puits de données
• la réalisation d’une prestation dans un mode de fonctionnement est
décrite par des fonctions et les flots de données qu’elles s’échangent
Françoise Simonot-Lion - LORIA • la spécification est hiérarchique
se décompose
en ...
fonction Function
consomme
données consommées Functional Input

produit
données produites Functional Output
capteur / actionneur Device

Organisation des Functional Architecture

fonctions d’un véhicule contient des ...
Function
est reliée à d’autres fonctions
ou à l’instrumentation par ses ...
Functional Input Functional Output

via des ...
Connexion de fonctions, Functional Flow

de fonctions avec l’instrumentation
par flots de données
Classes de la couche
AIL « Fonctionnelle »
v 2.5
Organisation des fonctions
Ports d’entrées-sorties
Flots de données
(types des données échangées)
Compatibilité applicative
GDR ARP – STRQDS / 16 janvier 2003 (entre données de types 22
v 2.5
Diagramme de contexte
Environnement
du diagramme
« Fonctionnelle »
exemple: dans une système embarqué (objet FunctionalArchitecture)
toute donnée consommée (objet Functional Input) par une
fonction (objet Function) est produite (objet Functional
Output) par une fonction ou par un capteur (objet Device)
• Documentation
-- > Modélisation comportementale

-- > Vérification des spécifications fonctionnelles
connexion à un outil de preuve de comportement / temps
Les composants architecturaux
Device
Device Device
Device Device
Device Device
Device
Driver COM-SC ICEM OS-SC
Composants
matériels Device
Device Device
Device Device
Device
Device ECU Network
Device
Device Device
Device
Composants Device Device Driver COM-SC
Device Device
logiciels ASC LDM Device
Device Device
Device
ICEM OS-SC
Composants Composants
distribuables dédiés
AIL Classes de la couche « Logicielle »
… modélisent la partie du système qui est réalisée

sous forme logicielle
• le modèle distingue entre logiciel allouable et logiciel résident
• la plus petite entité de la couche logicielle logiciel est une

entité de programmation non sécable entre plusieurs sites
• les échanges de données entre les fonctions de la couche

fonctionnelle sont dérivés dans la couche logicielle

composant logiciel SoftwareComponent
données consommées SoftwareInput
données produites SoftwareOutput
organisation des Allocatable Components

composants logiciels Architecture
connexion entre
composants SoftwareFlow
logiciels
Un composant logiciel Software component
… peut être un composant

distribuable Free Software component
c’est-à-dire un :
• composant applicatif ASC
• gestionnaire local de
capteur ou actionneur LDM

v 2.5
Architecture des
composants
allouables
Ensemble des
composants
logiciels
Ensemble des
composants logiciels
GDR ARP – STRQDS / 16 janvier 2003allouables 29
… peut être aussi un composant dédié à un calculateur,

c’est-à-dire un :
composant du ICEM
gestionnaire d’échange
pilote d’E/S et réseau Driver COM SC
composant du système OS SC
d’exploitation
Classes de la
AIL couche « Logicielle »
v 2.5
Couche « Matérielle »
Architecture des
composants du
support d’exécution
Ensemble des
composants
logiciels
Utilitaires du
support d’exécution
est constitué de:
entités de Logical Task

programmation
…caractérisées par : mode d’activation
WCET/type de processeur
paramètres d’ordonnancement
...

v 2.5
Tous composants logiciels
(allouables ou non)
Tâche
logique
… déclenchée
… déclenchée sur condition
sur condition temporelle
Françoise Simonot-Lion - LORIA événementielle
« Logicielle »
exemple: chaque donnée produite par une fonction (objet Function) de
la couche fonctionnelle est produite par une tâche logique
(objet Logical Task) dérivée de cette fonction.
• Documentation
-- > Génération du code source des composants logiciels

AIL Classes de la couche « Matérielle »
… modélisent les éléments matériels du support

d’exécution de l’architecture, les capteurs et les
actionneurs
• Les calculateurs (micro-contrôleurs) et les réseaux

• Les connexions des calculateurs aux réseaux
• Les dépendances technologiques entre capteurs et entre actionneurs

calculateur ECU
réseau Network
connexion de
calculateur sur Network Connection
réseau
capteur et Device
actionneur
Equipment

v 2.5
Composants matériels
du support d’exécution
Réseaux
Calculateurs

v 2.5
Dépendance
technologique Composants logiciels
Nom
Capteurs et logique
actionneurs
établi après
placement Connexion
à l’ECU
Matériel du support
d’exécution
« Matérielle »
• Documentation
-- > Calcul de coûts

-- > Dérivation des plans de câblage
-- > Schéma énergétique et compatibilité CEM

AIL Classes de la couche « Opérationnelle »
… modélisent les entités exécutables après

codage, placement et optimisation --> tâches OS
… modélisent la localisation des données et leurs

inclusions en trames dans les échanges répartis

AIL Éléments de la couche « Opérationnelle »
1
Couche logicielle
Composants
logiciels ASC#2 2 1
ASC#2 ASC#3 ASC#4
• flots logiciels
1
1 1 1 1
• tâches 2
logiques 2 2 2
3
Couche opérationnelle
OS-Task OS-Task OS-Task

Couche matérielle
OS-Task
#1 #2 #3 #4
1 2 1 2
Tâches OS 1 2 1
3 ECU#1 2 ECU#2
Trames Frame#1 1 2
AIL Architecture « Opérationnelle » d’un site
Composants logiciels applicatifs (A-SC)

Library Software Components
Operating System
Gestionnaire des échanges inter composants
Inter Component Exchange Manager (ICEM)
OSEK-OS
L-SC
Gestionnaire local de
capteur / actionneur (LDM-SC) Gestionnaire de
communication
(COM-SC)
Drivers (DRV-BSC) OSEK-COM
ECU
Others
Local Devices
ECU
(Actuator/Sensor)
Networks

v 2.5
Tâche OS
(temps réel)

v 2.5
Trame réseau
Donnée répartie

« Opérationnelle »
• Placement automatique sous contraintes
• Validation de propriétés temps réel

(évaluation de performances)
• Documentation
-- > Génération de vecteur de tests

-- > Configuration, déploiement
Conclusions
• AIL_Transport : un langage de référence pour modéliser

les systèmes électroniques embarqués dans l’automobile
• qui assure la maîtrise de la diversité des systèmes
• qui facilite les échanges constructeurs / équipementiers
• Validation sur des prototypes (outils de placement,
d’évaluation de performances, de documentation,
démonstrateurs)

Point dur
• Composition d’architectures :
algèbre de composition > cohérence

Point dur
• Eclatement / aggrégation des exigences :
opérateurs d’exigences > complétude

}~|

;
=;<> 87:9
?@
+-*,
NM I ./,
SUNT NNPO KJJ

QR IL
0

VW 2311
X | 546

}~
fb bbac ]^^
hg\c ebd _]` "#
\ $%
#'&(
YZ )
• Modes de fonctionnement :
synthèse d’inter-gestionnaires
ij \[
k

EF BAC
GG
H D
um qrr
no st
q
lm
Points durs
yu lvw npo
zz
{ x

!

49
®²¯ ÉȨ̀
° Ê
»
±»°¼ ¸¹
²½ º
®¯ recouvrement
²Â ³ ±°²
®²¯ ²²µ½ À¿¿
° ¶ ³Á ¯
·

³́
®µ´
º̧

Ë¼ ¶²·
·Ä ÊÉȨ̀

±² ²²Â½ ³¿¿
contraints par des modes de
®»·½ ¶²µ À³Á ¥¦

[ · §¨
• Modes de fonctionnement :
synthèse de modes passerelles
]\_^ ZY ¦ª©«
Ã¼ ¬
·Ä
º̧
²ÅÅ Ȩ̀
¾² ǢÇ ÊÉ

»» ¸¹ RQS
· º T
}~| RVUW ²ÅÅ ³¿¿
X Ǣ ÀÁ
} ³ 76854
¾²
ÅÅ
ǢÇ 9:
#$
%'&
h »» ¸¹
jilk fg tuv · º $(" !
wyx *)
zw{

KL
MJI
£¤ ¡¢ NO
¢ £ PH

¡
¢

à
cbd
e
>=?
@< ;
AB ..-
? /0,+
¢ 213
m
onp EFDC
rsq HG
50
Points durs …
• Cohérence fonctionnelle, comportementale et temporelle entre la
spécification qui est décrite dans la couche fonctionnelle et la
conception décrite dans la couche opérationnelle.
• Mécanismes de construction associant sous-architectures en boîtes

blanches, grises et noires et garantissant les propriétés des sous-
architectures
• Processus de conception bottom-up avec garantie des propriétés
• Spécification et dérivation des paramètres de sûreté de

fonctionnement de la spécification à la conception (ex : sécurité
niveau 3 -- > temps borné entre deux événements)
•…
… la suite
• Standardisation : UML Profile, XML Application
• Projet européen ITEA - EAST EEA


Langue

Loria

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Loria

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

AEE

Une Architecture Electronique Embarquée pour les

GDR ARP – thème STRQDS

Constructeurs : Laboratoires de recherche :

Financé par le Ministère de l’Industrie (septembre 1998 - décembre 2001)

GDR ARP – STRQDS / 16 janvier 2003 1

• Production de véhicules dans le monde :

• Coût de l’électronique embarquée

• Augmentation du confort et de la sécurité

Crédit photographique PSA Peugeot - Citroën

GDR ARP – STRQDS / 16 janvier 2003 4

GDR ARP – STRQDS / 16 janvier 2003 5

• Cycle de développement partagé entre

• Relations constructeurs / équipementiers

GDR ARP – STRQDS / 16 janvier 2003 6

• Personnalisation des véhicules

GDR ARP – STRQDS / 16 janvier 2003 7

c ECU c ECU ECU c ECU ECU c

• Système = assemblage de composants

GDR ARP – STRQDS / 16 janvier 2003 9

• Définit un référentiel commun pour modéliser tout ou partie

Diagrammes de classes UML

… sont des descriptions différentes du même système,

• une vue de haut niveau

• une vue intermédiaire décrivant les aspects logiciel et matériel

• une vue de bas niveau décrivant le système tel qu’il est

GDR ARP – STRQDS / 16 janvier 2003 Descriptions de l’implantation 12

GDR ARP – STRQDS / 16 janvier 2003 13

… modélisent la variété de la gamme des produits

• Un véhicule est la réalisation d’un ensemble de prestations

GDR ARP – STRQDS / 16 janvier 2003 14

version d’une prestation Variant

type de véhicule SystemType

GDR ARP – STRQDS / 16 janvier 2003 15

projet véhicule Project

type de véhicule SystemType

GDR ARP – STRQDS / 16 janvier 2003 17

-- > Gestion de configuration, historisation

… modélisent la spécification fonctionnelle des prestations

données consommées Functional Input

données produites Functional Output

capteur / actionneur Device

GDR ARP – STRQDS / 16 janvier 2003 20

Organisation des Functional Architecture

Functional Input Functional Output

Connexion de fonctions, Functional Flow

Organisation des fonctions

-- > Modélisation comportementale

… modélisent la partie du système qui est réalisée

• le modèle distingue entre logiciel allouable et logiciel résident

• la plus petite entité de la couche logicielle logiciel est une

• les échanges de données entre les fonctions de la couche

GDR ARP – STRQDS / 16 janvier 2003 26

composant logiciel SoftwareComponent

données consommées SoftwareInput

données produites SoftwareOutput

organisation des Allocatable Components

Un composant logiciel Software component