La conception des systèmes complexes fait intervenir des concepteurs provenant d’horizons techniques très variés. Les systèmes de contrôle-commande, en particulier, parce qu’ils nécessitent des connaissances avancées concernant le système piloté, le système pilotant et l’utilisateur, illustrent cet état de fait. La communication entre les concepteurs associés demeure souvent très compliquée notamment du fait de la variété des langages techniques utilisés. Ces problèmes de communication et d’interprétation de spécifications peuvent conduire à des erreurs de conception et au non respect du cahier des charges. Une étude a montré que 70% des erreurs des produits logiciels trouvent leur origine dans les phases de spécification et de conception [Selby et Selby 2007], et que 72% de ces erreurs sont détectées dans les phases de test ou en opération [Pham 2007]. La détection tardive des erreurs entraine une explosion des délais ainsi que les coûts de re-conception.

Dans le but de maîtriser la conception des systèmes de contrôle-commande, des démarches de conception plus rigoureuses et de plus en plus automatisées sont adoptées. La démarche de conception ascendante, par exemple, se focalise plus sur la réutilisation du code en adoptant une forte standardisation des composants constitutifs du système. La conception consiste ainsi en l’agrégation de plusieurs composants réutilisables. Bien qu’elle offre une forte réutilisation, cette démarche manque souvent de cohérence entre les composants utilisés et de vision globale du système à concevoir. Á contrario, la démarche, dite descendante, se focalise sur une vision plus générale en se basant sur des modèles de haut niveau. L’idée derrière cette démarche consiste à spécifier le système par un modèle abstrait décrivant un point de vue de conception, qui sera raffiné ou transformé en modèles décrivant d’autres points de vue, garantissant ainsi une certaine cohérence entre les modèles de départ et les modèles générés. Cependant, le raffinage et la transformation peuvent engendrer la propagation d’erreurs vers les modèles raffinés ou transformés. De plus, ces modèles manquent de modularité et sont donc difficilement réutilisables. Á l’issue de ces deux démarches, la démarche mixte a émergé.

Elle combine les deux premières démarches pour garantir, d’une part, la modularité et la réutilisation du code par l’utilisation d’un ensemble de composants prédéfinis « sur étagère » et, d’autre part, l’intégration d’une cohérence et d’une vision globale offertes par les modèles. En pratique, elle consiste donc en la construction d’un modèle structurel en s’appuyant sur des composants standards du domaine. Ensuite les modèles de contrôle-commande sont générés par intégration des modèles de contrôle-commande de chaque composant apparaissant dans le modèle structurel du système.

Cependant, la démarche mixte hérite des deux démarches, ascendante et descendante, de leurs avantages et aussi de leurs inconvénients. Les composants prédéfinis doivent être libres de tout défaut afin de garantir la qualité des systèmes conçus à partir de ces composants. Les modèles quant à eux, doivent intégrer les différentes exigences et recommandations du cahier des charges. Ils doivent être complets, cohérents et corrects afin de garantir la qualité des systèmes obtenus après raffinage de ces modèles.

Des études menées précédemment par SEGULA Technologies en collaboration avec le Lab-STICC ont abouti à la définition d’une démarche de conception conjointe de programme de commande et d’interface de supervision [Bignon et al. 2010, Bignon 2012, Bignon et al. 2013, Goubali et al. 2014]. Cette démarche (mixte) s’appuie sur deux piliers fondamentaux, le premier est la standardisation des composants de conception et le deuxième l’utilisation de modèles métier maîtrisés par les experts pour la spécification de leur système. Les modèles métier sont obtenus par une approche ascendante d’agrégation des éléments de conception. Les programmes de commande et les interfaces de supervision sont obtenus par une approche descendante de raffinages successifs des modèles métiers mettant en œuvre les concepts de l’ingénierie dirigée par les modèles. Bien qu’assurant déjà une bonne cohérence, la démarche proposée ne permet pas la vérification au plus tôt des programmes générés. Nos travaux, s’inscrivant dans la continuité de ces résultats, étudient les apports de différentes techniques de vérification formelle au sein de la démarche précédemment développée.

Le besoin d’amélioration imposé aux industriels, ainsi que le besoin de rendre les systèmes plus performants, plus sûrs, plus ergonomiques, offrant toujours plus de fonctionnalités aux utilisateurs, ne font qu’augmenter la complexité des systèmes. Cette complexité se traduit par l’augmentation importante de la taille des composants et des fonctionnalités. Elle a pour conséquences de nécessiter des équipes de développement de taille importante et souvent composées d’intervenants appartenant à divers domaines de l’ingénierie.

Une étude menée dans le domaine du génie logiciel, impliquant 14 systèmes complexes et comportant 3418 erreurs, montre que 70% des erreurs sont introduites lors des phases d’analyse (spécification et conception) [Selby et Selby 2007]. Ces résultats sont similaires à ceux de Sourisse et Boudillon [1997], qui trouvent que le pourcentage des erreurs introduites dans les phases d’analyse approche les 79%. dans le cycle de vie d’un système et leurs corrections font exploser les coûts. D’autres études montrent que 72% des erreurs sont détectées à la livraison [Pham 2007] et que le coût relatif aux corrections augmente considérablement au fil du temps [Boehm et al. 1981]. En effet, plus l’erreur est détectée tard dans le cycle de vie, plus le coût relatif à sa correction est élevé. Les investigations montrent aussi que 95% des erreurs pourraient être détectées et éliminées dans la phase où elles sont introduites, contre 47% dans les phases ultérieures [Selby et Selby 2007]. L’adoption de méthodes qui offrent des outils et techniques pour gérer la complexité d’un système et contrôler sa conception et sa réalisation permettent de diminuer considérablement l’introduction des erreurs dans chaque phase du cycle de développement.

Les grands concepteurs de système complexes, comme la NASA, se sont rendus compte, dès les années 60, de la nécessité de définir des démarches rigoureuses et outillées afin d’assister la conception des systèmes complexes. Ces démarches sont connues sous le nom de l’Ingénierie système (IS).

L’ingénierie système est une démarche dédiée à la réalisation des systèmes complexes. Son but est de cadrer le processus du développement d’un système. Elle propose des méthodes et outils pour maitriser le développement des systèmes durant toutes les phases du cycle de vie, à savoir : la définition des besoins des clients, la conception, la réalisation, l’intégration et la vérification. Elle permet, ainsi, de gérer la complexité des systèmes, en diminuant le risque d’introduction des erreurs. Plusieurs normes, telles-que ANSI/EIA-632 [EIA/ANSI-632 1999], IEEE1220 [IEEE-1220 1999], ISO 15288 [ISO-15288 2002] visent à encadrer la conception des systèmes complexes en adoptant l’IS. Nous retenons la définition suivante pour la notion d’IS :

Définition 1.1 [Fiorèse et Meinadier 2012] L’IS est une démarche méthodologique coopérative et interdisciplinaire, fondée sur la science et l’expérience, qui englobe l’ensemble des activités adéquates pour concevoir, développer, faire évoluer et vérifier un ensemble de produits, processus et compétences humaines apportant une solution économique et performante aux besoins des parties prenantes et acceptable par tous. Cet ensemble est intégré en un système, dans un contexte de recherche d’équilibre et d’optimisation sur tout son cycle de vie.

L’IS propose un processus de développement fondé sur plusieurs étapes. Une des étapes les plus importantes dans le cycle de développement d’un système, selon l’IS, est l’ingénierie des exigences. Une exigence est définie par :

Définition 1.2 [Fiorèse et Meinadier 2012] Une exigence prescrit une propriété dont l’obtention est jugée nécessaire. Son énoncé peut être une fonction, une aptitude, une caractéristique ou une limitation à laquelle doit satisfaire un système, un produit ou un processus.

Le processus de l’ingénierie des exigences permet d’extraire les besoins des parties prenantes, de les analyser, de les spécifier et enfin, de les vérifier [Fiorèse et Meinadier 2012]. Nous nous intéressons, dans cette thèse, aux deux dernières étapes, à savoir : la spécification des exigences et la vérification.