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 Mise en sécurité des Logiciels Boulanger Jean-Louis RATP ESE/ICH/AQL

2 18 Janvier 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 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 Hypothèses

5 18 Janvier 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 Processeur Sécuritaire Codé

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

8 18 Janvier 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 Matériel l Architecture mono-processeur, l Processeur standard, –Famille des l Matériel périphérique dédié.

10 18 Janvier 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 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 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 Ce quil provoque... l En cas de détection dun problème, le PSC garantit larrêt du train.

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

15 18 Janvier La méthode B

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

17 18 Janvier 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 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 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 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 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 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 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 Processus de développement

25 18 Janvier Séparation code/données

26 18 Janvier 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 Procesus de Validation

28 18 Janvier 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 Double Validation Cahier des charges Fonctionnel Spécification Fonctionnelle Equipement Spécification Logicielle EXECUTABLE Tests Fonctionnels Modélisation

30 18 Janvier Et pour demain...

31 18 Janvier 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 Dautres architectures.. l Les industriels commencent à proposer lutilisation dune architecture matérielle 2 parmi 3 avec voteur logiciel ou matériel.

33 18 Janvier 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 Dautres techniques.. l Loutil PolySpace Verifier –Recherche des erreurs dexécution, –Identification des opérations à risque, –Indépendant de larchitecture.

35 18 Janvier 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 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