DU VÉHICULE INFORMATISÉ AUX VÉHICULES CONNECTÉS, LA COMPLEXITÉ À TOUS LES ÉTAGESMatthieu Roy, LAAS-CNRSÉquipe TSF – Sûreté/SécuritéDépartement Informatique Critique

OUTLINE

Historique : les raisons de l’augmentation de la complexité

Maîtriser la complexité : standardisation dans l’automobile

Standards & sources actuelles de complexité

Défis pour les systèmes automobiles informatisés

Défis pour les systèmes automobiles connectés

PETIT HISTORIQUE DE LA COMPLEXITÉ EN AUTOMOBILE

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Débuts de l’automobile:

Architectures mécaniques :

fiabilisation

rationalisation industrielle

fardier à vapeur, Cugnot (1771)

Ford model T

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Années 50-70 :

augmentation des performances

utilisabilité

vitesse

Performances ⇒ Complexité mécanique

Carburateur Solex

CarburateurWeber

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Années 60-80 : normes anti-pollution US

Limites du modèle électro-mécanique

Démocratisation injections électroniques (Bendix, Bosch)

“Analog Computers”

Bosch L-jetronic

D-jetronic computer

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Années 60-80 : normes anti-pollution US

Limites du modèle électro-mécanique

Démocratisation injections électroniques (Bendix, Bosch)

“Analog Computers”

Bosch L-jetronic

D-jetronic computer

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Architectures digitales

Gestion allumage et carburant dans un seul bloc

intégration améliore émissions, puissance, maintenance …

"Schafer et al. Motronic – an advanced engine management system for future emission standards, proc. Int. Symp on Automotive Electronics and Alternate Energy Vehicles, 1999.”

Motronic 7, 1997

Réduction émissions ⇒ complexité

HISTORIQUE DES ARCHITECTURES AUTOMOBILES

Années 2000 :

Une complexité devenue trop élevée…

Informatisation des systèmes automobiles

MB w124 : câblage

MAÎTRISER LA COMPLEXITÉ : LA MARCHE VERS LES STANDARDS

INFORMATISATION DU VÉHICULE

Tradition automobile : développement en interne

Années 2000 :

maîtriser la complexité du développement

changement de modèle de développement

constructeurs, équipementiers

nécessité de compatibilité

OSEK : PREMIER STANDARD

OSEK : « Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug » (Systèmes ouverts et interfaces pour l’électronique des véhicules automobiles)

VDX : « Vehicle Distributed eXecutive »

OSEK-VDX = OSEK-VDK (consortium allemand) + VDX (Renault, PSA)

standard ouvert,

porté par consortium d’industriels

définit des interfaces

OSEK

Architecture :

OSEK COM : transfert de données

OSEK NM : contrôle réseau

OSEK OS : OS temps réel, non POSIX

OSEK OIL : langage

STANDARDS ACTUELS

AUTOSAR

fondé en 2003 sur la base d’OSEK :

architecture pour ECU (Electronic Control Unit)

basé composants

OS temps réel (tâches, deadlines)

abstraction niveau réseau

AUTOSAR : VUE GLOBALE

AUTOSAR : INTERFACES

AUTOSAR : TÂCHES

COMPLEXITÉ : LE LOGICIEL DEVIENT PRÉPONDÉRANT

AUTOSAR Consortium

LES CONTRAINTES DE SURETÉ ET DE SÉCURITÉ

Norme ISO 26262 : adaptation automobile de la norme IEC 61508

Hazard analysis and Risk Assessment (H&R)

Basé sur risques pour le véhicule et ses passagers

Classification des composantsselon le niveau ASIL (Safety Integrity Level)

LES SOURCES DE LA COMPLEXITÉ

COMPLEXIFICATION DU SYSTEME

Augmentation de la complexité due :

Normes : pollution, sûreté

Aide à la conduite (ADAS)

Services aux utilisateurs :

Confort dans l’habitacle

COMPLEXIFICATION DU SYSTEME

Transmission Systems

Electrical Systems

Climate Control

Driving Assistance

Interior Controls

Wiper Systems

Lighting Systems

Thermal Powertrain

ÉVOLUTIONS ACTUELLES

des ADAS aux véhicules autonomes

ACC (Adaptive Cruise Control),

TJP (Traffic Jam Pilot)….. Etc.

Développement agile, prototype rapide, temps de validation raccourcis

Mises à jour à distance, maintenance, amélioration, location de services

Business model qui évolue (ex. Tesla, over-the-air updates)

ÉVOLUTIONS ACTUELLES

des ADAS aux véhicules autonomes

ACC (Adaptive Cruise Control),

TJP (Traffic Jam Pilot)….. Etc.

Développement agile, prototype rapide, temps de validation raccourcis

Mises à jour à distance, maintenance, amélioration, location de services

Business model qui évolue (ex. Tesla, over-the-air updates)

Ces systèmes complexes doivent pouvoir évoluer…

… malgré des contraintes de sûreté fortes !!

DÉFIS : VÉHICULE INFORMATISÉ

DÉFI 1: DÉVELOPPEMENT AGILE

ÉVOLUTION DU LOGICIEL

Nécessité de faire évoluer le logiciel embarqué :

Maintenance

Personnalisation du véhicule

Améliorations

Diminution du temps de cycle de développement

Développement agile

EST-IL POSSIBLE DE FAIRE ÉVOLUER UN SYSTÈME AUTOSAR ?

Question : ajouter une fonctionnalité ou mettre à jour un système AUTOSAR ?

Problème : AUTOSAR est un système fermé, statique.

«AGILE» AUTOSAR ?

Collaboration CIFRE LAAS-Renault

Concepts :

Préparer le système pour évolution future

Intégration d’exécutables vides : «Containers»

Limitations :

pas de modification de communication, hardware fixé

processeurs (ECU) mono-cœurs

SEMI-AGILE AUTOSAR

Runnable2 Runnable5 Container Containerinitial task :

Runnable2 Runnable5 ContainerNewRunnableupdated task :

MODIFICATION DU PROCESSUS DE DÉVELOPPEMENT

MISES À JOUR : CONTRAINTES TEMPS RÉEL

• Système mis à jour

ΓN = {τ1,...,τ N}τ i = {Ti,Di,Ci}

Γ 'N = {τ1,...,τ N}τ i = {Ti,Di,C 'i}

LamiseàjourmodifieleWCET(piretempsd’exécution)

Lesystèmeest-iltoujoursordonnançable?

• Système initial

ANALYSE D’ORDONNAÇABILITÉ

Analyse des WCET

Analyse des contraintes de précédence

Possibilité de valider la mise à jour

sans recalculer l'ordonnancement

E. Bini and G. Buttazzo. Schedulability analysis of periodic fixed priority systems. Transactions on Computers, 2004.

La région Mn

qui contient toutes les valeurs possibles pour les WCET des tâches del’ensemble de tâches �

n

est définie telle que :M

n

(T1, ..., T

n

, D1, ..., D

n

) = {C1, ..., C

n

œ Rn

+ : �n

est ordonnançable avec un algorithmeà priorité fixe}

Cette région de l’espace délimite toutes les valeurs possibles pour les temps d’exé-cution de chacune des tâches tels que le système reste ordonnançable. Les auteurs ontalors proposé un théorème afin de déterminer de manière plus précise cette région :

Théorème 1 [26] La région des systèmes ordonnançables Mn

est définie parM

n

(T1, ..., T

n

, D1, ..., D

n

) = {C1, ..., C

n

œ Rn

+ :

fii=1..n

fltœPi≠1(Di)

C

i

+i≠1ÿj=1

Gt

T

j

HC

j

Æ t }

où Pi

(t) est l’ensemble des points d’ordonnancement tels que :Y_]_[P0(t) = t

Pi

(t) = Pi≠1

37t

T

i

8T

i

4 €P

i≠1(t)

Le C-space correspond à l’espace dans lequel chaque coordonnée est le WCET destâches. Un point dans cet espace correspond à un ensemble de valeurs de WCET pourchacune des tâches de l’ensemble considéré. Le Théorème 1 permet de déterminer une ré-gion dans cet espace contenant tous les points pour lesquels le système est ordonnançable.D’un point de vue des mises à jour dynamiques du système, déterminer la distance entrele point correspondant au système actuel et les limites de cet espace permet de connaitrela flexibilité disponible dans le système pour les mises à jour. La figure 4.3 montre unexemple de C-space pour un système de 3 tâches (cet exemple est tiré de [26]). Chacunedes inéquations obtenues avec le Théorème 1 correspond à un demi espace et l’assem-blage de l’ensemble des inéquation nous permet d’obtenir une représentation visuelle del’espace des WCET possible pour le système de tâches.

Bien que cette méthode d’évaluation pour l’ordonnançabilité d’un système est ini-tialement conçue pour des ordonnancement de type RMS (Rate Monotonic Scheduling),il est possible de l’utiliser pour n’importe quel système à priorité fixe. L’inconvénientmajeur de cette approche dans le contexte qui nous intéresse, est lié à l’hypothèse quetoutes les tâches sont indépendantes. Il n’est donc pas possible de prendre en compteles contraintes de précédence en appliquant directement cette méthode. Toutefois, il estnécessaire de prendre en compte ces contraintes lors de l’analyse d’ordonnancement. Ilfaut donc soit traiter ces contraintes séparément, soit utiliser une autre approche quipermette de les prendre en compte, cependant, qui est un problème connu pour êtredi�cile.

60

La région Mn

qui contient toutes les valeurs possibles pour les WCET des tâches del’ensemble de tâches �

n

est définie telle que :M

n

(T1, ..., T

n

, D1, ..., D

n

) = {C1, ..., C

n

œ Rn

+ : �n

est ordonnançable avec un algorithmeà priorité fixe}

Cette région de l’espace délimite toutes les valeurs possibles pour les temps d’exé-cution de chacune des tâches tels que le système reste ordonnançable. Les auteurs ontalors proposé un théorème afin de déterminer de manière plus précise cette région :

Théorème 1 [26] La région des systèmes ordonnançables Mn

est définie parM

n

(T1, ..., T

n

, D1, ..., D

n

) = {C1, ..., C

n

œ Rn

+ :

fii=1..n

fltœPi≠1(Di)

C

i

+i≠1ÿj=1

Gt

T

j

HC

j

Æ t }

où Pi

(t) est l’ensemble des points d’ordonnancement tels que :Y_]_[P0(t) = t

Pi

(t) = Pi≠1

37t

T

i

8T

i

4 €P

i≠1(t)

Le C-space correspond à l’espace dans lequel chaque coordonnée est le WCET destâches. Un point dans cet espace correspond à un ensemble de valeurs de WCET pourchacune des tâches de l’ensemble considéré. Le Théorème 1 permet de déterminer une ré-gion dans cet espace contenant tous les points pour lesquels le système est ordonnançable.D’un point de vue des mises à jour dynamiques du système, déterminer la distance entrele point correspondant au système actuel et les limites de cet espace permet de connaitrela flexibilité disponible dans le système pour les mises à jour. La figure 4.3 montre unexemple de C-space pour un système de 3 tâches (cet exemple est tiré de [26]). Chacunedes inéquations obtenues avec le Théorème 1 correspond à un demi espace et l’assem-blage de l’ensemble des inéquation nous permet d’obtenir une représentation visuelle del’espace des WCET possible pour le système de tâches.

Bien que cette méthode d’évaluation pour l’ordonnançabilité d’un système est ini-tialement conçue pour des ordonnancement de type RMS (Rate Monotonic Scheduling),il est possible de l’utiliser pour n’importe quel système à priorité fixe. L’inconvénientmajeur de cette approche dans le contexte qui nous intéresse, est lié à l’hypothèse quetoutes les tâches sont indépendantes. Il n’est donc pas possible de prendre en compteles contraintes de précédence en appliquant directement cette méthode. Toutefois, il estnécessaire de prendre en compte ces contraintes lors de l’analyse d’ordonnancement. Ilfaut donc soit traiter ces contraintes séparément, soit utiliser une autre approche quipermette de les prendre en compte, cependant, qui est un problème connu pour êtredi�cile.

60

LIMITES DE L’ADAPTATION DANS AUTOSAR

AUTOSAR est statique

Toute adaptation doit être «prévue»

Containers, contraintes matérielles (réseau, ECU)

Difficulté de garantir l’ordonnancement

Enveloppe d’adaptation définie à la construction

DÉFI 2 : INTÉGRER LA SAFETY

SAFETY DANS L’AUTOMOBILE

Norme ISO 26262 :

Définition d’ASIL par composant

Niveau de criticité (QM, A, B, C, D)

Nécessité d'intégrer l’injection de faute à tous les niveaux

INTÉGRATION ISO 26262 DANS PROCESSUS DE DÉVELOPPEMENT

Pre-implementation Phase / Design

Post-implementation Phase / Integration & Verification

System functional needs

System architecture

Product architecture

Preliminary hazards analysis (PHA)

System validation

System integration & verification

Product integration & verification

HW block integ- ration & verification

HW block architecture

SW block architecture

Product safety analyses

System safety analyses

HW block safety analyses

SW safety analyses

Implementation of SW modules & HW parts

L0: System

L1: Product

L2: HW & SW Block

L3: HW parts & SW Modules

SW module integ- ration & verification

Req.%1%

Req.%1%

Req.%6%%

Req%4%

Req%2%

Req.%9%

Req.%11%

Req.%8%%

Req.%10%

Req%3%

Req%5%

Req.%7%%

Req.%#% Requirements%on%Fault%Injec?on%in%the%ISO%26262%

Framework permettant  l’intégration de l’injection

de fautes dès les premières phases du développement

FAULT INJECTION EXPERIMENTS

94

6.1 Fault Injection Platform

A fault injection tool has been developed at Valeo, in order to implement the FI campaigns designs from the safety analyses. We mainly focus on the integration of two techniques: Software-Implemented Fault Injection (SWIFI) and Nexus-Based Fault Injection. These two methods have been introduced in Chapter 1.

6.1.1 Fault Injection Environment

Figure 6.1 shows an overview of the FI Environment

FIGURE 6.1 FAULT INJECTION ENVIRONMENT

This environment encompasses:

x The Target System is composed of the Front-Light Manager application (binary files ELF compiled from sources with Wind River Compiler) running on the SPC56EL70 microcontroller described before.

x The Controller is composed of the interface of the debugger Lauterbach TRACE 32. It enables fault injection experiments via scripts (PRACTICE Language). It also captures the execution trace of the target, controls the access to the memory for monitoring some variables, and provides commands to start the fault injection test cases according to a specified workload.

x The Lauterbach debugger (Lauterbach, 2015) is a central component of the Environment. It is connected to the controller via a USB link and to the target throughout a Nexus Probe. The debugger provides access to all memory sections of the microcontroller, particularly by monitoring the trace of the execution of the application (Monitor).

Data Collector

Data Analyzer

FITests Logs

ECU externalfault injection

ECU internalfault injection

+(Lauterbach tool: Debugger)

NEXUS / JTAG Adapter

Debugger Interface(Trace 32)

USB

Microcontroller SPC 56EL70

Application Binary files

FITests Logs

FITests Logs

Application Source filesApplication Source files

Application Source files

Application Source filesFI Specific

modification Workloadlibrary

Funct. Req.&Behavioralmodels

Faultlibrary

SafetyAnalyses(FMECA, FTA…)

MeasuresManual

CompilerWind River Flashing

FITests Logs

FITests Logs

FITests

Scripts

Fault injector, Monitor and Workloadgenerator

Controller

Target

Pintard, Leeman, Ymlahi-Ouazzani, Fabre, Kanoun, Roy. Using Fault Injection to Verify an AUTOSAR Application According to the

ISO 26262. SAE Technical Papers Journal, 2015

intégration FMEA – campagnes d’injection de fautes

DÉFI 3 : AGILITÉ 2 – ADAPTATION POUR LA SAFETY

RESILIENT COMPUTING

Adaptation du logiciel ⇒ adaptation des mécanismes de safety

Résilience ≣ tolérance aux fautes persistante en dépit changements

Système automobile ≣ système dependable.

Nécessité de fournir des mécanismes de résilience dans systèmes adaptatifs automobiles

MÉCANISMES DE MISE À JOUR ET TOLERANCE AUX FAUTES

L’adaptation du mécanisme de tolérance aux fautes doit aussi être tolérant aux fautes !

Approche basée composants

ajouter/retirer à la volée

mécanismes de surveillance on-line

architecture dynamique (cold : pas uniquement avant le déploiement)

Stoicescu, Fabre, Roy. Architecting resilient computing systems: A component-based approach for adaptive fault tolerance

Journal of Systems Architecture, 2017.

It is worth noting that our approach is reproducible on anyother platform that provides these features.

Figure 6: Component-based architecture of PBR

Figure 6 shows the resulting component-based architec-ture of PBR. The steps of the generic execution scheme areisolated in the components syncBefore, proceed, syncAfter.Thanks to the “design for adaptation” process, these vari-able features, that are subject to change during transitions,are mapped on small stateless components. The actual stateof the FTMs (e.g., request id, computation result) and thecommon parts of FTMs that were captured in the two baseclasses in the object-oriented design (i.e., FaultTolerance-Protocol and DuplexProtocol in Figure 3) are now mappedon components that are not modified during transitions be-tween FTMs, i.e., protocol, replyLog and server.

5. ADAPTATION OF FTMs AT RUNTIME

5.1 Adaptation process implementationFigure 7 outlines the adaptation process implementation

for executing fine-grained transitions between FTMs, un-der the supervision of the System Manager. The targetsystem runs an application to which are attached appro-priate FTM(s) (i.e., consistent with the current values of(FT,A,R)).

Hot Resilient Computing

System

FTM &

Adaptation Repository

New components

script

Transition package1

New components

script

Transition package2

Transition script

interpreter

modify

call

observe

trigger

Adaptation Engine

Monitoring Engine

Resilience Management

Service

FTM developer

System Manager

ON-LINEOFF-LINE

Cold Resilient Computing

Figure 7: Adaptation process implementation

When there is an inconsistency between the values of(FT,A,R) and the current FTM, the Resilience ManagementService triggers the Adaptation Engine giving it as input thenew FTM towards which a transition must be executed (if

such an FTM exists). The Adaptation Engine gets the re-quired transition package from the FTM&Adaptation Repos-itory. This package contains the new bricks that must beintegrated into the existing software architecture in order toexecute a di↵erential transition from the current FTM to thenew one and a script that operates the transition. Next, thetransition package feeds the Script interpreter that modifiesthe current FTM.

In our view, the process encompasses two aspects: coldresilient computing, covering o↵-line activities (the develop-ment of the transition packages from the repository), andhot resilient computing, consisting of all the other entitiesand their interactions that occur on-line. Together, thesetwo aspects form a loop: the cold one feeds transition pack-ages to the hot one, and the hot one provides feedback forimproving and enriching the cold one.

5.2 On-line fine-grained transitionsTo illustrate the feasibility of the approach, we performed

several fine-grained transitions between selected FTMs, cor-responding to the transition scenario from Figure 2. ThePBR!LFR transition is triggered by variations in A or R(based on Table 1) and requires changing the syncBeforeand syncAfter components (based on the generic scheme inTable 2). All the other components corresponding to themassive common parts are left untouched.

Each transition implies the deployment of a transitionpackage containing the new components that must be intro-duced in the existing architecture (in this example, syncBe-fore and syncAfter of LFR) and a script written in FScriptthat removes the components that are no longer necessary(here, syncBefore and syncAfter of PBR) and replaces themwith the new ones. In short, the script written in FScriptthat performs the PBR!LFR transition does the following:

• disconnect the old syncBefore and syncAfter from alltheir services and references;

• delete old components and add the new ones;

• connect the new syncBefore and syncAfter to all thenecessary services and references.

The LFR!LFR�TR transition (i.e., the composition ofLFR with TR) is triggered by the evolution of the faultmodel, from crash fault to crash fault and transient valuefaults. Such an evolution of the fault model may occurdue to hardware aging or physical perturbations. Table 2outlines the specificities of TR, namely the state captureand restoration before and after processing, respectively. Tosimplify the mapping on the component-based architecture,the behavior of TR is implemented by a proceed compo-nent that repeats processing and compares results. TheLFR!LFR�TR transition thus consists in replacing the el-ementary proceed component of LFR.

5.3 Consistency of distributed adaptationAs evolvability must not a↵ect the reliability of fault-

tolerant application, the consistency of transitions betweenFTMs must be ensured.Local consistency— FraSCAti and its integrated FScriptengine guarantee the consistency of local reconfigurationsperformed using scripts. FScript enforces an all-or-nothingsemantics [20]. The reliability of the reconfiguration is achieved

6

RESILIENT COMPUTING & AUTOMOBILE : ROS ?

AUTOSAR : orienté composants mais trop statique

Collaboration LAAS-Renault (2016-2019) :

Évolution des mécanismes de Tolérance aux Fautes au runtime

Plateforme ROS (Robotic Operating System)

Mécanisme publication/souscription entre nœuds du système

RESILIENT COMPUTING & AUTOMOBILE : ROS ?

AUTOSAR : orienté composants mais trop statique

Collaboration LAAS-Renault (2016-2019) :

Évolution des mécanismes de Tolérance aux Fautes au runtime

Plateforme ROS (Robotic Operating System)

Mécanisme publication/souscription entre nœuds du système

“BMW has been working on automated driving for the last decade (…). Several of these projects were presented at the 2015 Consumer Electronics Show, and (…) the

cars were running ROS for both environment detection and planning.” (Michael Aeberhard (BMW):

Automated Driving with ROS at BMW, May 31, 2016)

RESILIENT COMPUTING & AUTOMOBILE : ROS ?

AUTOSAR : orienté composants mais trop statique

Collaboration LAAS-Renault (2016-2019) :

Évolution des mécanismes de Tolérance aux Fautes au runtime

Plateforme ROS (Robotic Operating System)

Mécanisme publication/souscription entre nœuds du système

DÉFI 4 : INTÉGRATION DE BRIQUES LOGICIELLES HÉTÉROGÈNES…UNE NOUVELLE STANDARDISATION

BILAN DES DÉFIS PRÉCÉDENTS

Systèmes automobiles doivent

Fournir des mécanismes d’adaptation du logiciel

Y compris des mécanismes de safety

Intégrer des composants de niveaux de criticité différents, de fournisseurs différents.

Architecture multi-critique.

INTÉGRATION AVANCÉE

ADAS (Advanced driver-assistance systems) et véhicules autonomes nécessitent intégration de briques logicielles

plus complexes (vision, algorithmes de traitement)

pas prouvables (décision, machine learning)

non certifiables a priori (ROS)

… tout en garantissant la sûreté du véhicule…

ADAPTIVE AUTOSAR

«separation of concerns»

classic : safety critical

OSEK

ordonnancement fixe

adaptive :

POSIX

ordonnancement dynamique

1ère release : 31 mars 2017

AUTOSAR Consortium

DÉFI 5 : MAÎTRISER LA COMPLEXITÉ : RATIONALISER LES ARCHITECTURES

VERS DES ARCHITECTURES AUTOMOBILES STANDARDISÉES ET PARTITIONNÉES

Évolution des systèmes embarqués automobiles:

N ECU répartis → P multicœurs (N ≫ P)Partitionnement avancé de l’architecture

analogue à l’architecture ARINC 653 … mais en version dynamique

statique ≣ sur-réservation, sous-utilisationcoût trop élevé pour automobile

System Bus/Crossbar switch

Memory

RAISONS DU PARTITIONNEMENT AVANCÉ DE L’ARCHITECTURE

Mutualisation des ressourcesmaintenance, compromis poids / consommation / encombrement.

Réduction de la complexité de l'architecture

Utilisation de COTS (hard et soft)

Gestion de la multi-criticité

Rationalisation et standardisation

Facilité (?) des mises à jour… cette mutualisation a

un coût…

System Bus/Crossbar switch

Memory

RAISONS DU PARTITIONNEMENT AVANCÉ DE L’ARCHITECTURE

Mutualisation des ressourcesmaintenance, compromis poids / consommation / encombrement.

Réduction de la complexité de l'architecture

Utilisation de COTS (hard et soft)

Gestion de la multi-criticité

Rationalisation et standardisation

Facilité (?) des mises à jour… cette mutualisation a

un coût…

System Bus/Crossbar switch

Memory

RAISONS DU PARTITIONNEMENT AVANCÉ DE L’ARCHITECTURE

Mutualisation des ressourcesmaintenance, compromis poids / consommation / encombrement.

Réduction de la complexité de l'architecture

Utilisation de COTS (hard et soft)

Gestion de la multi-criticité

Rationalisation et standardisation

Facilité (?) des mises à jour… cette mutualisation a

un coût…

VERS UNE GESTION DYNAMIQUE DU PARTITIONNEMENT

Système partitionné : ⇒ perte d’information sur partages

⇒ non-déterminisme

⇒ support du run-time nécessaire

Résultats préliminaires LAAS-IRIT-ONERAExécution full load spéculative, surveillance à l’exécutionBasculement sur isolation (tâches critiques seules) si risque de dépassement temporel

Généralisation du full/isolation:plusieurs ordonnancements (statiques)

Gestion fine de la localisation spatiale des données

Différents niveaux de criticité ⇒ différents niveaux de service

Kritikakou, Marty, Pagetti, Rochange, Lauer, Roy. Multiplexing Adaptive with Classic AUTOSAR? Adaptive Software Control to Increase Resource Utilization in Mixed-Critical Systems. CARS

2016 - Critical Automotive applications : Robustness & Safety

VÉHICULES CONNECTÉS

DÉFI 6 : SÉCURITÉ DU VÉHICULE CONNECTÉ

SURFACE D’ATTAQUE DU VÉHICULE CONNECTÉ

Connection des véhicules :

augmentation de la surface d’attaque.

Nécessité de :

concevoir des canaux fiabilisés (chiffrement)

difficile en raison des acteurs multiples → standardisation

détecter les intrusions éventuelles

the automobile model being targeted and has the technicalskill to reverse engineer the appropriate subsystems andprotocols (or is able to purchase such information froma third-party). Moreover, we assume she is able to obtainthe appropriate hardware or medium to transmit messageswhose encoding is appropriate for any given channel.1When encountering cryptographic controls, we alsoassume that the adversary is computationally boundedand cannot efficiently brute force large shared secrets,such as large symmetric encryption keys. In general, weassume that the attacker only has access to informationthat can be directly gleaned from examining the systemsof a vehicle similar to the one being targeted.2 We believethese assumptions are quite minimal and mimic theaccess afforded to us when conducting this work.

By contrast, operational capabilities characterize theadversary’s requirements in delivering a malicious inputto a particular access vector in the field. In consideringthe full range of I/O capabilities present in a modernvehicle, we identify the qualitative differences in thechallenges required to access each channel. These inturn can be roughly classified into three categories:indirect physical access, short-range wireless access,and long-range wireless access. In the remainder of thissection we explore the threat model for each of thesecategories and within each we synthesize the “attacksurface” presented by the full range of I/O channelspresent in today’s automobiles. Figure 1 highlights whereI/O channels exist on a modern automobile today.

3.1 Indirect physical accessModern automobiles provide several physical interfacesthat either directly or indirectly access the car’s internalnetworks. We consider the full physical attack surfacehere, under the constraint that the adversary may notdirectly access these physical interfaces herself but mustinstead work through some intermediary.OBD-II. The most significant automotive interface isthe OBD-II port, federally mandated in the U.S., whichtypically provides direct access to the automobile’skey CAN buses and can provide sufficient access tocompromise the full range of automotive systems [14].While our threat model forbids the adversary from directaccess herself, we note that the OBD-II port is commonly

1For the concrete vulnerabilities we will explore, the hardwarecost for such capabilities is modest, requiring only commodity laptopcomputers, an audio card, a USB-to-CAN interface, and, in a fewinstances, an inexpensive, off-the-shelf USRP software radio platform.

2A question which we do not consider in this work is the extent towhich the attack surface is “portable” between vehicle models froma given manufacturer. There is significant evidence that some suchattacks are portable as manufacturers prefer to build a small numberof underlying platforms that are specialized to deliver model-specificfeatures, but we are not in a position to evaluate this question compre-hensively.

Figure 1: Digital I/O channels appearing on a moderncar. Colors indicate rough grouping of ECUs by function.

accessed by service personnel during routine maintenancefor both diagnostics and ECU programming.

Historically this access is achieved using dedicatedhandheld “scan” tools such as Ford’s NGS, Nissan’sConsult II and Toyota’s Diagnostic Tester which arethemselves programmed via Windows-based personalcomputers. For modern vehicles, most manufacturershave adopted an approach that is PC-centric. Under thismodel, a laptop computer interfaces with a “PassThru”device (typically directly via USB or WiFi) that in turnis plugged into the car’s OBD-II port. Software on thelaptop computer can then interrogate or program the car’sECUs via this device (typically using the standard SAEJ2534 API). Examples of such tools include Toyota’sTIS, Ford’s VCM, Nissan’s Consult 3 and Honda’s HDSamong others.

In both situations Windows-based computers directlyor indirectly control the data to be sent to the automobile.Thus, if an adversary were able to compromise suchsystems at the dealership she could amplify this access toattack any cars under service. Such laptop computers aretypically Internet-connected (indeed, this is a requirementfor some manufacturers’ systems), so traditional meansof personal computer compromise could be employed.

Further afield, electric vehicles may also communicatewith external chargers via the charging cable. Anadversary able to compromise the external charginginfrastructure may thus be able to leverage that accessto subsequently attack any connected automobile.Entertainment: Disc, USB and iPod. The otherimportant class of physical interfaces are focused onentertainment systems. Virtually all automobiles shippedtoday provide a CD player able to interpret a widevariety of audio formats (raw “Red Book” audio, MP3,WMA, and so on). Similarly, vehicle manufacturers alsoprovide some kind of external digital multimedia port(typically either a USB port or an iPod/iPhone dockingport) for allowing users to control their car’s media

DÉTECTION D’INTRUSION SUR RÉSEAU CAN

LAAS-Renault

Approche orientée langage pour la génération des scénarios d’attaques vérifiés par  l’IDS

Trophée innovation 2015, brevet en cours

Specs Automate produit

Automate ECUSpecs Automate ECUSpecs Automate ECUECU

specs.Automate

ECU

Séquences d’attaque

Lsys Lsys

Lattacks = Suf(Lsys.Σsys∩Lsys )∩Fact(Lsys )

§Ivan Studnia (2015), Détection d’intrusions pour des réseaux embarqués automobiles : une approche orientée langage, CIFRE Renault, Dir Thèse: V. Nicomette, E. Alata

DÉFI 7 : LE VÉHICULE COMME CAPTEUR/ACTIONNEUR

VÉHICULE CONNECTÉ À UNE INFRASTRUCTURE

Véhicules deviennent des capteurs pour le système global

Cloud interprète les données remontées

Retour d’information aux véhicules (accident, trafic, météo,…)

Grande masse de données produites

Dimension géographique du calcul

Pertinence information diminue avec distance

VÉHICULE CONNECTÉ À UNE INFRASTRUCTURE

Adaptation à

Capacité du réseau,

Évènements (prévisibles ou non)

Niveau de criticité

Garanties temporelles nécessaires

Aspect légal/monétaire : qui est le maître des données ?

COMPLEXITÉ

Problème complexe par nature :

grand volume de données

système distribué, géolocalisé

sécurité/safety : garantir des données fiables

disponibilité, ordonnancement :

données utiles, dans les temps

VÉHICULE CONNECTÉ

Agenda possible :

Standardisation nécessaire (nombreux acteurs)

Données traitées par l’infrastructure

Information dispatchées sur les véhicules comme «aide» à la décision (pas safety critical)

Problème de transfert d’information sous contraintes de ressources (réseau)

cf. problématique ordonnancement

contraintes géo-localisation supplémentaires.

Collaboration LAAS-Continental

DÉFI 8 : INTERNET OF CARS

INTERNET OF CARS

Véhicule autonome en isolation ?

Futur probable : internet of cars

Chaque véhicule possède capacités décisionnelles

Connection à l’infrastructure et aux autres véhicules (V2V)

Nécessité d’un tiers de confiance ?

INTERNET OF CARS CHALLENGE

Analogie insectes sociaux, oiseaux, poissons :

structures efficaces, robustes

pas de tiers de confiance

Prises de décision réparties

optimisation globale du réseau routier

Approche pluri-disciplinaire ?

?

CONCLUSIONS

COMPLEXITÉ ET SYSTÈMES AUTOMOBILES

Moteurs de la complexité :

Standards : émissions, sûreté

Services ajoutés (avantage commercial)

Moyens de maîtriser cette complexité :

Systèmes résilients, adaptables.

DÉFIS POUR LA COMPLEXITÉ

Véhicules en isolation :

Différents niveaux de criticité dans le même véhicule

Évolution des architectures : utilisation de COTS complexes

Véhicules connectés

Évolution fiable du véhicule pendant vie opérationnelle

Big data : confidentialité, traitement efficace

Véhicules autonomes : vers un prise de décision collective/collaborative ?

Complexité au sens classique : comportements émergents