Intégration et tests sur des systèmes mécatroniques ... · o Test interface interne o Check de consistance d’interface ... sur les aspects vérification, doit être considéré

20e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016

Intégration et tests sur des systèmes mécatroniques automobiles Application de l’ISO26262

Integration and testing on automotive mechatronic systems ISO26262 application

C. HELLER et X. OUDIN PSA 18 Rue des FauvellesLa Garenne-Colombes

Résumé Pour répondre à la complexification grandissante de l’électronique embarquée et aux risques de sécurité associés, l’industrie automobile s’est dotée depuis 2011 d’un standard méthodologique et technique, l’ISO 26262. Cette norme décrit notamment des méthodes de vérification et de validation. La mise en œuvre de ces exigences peut rapidement devenir complexe.Néanmoins, moyennant certaines précautions, il est possible d’en rationaliser les attendus pour faciliter son application sur le terrain. Ce document vise à mettre en évidence les difficultés d’application du standard sur la partie remontante du cycle en V, en présenter une interprétation et une optimisation (tailoring au sens de l’ISO 26262), puis l’illustrer par un exemple d’application sur un système mécatronique.

Summary To address the growing complexity of embedded electronics and their associated safety risks, the automotive industry got since 2011 a methodological and technical standard called ISO 26262. It describes in particular verification and validation methods. The implementation of these requirements can easily become complicated. However, with cautions, it is possible to rationalize standard expectations in order to facilitate its application on systemverification.This document aims to highlight difficulties of applying the standard on the ascending part of the V cycle, to present an interpretation and a tailoring of this one, and finally to have an application example on a mechatronic system.

Introduction

Les véhicules modernes embarquent un nombre croissant de fonctions complexes, et cette tendance va s’accélérer, avecl’introduction en nombre de fonctions mécatroniques, mêlant les aspects mécaniques et électroniques au sein d’un même système. Ces fonctions induisent naturellement une augmentation du nombre d’interlocuteurs, du nombre d’interactions dans ladéfinition du fonctionnel, engendrant dans le même temps une complexification dans la définition des concepts de sécurité associés.

Cette complexité en conception induit une difficulté en intégration et en vérification, rendant délicate la démonstration de sécurité.

Par ailleurs, le standard de sécurité fonctionnelle automobile (ISO 26262 :2011) exige de mettre en place de nombreuses méthodes de tests qui sont complémentaires mais parfois redondantes. Comment répondre à la fois aux exigences de sécurité de façon exhaustive sur des systèmes mécatroniques sans pour autant complexifier inutilement la phase de vérification ?

L’optimisation des activités de vérification a nécessité une analyse des exigences de la 26262 pour identifier leur complémentarité et leur recouvrement, ce qui a permis de définir un corpus minimum d’exigences méthodologiques.

Dans un second temps, un processus applicable au sein de PSA a été défini sur la base des optimisations réalisées afin de l’appliquer sur un premier système complexe, avant de le déployer plus largement.

Les attendus du standard ISO26262 sur la remontée du cycle en V

Outre une description du cycle de vie pour la conception, l’analyse de sureté de fonctionnement, le management, la norme ISO26262 spécifie des activités de vérification via la réalisation de tests et des activités de validation.

Comme illustré sur la figure ci-dessous, l’ensemble de ces activités se décomposent en plusieurs phases :

- Les vérifications unitaires, permettant de tester l’implémentation hardware et l’implémentation software

- Les vérifications d’intégrations, permettant de tester la conformité aux exigences à plusieurs niveaux :o Composant, via l’intégration hardware/softwareo Système, via la vérification des exigences définies dans les Technical Safety Conceptso Véhicule, via la vérification des exigences définies dans les Functional Safety Concepts

- La validation, qui assure la conformité du véhicule vis à vis du besoin exprimé

Communication 7F-1 /3 page 1/7


Figure 1 : ISO26262 - Intégration et vérification, validation

Lorsque l’on fait un focus sur la phase de vérification au niveau d’un système, il est demandé par la norme ISO 26262 de démontrer que la conception de celui-ci implémente les exigences de sécurité définies de sorte que l’on ait un niveau de confiance suffisant sur l’absence de comportement non souhaité. Pour y parvenir, on nous propose un ensemble de tables contenant des méthodes, des objectifs ainsi que des types de tests à mettre en place. Le principe réside dans l’utilisation de la table 4 (part 4) pour identifier la stratégie basée sur les méthodes de tests que l’on souhaite mettre en place, et des tables 10 à 14 (part 4), pour identifier les types de tests appropriés pour le système étudié. La table 4 (part 4) du standard nous recommande donc, avec un niveau d’applicabilité qui varie de recommandé (+) à hautement recommandé (++) selon le niveau ASIL manipulé de mettre en œuvre une combinaison des méthodes de tests proposées, à savoir :

- L’analyse des exigences - L’analyse des interfaces externe et interne - L’analyse des valeurs limites - Les tests imaginés à partir des connaissances ou de l’expérience - L’analyse des dépendances fonctionnelles - L’analyse des conditions limites, des séquences et de sources de défaillances dépendantes - L’analyse des conditions environnementales et des scénarii opérationnels - L’analyse du retour d’expérience

En complément, les tables 10 à 14 (part 4) nous fixent des objectifs associées, avec pour chacun, des propositions de types de tests qu’il est possible de réaliser :

- L’implémentation des FSR et TSR au niveau Système par : o Test d’exigence fonctionnelle o Test d’injection de défaillance o Back to back test

- L’implémentation des performances fonctionnelles et de précisions des mécanismes de sécurité du système par :

o Test de performance o Back to back test

- L’implémentation des interfaces internes et externes du système par :

o Test d’interface externe o Test interface interne o Check de consistance d’interface o Test d’interaction de communication

- La couverture efficace des défaillances des mécanismes de sécurité du système par :

o Test d’injection de défaillance o Test imaginé (connaissance, expérience) o Test issu du retour d’expérience

- Le niveau de robustesse du système par : o Test d’utilisation des ressources o Stress test o Test de perturbation EMC et ESD



L’expérience au sein de PSA nous montre que même si l’exercice pouvait paraitre trivial, l’application « directe », des attendus de la norme est en fait assez complexe, et ont pour effet d’engendrer des incompréhensions sur l’application par les équipes en charge de la vérification du système étudié. Prenons pour exemple l’analyse des dépendances fonctionnelles ainsi que l’analyse de sources de défaillances dépendantes. L’objectif dans les deux cas est d’avoir le niveau de confiance suffisant sur l’absence de comportement dangereux sur une dépendance, autrement dit un mode commun potentiel. Donc, même si il peut se traduire et se vérifier différemment, l’objectif est bien de s’assurer de l’absence de mode communs jusqu’à un niveau raisonnable sur le système. Cette similarité peut être une source d’optimisation, qui permet de surcroît une limitation des erreurs d’interprétation. D’une manière plus générale, l’interaction entre les méthodes de tests de la table 4 ainsi que les objectifs des tables suivantes est assez complexe à appréhender. Les types de tests proposés pour démontrer différents objectifs de tests peuvent également être pris pour exemple. Prenons le cas des tests par injections de défaillances. Ils sont utilisables pour la démonstration d’implémentation des FSR/TSR ainsi que pour l’efficacité des mécanismes de sécurité. Là encore, des erreurs d’interprétations sont possibles. Il ne faut pas perdre de vue que ce sont des moyens de tests pour arriver aux objectifs de tests initiaux, objectifs qui peuvent être assez vite perdus de vue sur le terrain. Ces difficultés viennent principalement d’une interprétation assez large possible de la norme, en particulier sur la stratégie de tests à adopter, ainsi qu’à plusieurs recoupements entre les objectifs et les types de tests qui leurs sont associées et qui sont présentés ci-dessus. En ce qui concerne la liberté d’interprétation de la stratégie, elle nous semble volontaire et souhaitée par le standard. Elle a pour objectif de laisser le choix d’adapter au mieux cette stratégie, que ce soit pour s’adapter au mieux aux spécificités organisationnelles de chaque entreprise, ou pour répondre aux spécificités du système étudié. Fort de ces constats, nous sommes arrivés aux conclusions suivantes : - Le standard ISO 26262, sur les aspects vérification, doit être considéré comme un canevas, permettant de définir une stratégie adaptée à l’entreprise, tout en conservant sa philosophie, afin de faciliter son implémentation dans la remontée de V - Moyennant certaines précautions, il est possible de regrouper judicieusement plusieurs types de tests afin de faciliter l’implémentation de la démarche

Appréhension de la norme au sein de PSA Pour pallier à ces difficultés, une analyse fine a été réalisée chez PSA, basée d’une part sur l’interprétation de la norme ISO 26262 (part 4, tables 10 à 14), et d’autre part sur la prise en compte des caractéristiques de l’organisation existante dans l’entreprise. Nous avons pu ainsi identifier chaque objectif de test, et proposer des regroupements pour les méthodes de tests associés. On distingue ainsi : 1. L’Analyse des exigences Cette première catégorie est fondamentale dans la démonstration du respect des objectifs de sécurité. Elle est utilisée pour vérifier que les caractéristiques des mécanismes de sécurité du système sont bien implémentées. Cette catégorie de test est à mettre en place dès le niveau ASIL A, et ceci pour chaque mécanisme de sécurité. Le niveau ASIL à prendre en compte est celui avant décomposition, comme exigé par le standard ISO 26262, autrement dit celui du Safety concept. Chez PSA, la rédaction de chaque exigence de sécurité passe par une caractérisation détaillée, et ce, dès leur définition. Chaque mécanisme de sécurité (Technical Safety Requirement, tel que défini dans l’ISO26262) doit donc avoir :

- Un principe - Une caractéristique de performance (physique ou temporelle) - Un mode dégradé - Une condition de réhabilitation

La rigueur dans l’écriture des TSR selon ces critères est essentielle car elle permet de tendre vers des exigences qui vont être exhaustives dans le concept de sécurité, et qui seront intrinsèquement testables. L’analyse de l’exigence de sécurité, telle que décrite, va donc passer par la vérification de chacune de ses caractéristiques. Pour ce faire, des injections de défaillances seront nécessaires. Avec cet exercice, nous pouvons ainsi couvrir plusieurs objectifs de la norme sur la vérification de l’implémentation (table 10 – part 4), la performance (table 11 – part 4), les interfaces (table 12 – part 4), et l’efficacité quant à la couverture des mécanismes de sécurité (table 13 – part 4). Un cas particulier doit également être pris en compte dans cette catégorie, et ce uniquement pour les mécanismes de sécurité de niveau ASIL D, le back to back test. L’iSO26262 demande en effet, via ce type de test, de comparer des résultats d’essais entre un modèle physique (ex : table d’intégration, véhicule prototype,..) et un modèle numérique (ex : modèle Simulink). Les tests évoqués auparavant devront donc être déroulés sur chacun de ces moyens, afin de vérifier la similitude des résultats d’essais.



. 2. L’Analyse des conditions aux limites Elle est utilisée pour vérifier qu’il n’y aucune zone d’ombre dans la spécification des mécanismes de sécurité, sur les valeurs limites de ses caractéristiques physiques et/ou temporelles. Cette catégorie de test est à mettre en place à partir du niveau de gravité ASIL C, et ceci pour chaque mécanisme de sécurité. Cette catégorie de test nous permet de couvrir une partie des besoins de tests exprimés dans la norme (table 4 – part 4). 3. L’Analyse des séquences Elle nous permet de vérifier le comportement d’un mécanisme de sécurité dans toutes les phases de vies spécifiques du système, liées à la sécurité. Cette catégorie de test est à mettre en place à partir du niveau ASIL C, et ceci pour chaque mécanisme. En effet, chaque mécanisme de sécurité doit être opérationnel tel que spécifié dans chaque phase de vie du système. Ces phases de vie pouvant être au niveau véhicule (démarrage, arrêt, roulage, stop and start..) ou au niveau calculateur (réveil, endormissement, Reset,…). Ces différents exemples ne sont bien sûr pas exhaustifs. Les phases de vies critiques d’un point de vue sécurité doivent être analysées pour chaque système étudié. Cette catégorie de test nous permet de couvrir une partie des besoins de tests exprimés dans la norme (table 4 – part 4). 4. L’Analyse issue de l’expérience Cette catégorie couvre deux aspects essentiels : Le premier est la capitalisation du retour d’expérience, issue de projets précédents, et ayant une similarité avec le nouveau système étudié. L’analyse se porte dans le cas d’une évolution d’un système existant sur les systèmes développés antérieurement. En ce qui concerne un nouveau système, on se basera sur les systèmes ayant une analogie forte en termes de stratégie de pilotage et/ou de stratégie de sécurisation. Par exemple, un système de porte latérale coulissante motorisé a plusieurs analogies avec un système d’ouverture de coffre arrière motorisé en termes de stratégies de sécurisation vis-à-vis du risque de pincement. Le second, est lié aux tests imaginés, issus de la connaissance de spécialistes des domaines relatifs au système, que ce soit en conception, dans la descente du cycle en V, ou en validation pour la remontée de ce cycle. Contrairement aux précédentes, cette catégorie est à mettre en œuvre au niveau du Safety concept, et non pour chacun des mécanismes de sécurité qui le constituent. On l’appliquera ainsi à partir du niveau ASIL C. Le processus de récupération de ces informations est spécifique à chaque organisation. Il se base en entre autres, sur le recueil de tous les cas clients recensés ayant un lien avec les évènements redoutés du système étudié. Il faut ici plutôt retenir que l’objectif est de vérifier que le système étudié est robuste par rapport à des modes de défaillances non triviaux (micro coupures, dérive d’alimentation,…)

5. L’Analyse des modes communs Cette catégorie a pour objectif de vérifier que les modes communs ont été traités correctement dans le Concept de sécurité. Bien que la norme ISO 26262 ne conseille d’appliquer ce type de vérification qu’à partir d’un niveau ASIL C, nous avons souhaité l’appliquer dès lors qu’une décomposition ASIL avec 2 mécanismes de sécurité était réalisée, c’est dire à partir d’un niveau ASIL B.

6. L’Analyse des conditions environnementales La vérification de la robustesse du système aux conditions environnementales est appliquée dès le niveau ASIL A. L’objectif ici est de vérifier que le Safety concept du système est efficace malgré des perturbations externes. On peut citer notamment la robustesse vis-à-vis des perturbations électromagnétiques.

Avec ces six catégories de tests identifiés, à mettre en œuvre à partir d’un niveau ASIL défini pour chacun d’entre eux, il est possible de démonter la robustesse du concept de sécurité tel que requis par la norme ISO 26262.

Il est fondamental de rappeler que ces catégories de tests ont été élaborées de manière à faciliter l’application de la démarche de remontée du cycle en V, tout en conservant une compatibilité totale avec les exigences de la norme.



Définition et mise en pratique du processus de vérification d’un système

Les catégories de tests dans le cadre de la vérification de la robustesse d’un point de vue sécurité ayant été rationalisées, il restait à définir un processus permettant de les mettre en œuvre, adapté au processus de conception PSA. Celui-ci prévoit une identification de l’ensemble des tests au moment de la rédaction des mécanismes du concept de sécurité. Cette activité est représentée dans la figure ci-dessous par les étapes 1.1 et 1.2. Cet exercice doit être réalisé par chaque métier participant à la conception du système étudié. La réalisation de ces deux étapes en parallèle est bénéfique. On observe en effet un cercle vertueux permettant de robustifier le test lui-même, mais également la définition du mécanisme de sécurité ainsi que sa caractérisation. Au-delà de l’optimisation apportée par ce processus sur la rédaction des exigences de sécurité, le gain apporté est multiple. D’une part, les simplifications et regroupements amenés par la standardisation des catégories de test (selon le niveau ASIL) sont une donnée d’entrée facile à consommer, et facile à implémenter dans un Template. Dans notre cas, nous avons ainsi pu enrichir celui de notre TSC. D’autre part, il est possible de vérifier lors des séances de vérification et confirmation reviews demandées par la norme ISO26262 que les exigences de vérifications ont été identifiées et traitées.

Figure 2 : Processus de vérification au niveau système au sein de PSA

L’étape suivante consiste à partager les différents tests identifiés par chaque entité, en privilégiant les groupes de travail, dans le but d’identifier les moyens d’essais le plus appropriées. Les groupes de travail, axés sur la vérification, rassemble les différents acteurs de chaque métier attenant au système, notamment les rédacteurs des concepts de sécurité, des plans de test, ainsi que les valideurs. Le partage des tests identifiés par chaque métier lors de ses séances va permettre de s’assurer de la bonne couverture du Safety concept, de la faisabilité de réalisation de ceux-ci, et de leur adaptation le cas échéant. La démarche de « standardisation » des objectifs de test à réaliser sur un système, et leurs définitions effectuées lors de l’étape précédente prend une importance capitale dans cette dernière phase puisque, elle met en avant le fait que le moyen de test le plus approprié n’est pas nécessairement un moyen de test dédié pour l’un ou l’autre des métiers concernés. L’ensemble de cette démarche permet une cohérence entre la stratégie mise en place en phase de conception, et celle mise en place dans la phase de vérification. Les efforts mis en place en phase de descente de V en termes de barrières de sécurité, feront l’objet de vérification avec le niveau de robustesse et de rigueur exigé en remontée de V. La cohérence de l’argumentaire Safety du système étudié, autrement dit l’axe de démonstration de la robustesse du concept de sécurité, est donc respecté. Ce processus et les livrables associés ont été mis en place sur un Safety concept relatif à un système de portes latérales coulissantes motorisées, qui associent des aspects électriques, électroniques et mécaniques, telles que représentées sur la figure 3.



Figure 3 : Représentation d’un système de portes latérales coulissantes motorisée d’un véhicule

Les évènements redoutés les plus critiques sur ce système sont :

- L’ouverture intempestive de la porte latérale coulissante en roulage - Le risque de pincement lors de la fermeture de la porte latérale coulissante

Les composants pouvant défaillir et mener à ces évènements redoutés peuvent aussi bien être d’origines électrique / électronique que mécanique. Cependant, en fonction de l’évènement redouté considéré, les interactions entre ces composants et donc les métiers électroniques et mécaniques sont très disparates. En ce qui concerne le risque d’ouverture intempestive de la porte latérale coulissante, les défaillances peuvent provenir du calculateur et de l’actionneur d’ouverture pour la partie électronique, et de la serrure pour la partie mécanique. Des mécanismes de sécurité, gérés par le calculateur et utilisant l’information vitesse véhicule qui sont complétement indépendant de la serrure peuvent être testés avec ce même niveau d’indépendance. On retrouve ce constat d’indépendance au niveau de la serrure, qui peut être vérifiée sans prise en compte du calculateur. Pour le risque de pincement, le constat diffère du cas cité précédemment. Le risque de pincement est fortement lié à la vitesse de la porte, du temps de détection d’un obstacle éventuel, ainsi que du temps de réaction du système. Il n’est pas possible de prendre indépendamment chacune de ces caractéristiques et de les attribuer d’une part à l’électronique, et d’autre part à la mécanique. Avec la mise en place du processus évoqué, il a été possible de mettre en avant, pour chaque type de test, la représentativité nécessaire du moyen d’essai pour pouvoir réaliser de manière robuste nos essais de vérification, et ceux pour chaque partie prenante. Cela a ainsi contribué à

- Mettre en évidence les avantages et inconvénients des différents moyens (unitaires, sous-systèmes, systèmes) d’essais à disposition

- De démontrer l’exhaustivité sur la couverture des tests de chaque catégorie, qui a été grandement facilitée par la

communauté des catégories de tests entre les différents métiers (électronique et mécanique dans notre exemple).

- D’accentuer le niveau de confiance quant au niveau de couverture du concept de sécurité, avec ces mécanismes, sur l’ensemble du système étudié

De surcroît, la robustesse des mécanismes de sécurité définis a ainsi pu être améliorée, grâce à l’effet vertueux induit par définition des tests en parallèle de la définition du concept de sécurité En synthèse, l’exemple du système de portes latérales coulissantes motorisées nous montre qu’une synergie entre les différents métiers concernés, ainsi qu’une réflexion permanente pour choisir la bonne association entre les méthodes de tests et les moyens de tests est essentielle pour atteindre l’objectif fixée par l’ISO 26262, à savoir garantir le niveau de confiance requis dans la vérification des mécanismes de sécurité implémentés.



Conclusion Apres 5 années de déploiement du standard ISO 26262, il apparait que l’industrie automobile a opérée une véritable révolution dans l’approche de la Sécurité Fonctionnelle. Par ailleurs, le standard est un excellent support méthodologique pour la définition de la stratégie de vérification et validation Safety. Le premier retour d’expérience est que cette stratégie doit être cohérente de l’argumentation Safety utilisé en conception. Il est important de renforcer les exigences de tests sur les propriétés de Safety du système, ainsi que les modes de défaillances critiques identifiés en descente de V. Le second retour d’expérience est qu’il est possible (voire souhaitable) de rationaliser les exigences méthodologique associés à la remontée de cycle en V tout en étant totalement compatible de l’ISO 26262. Le troisième retour d’expérience est que la définition de la stratégie de validation ainsi que la définition des cas de tests permet d’identifier des faiblesses de la conception ainsi que des faiblesses dans la rédaction des exigences. Enfin, sur des systèmes complexes il convient de définir finement le partage de responsabilité entre les métiers concernés ainsi que définir précisément les moyens de tests appropriés.

Sigles

- ASIL: Automotive Safety Integrated Level - EMC: Electromagnetic compatibility - ESD: Electrostatic discharge - SC: Safety Concept - TSR : Technical Safety Requirement - TSC : Technical Safety Concept

Références

- ISO26262 : 2011


Documents

Intégration et tests sur des systèmes mécatroniques ... · o Test interface interne o Check de consistance d’interface ... sur les aspects vérification, doit être considéré