La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL.

Présentations similaires


Présentation au sujet: "18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL."— Transcription de la présentation:

1 18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL

2 18 Janvier 20012 Le Laboratoire ICH/AQL l Atelier de Qualification des Logiciels, l Premier Laboratoire français à être accrédité par le COFRAC dans le cadre du programme 152 pour les essais: SUR1, SUR2, (vérification de spécification) SUR 6, (traçabilité) SUR11, SUR 13(vérification fonctionnelle) SUR14(analyse dimpact)

3 18 Janvier 20013 Sommaire Hypothèses –Processeur Sécuritaire Codé –La méthode B Processus de développement et de validation Et pour demain... Conclusions - Questions

4 18 Janvier 20014 Hypothèses

5 18 Janvier 20015 Hypothèses l Pour le métro, il existe un état de sécurité: larrêt. l La RATP fixe actuellement deux contraintes pour le développement des logiciels critiques (SSIL>2): –Utiliser la méthode formelle B, –Utiliser le processeur sécuritaire codé (PSC).

6 18 Janvier 20016 Processeur Sécuritaire Codé

7 18 Janvier 20017 PSC l Problèmes matériels dûs à lenvironnement: –Perturbations électromagnétiques –Vibrations. l Solutions: –Transmissions numériques, –Processeurs codés.

8 18 Janvier 20018 Principes l La sécurité repose sur le codage des informations et des traitements, l Codage arithmétique séparable, l Contrôle de signatures.

9 18 Janvier 20019 Matériel l Architecture mono-processeur, l Processeur standard, –Famille des 68000 l Matériel périphérique dédié.

10 18 Janvier 200110 Codage l Chaque donnée est constituée de deux champs: –Le champ «information», –Le champ «contrôle de longueur fixe» : Reste de la div entière de linfo par la clé du code, Signature statique Bx(trace des antécédents) Signature dynamique D (validité temporelle) (2 k x, -r kx +B x +D)avec 2 k >A

11 18 Janvier 200111 Contrôle des signatures l Vérifier que les signatures statiques sont égales aux valeurs prédéterminées, l Vérifier que la signature dynamique évolue correctement à chaque itération.

12 18 Janvier 200112 Ce quil prend en charge.. l Le PSC peut détecter –les erreurs dopération, bonne opérande et bon opérateur mais mauvais calcul –les erreurs dopérandes ou dopérateur, la présence dune donnée erronnée, la tentative dexécution dune instruction non prévue, –les erreurs de rafraichissement, –les débordements de pile, –les mauvais accès de tableau, –....

13 18 Janvier 200113 Ce quil provoque... l En cas de détection dun problème, le PSC garantit larrêt du train.

14 18 Janvier 200114 Utilisation l SACEM l VAL de Chicago l MAGGALY l... l METEOR l ASTREE

15 18 Janvier 200115 La méthode B

16 18 Janvier 200116 Historique 1979-1981 –Z est développé lors du séjour de JR Abrial au sein du Programming Research Group 1985 –C. Morgan introduit le raffinement 1988-1991 –JR Abrial développe la méthode B pour British Petroleum 1994-1995 –industrialisation de la méthode B et application METEOR

17 18 Janvier 200117 Caractéristiques (1) Orientée Modèle: –comme Z et VDM Séquentielle et ininterruptible Orientée Objet: –lien de structuration et module.

18 18 Janvier 200118 Caractéristiques (2) La méthode B permet le développement incrémental de spécifications jusquà leurs implémentations. Une seule notation pour les trois niveaux La méthode est basée sur la PREUVE

19 18 Janvier 200119 Concept (1) Les machines abstraites sont composées de trois parties: –la partie déclarative (description de létat+propriétés): Théorie des ensembles Logique du premier ordre –la partie de composition –la partie exécutive (opération faisant évoluer létat) Substitution Généralisée

20 18 Janvier 200120 Exemple: une pile MACHINESTACK ( max) CONSTRAINTSmax NAT1 SEES OBJECT VARIABLESstack INVARIANTstack seq(Object) size(stack) <= max INITIALISATIONstack := <> OPERATIONS PUSH (XX) =PRE XX Object size(stack) < max THEN stack := stack XX END; XX POP =PRE size(stack) > 0 THEN XX,stack := last(stack),front(stack) END END

21 18 Janvier 200121 De la spécification à limplantation 3 niveaux de détail: –la MACHINE «non séquentielle, non déterministe» –le(s) REFINEMENT introduit plus de détail mais doit préserver les caractéristiques «non séquentielles, non déterministes» –lIMPLEMENTATION séquentielle et déterministe

22 18 Janvier 200122 Validation du Modèle Machine Raffinement Implementation PO : Le modèle est consistant 1. Modèle non vide 2. Les Opérations préservent linvariant PO : cohérence du raffinement Linitialisation et les opérations préservent la sémantique du niveau supérieur

23 18 Janvier 200123 Ce quelle prend en compte l Correction statique du typage, au travers des PO. –débordement, –accès hors borne, –mauvaise utilisation (division par 0,...) l Correction de lutilisation des opérations au travers de la vérification du respect des pré- conditions.

24 18 Janvier 200124 Processus de développement

25 18 Janvier 200125 Séparation code/données

26 18 Janvier 200126 Cycle de développement spécification littérale du logiciel tests fonctionnels ré-expression formelle en B conception formelle génération de programme (automatique) intégration logicielle preuve

27 18 Janvier 200127 Procesus de Validation

28 18 Janvier 200128 Processus RATP Le processus de validation des logiciels critiques de la RATP sappuie sur deux activités: –Un contrôle de lindustriel sur lensemble du processus. –Une double validation des logiciels critiques, des données manipulées par les logiciels critiques.

29 18 Janvier 200129 Double Validation Cahier des charges Fonctionnel Spécification Fonctionnelle Equipement Spécification Logicielle EXECUTABLE Tests Fonctionnels Modélisation

30 18 Janvier 200130 Et pour demain...

31 18 Janvier 200131 Europe l Suite à louverture des marchés dans le cadre de lEUROPE, la RATP se doit de respecter la réglementation européenne pour les appels doffre, la RATP ne peut donc plus avoir les mêmes exigences.

32 18 Janvier 200132 Dautres architectures.. l Les industriels commencent à proposer lutilisation dune architecture matérielle 2 parmi 3 avec voteur logiciel ou matériel.

33 18 Janvier 200133 Dautres langages... l Dans le cadre des marchés européens, la RATP peut recommander lutilisation dune méthode formelle, mais pas lexiger.

34 18 Janvier 200134 Dautres techniques.. l Loutil PolySpace Verifier –Recherche des erreurs dexécution, –Identification des opérations à risque, –Indépendant de larchitecture.

35 18 Janvier 200135 PolySpace l La RATP a mené une étude sur un équipement en cours dutilisation qui a déjà fait lobjet dune validation. l Bilan: –Non respect de la norme ADA83 (non initialisation de paramètres «in out»), –Une boucle infinie, –Du code mort.

36 18 Janvier 200136 Conclusions - Questions


Télécharger ppt "18 Janvier 20011 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL."

Présentations similaires


Annonces Google