Chapitre 07
Diagnostiquer Profinet

Objectifs du chapitre

Comprendre le contrat temps réel d'un échange Profinet : temps de cycle (update time), watchdog, connexion applicative (AR).
Mesurer depuis une capture le temps de cycle réel, le jitter et les trames perdues — deltas d'inter-arrivée et CycleCounter.
Lire l'état de l'échange : bits du DataStatus (provider/consumer, DataValid, StationProblem).
Reconnaître dans la capture la signature d'une station qui décroche : arrêt du cyclique → alarme → tentative de reconnexion, et savoir sur quelles couches boucler ensuite.

1. Le contrat temps réel

Au chapitre 6, on a disséqué une trame Profinet RT : Ethertype 0x8892, Frame ID, données cycliques, puis le trailer APDU-Status. Ici, on ne regarde plus une trame isolée mais le flux : est-ce que l'échange respecte son contrat ?

Ce contrat est simple. À la mise en route, le CPU (cpu1500, 192.168.0.1) établit avec chaque IO-device une connexion applicative, l'AR (Application Relation). Dans cette AR, chacun s'engage à envoyer sa trame cyclique à intervalle fixe — l'update time, configuré dans TIA (typiquement 1 ms, parfois 250 µs ou 4 ms selon la charge). Les deux sens comptent : le device est provider de ses entrées et consumer des sorties ; le CPU, l'inverse.

Si les trames attendues n'arrivent plus, un watchdog se déclenche. Sa valeur par défaut est de 3 cycles manqués : passé ce délai, le consumer déclare le provider absent, l'AR est déclarée perdue, et côté CPU cela remonte comme une défaillance de station. Diagnostiquer Profinet, c'est donc vérifier deux choses sur le fil : la régularité des cycles et l'absence de perte.

Le watchdog vaut par défaut 3 × l'update time (« Accepted update cycles without IO data » dans TIA Portal). À 1 ms, il suffit donc de 3 ms sans trame pour que le CPU déclare la station en défaut et lève une alarme de « défaillance de station » (station failure) dans son tampon de diagnostic. C'est court : un micro-défaut de câble suffit. Le shell, lui, mesure ces millisecondes sur le fil.

2. Mesurer le temps de cycle depuis une capture

La méthode ne varie jamais : on isole le cyclique d'un seul device — par sa MAC source et le filtre pn_rt — puis on regarde le temps qui sépare deux trames consécutives. Prenons et200sp-1 (MAC 00:1b:1b:2a:10:20). D'abord on capture le flux Profinet brut (Ethertype 0x8892), puis on relit hors-ligne :

sudo tshark -i eth0 -f 'ether proto 0x8892' -w pn.pcap
tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' \
       -T fields -e frame.time_delta_displayed -e pn_rt.cycle_counter

Le champ frame.time_delta_displayed donne l'écart de temps avec la trame précédente du même affichage filtré — donc, comme on a filtré sur une seule MAC source, l'écart entre deux trames cycliques de ce device. C'est la mesure directe du temps de cycle. Sur un échange sain à 1 ms :

# deltas (s) et cycle_counter — échange sain à 1 ms
0.001004   12480
0.000998   12512
0.001001   12544
0.000999   12576
0.001003   12608
0.000997   12640

Les deltas oscillent autour de 0,001 s — un métronome. Le cycle_counter progresse d'un pas régulier (ici +32, on y revient au §3). Maintenant, un échange qui hoquette :

# même device, mais un trou
0.001002   13120
0.000999   13152
0.004013   13248
0.001001   13280
0.000998   13312

Le delta de 0,004 s saute aux yeux : quatre fois le cycle. Trois trames ont manqué sur le fil (le device aurait dû émettre à +1, +2 et +3 ms). On le confirme au compteur : il bondit de 13152 à 13248, soit +96 au lieu de +32 — trois pas d'un coup. À 1 ms, un tel trou frôle déjà le seuil du watchdog : une ou deux trames de plus, et l'AR tombait.

Le jitter, c'est précisément la dispersion de ces deltas autour de la consigne. Un échange sain a un jitter de quelques microsecondes ; un jitter qui grimpe (deltas qui varient de 0,8 à 1,3 ms sans trame perdue) trahit un problème de transport — un port saturé, un switch qui peine, ou pire, un lien tombé en half-duplex (§piège).

Le delta d'inter-arrivée d'un device filtré sur sa MAC, c'est son temps de cycle réel, mesuré sur le fil. Tu n'as pas besoin de connaître la config TIA pour le trouver : capture, filtre, lis la colonne. Si le delta médian vaut 1 ms, l'update time est à 1 ms. La capture ne ment pas ; l'ingénierie, parfois.

Un seul one-liner pour sortir cycle moyen, min et max d'un device — pratique pour juger la régularité d'un coup :

$ tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' \
      -T fields -e frame.time_delta_displayed \
    | awk 'NR>1{n++;s+=$1;if($1>mx)mx=$1;if(mn==""||$1<mn)mn=$1}
           END{printf "cycle moyen=%.4f ms  min=%.4f  max=%.4f  (n=%d)\n",s/n*1000,mn*1000,mx*1000,n}'
cycle moyen=1.0010 ms  min=0.9970  max=4.0130  (n=4192)

Le max très supérieur à la moyenne pointe le trou. On saute la première ligne (NR>1) car son delta n'a pas de trame précédente.

3. Le CycleCounter : compter les trames perdues

Le delta de temps te dit qu'il manque des trames ; le CycleCounter te dit combien, sans ambiguïté. Ce compteur voyage dans l'APDU-Status de chaque trame RT (chapitre 6). Il s'incrémente d'un pas fixe à chaque cycle, en unités de 1/32 de milliseconde — soit 31,25 µs. À un update time de 1 ms, le pas normal est donc de 32 (1 ms ÷ 31,25 µs). Il est codé sur 16 bits : il boucle de 65535 à 0, ce dont il faut tenir compte au calcul.

La règle est limpide : entre deux trames consécutives d'un même provider, le compteur augmente du pas nominal. Un saut supérieur au pas = des trames perdues sur le fil. Le nombre de trames manquées vaut :

trames_perdues = (Δcompteur / pas_nominal) − 1

Reprenons la séquence hoquetante du §2 et calculons les écarts du compteur avec awk :

$ tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' \
      -T fields -e pn_rt.cycle_counter \
    | awk 'NR>1{d=$1-p; if(d<0)d+=65536; if(d!=32) printf "saut de %d (=%d cycles) apres cc=%d\n",d,d/32,p} {p=$1}'
saut de 96 (=3 cycles) apres cc=13152

Un seul saut détecté : +96, soit 3 cycles au lieu d'1 → 2 trames perdues entre les deux trames vues (la 3ᵉ est celle qu'on a reçue). Le if(d<0)d+=65536 gère le rebouclage du compteur 16 bits. Additionne tous les sauts sur une capture longue et tu obtiens le total de trames perdues sur l'intervalle — une métrique de santé bien plus parlante qu'un ressenti « ça rame ».

Deux compteurs à ne pas confondre. Le CycleCounter est une horloge : il avance du temps écoulé (pas de 32 à 1 ms), donc un saut mesure des trames manquées. Le champ DataStatus, lui, porte des bits d'état (§4), pas un décompte. Le premier dit « combien j'en ai raté », le second « est-ce que ce que je reçois est valable ».

4. Le DataStatus : provider, consumer, validité

Chaque trame RT porte un octet DataStatus (dans l'APDU-Status) qui résume l'état de l'émetteur. tshark le décode ; on lit soit l'octet brut, soit le détail avec -V :

# l'octet brut, trame par trame
tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' \
       -T fields -e frame.number -e pn_rt.data_status

# le détail bit à bit d'une trame
tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' -V | grep -A8 'DataStatus'

Les bits qui comptent pour le diagnostic :

Bit	Nom	Sain	Ce qu'il signale sinon
0	State (Run/Stop)	1 = Run	0 = le provider (CPU ou device) est à l'arrêt
1	Redundancy	0/1	rôle dans un couple redondant (S2/R1)
2	DataValid	1 = valide	0 = données non valables — le provider ne garantit plus ses données
4	ProviderState	1 = Primary	0 = Backup — cette trame n'est pas la source active
5	StationProblem	0 = OK	1 = problème — un module/sous-module du device est en défaut

Deux réflexes. Un DataValid=0 dit que le provider a lui-même déclaré ses données inexploitables (module manquant, sous-module non prêt) — le consumer les ignorera. Un StationProblem=1 (aussi appelé le bit d'état de station, ou Ident) est le signal « regarde mon diagnostic » : le device signale qu'un de ses modules a un souci, et il émettra une alarme (§5) pour dire lequel. Sur l'échange sain, on lit typiquement un DataStatus à 0x35 (Run + DataValid + Primary, StationProblem à 0). Dès que le bit 5 passe à 1, la valeur change et le device est sur le point de lever une alarme — ou vient de le faire.

Tu n'as pas besoin de mémoriser l'octet. Filtre directement sur le bit décodé : par exemple -Y 'pn_rt.data_status.station_problem == 1' ne te sort que les trames où une station crie au secours, ou -Y 'pn_rt.data_status.data_valid == 0' pour les données réputées mauvaises. C'est le moyen le plus rapide de savoir « qui va mal » dans une grosse capture.

5. Détecter une station qui décroche

C'est le scénario roi de ce chapitre. Une station perd le contact — câble qui bouge, module qui grille, alimentation qui fléchit — et il faut le lire dans la capture. La séquence a une signature reconnaissable, toujours la même :

Le cyclique du device s'arrête : plus de trames pn_rt de sa MAC (ou DataStatus qui bascule juste avant).
Une ou plusieurs trames d'alarme (pn_alarm) partent : « module retiré », « port en défaut », « diagnostic apparu ».
Le watchdog du CPU expire (3 cycles) et la station est déclarée en défaut.
Le CPU tente de rétablir l'AR : un nouveau DCP identify multicast pour retrouver le device par son nom, puis un Connect pour rouvrir la connexion (exactement le mécanisme du chapitre 6).

Figure 7.1. La signature d'un décrochage sur l'axe du temps. Le cyclique régulier (teal) s'interrompt : c'est le trou. Passé le watchdog, une alarme (ambre) part, puis le CPU relance un DCP identify + Connect (vert) pour retrouver et reconnecter le device. Retrouver cette forme dans une capture, c'est diagnostiquer un décrochage.

Pour lire la séquence, on ne filtre plus une MAC mais on trie par le temps et on regarde les trois familles ensemble. Les alarmes d'abord :

$ tshark -r pn.pcap -Y pn_alarm \
      -T fields -e frame.time_relative -e eth.src -e pn_alarm.alarm_type
2.418500   00:1b:1b:2a:10:20   0x0002   # diagnosis appears — et200sp-1
2.418700   00:1b:1b:2a:10:20   0x0006   # module pulled / removed

On voit et200sp-1 lever une alarme « module retiré » à t=2,4188 s. On zoome alors sur la fenêtre autour de cet instant, toutes familles Profinet confondues, pour reconstituer l'histoire :

$ tshark -r pn.pcap -Y 'frame.time_relative > 2.41 && frame.time_relative < 2.60' \
      -T fields -e frame.time_relative -e eth.src -e _ws.col.Protocol -e _ws.col.Info
2.415000  00:1b:1b:2a:10:20  PNIO   RTC1, Len:40  # derniere trame cyclique du device
2.418500  00:1b:1b:2a:10:20  PNIO   Alarm, DiagnosisAppears
2.418700  00:1b:1b:2a:10:20  PNIO   Alarm, ModulePulled
2.421000  00:1b:1b:2a:10:01  PNIO   ... plus aucune trame RT de .20
2.540000  00:1b:1b:2a:10:01  PN-DCP Ident Req "et200sp-1"  # le CPU cherche le device
2.560000  00:1b:1b:2a:10:20  PN-DCP Ident Ok                # il repond → Connect suit

Tout y est : la dernière trame cyclique à 2,415 s, l'alarme à 2,4185 s, le silence du device, puis à 2,54 s le CPU (00:1b:1b:2a:10:01) qui relance un DCP Ident Req ciblant le nom « et200sp-1 », auquel le device finit par répondre. La reconnexion s'enchaîne (Connect, cf. chapitre 6). Tu viens de diagnostiquer un décrochage sans jamais ouvrir TIA.

Un jitter qui explose ou des trames perdues par rafales, sans que le device tombe vraiment, trahit souvent un problème de couche basse : un lien qui a négocié en 100 Mbit half-duplex au lieu de full. En half-duplex, les collisions et le CSMA/CD retardent les trames de façon erratique — le temps réel Profinet ne le supporte pas. Ne reste pas bloqué sur Profinet : boucle sur le chapitre 2 (ethtool) et vérifie duplex, débit et compteurs d'erreurs FCS/CRC du port. La cause d'un « problème Profinet » est très souvent en L1/L2.

6. Statistiques rapides

Avant de plonger trame par trame, deux vues d'ensemble te disent en une commande où regarder. D'abord, le débit de trames RT par seconde : un échange sain est parfaitement plat (autant de trames chaque seconde) ; un décrochage creuse un trou visible :

$ tshark -r pn.pcap -q -z io,stat,1,pn_rt
=================================================
| IO Statistics                                 |
| Interval: 1 s   |   Filter: pn_rt             |
|-----------------|-----------------------------|
| Interval        |            pn_rt   Frames   |
|-----------------|-----------------------------|
|   0 <> 1        |                     4000    |
|   1 <> 2        |                     4000    |
|   2 <> 3        |            3120    # ← le trou : ~880 trames en moins |
|   3 <> 4        |                     3000    # .20 muet, l'AR pas encore reprise |
|   4 <> 5        |                     4000    # reconnecte |
=================================================

La seconde 2→3 pique du nez : c'est là que le device a décroché. On sait maintenant quand zoomer (§5). Ensuite, qui parle à qui — les conversations Ethernet :

$ tshark -r pn.pcap -q -z conv,eth
================================================================================
Ethernet Conversations
                                       |  Frames  |   Bytes  |
00:1b:1b:2a:10:01 <-> 00:1b:1b:2a:10:20   15980    1.2 MB   # cpu1500 ↔ et200sp-1
00:1b:1b:2a:10:01 <-> 00:1b:1b:2a:10:21   19998    1.5 MB   # cpu1500 ↔ et200sp-2 (intact)
================================================================================

Les deux stations devraient afficher un nombre de trames quasi identique. et200sp-1 (.20) en a nettement moins que et200sp-2 (.21) : c'est bien .20 qui a perdu des trames. En un coup d'œil, on a isolé la station coupable et confirmé que sa voisine, elle, est saine.

Un device qui ne se connecte jamais (aucune trame cyclique dès le départ, jamais d'AR) n'est pas forcément en panne : c'est souvent un nom de station erroné (name mismatch). Le CPU cherche « et200sp-1 » par DCP, mais le device s'appelle autrement (ou rien) → il ne le reconnaît pas et ne le connecte pas. Vérifie le nom réel du device par DCP (chapitre 3, pnio-dcp) et compare-le à celui attendu dans le projet. « Il est bien branché mais absent du réseau » = suspecte le nom avant le matériel.

Récapitulatif

Profinet est un contrat temps réel : chaque device échange à l'update time ; 3 cycles manqués (watchdog) → l'AR est perdue et le CPU déclare une défaillance de station.
Temps de cycle mesuré = delta d'inter-arrivée d'un device filtré sur sa MAC (frame.time_delta_displayed). Un delta ≈ 4× le cycle = 3 trames sautées ; le jitter est la dispersion des deltas.
Le CycleCounter avance d'un pas fixe (32 unités de 1/32 ms à 1 ms) : un saut = trames perdues, (Δcompteur/pas)−1, en gérant le rebouclage 16 bits.
Le DataStatus porte les bits d'état : DataValid=0 ou StationProblem=1 signalent un problème provider côté device ; on filtre directement sur le bit décodé.
Signature d'un décrochage : cyclique qui s'arrête → pn_alarm → DCP identify + Connect. Vues d'ensemble : -z io,stat,1,pn_rt (le trou), -z conv,eth (la station coupable).
Un « problème Profinet » vient souvent d'en dessous : boucle sur L1/L2 (half-duplex, FCS/CRC, chapitre 2) et sur le nom de station (chapitre 3) avant de conclure.

Exercices

Exercice 1 — Temps de cycle, jitter, trames sautées

On t'a fourni les deltas d'inter-arrivée (en secondes) du device et200sp-2 (00:1b:1b:2a:10:21), extraits d'une capture : 0.000998, 0.001003, 0.001001, 0.002015, 0.000999, 0.001002. Quel est l'update time configuré ? Y a-t-il des trames perdues, et combien ? Le jitter te paraît-il inquiétant ? Écris la commande qui aurait produit ces deltas.

Voir la solution

Cinq deltas sur six tournent autour de 0,001 s → l'update time est de 1 ms. Le delta isolé de 0.002015 vaut ≈ 2× le cycle : une trame a été sautée à cet instant (2 cycles écoulés = 1 trame manquée). Le jitter sur les cycles sains va de 0,998 à 1,003 ms, soit ±5 µs : négligeable, rien d'inquiétant côté transport — c'est une perte ponctuelle, pas une dégradation continue. La commande d'extraction :

$ tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:21' \
      -T fields -e frame.time_delta_displayed

Si tu veux confirmer sans compter à la main, ajoute -e pn_rt.cycle_counter : le pas passerait de 32 à 64 sur la trame en défaut.

Exercice 2 — Suivre le CycleCounter et compter les pertes

Sur un intervalle, le cycle_counter de et200sp-1 a pris successivement les valeurs : 65472, 65504, 28, 60, 156, 188. L'update time est 1 ms (pas nominal = 32). Combien de trames ont été perdues au total ? Attention au rebouclage. Écris un awk qui compte automatiquement les trames perdues sur toute une capture.

Voir la solution

On calcule chaque écart, en corrigeant le rebouclage 16 bits (+65536 si négatif) :

65504 − 65472 = 32 → 1 cycle, RAS.
28 − 65504 = −65476, +65536 = 60 → pas 32 ! 60/32 ≈ presque 2 cycles. En fait le compteur avance du temps réel écoulé ; 60 ≈ 2×32 moins le passage de boucle — arrondi, cela vaut 2 cycles, soit 1 trame perdue.
60 − 28 = 32 → RAS.
156 − 60 = 96 = 3 cycles → 2 trames perdues.
188 − 156 = 32 → RAS.

Total : 3 trames perdues sur l'intervalle. Le passage à zéro (65504 → 28) n'est pas une perte en soi — c'est le rebouclage normal du compteur, qu'il faut corriger sous peine de compter un saut géant. Le script généralisé :

$ tshark -r pn.pcap -Y 'pn_rt && eth.src==00:1b:1b:2a:10:20' \
      -T fields -e pn_rt.cycle_counter \
    | awk 'NR>1{d=$1-p; if(d<0)d+=65536; lost+=(d/32)-1}
           {p=$1} END{printf "trames perdues (total) = %d\n", lost}'
trames perdues (total) = 3

On somme (d/32)−1 à chaque pas : 0 quand le cycle est nominal, positif dès qu'il y a un saut. Sur une capture réelle, ce chiffre unique est un excellent indicateur de santé.

Exercice 3 — Reconstituer un décrochage

Une capture pn.pcap couvre une ligne qui « s'est arrêtée » vers la 12ᵉ seconde. Reconstitue la chronologie de l'incident : repère la station qui décroche, l'instant de l'arrêt cyclique, l'alarme émise, et la tentative de reconnexion du CPU. Puis dis quelles couches tu vérifierais ensuite pour trouver la cause racine.

Voir la solution

1) Localiser le trou et la station. Une vue d'ensemble situe l'instant, une conversation désigne le coupable :

$ tshark -r pn.pcap -q -z io,stat,1,pn_rt   # trou à l'intervalle 12→13
$ tshark -r pn.pcap -q -z conv,eth          # .20 a bien moins de trames que .21

2) Zoomer sur la fenêtre, toutes familles Profinet, triées par le temps :

$ tshark -r pn.pcap -Y 'frame.time_relative > 11.9 && frame.time_relative < 12.8' \
      -T fields -e frame.time_relative -e eth.src -e _ws.col.Info
11.980  00:1b:1b:2a:10:20  RTC1 ...            # derniere trame cyclique de .20
11.984  00:1b:1b:2a:10:20  Alarm, ModulePulled # l'alarme
12.100  00:1b:1b:2a:10:01  PN-DCP Ident "et200sp-1"  # le CPU cherche
12.140  00:1b:1b:2a:10:20  PN-DCP Ident Ok     # reprise de l'AR

Chronologie : et200sp-1 (.20) émet sa dernière trame cyclique à 11,980 s, lève une alarme « module retiré » 4 ms plus tard (au-delà du watchdog), reste muet, puis le CPU relance un DCP identify sur son nom à 12,100 s et le reconnecte.

3) Couches à vérifier ensuite. L'alarme « module retiré » oriente vers le matériel du device (un module mal enclenché, une alim). Mais avant de conclure, on boucle sur les couches basses : L1/L2 avec ethtool sur le port concerné (duplex, débit, compteurs FCS/CRC — chapitre 2) pour écarter un lien half-duplex ou un câble douteux, et on confirme que le nom de station est correct (chapitre 3) au cas où le device rejoue mal sa reconnexion. Si tout est propre en L1/L2, la cause est bien l'événement matériel signalé par l'alarme.

Chapitre 07Diagnostiquer Profinet

Objectifs du chapitre

1. Le contrat temps réel

2. Mesurer le temps de cycle depuis une capture

3. Le CycleCounter : compter les trames perdues

4. Le DataStatus : provider, consumer, validité

5. Détecter une station qui décroche

6. Statistiques rapides

Récapitulatif

Exercices

Exercice 1 — Temps de cycle, jitter, trames sautées

Exercice 2 — Suivre le CycleCounter et compter les pertes

Exercice 3 — Reconstituer un décrochage

Chapitre 07
Diagnostiquer Profinet