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

Nowadays, we have connected cars, which means that everything in our vehicles operates as a complex system of systems. Even a seemingly minor failure can ultimately lead to serious injuries for the driver or passengers. That’s why testing at every stage of development is so important – 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 ?

Is there any difference when a requirement is marked with an ASIL (Automotive Safety Integrity Level)? Maybe it’s simply an additional attribute for a requirement that we can overlook, and no one will notice? Do we really need to adjust our standard testing approach that has “always worked” without 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é.

ASIL functions are crucial for our health and safety, making them the highest priority during the development of embedded systems. ISO26262 outlines many restrictions for their implementation and testing. A well-defined process allows us to thoroughly and accurately verify the implementation, operation, and safety mechanisms specified for these safety functionalities.

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 :

For each test level (unit tests, software integration tests, software qualification tests, system integration tests, system qualification tests), ISO26262 defines the methods to prepare a test environment, derive test cases, and conduct both functional and non-functional testing.

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

For each dedicated method listed in the ISO standards, we begin by assessing its relevance to our system. If a method is not applicable, we provide a clear explanation as to why it doesn’t fit our needs. Additionally, we outline the rationale for selecting a specific combination of methods.

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.