Résultats étendus dans l’environnement d’évaluation en C

Nous présentons maintenant une sélection des résultats étendus de nos expérimentations sur le pouvoir de détection des codes présélectionnées dans l’environnement d’évaluation en C. Il s’agit de résultats « étendus » car nous avons pu mener des expérimentations plus conséquentes (que dans le premier environnement), plus proches du cas des systèmes embarqués critiques ciblés. Nous ne présentons qu’une « sélection » de nos résultats, ceux qui sont en adéquation avec les caractéristiques des systèmes ciblés. Les scénarios que nous exposons ciblent toujours les erreurs multiples aléatoires. Ils se basent sur le cadre suivant :

• trois tailles des codes : 8, 16 et 32 bits de contrôle,

• chacune de ces tailles de code a été appliquée à plusieurs tailles de la charge utile : 8, 16 et 32 octets de données utiles,

• une génération aléatoire des erreurs sur les données en entrée, avec un nombre de cas de test pris égal à 2n * 100 par scénario, avec n la taille des codes testés.

Ce dernier choix (2n*100 tests par scénario) découle d’une analyse a priori des intervalles de

confiances. En effet, le passage à cet environnement C permet de gagner largement en temps de simulation, cependant ce gain n’est quand même pas suffisant pour envisager n’importe quelle longueur de simulation. D’où le choix d’une génération aléatoire des erreurs, qui permet, comme dans toute simulation de ce type (appelée aussi simulations de Monte Carlo), de ne pas avoir à explorer la totalité des cas de test possibles (parce que ce ne serait pas possible à cause de la lenteur des simulations ou du nombre de cas irréaliste à explorer). Vu l’espace à explorer dans notre cas, il faut se poser la question sur le nombre de tests à réaliser. Pour répondre à cette question, nous avons utilisé le principe des intervalles de confiance.

1) Intervalles de confiance et choix du nombre des cas de test

Les intervalles de confiance permettent d’estimer la crédibilité des résultats à obtenir ou obtenus parce que le calcul d’intervalles de confiance peut être utilisé à deux fins différentes :

• Il peut être fait « a priori » (avant le lancement de simulation) pour estimer, ou dimensionner, le nombre des cas de test qu’il faudra explorer pour estimer que les résultats observés seront suffisamment significatifs. Cela revient à chiffrer la condition d’arrêt des simulations (cette estimation se fera en fonction du nombre n de bits de contrôle pour notre cas).

• Il peut aussi être fait a posteriori (une fois les simulations faites) pour vérifier ou confirmer la pertinence et la représentativité des résultats observés.

Pour faire ces calculs, nous nous sommes appuyés sur la formule suivante, couramment utilisée, qui définit l’intervalle de confiance :

Avec :

- CT : le nombre de Cas de Test,

- Pud : la proportion d’erreurs non détectées sur le nombre de cas de test qui correspond au taux de non détection,

- R : un coefficient qui traduit indirectement le risque d’erreur accepté (ou son complément, le niveau de confiance dans les résultats). Le Tableau III.4 donne les valeurs de R utiles à nos calculs

Seuil de l'intervalle de confiance 95 % 99 %

Niveau de risque correspondant 5 % 1 %

Valeur approchée du coefficient R 1,96 2,58

Tableau III.4 : Coefficients du niveau de confiance

Pour nos expérimentations sur le pouvoir de détection (évaluation du taux de non détection des différents codes), nous avons calculé les intervalles de confiance pour chaque scénario. Nous avons d’abord effectué des calculs a priori. Afin de ne pas surcharger la section, nous ne présentons (voir Tableau III.5) que deux exemples de calcul qui sont représentatifs :

• deux intervalles de confiance, à 95% et 99% de confiance, • tous les deux pour le scénario avec des codes de taille 32 bits,

• à chaque fois, avec trois valeurs du nombre de cas de test (CT), notés « Court », « Long » et « Très long », correspondant respectivement à un nombre prévu d’erreurs non détectées (ND) de 1, 10 et 100.

Nous considérons que le nombre minimum prévu de cas de test est l’inverse du maximum théorique de non détection attendu (2-n pour un code de taille n). En effet, c’est le seuil limite pour espérer pouvoir avoir au moins une erreur non détectée. Avec n=32, ce seuil est de 4294967296 tests. Dans la mesure où nous ne cherchons qu’un ordre de grandeur du nombre de tests, nous avons retenu les valeurs correspondant à 1, 10 et 100 de cas non détectés.

À partir de là, il est possible de calculer la limite supérieure (Sup) et la limite inférieure (Inf) de l’intervalle de confiance, et surtout le rapport entre ces deux bornes (rapport Sup/Inf). En effet, c’est ce dernier rapport qui va être déterminant pour choisir la configuration du nombre de cas de tests à réaliser. Dans le principe, on cherche un intervalle de confiance de taille réduite. Si l’intervalle est trop grand, on considère que les résultats ne seront pas assez significatifs. Dans la pratique, quantifier la limite à partir de laquelle l’intervalle sera trop grand, dépend du contexte et des objectifs qu’on vise. Dans notre cas, nous considérons qu’un rapport positif et inférieur à 2 est tout à fait satisfaisant pour nos objectifs, alors qu’un rapport supérieur ou égal à 10 n’est pas pertinent. Enfin, précisons que nous éliminons toutes les configurations avec un rapport est négatif.

Au final, vu les résultats donnés dans le Tableau III.5, nous retenons que pour avoir un intervalle de confiance à 95 % (ou 99%) de confiance, il faut effectuer un nombre de test de

2n*100 (dans l’exemple n = 32). Précisons que les calculs menés sur les scénarios avec n=16

et n=8 bits de contrôle ont conduit à la même conclusion : dans tous les cas, nous lancerons des simulations qualifiées (selon le Tableau III.5) de « très long » avec 2n*100 cas de test, n

III.3 Évaluations pour l’approche mono-code 61

Court Long Très long

Nombre prévu de cas de test (CT) 4294967296 42949672960 429496729600 Nombre prévu d’erreurs non détectées (ND) 1 10 100 Nominal (proportion Pud = ND/CT) 2,33*10-10 2,33*10-10 2,33*10-10

Intervalle de confiance à 95% de confiance

Limite Supérieure (Sup) 6,89*10-10 3,77*10-10 2,78*10-10

Limite Inférieure (Inf) -2,24*10-10 8,85*10-11 1,87*10-10

Écart en ± (%) 196% 62% 20%

Rapport Sup/Inf -3,1 4,3 1,5

Intervalle de confiance à 99% de confiance

Limite Supérieure (Sup) 8,34*10-10 4,23*10-10 2,93*10-10

Limite Inférieure (Inf) -3,68*10-10 4,29*10-11 1,73*10-10

Écart en ± (%) 258% 82% 26%

Rapport Sup/Inf -2,3 9,9 1,7

Tableau III.5 : Calculs a priori des intervalles de confiance à 95 % et 99 % de confiance pour les simulations sur des codes de 32 bits

2) Résultats des évaluations des codes de 8, 16 et 32 bits

Nous pouvons maintenant présenter les résultats de nos évaluations sur les codes de 8, 16 et 32 bits, pour des longueurs de charges utiles de 8, 16 et 32 octets.

Pour les codes de taille 8 bits, nous avons réalisé des simulations avec 28*100 (25600) trames de test. Globalement, les résultats (présentés dans la Figure III.4) montrent qu’on peut considérer que :

• Les pouvoirs de non détection convergent tous relativement vers le maximum théorique, égal à 3,9*10-3.

• Dans un contexte des erreurs multiples aléatoires, les pouvoirs de non détection des trois codes se valent.

• La longueur de la charge utile n’influe pas sur le pouvoir de détection, ce qui confirme le constat théorique qui dit que le pouvoir de détection d’un code dans le contexte des erreurs multiples dépend exclusivement de la taille du code (nombre de bits de contrôle). Ce résultat est différent de celui prouvé dans certains travaux qui considèrent une multiplicité faible des erreurs montrant que la distance Hamming (décrite dans le chapitre I, section I.4.1) est proportionnelle à la taille de la charge utile.

Dans le détail, on note quand même des écarts de valeurs, par rapport à la valeur théorique, et aussi entre les codes. On note également que l’ordre des performances (par rapport à la taille de la charge utile) est différent selon le type de code. Cependant, tous ces écarts sont négligés, car soit minimes, soit potentiellement imputables aux fluctuations liées à la génération aléatoire, comme déjà évoqué pour les résultats préliminaires sur Matlab-Simulink.

Globalement, les résultats obtenus sont cohérents avec les résultats préliminaires (pour la même taille des codes 8 bits).

Figure III.4 : Pud des codes de taille 8 bits (charges utiles de 8, 16 et 32 octets)

Pour les codes de taille 16 bits, nous avons réalisé des simulations avec 216*100 (6553600) trames de test. Globalement, les résultats (présentés dans la Figure III.5) montrent que là aussi, globalement, on peut considérer que : les résultats convergent tous vers le maximum théorique, égal à 1,52*10-5, les pouvoirs de détection des trois codes se valent, et ce, indépendamment de la taille de la donnée. Et là aussi, dans le détail, on note quand même des écarts et des fluctuations de même nature que ceux constatés pour les évaluations des codes 8 bits, et pour les mêmes raisons, ces écarts sont négligés.

Figure III.5 : Pud des codes de taille 16 bits (charges utiles de 8, 16 et 32 octets)

Enfin, pour les codes de taille 32 bits, nous avons réalisé des simulations avec 232*100 (429496729600) trames de test. Globalement, les résultats (présentés dans la Figure III.6) conduisent aux mêmes conclusions que précédemment avec notamment une convergence vers le maximum théorique égal à 2,32*10-10.

3,50E-03 3,90E-03 4,30E-03 4,70E-03 crc8 adler8 fletcher8 Charge utile 8 octets 16 octets 32 octets 1,20E-05 1,25E-05 1,30E-05 1,35E-05 1,40E-05 1,45E-05 1,50E-05 1,55E-05 crc16 adler16 fletcher16 Charge utile 8 octets 16 octets 32 octets

III.3 Évaluations pour l’approche mono-code 63

Figure III.6 : Pud des codes de taille 32 bits (charges utiles de 8, 16 et 32 octets)

Une conclusion générale à partir de toutes ces évaluations est que, dans un contexte d’erreurs multiples aléatoires, les pouvoirs de non détection des codes avec la même taille se valent et convergent assez bien vers les maximums théoriques.

3) Intervalles de confiance : calcul a posteriori

Suite à l’introduction des calculs d’intervalles de confiance pour dimensionner la taille de toutes nos expérimentations, nous avons utilisé cet outil pour faire des calculs a posteriori, pour confirmer la crédibilité des résultats obtenus. Nous ne donnons ici que le calcul pour un seul scénario. Il s’agit du scénario le plus lourd, avec 32 bits de contrôle et 32 octets de donnés. Nous avons fait les calculs pour les trois types de codes évalués (Adler, Fletcher et CRC) et pour un niveau de confiance à 99%. Les résultats sont donnés dans le Tableau III.6. Le constat principal est que pour les trois codes, le rapport Sup/Inf (qui nous sert d’indicateur de pertinence) est satisfaisant pour nos objectifs, même dans le cas du CRC32 (avec un écart légèrement supérieur à 2).

adler32 fletcher32 crc32

Nombre de cas de test (CT) 429496729600 429496729600 429496729600 Nombre relevé d’erreurs non

détectées (ND)

109 79 40

Nominal (proportion P= ND/CT) 2,54*10-10 1,84*10-10 9,31*10-11

Limite Supérieure (Sup) 3,17*10-10 2,37*10-10 1,31*10-10

Limite Inférieure (Inf) 1,91*10-10 1,31*10-10 5,51*10-11

Écart en ± (%) 25% 29% 41%

Rapport Sup/Inf 1,7 1,8 2,4

Tableau III.6 : Calcul a posteriori des intervalles de confiance à 99,9% de confiance pour les simulations sur des codes de taille 32 bits et 32 octets de données

De toutes ces évaluations sur le pouvoir de détection des trois types de code que nous avions présélectionnés, la conclusion principale est que ces trois types, pour l’instant, sont toujours de « bons » candidats pour l’approche mono-code (le choix de la longueur du code adéquate dépend des objectifs d’intégrité de chaque système). Nous allons maintenant passer à la présentation de tout ce qui touche aux évaluations des temps de calculs pour ces trois codes.

7,5E-11 1,15E-10 1,55E-10 1,95E-10 2,35E-10 2,75E-10 crc32 adler32 fletcher32 Charge utile 8 octets 16 octets 32 octets