Pourquoi les tests de sécurité fonctionnelle sont si importants et comment ils sont réalisés

Aujourd'hui, nous disposons de voitures connectées, ce qui signifie que tout, dans nos véhicules, fonctionne comme un système complexe de systèmes. Même une défaillance apparemment mineure peut, en fin de compte, entraîner des blessures graves pour le conducteur ou les passagers. C'est pourquoi les tests à chaque étape du développement sont si importants – en particulier lorsqu'il s'agit detests de sécurité fonctionnelle. Les fonctions ASIL, qui sont au cœur de ce processus, jouent un rôle critique dans la garantie de notre sécurité et de notre bien-être.

Pourquoi les tests standards ne suffisent pas lorsque la sécurité fonctionnelle est en jeu

Les tests dans l'industrie automobile couvrent tout le côté droit du modèle en V. Ils sont essentiels en raison des exigences des niveaux ASPICE demandés par les OEM.

Lorsqu'une organisation définit et comprend clairement ses processus ASPICE et évite un ajustement excessif, l'équipe peut exécuter correctement le processus de test. Les services qualité supervisent son exactitude et la vérifient lors des audits et évaluations ASPICE.

Cela semble simple et familier à ceux qui sont impliqués dans les processus de développement automobile, n'est-ce pas ?

Où se situe la sécurité fonctionnelle ?

Y a-t-il une différence lorsqu'une exigence est marquée d'un ASIL (Automotive Safety Integrity Level) ? Il s'agit peut-être simplement d'un attribut supplémentaire pour une exigence que nous pouvons négliger, et personne ne le remarquera ? Devons-nous vraiment ajuster notre approche de test standard qui a « toujours fonctionné » sans incident ?

La réponse est oui, nous devons nous adapter.

L'importance d'un processus bien défini pour les tests de sécurité fonctionnelle

J'ai souvent pensé que la vérification liée à la sécurité est sous-estimée et considérée comme un mal nécessaire. Pourtant, bien qu'elle soit exigée par les normes ISO et évaluée lors de la Functional Audits de sécurité et les évaluations, cela peut réellement offrir une valeur significative pour nous en tant que testeurs.

Il y a quelque temps, je suis tombé sur un dicton : «Ce n'est que lorsqu'on paie pour une erreur que l'on en réalise le prix». À mon avis, cela donne matière à réflexion, en particulier lorsqu'on considère les fonctions de sécurité, où le « prix » peut être le plus élevé.

Les fonctions ASIL sont cruciales pour notre santé et notre sécurité, ce qui en fait la priorité absolue lors du développement de systèmes embarqués. L'ISO 26262 définit de nombreuses restrictions pour leur mise en œuvre et leurs tests. Un processus bien défini nous permet de vérifier de manière approfondie et précise la mise en œuvre, le fonctionnement et les mécanismes de sécurité spécifiés pour ces fonctionnalités de sécurité.

Ce qu'exigent l'ISO 26262 et l'IEC 61508

ISO26262 ne définit pas une stratégie de test entièrement nouvelle. Iil s'agit plutôt d'un complément à une approche bien connue d'ASPICE et ISTQB.

Consultez le tableau ci-dessous :

Pour chaque niveau de test (tests unitaires, tests d'intégration logicielle, tests de qualification logicielle, tests d'intégration système, tests de qualification système), l'ISO 26262 définit les méthodes permettant de préparer un environnement de test, de dériver des cas de test et de réaliser des tests fonctionnels et non fonctionnels.

Comment abordons-nous les tests de sécurité fonctionnelle chez Spyrosoft ?

Je décrirais notre approche chez Spyrosoft comme « complexe ». Dans nos plans de test, nous définissons toujours les Sécurité fonctionnelle processus de test (FuSa).

Notre point de départ consiste à définir toutes les méthodes et leurs combinaisons que nous prévoyons d'utiliser pour un projet spécifique.

L'approche que nous adoptons dépend de divers facteurs, notamment l'ASIL, l'étape de développement, le système, l'architecture, le type de tests dont nous sommes responsables et les outils disponibles. Nous utilisons nos propres modèles que we créé sur la base des recommandations décrites dans l'ISO 26262.

Sélection et documentation des méthodes

Pour chaque méthode dédiée répertoriée dans les normes ISO, nous commençons par évaluer sa pertinence pour notre système. Si une méthode n'est pas applicable, nous fournissons une explication claire des raisons pour lesquelles elle ne correspond pas à nos besoins. De plus, nous exposons la justification du choix d'une combinaison spécifique de méthodes.

L'étape suivante consiste à définir la stratégie de mise en œuvre de la méthode choisie. Nous identifions également le produit de travail résultant de l'utilisation de la méthode, ainsi que sa stratégie de vérification.

Voici à quoi ressemble le résumé :

Garantir la sécurité grâce à la traçabilité et à l'outillage

We use nos propres documents et scripts, évalués et qualifiés conformément à l'ISO 26262. TCela nous permet de garantir la traçabilité complète requise pour ASPICE et la conformité au processus ISO 26262 in préparation, exécution et reporting des tests.

Nous reconnaissons que les tests de sécurité fonctionnelle (FuSa) sont hautement bénéfiques lors de la qualification des composants matériels (HW) et logiciels (SW).

De plus, l'injection de fautes est une méthode efficace pour vérifier les mesures de sécurité. Elle consiste à introduire intentionnellement des défaillances dans le système afin de vérifier si les mécanismes de détection et de récupération fonctionnent comme prévu.

Chez Spyrosoft, nous proposons une variété de techniques d'injection de fautes, comme l'injection de défauts via le protocole XCP dans le logiciel sous test (SUT) et la réalisation de simulations de défaillance matérielle.

Vous souhaitez en savoir plus ? Contactez-nous pour plus de détails.