Contribution lobtention dune haute disponibilit pour des architectures

Contribution à l’obtention d’une haute disponibilité pour des architectures de contrôle commande sur Ethernet Doctorant: Steve Limal (contrat CIFRE + Monitorat IUT Cachan) Directeur de recherche: Jean Jacques Lesage Encadrement scientifique: Bruno Denis Encadrement industriel: Ludovic Guillemaud, Stéphane Potier

But de la thèse § Accompagner la stratégie de développement d’un système de contrôle-commande • Abandon d’un bus de terrain éprouvé mais plus assez performant, • Saut technologique vers une solution réseau « Ethernet Industriel » , support performant mais n’ayant pas fait ses preuves, • Prise en compte des contraintes particulières de l’activité Energie. § Justifier des propositions de développement grâce à la modélisation • Modélisation par automates à états finis, • Vérification formelle des propriétés recherchées. 2

Plan de la présentation § Contexte Industriel § Modélisation de la disponibilité d’une architecture § Participation à l’activité industrielle § Poursuite des travaux 3

Contexte Industriel : Présentation du produit ALSPA P 320 § ALSPA P 320 est un système de contrôle-commande utilisé pour • L’automatisation des centrales d’énergie, - Thermique - Hydraulique • Le contrôle de machine. - contrôle de turbine § Les architectures • Doivent répondre à des contraintes temporelles de différents niveaux, • Doivent répondre à des contraintes de disponibilité, • Doivent répondre à des contraintes de sûreté, • peuvent être grandes, • peuvent être compliquées. 4

Contexte Industriel : HO-PING Power plant 2 x 660 MW 5

Contexte Industriel : Caractéristiques du réseau actuel F 8000 § Caractéristiques importantes: • Déterministe • Temps réel - Cycles de rafraîchissement de 20 ms garantis par l’arbitre de bus • Supporte un trafic apériodique • Fourni un haut niveau de disponibilité - Redondance d’arbitre - Redondance de médium • Datation des évènements à la milliseconde • Synchronisation à 5 ms 1 s Cell Controller § Caractéristiques justifiant un saut technologique: 100 ms • Débit limité à 2, 5 Mbits/s • Condamné à l’obsolescence • Câblage additionnel utilisé pour la synchronisation Field Controller I/O Le marché pousse à l’utilisation d’Ethernet en tant que réseau de terrain. 5 ms F 8000 6

Contexte Industriel : Ethernet Industriel / Ethernet Bureautique § Critères de choix d’un Ethernet industriel ALSTOM • • • Déterministe Temps réel dur (5 ms à 1 ms) Débit suffisant Mécanismes de disponibilité Mécanismes de synchronisation § Caractéristiques de l’Ethernet bureautique/classique: • Non déterministe • Temps réel mou (100 ms) - Commutateurs (latence importante) - Full-Duplex • Performant ~ augmentation des débits • Mécanismes de disponibilité (adaptés à la bureautique) - Reconfiguration en 20 ms sur les systèmes les plus performants • Mécanismes de synchronisation - Network Time Protocol - IEEE 1588 • Synchronisation à la µs • Nécessite du matériel spécifique 7

Contexte Industriel : Solutions Commerciales utilisant Ethernet § Sercos III • FPGA available (only prototype in Q 4/2004) § Ethercat Estimated Market Shares in 2010 (Source Smart Network Devices 16/11/2005) 2% • Patented, proprietary ASIC from Beckhoff 10% 8% 40% § Profinet IRT • Patented, proprietary ASIC from Siemens § Ether. Net Industrial Protocol 15% 25% PROFInet Ether. Net/IP EPL Ether. CAT SERCOS III Others • Rockwell • Real Time with CIPsync (IEEE 1588) + Ethernet Frame Priority. (CIPsync available in 2006) § Ethernet Power. Link (EPL) 8

Contexte Industriel : Cycle déterministe Ethernet Power. Link § Le cycle EPL est orchestré par un arbitre (Managing Node). Les esclaves (Controlled Nodes) n’émettent que sur demande du MN § Le cycle élémentaire se déroule en 4 étapes: • • Etape de démarrage, message “Start of Cycle” (So. C), synchronisation des CN avec le MN, Etape isochrone, interrogation de chaque CN, Etape asynchrone, autorisation d’envoi d’un message asynchrone, Etape idle, pour garantir la régularité du So. C. T 9

Contexte Industriel : Caractéristiques du réseau utilisant EPL § Caractéristiques importantes: • Déterministe - Communications régies par un arbitre • Temps réel - Cycles de rafraîchissement inférieurs à 5 ms (200µs possibles) • Support de trafic périodique et apériodique • Faible niveau de disponibilité - Médium potentiellement plus défaillant - Pas de redondance médium spécifiée - Pas de redondance d’arbitre spécifiée • Synchronisation des équipements jusque 1µs - N’utilise pas la synchronisation IEEE 1588 • Repose sur IEEE 802. 3 Fast-Ethernet (100 Mbits/s) • En cours(fin) de développement § Il reste à spécifier et développer la disponibilité et sa gestion 1 s Cell Controller Hub 5 ms Remote I/O E 8000 EPL 10

Modélisation de la disponibilité d’une architecture § Quoi? • La disponibilité physique (Redondance médium), • La disponibilité logique gérée par le protocole (Redondance d’arbitre). § Dans quel objectif? ? • Justification des propositions de modifications du protocole, - Pour l’ajout des fonctions de disponibilité - De la conservation des propriétés du protocole • Justification en interne, • Justification auprès des organismes de certification du niveau de sûreté de la solution. § Sous quel formalisme? • Automates à états pour la vérification formelle. 11

Modélisation de la disponibilité d’une architecture: Vérification Formelle § Quelques exemples de vérification par méthode formelle: • Protocole du bus CAN (M. Van Osch et S. A. Smolka, 2001), • Protocole PROFIsafe (R. Malik et R. Muhlfeld, 2002). § Son utilisation est recommandée dans l’IEC 61508 (SIL 3) pour la vérification de logiciels. • Il n’y a pas de recommandation en ce qui concerne les protocoles de communication, • Néanmoins la vérification du protocole pourrait s’inscrire dans une démarche globale de conception d’un système de contrôle commande sûr. § Il faudrait pouvoir prendre en compte • L’aspect temporel qui accompagne la fonction de redondance d’arbitre, • L’aspect probabiliste qui accompagne la fonction de redondance de médium. 12

Modélisation de la disponibilité d’une architecture: Utilisation du logiciel de Model Checking Probabiliste PRISM module Hub 1 module Cable 1 module Node 1 § Idée: obtenir la probabilité de défaillance d’une architecture modélisée … End module Noeud § Le modèle d’architecture vérifié comprend • Des instanciations de modèles d’éléments physique (Câble, concentrateur. . ), • Des instanciations d’un modèle d’émetteur/ récepteur de message. § Particularités du modèle: • Le modèle ne prend pas en compte le temps, • Le modèle n’est pas spécifique au protocole, • mono ou bi-médium. § Modèle 6 nœuds/ 1 x(17 éléments physiques) • Calcul de 30 s sur PIII 933 MHz– 256 Mo RAM Noeud § Modèle 6 nœuds/ 2 x(17 éléments physiques) • Le logiciel PRISM « quitte inopinément » sur un PIV 2, 8 GHz- 1 Go RAM § Hors il est prévu des architectures comprenant jusque 30 nœuds… Hub externe ou interne 13

Modélisation de la disponibilité d’une architecture: Utilisation du logiciel de Model Checking temporel UPPAAL 1/2 § Idée: Vérification d’un principe de redondance d’arbitre Modèles UML Modèle UPPAAL 14

Modélisation de la disponibilité d’une architecture: Utilisation du logiciel de Model Checking temporel UPPAAL 2/2 § Le modèle d’architecture vérifié comprend • 2 MN redondants • De 2 à 5 CN § Particularités du modèle: • La phase de démarrage du réseau et des nœud n’es pas simulée, • Le réseau est modélisé par l’introduction de délais de transmission, • Les seules erreurs détectées par les modèles sont: - La perte d’un message par un CN, - Le dépassement du temps de cycle par un nœud. § Propriétés vérifiées (moins de 5 s/PIII 933 MHz/256 Mo RAM) • Le modèle n’atteint pas d’état bloquant, • Un seul MN est actif à la fois, • Le basculement sur le MN veille est réalisé en moins de 3 Tcyc du point de vue de chaque CN. § On constate un problème d’explosion combinatoire sur ces modèles (non optimisés) • t>10 min de vérification pour 2 MN et 4 CN (PIV 2, 8 GHz/1 Go RAM) • Mémoire insuffisante pour 2 MN et 5 CN (PIV 2, 8 GHz/1 Go RAM) § Hors il est prévu des architectures comprenant jusque 30 nœuds… 15

Participation à l’activité industrielle § Participation au choix d’une solution du marché (EPL) § Définition d’un algorithme de calcul du temps de cycle d’une architecture • Evaluation des performances atteignables • Paramétrage des modèles § Spécification d’un outil de description d’architecture • Développement en cours • Intégration du calcul du temps de cycle • Possibilité d’intégrer d’autre calculs (ex: disponibilité) § Participation au groupe de travail « Haute Disponibilité sur EPL » • Validation des idées issues du groupe 16

Poursuite des travaux § Disponibilité physique du réseau • Abandon du model checking • Définition d’un modèle analytique (algorithme d’obtention) de la disponibilité d’une architecture - Ex: Diagramme de fiabilité § Disponibilité gérée par le protocole • Conservation nécessaire du model checking • Conservation nécessaire de l’aspect temporel Simplification des modèles § Entre temps… • Les équipements EPL seront disponibles pour test • Le groupe de travail « Haute Disponibilité sur EPL » aura retenu/éliminé d’office certaines possibilités 17

Merci de votre attention Muchas gracias por su atención ﺷﻜﺮﺍ ﻋﻠﻰ ﺍﻫﺘﻤﺎﻣﻚ obrigado pela sua atenção Grazie per la vostra attenzione 18