Ordonnancement temps réel multiprocesseur et conception de

&

www.cea.fr

[email protected]

Conception de systèmes cadencés par le temps

Cliquez pour modifier le style du titre

DACLE Division| Sept. 2015 © CEA. All rights reserved | 2 &

Aperçu du fonctionnement d’une approche cadencée par le temps

Illustration de la programmation & exemple applicatifs

Extension pour adresser d’autres domaines applicatifs (contrôle moteur)

Cadencé par des évènements extérieurs temporellement maîtrisés

Aperçu d’une extension au distribué (topologie bus)

Plan



Modèle de programmation : YC Expression du parallélisme (définition des agents)

Expression de contraintes temporelles

Expression des communications

Modèle d’exécution (multitâche communiquant) Cadencé par le temps réel, multi-échelle

Cadencements déduits d’après les contraintes de temps exprimées et les communications

Outils support permettant … … la génération de code et l’implantation sur cible

… l’aide à l’analyse et la validation (simulation POSIX)

Noyau orienté sûreté de fonctionnement et performance Simple cœur (e.g. 68K, IA32, ARM), multicoeur hétérogène (e.g. S12XE), multicoeur SMP (e.g. IA32), architecture distribuée

Méthode de conception



Le système est cadencé par le temps réel (Time-Triggered) tous les traitements prennent place entre deux instants du système

les exécutions sont asynchrones mais sont synchronisées (synchronisme) au début et à la fin des traitements : isochronisme réel indépendant du matériel

Cela définit une action élémentaire (AE)

tous les transferts de données entre « tâches » ont lieu à la transition entre deux traitements

Multi-échelle de temps

AE

Td Tf

temps physique

Intervalle de temps spécifié

Durée d’exécution effective

… …

Date de début au plus tôt Date de fin au plus tard

Modèle d’exécution



H 1

H 2

p 2

t 0 X( t

0 )=X( déb )

déb fin

H 1

H 2

X p1

p 2

t X( t )=X( )

principe d’observabilité strict

mise à jour implicite et automatique aux rythmes définis

dimensionnement automatique et protection des tampons, optimaux et sûrs

Modèle d’exécution

Cohérence temporelle des échanges encapsulation des données et des traitements (donnée protégée et un seul producteur)

les valeurs des données sur lesquelles travaille une AE sont figées à un instant temporel donné (date de début de l’AE)

Consommation et production de nouvelles données uniquement aux TSPs


DACLE Division| Sept. 2015 © CEA. All rights reserved | 6 & 6

Determinism property

Data values are independent From the effective execution duration From the scheduling policies (including job preemptions)

Determinism property Dynamic behavior of the system predictable and unvarying (reproducibility) Implementations have identical results (except for the sizing) Test scenarios are predictable and their results reproducible

Fetched

inputs

Tb Te

real time

Same observed

behaviour

outputs

availability

Tb Te

real time

For the same processing

- scheduled differently -Fetched

inputs

Tb Te

real time

Same observed

behaviour

outputs

availability

Tb Te

real time


- scheduled differently -Same observed

behavior

Fetched

inputs

Tb Te

real time

Same observed

behaviour

outputs

availability

Tb Te

real time


- scheduled differently -Fetched

inputs

Tb Te

real time

Same observed

behaviour

outputs

availability

Tb Te

real time


- scheduled differently -Same observed

behavior



Un agent avance dans le temps par sauts successifs le long d’une échelle de temps (horloge de base de la tâche) définie par le concepteur pour chaque agent

Les sauts peuvent être de longueurs différentes (comme ci-dessous 1-3-1-1-3-1-1-…)

Hw

…

clock HBASE= gtc1(0, 1); /* 1 ms */

application demo(inittime= 99) with

HBASE;

agent ag1tst(starttime= 1) with HBASE

{

body start

{

/* proc 1 */ advance(1);



}

}

temps

Initialisation TT :

– La valeur initiale du temps TT de

l’application est elle aussi prédéfinie

par le concepteur

– Chaque tâche démarre à partir d’un

instant spécifié de son horloge de

base après le démarrage TT de

l’application

Graphe de contrôle et d’exécution de

la tâche utilisé par le noyau Chaîne de compilation et de

génération de code

Exemple d’écriture d’un cadencement simple



Les horloges : bases de temps

Hbase (ms)

Hpair

Himpair

clock Hbase = gtc1 (0,1) ;

ou clock Hbase = gtc2 (0,1,0) ;

ou clock Hbase = gtc3 (0,1,0,0) ;

clock Hpair = 2*Hbase ;

clock Himpair = 2*Hbase + 1 ;

0 1 2 3 4 5 6 7 8 9 …

0 1 2 3 4 5 …

1 2 3 4 5 …



Les horloges : démarrage

Hbase (ms)

Hpair

Himpai

r

application monAppli ( inittime = 4 ) with Hbase ;

inittime starttime

(agC)

starttime (agB, agA)

agent agB ( starttime = 4 with Hpair ) with Hbase

{ ... }

agent agC ( starttime = 3 with Himpair ) with Hbase

{ ... }

agent agA ( starttime = 8 ) with Hbase

{ ... /* ensemble de blocs */ ... }

t=4 9 12

0 1 2 3 4



Fenêtres temporelles : advance

agC

starttime (agC)

(rmq : code de l’agent agC exécuté après son démarrage)

body start

{

/* traitement f_a */

advance (1) ;

/* traitement f_b */

advance (4) with Himpair ;

}

t=9

f_a f_b

Hbase (ms)

Himpair

17

…



Fenêtres temporelles : before

Hbase (ms)

agC

starttime (agC)

Code de l’agent agC exécuté après son démarrage : {

/* traitement f_a */

advance (1) ;

/* traitement f_b */

before (2) ;

/* traitement f_c */

advance (4) with Himpair ;

}

t=9

Himpair

f_a f_b f_a f_b

…

…

17



Variables temporelles : définition et droits

/* Blocs chez le propriétaire (agA) */

temporal

{

unsigned long 1$varT=0 ; }

display

{

varT : agB ; }

Hbase (ms)

varT (Hbase)

agA

t=12 15 18 22 23 27

/* Bloc chez un consultant (agB) */ consult

{

agA : 1$varT ; }



Variables temporelles : accès aux valeurs passées (1/2)

/* Code chez le propriétaire (agA) */

{ varT=1; affiche(`0$varT);

advance(3);

++varT; affiche(`0$varT);

advance(2) with Hpair;



++varT; affiche(`0$varT); advance(1);


advance(4); /* ... */ }

Q : dessinez chronogramme

avec ‘temporal with Hpair’ et

le même code YC

Hbase (ms)

agA t=12 15 18 22 23 27

0 0 1 0$varT 2 2 3 4 4 5

‘0’ ‘1’ ‘2’ ‘3’ ‘4’ ‘5’

0 1 1 2 2 4 4 5



Variables temporelles : accès aux valeurs passées (2/2)

/* Code chez le consultant (agB) */

{ affiche(agA`0$varT);

advance(1) with Hpair ;

}

Q : redessinez ce chronogramme

lorsque agB consulte les deux

dernières valeurs passées de

varT

agB t=12 14

‘0’ ‘0’ ‘1

’

‘2’ ‘2’ ‘3’ ‘4’ ‘4’

Hbase (ms)

0 0 1 0$varT 2 2 3 4 4 5 0 1 1 2 2 4 4 5



Variables temporelles : réponse

/* Code chez le propriétaire (agA) */

{ varT=1; affiche(`0$varT);

advance(3);





++varT; affiche(`0$varT); advance(1);


advance(4); /* ... */ }

Hbase (ms)

varT (Hpair)

agA t=12 15 18 22 23 27

0 0 1 0$varT 2 2 3 4 4 5

‘0’ ‘0’ ‘2’ ‘3’ ‘3’ ‘4’



Variables temporelles : réponse

/* Code chez le consultant (agB) */

{ affiche(agA`0$varT);

advance(1) with Hpair ;

}

Hbase (ms)

varT (Hpair)

agB t=12 14

0 0 1 agA`0$varT 2 2 3 4 4 5

‘0’ ‘0’ ‘1

’

‘2’ ‘2’ ‘3’ ‘4’ ‘4’



Construction simple d’une « synchronisation multi-échelle »

AgDemo

(MS)

Horloge HB=5*MS

Inittime

1000s Lecture des données d’un coupleur toutes les 5 ms

AgDemo

(MS)

Horloge HB=5*MS

Inittime

1000s Lecture des données d’un coupleur toutes les 5 ms

Déclaration de plusieurs

horloges (échelles de temps) :

1ms et 5 ms

Contrainte temporelle d’un tick

de l’horloge à 1ms Resynchronisation au prochain tick de l’horloge à

5ms quelque soit le nombre de tours de boucle



Affichage d’un tiret toute les secondes avec une maîtrise de la gigue Par construction le cadencement temporel implémenté garantit une gigue entre deux occurrences d’affichage de [750;1250ms] (si système ordonnançable)

HSEC

HJIT

Agent test

JIT_in_ms

#define SEC_in_ms 1000

#define JIT_in_ms 250

clock MS= gtc1(0,1); /* 1ms */

clock HSEC= SEC_in_ms*MS;

clock HJIT= SEC_in_ms*MS + JIT_in_ms;

application dash(inittime= 10) with HSEC;

agent test(starttime= 1) with HSEC {

body start {

edit("-"); advance(1) with HJIT;

advance(1);

}

}

Paramètre du

comportement temporel

Déclaration des horloges

Maîtrise de la gigue

Gigue min Gigue max

Exemple simple de gestion de la gigue



Un système contient toujours des défauts résiduels

Principe de déterminisme fort dans OASIS

Confiner les anomalies et maîtriser leurs conséquences pour conserver la propriété de déterminisme même en cas d’anomalies

il faut détecter à l’exécution toutes les tentatives de violation de la séparation des tâches

contrôler le dimensionnement des ressources d’exécution (tampons, quotas CPU, etc.)

contrôler l’enchaînement séquentiel des actions, etc.

Partitionnement spatial et temporel au sein d’OASIS

Unité d’exécution et de confinement d’anomalie : l’agent

Isolation spatiale (illustré sur le transparent suivant) entre les différents agents

entre les différentes parties du noyau

entre le noyau et les agents

Isolation temporelle Surveillance des budgets (WCET) associés aux actions élémentaires (AE) : ségrégation de la

défaillance au sein de la tâche et maintien de disponibilité du système Impact limité à l’agent, possibilité de définir une stratégie d’exécution en mode dégradé

Surveillance des échéances des AE : détection d’une erreur de dimensionnement

Anomalies, déterminisme et modularité



Pré-requis : disponibilité de timers Pour représenter l’évolution du temps, l’échéance de la tâche en cours et son budget temps

Plusieurs variantes d’implémentation possibles (2/3 timers, valeur de comparaison par rapport à la valeur du compteur, etc.)

Granularité d’un timer peut être abitraire et dépend du nombre de bits du compteur (16, 32 ou 64 bits)

Impact sur la précision

Implémentation du modèle TT

job Td

Tf

Temps

Budget de temps (WCET)

Préambule (système)

Consultation des données visibles

Production des données visibles

Postambule (système)

Interruption timer

Scheduler (micronoyau)

Uniquement si la tâche dépasse son WCET



Organisation défensive des programmes exécutables

trap

move sr

horloge

Mode d’exécution

utilisateur

Mode d’exécution

privilégié

Code et données

d’une tâche

Code et données

d’une tâche

Prolongement du

contexte d’une

tâche dans la

couche système

Prolongement du

contexte d’une

tâche dans la

couche système

Code de la couche système

Données et code du micro-noyau (gestion de l’allocation du processeur aux tâches et gestion du temps)

Code générique

(Noyau)

Codes et données

applicatifs

…

Données relatives

d’une application

(runtime)

contextes d’exécution distincts hors de CS et différents internes à CS, contexte mN indépendant segmentation particulière des exécutables et des données

conception orienté sûreté et exploitation spécifique des mécanismes de protection liés au H/W contrôle de conformité de l’exécution de chaque tâche contrôle toutes les hypothèses de dimensionnement (quotas, tampons, etc.) les préemptions de tâches sont toutes contrôlées par le mNoyau atomique CS 100% préemptible



Partitionnement spatial

MICRO-NOYAU

COUCHE SYSTEME

AGENT ACTIF AUTRES AGENTS

Droits d’accès mémoire RAM

Lecture/écriture

Lecture uniquement

Aucun droit

Contexte tâche

applicatif

MICRO-NOYAU

COUCHE SYSTEME

AGENT ACTIF

AUTRES AGENTS

Micro-noyau

Td

Interruption timer

MICRO-NOYAU

COUCHE SYSTEME

AGENT AUTRES AGENTS

Couche système

Tâche

Préambule

Job

Postambule

Contexte couche

système

Contexte

micro-noyau

…

Tf



Bénéfices

Portabilité Composabilité

Déterminisme Différence avec les pratiques

courantes



OASIS and the QDS plaform

Industrial success in the nuclear industry with AREVA NP (2003-2006)

The Qualified Display System platform (compliant to requirements of safety classified system of category A, IEC 61513 & 60880) Part of 1E safety-classified I&C system of the EPR (European pressurized reactor) Single processor IA32 architecture

QDS: display equipment with high dependability level for safety classified application

Based on the OASIS system software and off the shelf hardware components

Application: post-accident monitoring & control / supervision of the NPP starting phase and monitoring when operational

full control of a graphical HMI (10 images per second, 1024x768x16bpp)

data storage (24h) and calculations for 20 million measure points

network communication management (about 50000 data per second)

application downloading and monitoring

all hardware component configurations performed & checked

self-tests in regular time



netSUAg

updAg

appliNAg

selfTestAg

netAg

HMIdisAgHMImkAg

statMemAg

ALLDATA

DATAtoTXS

NET_SELFTEST

DATAfromTXS

ACTION

DISPLAYDATA COMMAND

MO_POSITION

ECHOES HMItouchAg

STRESULTS

MK_SELFTEST TS_SELFTEST

SM_SELFTEST

SU_REQ

SU_BUF

HC_BLOCK

static

memory

mouse

keyboard touchscreen

TXS

network

SU

network

graphic

card LFB

OASIS

Safety-oriented

Kernel

ST_STORAGE

MT_STORAGE

STATUS

TS_POSITION

ECHO



QDS: example of Real-Time behaviors

n e tS U A g

H M Ito u c h A g

s e lfT e s tA g

u p d A g

H M Id is A g

a p p li1 A g

1 0 m s

1 0 m s

1 s

2 0 m s

1 0 0 m s

2 0 m s

n e tA g

1 0 m s

H M Im k A g

5 m s

s ta tM e m A g

1 s

n e tS U A g

H M Ito u c h A g

s e lfT e s tA g

u p d A g

H M Id is A g

a p p li1 A g

1 0 m s

1 0 m s

1 s

2 0 m s

1 0 0 m s

2 0 m s

n e tA g

1 0 m s

H M Im k A g

5 m s

s ta tM e m A g

1 s



Medium voltage protection relays Safety-function of the software part of protection relays

Detects and isolates fault in the electrical network Sepam line of products within Schneider Electric

Requirements for SIL2 or higher certification (IEC 61508)

Demonstration of the fulfillment of the detection delay (tdetection) End-to-end temporal constraint between the detection of power

faults and asking the tripping of circuit breakers tdetection <= 26,640 ms

Current practice: costly phase of tests and high margins are taken on the temporal behaviour of the software part of protection relays

Circuit breaker closed

Default

Circuit breaker opened

Sensor

Sensor: transmits information

current/voltage

Relay: digitalizes the information and

takes decisions according to user

settings



Software architecture of OASISepam: a simplified Sepam 10 protection relay

AgMoy AgARGA

Simulated

electrical network

AgTRS

AgCrete

Ag50

Ag51

Activate

protections

1$

3$

1$

1$

1$

555usec

(1 samping)

3 samplings (1665µsec)

1 sampling

Acquisition Measurement Protections

12 samplings 12 samplings

12 samplings

12$

1$

Database of

tests

AgCumulRMS AgRMS

1800 samplings

1 sampling

1$



Mastered temporal behavior within OASISepam

Worst-case tdetection = 26,64 ms

Failure observed at AgMoy level (tAgMoy_taken): 3 * 0,555 ms

Failure observed at AgTRS level (tAgTRS_taken): + 6,66 * 3 ms

Failure observed at Protection level (tProtections_taken): + 6,66 - 3*0,555 ms

…

…

Ag_TRS

Protections

Cycle 1 Cycle 2

tdeb

tfailure = tdeb + ε

Power failure detection time: tdetect_failure

tAg_TRS_taken

tProtections_taken

… Ag_Moy

… Ag_ARGA

555µsec

3 * 555µsec tAg_ARGA_taken

tAg_Moy_taken

3 * 555µsec

6,66ms



Domain field: automotive powertrain

Move from single core to multi-core architectures in order to be compliant with next « euro » emission norms

Upcoming safety standard (ISO 26262) requires an increase in the confidence of the temporal behavior

Advanced features of PharOS: context



Powertrain Usecase

31

0

30

60

90

TDC

90°

45°

180°

135°

0°

Injection cycle

Pulses before optional

Pulses after optional

Pulses around mandatory

Injection pulse management

Pulse HW configuration

Execution window

Start of

physical injection

Static angle

Dynamic angle

SW processing



Classical Time-Triggered (TT) paradigm [Giotto, etc.]

Specify task activation and deadlines using physical time

Abstract the underlying architecture

BUT inappropriate for interacting with the external world

Inefficiency of the looping approach

Express timing constraints in another temporal reference than physical time

Advanced features of PharOS: problems



• Address sporadic interactions

– Specify job release/deadline independently of the exact timing occurrence of events

– Min. and max. inter-arrival time for: 1) system liveness and 2) schedulability demonstration

• Specificy timing constraints using an application specific temporal reference

– Given for a set of range of values of an application-level variable

– For example: [1000 – 3000 rpm] and [3000 – 5000 rpm]

Generalized TT paradigm: eXternal-Triggered (xT)

Job Temporal

reference

…

Tick #0 Tick #3

Expected inter-arrival interval



Executed at each occurrence of an xT tick

To implement a specific protocol (receive/send)

To give a semantic to xT ticks

What is the number of a tick ?

Should the tick be filtered?

Initialization sequence (identification of the tooth number)

Intermediate event for communicating through a peripheral

Application-level filtering function



Extension à des bus de communication

Continuité et intégration avec le modèle OASIS intègre déjà de manière réaliste les contraintes temporelles

délais de communication jamais estimés comme nuls

diffusion avant l’échéance, approvisionnement après l’échéance

couches systèmes et matérielles transparentes pour le développeur

application conçue indépendamment de l’architecture

Interface TDMA avec Ethernet standard (physical layer) aucune collision par construction (une collision devient une erreur)

garantir par construction la ponctualité des communications

dimensionnement et ordonnancement statique du réseau

pour vérifier et valider le réseau hors-ligne

pour détecter un comportement fautif

=> Cadencement global des communications connu de tous



Concept de l’extension du modèle d’exécution

Network window

Agent 1

Agent 2

Pilot

Network

r

Network deadline

s

Pilot

t

L'échéance réseau

Prise en compte des délais de transmission

Surcontraindre l’échéance d’un traitement

Libération d’une fenêtre de transmission des données



Exemple de conception d’un agent de contrôle-commande

Syntaxe YC

Annexe A



Agent communicant & avec plusieurs échelles de temps

MS …

MS … T1

T2

communications communications

Q : écrivez le code YC d’un agent qui

structurerait ce comportement temporel

Documents

Ordonnancement temps réel multiprocesseur et conception de