1 / 31

Utilisation des outils d ’analyse sémantique de code à EDF

Utilisation des outils d ’analyse sémantique de code à EDF. Sommaire. Contexte Les outils d ’analyse de code Analyse d ’un système classé de sûreté le système de protection RPN-CP0 Perspectives futures. Le contexte du nucléaire. En qualité de maître d ’ouvrage d ’installations nucléaires

xiu
Download Presentation

Utilisation des outils d ’analyse sémantique de code à EDF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Utilisation des outils d ’analyse sémantique de code à EDF

  2. Sommaire • Contexte • Les outils d ’analyse de code • Analyse d ’un système classé de sûreté • le système de protection RPN-CP0 • Perspectives futures

  3. Le contexte du nucléaire • En qualité de maître d ’ouvrage d ’installations nucléaires • EDF est responsable de la qualification des systèmes programmés importants pour la sûreté • Tendance à la généralisation des systèmes programmés • Salle de commande • Régulations et automatismes non importants pour la sûreté • Systèmes de protection et de sauvegarde • Coût de qualification des systèmes programmés non négligeable par rapport au coût total de qualification d’une installation

  4. Le cadre réglementaire • La Règle fondamentale de sûreté • relative aux logiciels • des systèmes électriques classés de sûreté • ici contrôle-commande associé au système • Elle fournit un ensemble d ’exigences • suivant le classement du système • Et donne des pratiques acceptables

  5. Champ d ’application de la RFS Système Électrique IPS (important pour la sûreté) Non-IPS Classé de sûreté IPS-NC (Non Classé de sûreté) Classé 1E Classé de sûreté et non 1E Parfois appelé 2E Système classé de sûreté et non-1E au titre des conditions de fonctionnement de dimensionnement Système classé de sûreté et non-1E au titre des conditions de fonctionnement complémentaires

  6. Les types de systèmes utilisés • Systèmes les plus critiques (classement RFS classé 1E) • Systèmes spécifiques • Systèmes à base de produits catalogue de fournisseurs spécialisés • Fonctionnalités « simples » : actions de protection • Maîtrise totale du code source des systèmes programmés • Objet des évaluations actuelles • Systèmes classé sûreté non 1E • Systèmes standard du marché • Non maîtrise totale du code (notamment système d’exploitation) • Fonctionnalités variées : régulations, conduite, ...

  7. Les pratiques actuelles de qualification • Relecture des documents produits • y compris les sources • Analyse des pratiques des fournisseurs • Suivi du développement des systèmes chez les fournisseurs • Mise en place de tests de recette en plateforme et sur site

  8. Les objectifs du projet « Alcasar » • Maîtriser le coût de qualification des systèmes programmés : • en proposant des méthodes et outils • capables de fournir des informations indiscutables • ou pour diriger l’analyse sur des points sensibles. • Par exemple en effectuant des tests complémentaires • Les outils d’analyse sémantique de code • Une des techniques retenues par le projet • Une des pratiques acceptables donnée par la RFS « logiciels »

  9. Les outils d ’analyse • Peu d’outils sur le marché • deux produits commerciaux • PolySpace Verifier (PolySpace Technologies) • MALPAS (Fluor Global Services) • un outil du domaine de la recherche • CAVEAT (partenariats CEA-EADS-EDF) • Deux technologies complémentaires • La logique de Hoare • CAVEAT, MALPAS • L ’interprétation abstraite • PolySpace Verifier

  10. PolySpace : objectifs de l ’outil • Détecter les erreurs d ’exécution et les menaces dans un logiciel. • Analyse statique : l ’outil exploite le code source du logiciel (C ou ADA), sans l ’exécuter. • Élabore et travaille sur 2 modèles : • Un modèle abstrait de l ’application (fonctions, arbre d’appels, dictionnaire des variables, …), • Un modèle de toutes les exécutions possibles (Modèle de l ’application + domaines dans l’espace des valeurs des variables).

  11. Erreurs et menaces détectées par l ’outil • Code mort & appel sans fin. • Erreurs certaines ou potentielles : • NIV / NIP (variable ou pointeur non initialisé) • U-OVFL (underflow, overflow) • ZDV (division par zéro) • COR (condition d’exécution incorrecte : index de tableau invalide, pointeur hors limite). • ASRT (assertion de l ’utilisateur)

  12. Interface utilisateur • PolySpace comporte 2 outils : • le « verifier », pour lancer l ’analyse. • Création d ’un projet • Déclaration des fichiers sources, des chemins d ’include • Paramètres (précision, profondeur, …) • le « viewer », pour exploiter les résultats de l ’analyse : • Graphe d ’appel • Listes de variables et de leurs accès • Liste des erreurs et menaces • Visualisation du code source • Classification des résultats selon un code de couleur : rouge, vert, orange, gris.

  13. Code des couleurs • Rouge : une erreur systématique a été détectée. • Exemple a = 0 suivi de c = b/a : ZDV • Gris : le code n ’est jamais exécuté. • Vert : l ’erreur ne peut pas se produire • Exemple : une variable est dans tous les cas affectée avant utilisation : NIV • Orange : incertitude ? Menace ? Fausse alerte ? • Il faut augmenter le niveau de précision.

  14. CAVEAT : Logique de Hoare (1/2) • Objectif : Preuve de propriétés • Par utilisation de règles de réécriture suivant le type d ’instruction • Types de propriétés sur une fonction • Précondition • Postcondition • Assertion (sur un label dans le code) • Invariant de boucle • Propagation des propriétés sur le graphe d ’appel

  15. CAVEAT : Logique de Hoare (2/2) • Mécanisme de synthèse de menaces int p,q,s; void fonction(int a,b) { int i; s=a+b; p=0; i=b; while (i>0) { p+=a; i--; } q=a/s; } synthèse menace « Pre : a+b0 » remontée menace : a+b0 remontée menace : s0 remontée menace : s0 menace division : s0

  16. CAVEAT : Fonctionnalités • Recherche exhaustive de menaces • Types de menaces recherchées • division par zéro • utilisation de pointeurs nuls • débordement de tableaux • utilisation de variables non initialisées (pas de menace générée) • Affichées sous forme de préconditions • La preuve de la précondition montre l’innocuité de la menace • Preuves de propriétés issues des spécifications • Étude des domaines de variation des variables de sorties • propriétés exprimées sous forme de postconditions • Calcul de menaces complémentaires par ajout de propriétés • racine carrée, logarithme négatifs …

  17. CAVEAT : Présentation des résultats • État des preuves des menaces du graphe d ’appel • fonction verte : Toutes les menaces sont prouvées localement. • fonction bleue : Toutes les menaces ont été prouvées par le contexte d ’appel de la fonction. • fonction rouge : Une menace n ’a pas pu être prouvée par l ’outil. • Le résidu de la preuve permet de connaître ce qui manque à la conclusion de la preuve • Preuve : activité itérative • fonction rose : Les menaces de la fonction n ’ont pas pu être générées.

  18. Utilisation dans le cadre d ’une qualification • Rénovation du système de protection • des premières tranches nucléaires de 900 MWe • Remplace à l ’identique un système électronique analogique • Système RPN de mesure de la puissance neutronique du cœur • Code C + assembleur de 50 000 lignes de code • Partie système générique • Parties applicatives générées automatiquement à partir de SCADE • Contribution à l ’argumentaire de sûreté en cours

  19. Méthode d ’analyse pour PolySpace

  20. Travail à effectuer • Le code source C doit respecter la norme ANSI. Il doit y avoir un « main ». • Toutes les fonctions doivent être définies : • Création de « bouchons » pour les fonctions en assembleur, ou celles des bibliothèques. • Exemple : log10(x) -> assert(x>0)

  21. Procédure d ’analyse : 3 phases • Vérification du code source (SCC) • CDFA : Control & Data Flow Analysis • Elabore le modèle de l ’application • SSA (Software Safety Analysis) • Elabore le modèle d ’exécution. • Décomposé en 4 sous-phases : • SSUA (vérifications locales à la fonction), • SSIA 1 (on propage les contraintes issues des fonctions appelantes) • SSIA 2 et SSIA 3 (on raffine la propagation des contraintes…)

  22. Procédure d ’analyse SCC CDFA SSUA Erreur rouge : correction du code SSIA 1 Augmentation de la précision SSIA 2

  23. Analyse du RPN dans son ensemble : résultats bruts • L ’augmentation de la sélectivité a été obtenue en travaillant sur les macro-commandes de la partie applicative. • Sur la partie système, il est beaucoup plus difficile de progresser.

  24. Méthode d ’analyse pour CAVEAT

  25. Phases d ’analyse de Caveat Ajout d ’hypothèses Conformité C Ansi Recherche var non initialisées Génération du projet Génération des menaces menaces non prouvées Analyse des résidus menaces prouvées Menaces potentielles : conditions d ’activation Pas de menaces

  26. Bilan sur le système RPN • Parties applicatives • Toutes les menaces ont été générées et prouvées par l ’outil • Partie système • Analyse encore impossible dans son ensemble • Analyse possible unitairement • Limitations actuelles • Non prise en compte des alias • Gênant pour des logiciels gérant du matériel

  27. Deux techniques complémentaires • L ’approche interprétation abstraite de PolySpace • Richesse des types de menaces détectées • Code mort • Arrondis dans l ’arithmétique entière et flottante • Mais pas d ’informations complémentaires en présence d ’orange • pour lever ou confirmer ce risque • La logique de Hoare de Caveat • Traite un sous ensemble des menaces • En cas d ’échec de preuve pour lever une menace • L ’outil exhibe une condition nécessaire pour lever la menace • Permet d ’orienter sur la cause et sa correction éventuelle

  28. Les limitations actuelles • PolySpace • ne gère pas des octets ni des adresses, mais uniquement des variables et des pointeurs ; • exemple : affectation de variables par memcpy() • ne modélise pas l ’organisation physique de la mémoire • exemple : utilisation d ’adresses absolues + offset • Caveat • ne gère pas les alias • le passage d ’adresse de pointeur comme type entier dégrade la précision des résultats • les conditions d ’arrêt de boucle par une égalité donnent des menaces trop complexes

  29. Perspectives • Étendre ces approches aux systèmes moins critiques • Code partiellement disponible • Problématique du multi-tâche • Volume et complexité du code • Promouvoir ces approches au niveau des fournisseurs • Adaptation des règles de codage pour en faciliter l ’analyse ? • Allègement de l ’effort de test unitaire

More Related