Fondements d'un processus d'ISSdF

Le processus décrit l'ensemble des activités, des tâches − avec des ressources dédiées, des flux de données entrant et sortant − qui doivent être enchaînées pour obtenir un résultat jugé performant d'un point de vue opérationnel (conformité, efficacité, délai, coût, etc.). Un processus peut être générique, opérationnel ou instancié. Les processus listés dans l'ISO 15288:2008 sont génériques : tout responsable d'un bureau d'étude souhaitant aligner sa pratique sur les principes de l'IS doit se mettre en cohérence avec leur contenu. Un processus opérationnel est spécifique : il concerne par exemple un bureau d'études, un secteur, etc., donnés. Ainsi, dans cette thèse, le processus d'ISSdF présenté est spécifique mais généralisable à d’autres secteurs. Enfin, un processus instancié est un processus mis en œuvre dans un projet de conception donné. S'ajoute à cette typologie des processus (générique, opérationnel, instancié), une typologie reposant sur leur périmètre. Il est ainsi possible de distinguer un macroprocessus, qui présente de façon panoramique ce qui doit être fait, des processus opérationnels, qui sont plus détaillés.

Plusieurs sources peuvent alimenter la modélisation d'un processus. Il peut s'agir d'un travail académique, d'une norme comme l'ISO 15288:2008, d'un recueil de connaissances comme le

SEBoK (Pyster & Olwell, 2013), d'un mode d'emploi d'une suite logicielle dédiée au MBSE, etc. Certaines sources ont une vocation ontologique, comme les travaux académiques ou l'ISO 15288:2008 ; d'autres, comme le mode d'emploi, ont une vocation pratique : son objectif est de bien utiliser un logiciel. Pour ce qui concerne cette dernière source, de plus en plus importante à mesure que l'IS est instrumentée par du logiciel, on peut par exemple mentionner, et comme expliqué dans (INCOSE, 2008), la méthodologie Harmony SE. Cette méthodologie, rédigée par Hans-Peter Hoffmann, est associée au logiciel Rhapsody, outil proposé par IBM. La part consacrée à la SdF est très faible dans cette suite logicielle. À suivre le Deskbook d’IBM (IBM, 2011), un modèle exécutable ne s'appuie que sur des AMDEC, ce qui est insuffisant pour développer des architectures sûres. Un tel manque se constate aussi dans les produits concurrents, que ce soit la méthodologie associée à Object-Oriented Systems Engineering

Method (OOSEM) de (Lykins, Friedenthal, & Meilich, 2000) ou au Rational Unified Process

for SE de (Kruchten, 2004). Si les modes d'emploi des logiciels dédiés au MBSE n'intègrent

pas la problématique de la SdF, qu’en est-il des processus proposés par le monde académique ?

3.3.2 Les processus de conception prenant en compte la SDF

Dans (Cressent, David, Idasiak, & Kratz, 2012), Robin Cressent présente un processus d'IS prenant en compte la SdF sous la forme d’un diagramme d’activités avec deux travées (swimlanes) ; l'une pour l'IS et l'autre pour la sûreté. Il détaille chacun de ces types de processus en précisant les activités à réaliser et les livrables attendus. Si cette approche est un premier pas vers l'ISSdF, elle présente toutefois des inconvénients. Elle ne repose sur aucune norme établie en IS ou en SdF. Les activités sont séquentielles et non interactives, si bien qu'il est impossible d'apprécier les tâches, les modèles, les livrables, etc., qui peuvent être partagés entre l'architecte système et l'ingénieur spécialiste en SdF. Une telle problématique se rencontre heureusement dans le travail de Faida Mhenni (Mhenni, 2014) intitulé SafeSysE, pour Safety Analysis

Integration In Systems Engineering. La sûreté est mieux traitée que dans le modèle de Crescent,

mais elle ne se limite qu'aux activités d'analyse. De plus, s'il est possible de lire et de bien comprendre les liens de l’IS vers la SdF, la réciproque n'est pas vraie.

La méthode STAMP de Nancy Leveson définie dans (Leveson, 1995), puis développée dans (Leveson, 2011), satisfait mieux les exigences énoncées précédemment. Dans (Weiss, 2006), Kathrin Anne Weiss utilise STAMP pour proposer un processus à vocation intégrative. Celle-ci détaille uniquement les étapes du processus de sûreté système, comme le montre le tableau suivant. De plus, la SdF est vue comme faisant l'objet d'activités réalisées ex post, c'est-à-dire après la conception. Le concepteur développe ainsi une solution, puis applique des critères issus de la SdF pour apprécier si elle est sûre. L'auteure ne traite donc pas des questions relatives aux exigences de SdF, à la proposition d'un concept de SdF, etc. Enfin, elle suppose que la seule

P.Mauborgne : Vers une ISSdF basée sur les modèles en conception innovante – p. 71

solution organique possible pour garantir la sûreté est le contrôle / commande du système réside dans l'électronique embarquée.

Tableau 11 : Étapes du System Safety Process basé sur STAMP (Weiss, 2006)

Étape System Safety Process

1 Identify System Hazards

2 Identify System-Level Safety-related Requirements and Constraints

3 Define the System Safety Control Structure

4 Identify Inadequate Control Actions leading to a Hazardous State

5 Determine how the Constraint could be Violated and Implement Mitigation

Si nous reprenons les exigences énoncées ci-dessus, nous constatons que les processus à vocation intégrative proposés présentent des limites. Aucun ne se réfère explicitement à l'ISO 15288:2008 et à l'ISO 26262:2011 (Exi. 1, Exi. 2). La prise en compte de la SdF est faite

ex post, une fois la conception réalisée (Exi. 4). D'où la possibilité, constatée dans la pratique,

de modifications coûteuses des solutions proposées par le concepteur du fait des analyses menées par l'ingénieur de SdF (Exi. 6). Enfin, les travaux mentionnés couvrent insuffisamment le domaine de la SdF. Des activités habituelles comme l’APR ou l’AMDEC sont présentes, mais il n’y a pas de lien avec l’ISO 26262:2011 (Exi. 1, Exi. 2, Exi. 5). Il n’a pas été possible de vérifier les exigences 3 et 7 dans cet état de l’art. Un tel bilan motive donc le choix de définir un nouveau processus d’ISSdF susceptible de mieux respecter les exigences définies précédemment.