Rapport de performances EMS Builder sur AFE-E620
Version du rapport : v1.0
Dates des essais : 2026-07-30 au 2026-07-31
Date du rapport : 2026-07-31
Méthode statistique : 2 002 acquisitions par scénario ; premier et dernier échantillons ignorés, statistiques sur les 2 000 échantillons de ressources validessample_no=2～2001
Manuel associé : Manuel des essais de performance Edge-EMS Builder
1. Vue d’ensemble des performances
Section intitulée « 1. Vue d’ensemble des performances »Acquisition configurée
Calculs agrégés
Objectif Trigger
Objectif des tâches MQTT
Tâches de coordination
Enregistrement au plus tard à 10 s
CPU machine, moyenne / P95
Mémoire machine, moyenne / P95
Trigger P95
MQTT P95
Chaque exécution Trigger représente une commande d’équipement, une alarme locale et MQTT, et une écriture de donnée agrégée. Edge-EMS Builder alloue les ressources PostgreSQL selon la mémoire de l’équipement ; l’occupation peut donc varier sensiblement selon le matériel, la taille de la base et l’état des caches. Avec 982 MB physiques, l’AFE-E620 dispose de beaucoup moins de marge que l’AFE-E630 ; la mémoire doit guider le dimensionnement.
1.1 Conclusion principale
Section intitulée « 1.1 Conclusion principale »Configuration recommandée sur AFE-E620 : scénario S2.5, avec 2 000 points/seconde, 20 calculs agrégés, 40 Trigger/seconde, 10 MQTT/seconde, 2 tâches de coordination/seconde et stockage sur changement toutes les 10 secondes au maximum.
Mesures S2.5 : 39,96 Trigger/seconde et 9,98 MQTT/seconde, soit 99,91% et 99,82% de l’objectif ; P95 Trigger / MQTT de 25 ms / 56 ms. P95 CPU de la machine : 45,54% ; P95 mémoire réelle : 86,10%. 8 expirations d’échantillonnage ont été observées.
Pour une exploitation durable, réservez environ 20% de marge d’ingénierie par rapport à S2.5. Le dimensionnement initial peut viser au plus environ 1 600 points/seconde, 32 Trigger/seconde, 8 MQTT/seconde et 2 tâches de coordination/seconde. Ces valeurs sont dérivées de la configuration mesurée et n’ont pas fait l’objet d’un scénario d’essai distinct. Avant production, retestez avec les scripts, tailles de messages et historique de base réels.
1.2 État des scénarios
Section intitulée « 1.2 État des scénarios »| Icône | Scénario | Conclusion |
|---|---|---|
| 🟢 | S1 | Scénario de référence validé, atteinte de 100% ; mémoire moyenne de la machine déjà à 74,02%, niveau de base élevé. |
| 🟡 | S2 | Avec stockage temps réel, atteinte Trigger / MQTT de 98,65% / 98,76%, légèrement sous 99%, et 34 expirations d’échantillonnage. |
| 🟢 | S2.5 | Charge maximale atteignant la référence de 99%, scénario actuellement recommandé sur AFE-E620. |
| 🔴 | S3 | Échec : atteinte Trigger / MQTT de 43,08% / 44,65%, forte dégradation des latences et 617 expirations d’échantillonnage. |
| 🔴 | S3.5 | Échec : le stockage sur changement améliore nettement S3, mais l’atteinte reste à 87,30% / 86,69%, sous 99%. |
| 🔴 | S6 | Surcharge sévère : atteinte Trigger / MQTT de 19,15% / 19,18% et 886 expirations d’échantillonnage. |
2. Synthèse des conclusions
Section intitulée « 2. Synthèse des conclusions »- Six scénarios ont été testés : S1, S2, S2.5, S3, S3.5 et S6. Les autres sont exclus des tableaux, comparaisons et conclusions.
- À 2 000 points/seconde configurés, S2.5 atteint 99,91% pour Trigger et 99,82% pour MQTT ; leurs P95 sont de 25 ms et 56 ms.
- S2 et S2.5 ont la même charge métier. Le stockage sur changement réduit la moyenne CPU de 29,41% à 26,24% et le P95 de 52,01% à 45,54%, tandis que l’atteinte Trigger passe de 98,65% à 99,91%.
- S3 et S3.5 ont la même charge métier. Le stockage sur changement fait passer l’atteinte Trigger de 43,08% à 87,30% et MQTT de 44,65% à 86,69%, et réduit le P95 CPU de 82,71% à 66,05%. Le scénario échoue encore : 5 000 points/seconde dépassent la capacité soutenue de l’AFE-E620.
- Comparaison avec AFE-E630 : E630 supporte S3.5, soit 5 000 points/seconde et 90 Trigger/seconde ; la limite validée d’E620 est S2.5, soit 2 000 points/seconde et 40 Trigger/seconde. L’écart mémoire, 3,81 GB contre 982 MB, est la principale différence.
- Chaque scénario comporte une exécution Trigger exceptionnellement longue d’environ 10 à 11 secondes. En surcharge, ces valeurs extrêmes augmentent : S3.5 atteint 53 472 ms pour Trigger et 53 373 ms pour MQTT.
- La mémoire moyenne de la machine dépasse 74% dans tous les scénarios ; à partir de S3, son P95 dépasse 91%. La mémoire est une contrainte commune à tous les scénarios E620 et doit être surveillée continuellement.
- Chaque scénario ne conserve que 2 000 secondes valides, soit environ 33 minutes 20 secondes. Ces données permettent une comparaison de performances, sans remplacer un essai de stabilité de 72 heures.
3. Méthode statistique
Section intitulée « 3. Méthode statistique »3.1 Sélection des échantillons
Section intitulée « 3.1 Sélection des échantillons »La surveillance compte les acquisitions. Les données brutes de chaque scénario contiennent sample_no=1～2002 :
Ignorer：sample_no = 1Comptabiliser：sample_no = 2～2001，2,000 au totalIgnorer：sample_no = 2002L’exclusion des premier et dernier échantillons évite les secondes incomplètes. Les résultats globaux Trigger et MQTT utilisent 2 000 secondes comme dénominateur. Une seconde sans enregistrement de tâche reste incluse dans le débit moyen, afin de ne pas le surestimer en ne comptant que les secondes actives.
3.2 Périmètre global EMS Builder
Section intitulée « 3.2 Périmètre global EMS Builder »Les 5 services suivants forment ensemble Edge-EMS Builder :
| Service | Fonction |
|---|---|
cb_core |
Acquisition de données et communication principale |
cb_nginx |
Web CommBridge / reverse proxy |
cb_backend |
Backend CommBridge |
ems_backend |
Calcul, stratégies et logique métier EMS Builder |
ems_postgresql |
Stockage des données EMS Builder |
Pour chaque sample_no, les 5 services sont d’abord additionnés ; moyenne, P95, P99 et pic sont ensuite calculés sur les 2 000 sommes. Les pics indépendants survenus à des instants différents ne sont pas additionnés.
3.3 CPU, mémoire et latence des tâches
Section intitulée « 3.3 CPU, mémoire et latence des tâches »- Les valeurs CPU brutes des cinq services sont exprimées en pourcentage équivalent monocœur. L’AFE-E620 possède 4 cœurs : CPU Edge-EMS Builder équivalent 4 cœurs = somme CPU des cinq services ÷ 4.
- Le CPU de la machine utilise
_system_totaldu classeur, normalisé sur toute la capacité CPU de 0 à 100%. C’est l’indicateur principal de capacité. - La mémoire attribuée à Edge-EMS Builder additionne la mémoire cgroup des cinq services. Pages partagées et caches peuvent être attribués plusieurs fois ; cette somme peut dépasser la mémoire réellement utilisée et ne doit pas être divisée directement par la mémoire physique pour obtenir un taux d’occupation.
- La mémoire réelle de la machine est
MemTotal - MemAvailable, indicateur principal de marge physique. Les pourcentages de ce rapport utilisent MemTotal = 982 MB. - Moyennes et P50, P95, P99 Trigger / MQTT portent sur tous les enregistrements de tâches de la période valide, et non sur les moyennes par seconde.
- Tous les classeurs ont passé la vérification de l’arrêt de charge avant consolidation : Trigger, MQTT et CommBridge ont été arrêtés, puis une attente de 30 secondes a précédé la consolidation.
4. Équipement et environnement
Section intitulée « 4. Équipement et environnement »| Élément | Configuration |
|---|---|
| Modèle | AFE-E620 |
| CPU | Arm Cortex-A55, 4 cœurs |
| Mémoire | 982 MB DDR3 |
| Système d’exploitation | JelinaOS, basé sur Ubuntu 20,04 |
| Stockage | eMMC |
| Versions logicielles | À compléter : non enregistrées dans les classeurs ; versions CommBridge / EMS Builder / PostgreSQL à ajouter avant archivage |
| Réseau | Réseau local ; MQTT / TCP |
| Échantillonnage de surveillance | Une acquisition par seconde ; 2 002 par scénario, statistiques sur les 2 000 centrales |
| Sources des essais | perf_S1_20260730_101351.xlsx, perf_S2_20260730_105126.xlsx, perf_S2.5_20260730_113029.xlsx, perf_S3_20260730_152548.xlsx, perf_S3.5_20260731_122356.xlsx, perf_S6_20260731_173626.xlsx |
5. Scénarios et charges
Section intitulée « 5. Scénarios et charges »| Scénario | Acquisition | Calculs agrégés | Trigger ordinaires | Trigger 100 ms | Objectif Trigger | Objectif MQTT | Coordination | Stockage |
|---|---|---|---|---|---|---|---|---|
| S1 | 500 points/seconde | 10 | 10 /seconde | 0 | 10 /seconde | 5 /seconde | 0 /seconde | Temps réel |
| S2 | 2 000 points/seconde | 20 | 20 /seconde | 2 | 40 /seconde | 10 /seconde | 2 /seconde | Temps réel |
| S2.5 | 2 000 points/seconde | 20 | 20 /seconde | 2 | 40 /seconde | 10 /seconde | 2 /seconde | Sur changement (10 secondes) |
| S3 | 5 000 points/seconde | 30 | 50 /seconde | 4 | 90 /seconde | 20 /seconde | 10 /seconde | Temps réel |
| S3.5 | 5 000 points/seconde | 30 | 50 /seconde | 4 | 90 /seconde | 20 /seconde | 10 /seconde | Sur changement (10 secondes) |
| S6 | 5 000 points/seconde | 20 | 50 /seconde | 10 | 150 /seconde | 30 /seconde | 15 /seconde | Temps réel |
L’acquisition représente la charge configurée selon les scénarios du manuel. Les classeurs ne fournissent ni nombre de réussites par point ni détails de configuration par scénario ; cette charge ne constitue donc pas un débit d’écriture réussie vérifié indépendamment. Les objectifs Trigger / MQTT correspondent aux références de calcul d’atteinte des classeurs.
6. Périodes d’essai
Section intitulée « 6. Périodes d’essai »| Scénario | Intervalle statistique valide | Durée valide |
|---|---|---|
| S1 | 2026-07-30 10:13:55 ～ 10:47:13 | 2 000 secondes |
| S2 | 2026-07-30 10:51:30 ～ 11:24:48 | 2 000 secondes |
| S2.5 | 2026-07-30 11:30:33 ～ 12:03:51 | 2 000 secondes |
| S3 | 2026-07-30 15:25:51 ～ 15:59:09 | 2 000 secondes |
| S3.5 | 2026-07-31 12:23:59 ～ 12:57:17 | 2 000 secondes |
| S6 | 2026-07-31 17:36:29 ～ 18:09:47 | 2 000 secondes |
Toutes les heures sont en UTC+8.
7. Résultats CPU
Section intitulée « 7. Résultats CPU »7.1 Somme des cinq services EMS Builder, équivalent 4 cœurs
Section intitulée « 7.1 Somme des cinq services EMS Builder, équivalent 4 cœurs »| État | Scénario | Moyenne | P95 | P99 | Pic |
|---|---|---|---|---|---|
| 🟢 | S1 | 9,87% | 19,19% | 27,73% | 32,42% |
| 🟡 | S2 | 22,39% | 41,93% | 51,69% | 110,22% |
| 🟢 | S2.5 | 19,86% | 36,67% | 47,88% | 75,63% |
| 🔴 | S3 | 32,80% | 57,33% | 71,41% | 115,84% |
| 🔴 | S3.5 | 32,25% | 52,81% | 64,87% | 130,65% |
| 🔴 | S6 | 30,90% | 63,74% | 77,34% | 99,06% |
Les pics Edge-EMS Builder de S2, S3 et S3.5, respectivement 110,22%, 115,84% et 130,65%, sont des valeurs instantanées sur une fenêtre d’échantillonnage. Ils correspondent à un temps CPU cumulé supérieur à la capacité normale de 4 cœurs ; par exemple, ems_backend atteint seul 402% sur un échantillon S2. Avec les expirations observées, cela peut indiquer un chevauchement des fenêtres ou un ordonnancement en rafale. Ces valeurs ne sont pas considérées comme une occupation soutenable.
7.2 CPU de la machine, normalisé sur toute sa capacité
Section intitulée « 7.2 CPU de la machine, normalisé sur toute sa capacité »| État | Scénario | Moyenne | P95 | P99 | Pic |
|---|---|---|---|---|---|
| 🟢 | S1 | 15,27% | 26,83% | 34,00% | 50,88% |
| 🟡 | S2 | 29,41% | 52,01% | 70,29% | 100,00% |
| 🟢 | S2.5 | 26,24% | 45,54% | 58,41% | 97,05% |
| 🔴 | S3 | 48,29% | 82,71% | 97,18% | 100,00% |
| 🔴 | S3.5 | 41,32% | 66,05% | 90,63% | 100,00% |
| 🔴 | S6 | 49,35% | 88,33% | 98,30% | 100,00% |
Le CPU de la machine est le critère principal de capacité CPU. Le P95 S2.5 est inférieur de 6,47 points à celui de S2. À partir de S3, tous les P95 dépassent 66% et les pics atteignent 100%, indiquant la saturation.
8. Résultats mémoire
Section intitulée « 8. Résultats mémoire »| État | Scénario | Mémoire attribuée EMS Builder, moyenne | Mémoire attribuée EMS Builder, P95 | Mémoire réelle machine, moyenne | Mémoire réelle machine, P95 | Mémoire réelle machine, pic |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 484,14 MB | 529,22 MB | 726,92 MB（74,02%） | 810,83 MB（82,57%） | 825,71 MB（84,08%） |
| 🟡 | S2 | 567,86 MB | 589,11 MB | 788,52 MB（80,30%） | 878,61 MB（89,47%） | 900,03 MB（91,65%） |
| 🟢 | S2.5 | 562,11 MB | 580,93 MB | 785,65 MB（80,01%） | 845,52 MB（86,10%） | 918,53 MB（93,54%） |
| 🔴 | S3 | 573,27 MB | 603,92 MB | 843,22 MB（85,87%） | 930,97 MB（94,80%） | 938,00 MB（95,52%） |
| 🔴 | S3.5 | 560,39 MB | 590,84 MB | 838,25 MB（85,36%） | 902,91 MB（91,95%） | 937,29 MB（95,45%） |
| 🔴 | S6 | 549,24 MB | 608,00 MB | 827,91 MB（84,31%） | 932,14 MB（94,92%） | 939,57 MB（95,68%） |
La mémoire attribuée aux cinq services inclut pages partagées et caches cgroup et n’équivaut pas à une occupation physique nette. La mémoire réelle reflète mieux la capacité restante et sert donc à évaluer les scénarios. Avec seulement 982 MB physiques, l’AFE-E620 atteint déjà 74,02% en moyenne sur S1 : système et Edge-EMS Builder occupent près des trois quarts de la capacité. À partir de S3, le P95 dépasse 91%, laissant moins de 90 MB disponibles : la pression mémoire est forte. L’état initial de la base et le réchauffement des caches varient entre scénarios ; le nombre de points seul ne permet pas de déduire l’évolution mémoire.
9. Débit de traitement
Section intitulée « 9. Débit de traitement »Le débit moyen utilise toute la période valide de 2 000 secondes. Le taux d’atteinte divise le nombre total de tâches par l’objectif total, pour éviter les erreurs d’arrondi des valeurs affichées dans les classeurs.
| État | Scénario | Total Trigger | Moyenne / objectif Trigger | Atteinte Trigger | Total MQTT | Moyenne / objectif MQTT | Atteinte MQTT |
|---|---|---|---|---|---|---|---|
| 🟢 | S1 | 20 000 | 10,00 / 10 | 100,00% | 10 000 | 5,00 / 5 | 100,00% |
| 🟡 | S2 | 78 917 | 39,46 / 40 | 98,65% | 19 752 | 9,88 / 10 | 98,76% |
| 🟢 | S2.5 | 79 924 | 39,96 / 40 | 99,91% | 19 964 | 9,98 / 10 | 99,82% |
| 🔴 | S3 | 77 536 | 38,77 / 90 | 43,08% | 17 860 | 8,93 / 20 | 44,65% |
| 🔴 | S3.5 | 157 134 | 78,57 / 90 | 87,30% | 34 676 | 17,34 / 20 | 86,69% |
| 🔴 | S6 | 57 442 | 28,72 / 150 | 19,15% | 11 508 | 5,75 / 30 | 19,18% |
Le rapport utilise 99% comme référence de débit pour les scénarios recommandés. S2 est légèrement en dessous ; S3, S3.5 et S6 montrent une capacité nettement insuffisante. En surcharge, les files s’accumulent et le nombre de tâches achevées reste très inférieur à l’objectif.
10. Latence Trigger
Section intitulée « 10. Latence Trigger »Les percentiles suivants portent sur toutes les tâches Trigger de la période valide, en millisecondes.
| État | Scénario | Moyenne | P50 | P95 | P99 | Maximum individuel |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 15,57 | 12 | 18 | 30 | 10 237 |
| 🟡 | S2 | 22,98 | 9 | 28 | 61 | 11 012 |
| 🟢 | S2.5 | 17,28 | 9 | 25 | 40 | 10 999 |
| 🔴 | S3 | 70,61 | 17 | 120 | 713,65 | 27 281 |
| 🔴 | S3.5 | 76,65 | 13 | 58 | 170 | 53 472 |
| 🔴 | S6 | 71,90 | 17 | 127 | 610,59 | 24 421 |
Les percentiles usuels sont faibles jusqu’à S2.5, mais tous les scénarios présentent des exécutions extrêmes d’environ 10 à 11 secondes. En surcharge, elles augmentent nettement la moyenne : dans S3.5, 76,65 ms de moyenne dépassent le P95 de 58 ms, avec un P50 de seulement 13 ms. Pour le comportement courant, privilégiez P50 / P95. Ces extrêmes changent peu le P99 mais peuvent affecter certaines commandes ou alarmes et doivent être investigués séparément.
11. Latence MQTT
Section intitulée « 11. Latence MQTT »Les percentiles suivants portent sur toutes les tâches MQTT de la période valide, en millisecondes.
| État | Scénario | Moyenne | P50 | P95 | P99 | Maximum individuel |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 49,65 | 49 | 52 | 56 | 440 |
| 🟡 | S2 | 54,77 | 51 | 64 | 90 | 1 182 |
| 🟢 | S2.5 | 51,80 | 52 | 56 | 64 | 402 |
| 🔴 | S3 | 93,56 | 56 | 249,05 | 944,41 | 2 471 |
| 🔴 | S3.5 | 109,53 | 55 | 95 | 242 | 53 373 |
| 🔴 | S6 | 95,33 | 59 | 201 | 782 | 19 969 |
12. Évaluation des scénarios
Section intitulée « 12. Évaluation des scénarios »| Scénario | Verdict | Principaux éléments |
|---|---|---|
| S1 | Réussi | Atteinte Trigger / MQTT de 100% sous charge de référence ; P95 CPU de 26,83%. Attention à la mémoire moyenne déjà à 74,02%. |
| S2 | Réussi sous conditions | Marge de ressources acceptable, P95 CPU 52,01%, mais atteinte Trigger / MQTT 98,65% / 98,76% légèrement sous 99% et 34 expirations. |
| S2.5 | Recommandé | À 2 000 points/seconde, atteinte Trigger / MQTT 99,91% / 99,82%, P95 de 25 ms / 56 ms, P95 CPU 45,54% ; charge maximale atteignant la référence. |
| S3 | Échec | Atteinte Trigger / MQTT 43,08% / 44,65%, P99 MQTT 944,41 ms, P95 CPU 82,71%, P95 mémoire 94,80% et 617 expirations. |
| S3.5 | Échec | Stockage sur changement nettement meilleur que S3, P95 CPU 66,05% et Trigger 58 ms, mais atteinte 87,30% / 86,69% sous la référence et 96 expirations. |
| S6 | Déconseillé pour toute production | Atteinte 19,15% / 19,18%, P95 CPU 88,33%, P95 mémoire 94,92%, 886 expirations : surcharge sévère. |
13. Recommandations de capacité et de déploiement
Section intitulée « 13. Recommandations de capacité et de déploiement »13.1 Configuration recommandée validée
Section intitulée « 13.1 Configuration recommandée validée »- Acquisition configurée : 2 000 points/seconde.
- Calculs agrégés : 20.
- Trigger ordinaires : 20/seconde.
- Trigger 100 ms : 2, soit 20/seconde.
- Total Trigger : 40/seconde.
- MQTT : 10/seconde.
- Coordination : 2 tâches/seconde.
- Enregistrements des tâches Trigger : conservés.
- Stockage sur changement, avec enregistrement au plus tard toutes les 10 secondes si la valeur reste identique.
13.2 Déploiement en production
Section intitulée « 13.2 Déploiement en production »- Pour une exploitation durable, conservez environ 20% de marge sur cette configuration mesurée et retestez avant mise en service avec scripts Lua, tailles de messages et historique réels.
- Le niveau mémoire de base d’AFE-E620 est élevé, déjà plus de 74% en moyenne dans le scénario de référence S1. Configurez un avertissement CPU à 80%, mémoire à 85% et une alarme mémoire critique à 90%. Surveillez caches PostgreSQL et croissance de la base ; envisagez de réduire le quota mémoire PostgreSQL ou de choisir un modèle plus capacitaire.
- Si le stockage temps réel est obligatoire, référez-vous à S2, dont l’atteinte reste légèrement sous 99%. Sinon, privilégiez le stockage sur changement S2.5.
- S3, à 5 000 points/seconde, et les charges supérieures dépassent la capacité soutenue d’AFE-E620 ; même S3.5 échoue avec stockage sur changement. Choisissez AFE-E630 pour ce besoin.
- S6 est trop surchargé sur E620 pour servir de prévalidation de charge. Pour tester la protection contre la surcharge, utilisez brièvement une charge de l’ordre de S3.
14. Alertes de qualité et essais complémentaires
Section intitulée « 14. Alertes de qualité et essais complémentaires »- Expirations d’échantillonnage : S1 3, S2 34, S2.5 8, S3 617, S3.5 96 et S6 886. En surcharge, la surveillance elle-même ne termine pas à temps ; la fiabilité des mesures de ressources diminue. Le débit et la latence doivent guider l’évaluation.
- Ajouter les versions CommBridge / Edge-EMS Builder / PostgreSQL de la campagne pour compléter l’environnement.
- Réaliser les 72 heures de stabilité complètes en suivant redémarrages, OOM, erreurs, pente mémoire et croissance de la base. Le niveau mémoire élevé d’E620 exige de surveiller toute progression lente.
- Ajouter des compteurs de réussite, échec, expiration et abandon pour acquisition, Trigger, MQTT et coordination.
- Mesurer débit disque, I/O wait, WAL / checkpoint PostgreSQL, pools de connexions et profondeur des files.
- Investiguer les extrêmes Trigger de 10 à 11 secondes et les valeurs d’environ 53 secondes simultanées Trigger/MQTT dans S3.5, en corrélant IDs de tâches, Lua, SQL, GC, I/O et journaux système.
- Enregistrer avant chaque scénario taille de base, configuration PostgreSQL et état des caches pour améliorer la comparabilité mémoire.
15. Limites des données
Section intitulée « 15. Limites des données »- Le nombre de points est une charge configurée, sans comptage des réussites par point. Les données ne prouvent pas indépendamment que chaque point a été écrit avec succès.
- Les configurations métier, nombres d’agrégations, composition Trigger et tâches de coordination, reprennent le manuel ; les classeurs n’enregistrent pas les détails par scénario.
- Les classeurs ne contiennent pas de taux d’erreur métier, d’état de résultat ou d’exactitude. Un débit atteint ne signifie pas 100% de résultats métier corrects.
- Chaque scénario dure environ 33 minutes 20 secondes et permet une comparaison de performances, sans remplacer une stabilité longue durée.
- Les versions logicielles n’ont pas été enregistrées avec les classeurs ; la correspondance entre résultats et versions reste à confirmer après ajout.
- S2.5 est la charge testée maximale de cette campagne atteignant 99%. La marge de 20% est une recommandation de dimensionnement, pas une mesure indépendante.
Autre modèle : Rapport AFE-E630.