Schneider crée la surprise en rejoignant l’ODVA. De quoi marier Modbus/TCP aux spécifications CIP Network.
La foire de Hanovre reste décidément un lieu incontournable, même si elle a de sérieux concurrents, elle sait toujours réserver des surprises. Parmi les annonces des années antérieures nous avions eu : Phœnix Contact rejoignant la mouvance ProfiNet et renonçant à un développement de type InterbusNet ; les rapprochements vers AS-Interface de Siemens et Schneider ; les créations de SateyNet, Powerlink, Ethercat, Sercos … Hannover Messe reste un lieu où les stratégies en matière de réseaux de communication se font, et se défont.
Pour cette édition 2007, c’est Schneider qui crée la surprise en rejoignant l’ODVA. De quoi marier Modbus/TCP aux spécifications CIP Network. Après des années de confrontations et avec la transformation d’un protocole âgé de plus vingt ans (Modbus) hérité du rachat de Modicon en un protocole sur Ethernet parmi le plus utilisé dans le monde, voici une nouvelle page qui se tourne.
Les stratégies s’affinent
Autour d’Ethernet industriel, pour Siemens et Phœnix Contact ce sera Profinet, et pour Schneider, Rockwell Automation et Omron ce sera CIP avec Ethernet/IP et Modbus/TCP. Il ne reste plus qu’à attendre une clarification des protocoles Ethernet temps réel, ce sera sans nul doute à Hannover Messe édition 20xx.
Ce ralliement de Schneider ne correspond pas à un abaissement de la « garde » de l’offreur. L’ODVA avait pour volonté d’élargir les spécifications CIP Network pour assurer la compatibilité des dispositifs Modbus/TCP avec les réseaux établis sur la base du Common Industrial Protocol (CIP). Avec ce rapprochement avec Schneider, plus aucune barrière ne viendra bloquer les développements de l’ODVA.
Cet élargissement permettra aux utilisateurs existants de Modbus/TCP de se connecter au réseau CIP tout en conservant leur investissement existant en automatisation. Ils bénéficieront ainsi d’une interopérabilité entre les bases installées des réseaux Ethernet industriels EtherNet/IP et Modbus/TCP, ainsi qu’une offre de produits connectables plus conséquente. Dans l’opération, les utilisateurs pourront même profiter des versions Safety ou Motion de CIP, une économie non négligeable.
Interrogé sur les frontières de cet accord, André Bourachaki, Connectivity & Product Support de Schneider reste très explicite. Cet accord ne concerne que la partie Ethernet, « nous étions convaincus que l’avenir était à Ethernet, nous en sommes aujourd’hui encore plus convaincu ».
Alors pourquoi ce virage maintenant, Modbus était-il arrivé à un virage de sa carrière ? Lors de sa conférence de presse l’ODVA a clairement montré que l’association était très satisfaite de trouver un accord avec Modbus/TCP et Schneider. Ce dernier se trouvant dans le staff de décision aux côtés de Cisco, Omron ou Rockwell Automation.
Encore quelques années de patience
Concrètement, les utilisateurs devront attendre 2008 pour voir la convergence de Modbus/TCP et d’Ethernet/IP. Dans un an, l’utilisateur pourra rajouter une carte Ethernet/IP dans son automate programme Schneider de façon contiguë à la carte Modbus/TCP, et les deux dialogueront ensemble. C’est en 2009 qu’une seule et même carte de communication intègrera à la fois Ethenet/IP et Modbus/TCP, rendant transparent les deux protocoles.
Bien entendu, un tel choix n’est intéressant que si l’utilisateur veut pouvoir mixer des produits de fournisseurs concurrents, car dès l’année prochaine (en utilisant deux cartes ou 2009 avec une seule) il deviendra possible de rajouter dans une architecture n’importe quel appareil utilisant Ethernet/IP. Et c’est à ce moment-là que Schneider va pouvoir profiter de cette ouverture, notamment sur le marché américain et encore plus asiatique, car n’oublions pas que c’est également Ethernet/IP qui a été choisi par Omron et Rockwell Automation. Ce ralliement avec l’ODVA « c’est la meilleure façon pour nous de pouvoir continuer le leadership qu’a déjà Modbus/TCP » précise André Bourachaki.
L’utilisateur qui aura fait le choix d’équipements Modbus/TCP deviendra compatible avec les services IP de demain, et pourra se connecter aux équipements Rockwell ou Omron. Bien entendu, l’inverse sera vrai, si les offreurs concurrents de Schneider souhaitent s’interconnecter avec le monde Modbus/TCP, la possibilité leur sera offerte, d’autant plus que la croissance des ventes Ethernet est largement en deça des 30%, on parle de 35 à 40% de progression par an du côté de Schneider.
Hors Ethernet, pas de changement
Nous avons profité de l’annonce officielle de l’ODVA pour nous interroger sur le devenir des autres bus de terrain, vu du côté Schneider et notamment de CompoNet utilisant CIP, le concurrent direct d’AS-Interface utilisé par Schneider depuis des années, ou du choix de CanOpen fait par Schneider face à DeviceNet, ce dernier utilisant CIP. Pour la firme française, la réponse est très claire, cet accord ne vise que le monde Ethernet qui reste la stratégie d’avenir, aucun changement en ce qui concerne CanOpen ou AS-Interface ne semble envisagé pour l’instant.
Encadré
Les forces en présence
EtherNet/IP et Modbus/TCP seraient les deux protocoles Ethernet industriel les plus populaires, représentant plus de 50 pour cent de parts de marché dans le monde, selon l’étude la plus récente de l’ARC Advisory Group. « Il s’agit là d’un développement important dans l’industrie d’automatisation » constate Harry Forbes, Senior Analyst auprès de l’ARC Advisory Group. « C’est quelque chose d’inhabituel de voir que plusieurs « géants » de l’automatisation établissent une aussi étroite collaboration notamment dans un domaine stratégique tel que l’Ethernet industriel ».
Après Rockwell à l’origine de DeviceNet et de ControlNet, puis l’apport d’Omron avec dans ses bagages les bases de CompoNet et maintenant Schneider avec Modbus/TCP, la famille ODVA s’agrandit et risque bien de faire bouger quelques lignes. Petit rappel des forces en présence.
CIP
Une photo à scanner
CIP est une technologie orientée objet couvrant les couches Session, Présentation et Application du modèle OSI. Pour l’utilisateur, cela se traduit par une transparence du type de réseau utilisé. Les développeurs d’application n’ont même pas à se soucier de la nature de réseau sur lequel sont connectés les équipements qu’ils programment. CIP définit également des profils d’équipements standards, qui identifient les objets, options de configuration et formats de données d’E/S pour différents types d’équipements. Les équipements possédant le même profil standard répondront aux mêmes commandes, et auront le même comportement sur le réseau.
Un autre élément caractéristique important des réseaux basés sur CIP est leur capacité à générer des messages à partir d’un réseau, puis à les transmettre vers un autre réseau de façon transparente. Cela signifie qu’un ensemble d’objets inclus dans la spécification de CIP défini les mécanismes peuvent être utilisés par un équipement de routage ou une passerelle pour pouvoir transmettre un message d’un port réseau vers un autre sans avoir besoin d’agir sur le contenu du message lui-même. L’un de ses éléments distinctifs est sa capacité à atteindre de grandes vitesses pour la transmission de données de contrôle d’entrées-sorties, tout en restant capable d’échanger des messages explicites avec les couches de niveaux supérieurs.
Parmi les dernières évolutions de la technologie on trouve CompoNet, annoncé à la fin d’année 2005 par l’ODVA. CompoNet, c’est une nouvelle technologie de bus de terrain de niveau capteurs/actionneurs. Celle-ci permettra la transmission rapide de paquets de données de faibles tailles entre contrôleurs, capteurs et actionneurs, au travers d’un media physique économique. Destiné aux applications requérant la mise en œuvre d’un grand nombre de capteurs et d’actionneurs distribués, telles que machines d’assemblage ou systèmes de convoyage, ce bus de terrain entrera en concurrence directe avec AS-Interface. CompoNet s’appuiera sur la même pile protocolaire CIP. Lors de son annonce, l’ODVA a dévoilé que ce bus de terrain serait basé sur une technologie développée à l’origine par l’un des membres fondateurs de l’association, qui n’est autre qu’Omron. Ce dernier a d’ores et déjà accordé les droits nécessaires à l’ODVA pour la réalisation de l’adaptation de sa technologie.
Autre évolution, la sécurité avec CIP Safety. Publiés en janvier 2005, les spécifications de CIP Safety décrivent les extensions fonctionnelles apportées au protocole CIP pour les applications de sécurité. CIP Safety est destiné à des applications de sécurité de niveau SIL 3, suivant le standard IEC 61508. Il a été, à ce titre, approuvé par le TUV Rheinland.
A la fin de la même année, Rockwell a annoncé à l’occasion d’Automation Fair de Saint-Louis, la possibilité de combiner les standards de communication CIP et Ethernet, pour la réalisation d’applications de « Motion Control » distribuées. Cette approche, baptisée CIP Motion, est une solution de contrôle d’axes distribués offrant des possibilités de connectivité controller-to-controller ou controller-to-drive. Elle met en œuvre le mécanisme de synchronisation CIP Sync, basé sur le standard IEEE 1588, qui assure un niveau de précision de la synchronisation des horloges permettant de répondre aux besoins des applications de « Motion Control ».
Modbus/TCP
Modbus/TCP est la variante « encapsulée » dans TCP/IP du protocole Modbus, introduit en 1979 par la société Modicon. Aujourd’hui standard géré par l’organisation Modbus IDA, Modbus/TCP a récemment été approuvé par l’IEC en tant que spécification ouverte au public.
Le protocole Modbus Série est populaire depuis longtemps dans le monde des automatismes. Plus d’un million de produits Modbus sur liaison série ont été installés à ce jour dans le monde, et de nombreuses passerelles avec les diverses variantes d’Ethernet existent. Il faut ajouter le fait que les spécifications de Modbus/TCP sont téléchargeables gratuitement sur Internet, et qu’il existe un grand nombre d’implémentations open source du protocole.
Basé sur un mode de communication client/serveur, le fonctionnement du service de messagerie Modbus TCP permet d’échanger des informations en temps réel entre différents produits d’automatismes sur Ethernet TCP/IP. Il convient de préciser que la notion de temps réel est ici entendue au sens « mou », car si avec des temps de réponse variant entre 0.2 et 1 seconde, Modbus TCP couvre une grande partie des besoins, notamment pour des applications où l’information est centralisée (entrées/sorties déportées), il ne constitue pas une solution idéale pour des applications d’automatismes distribués nécessitant des temps de réponse beaucoup plus faibles (jusqu’à quelques micro-secondes dans le cas du contrôle de mouvements). Notons toutefois qu’il existe des manières d’améliorer les performances de Modbus TCP, mais demain avec CIP Motion, ce problème sera résolvable.
Un système de communication basé sur Modbus TCP/IP peut mettre en jeu différents types d’équipements : des clients et des serveurs Modbus TCP/IP, bien entendu, mais également du matériel d’interconnexion (ponts, routeurs ou passerelles) assurant le lien entre le réseau TCP/IP et une ou plusieurs liaisons Modbus Série, sur lesquelles sont connectés différents terminaux Modbus.
Le protocole Modbus définit une « unité de données de protocole », ou PDU pour Protocol Data Unit, indépendante des couches de communication sous-jacentes. Le mapping du protocole Modbus sur des bus spécifiques ou des réseaux peut introduire des champs supplémentaires au niveau de l’unité de donnée d’application, ou ADU pour Application Data Unit. C’est le client qui initie la transaction Modbus qui construit l’ADU. Le champ Function Code du PDU indique au serveur le type d’action à mener.
Dans le cas d’un mapping sur TCP/IP, une entête spécifique baptisée « MBAP Header » est utilisée pour identifier l’ADU Modbus. Cette entête possède quelques spécificités qui permettent de différencier l’ADU Modbus TCP/IP de l’ADU Modbus RTU, utilisée en liaison série. L’adresse esclave traditionnellement utilisée avec Modbus Série est remplacée par un octet baptisé « Unit Identifier ». Celui-ci permet la communication au travers de ponts, de routeurs ou de passerelles utilisant une adresse IP unique pour supporter plusieurs terminaux Modbus indépendants.
Toute demande ou réponse Modbus est conçue de façon à ce que le récepteur soit en mesure de vérifier que le message est bien terminé. Dans le cas de PDU de longueur fixe, le champ Function Code apporte toutes les informations nécessaires. Ce n’est pas le cas, en revanche, lorsque le PDU transporte une quantité variable de données. Dans ce cas, le champ réservé aux données inclut un compteur d’octets. Par ailleurs, des informations supplémentaires concernant la longueur des messages sont incluses dans l’entête MBAP pour permettre au récepteur de reconnaître les limites des messages, lorsque ceux-ci ont été découpés en plusieurs morceaux pour la transmission.
j52p24La foire de Hanovre reste décidément un lieu incontournable, même si elle a de sérieux concurrents, elle sait toujours réserver des surprises. Parmi les annonces des années antérieures nous avions eu : Phœnix Contact rejoignant la mouvance ProfiNet et renonçant à un développement de type InterbusNet ; les rapprochements vers AS-Interface de Siemens et Schneider ; les créations de SateyNet, Powerlink, Ethercat, Sercos … Hannover Messe reste un lieu où les stratégies en matière de réseaux de communication se font, et se défont.
Pour cette édition 2007, c’est Schneider qui crée la surprise en rejoignant l’ODVA. De quoi marier Modbus/TCP aux spécifications CIP Network. Après des années de confrontations et avec la transformation d’un protocole âgé de plus vingt ans (Modbus) hérité du rachat de Modicon en un protocole sur Ethernet parmi le plus utilisé dans le monde, voici une nouvelle page qui se tourne.
Les stratégies s’affinent
Autour d’Ethernet industriel, pour Siemens et Phœnix Contact ce sera Profinet, et pour Schneider, Rockwell Automation et Omron ce sera CIP avec Ethernet/IP et Modbus/TCP. Il ne reste plus qu’à attendre une clarification des protocoles Ethernet temps réel, ce sera sans nul doute à Hannover Messe édition 20xx.
Ce ralliement de Schneider ne correspond pas à un abaissement de la « garde » de l’offreur. L’ODVA avait pour volonté d’élargir les spécifications CIP Network pour assurer la compatibilité des dispositifs Modbus/TCP avec les réseaux établis sur la base du Common Industrial Protocol (CIP). Avec ce rapprochement avec Schneider, plus aucune barrière ne viendra bloquer les développements de l’ODVA.
Cet élargissement permettra aux utilisateurs existants de Modbus/TCP de se connecter au réseau CIP tout en conservant leur investissement existant en automatisation. Ils bénéficieront ainsi d’une interopérabilité entre les bases installées des réseaux Ethernet industriels EtherNet/IP et Modbus/TCP, ainsi qu’une offre de produits connectables plus conséquente. Dans l’opération, les utilisateurs pourront même profiter des versions Safety ou Motion de CIP, une économie non négligeable.
Interrogé sur les frontières de cet accord, André Bourachaki, Connectivity & Product Support de Schneider reste très explicite. Cet accord ne concerne que la partie Ethernet, « nous étions convaincus que l’avenir était à Ethernet, nous en sommes aujourd’hui encore plus convaincu ».
Alors pourquoi ce virage maintenant, Modbus était-il arrivé à un virage de sa carrière ? Lors de sa conférence de presse l’ODVA a clairement montré que l’association était très satisfaite de trouver un accord avec Modbus/TCP et Schneider. Ce dernier se trouvant dans le staff de décision aux côtés de Cisco, Omron ou Rockwell Automation.
Encore quelques années de patience
Concrètement, les utilisateurs devront attendre 2008 pour voir la convergence de Modbus/TCP et d’Ethernet/IP. Dans un an, l’utilisateur pourra rajouter une carte Ethernet/IP dans son automate programme Schneider de façon contiguë à la carte Modbus/TCP, et les deux dialogueront ensemble. C’est en 2009 qu’une seule et même carte de communication intègrera à la fois Ethenet/IP et Modbus/TCP, rendant transparent les deux protocoles.
Bien entendu, un tel choix n’est intéressant que si l’utilisateur veut pouvoir mixer des produits de fournisseurs concurrents, car dès l’année prochaine (en utilisant deux cartes ou 2009 avec une seule) il deviendra possible de rajouter dans une architecture n’importe quel appareil utilisant Ethernet/IP. Et c’est à ce moment-là que Schneider va pouvoir profiter de cette ouverture, notamment sur le marché américain et encore plus asiatique, car n’oublions pas que c’est également Ethernet/IP qui a été choisi par Omron et Rockwell Automation. Ce ralliement avec l’ODVA « c’est la meilleure façon pour nous de pouvoir continuer le leadership qu’a déjà Modbus/TCP » précise André Bourachaki.
L’utilisateur qui aura fait le choix d’équipements Modbus/TCP deviendra compatible avec les services IP de demain, et pourra se connecter aux équipements Rockwell ou Omron. Bien entendu, l’inverse sera vrai, si les offreurs concurrents de Schneider souhaitent s’interconnecter avec le monde Modbus/TCP, la possibilité leur sera offerte, d’autant plus que la croissance des ventes Ethernet est largement en deça des 30%, on parle de 35 à 40% de progression par an du côté de Schneider.
Hors Ethernet, pas de changement
Nous avons profité de l’annonce officielle de l’ODVA pour nous interroger sur le devenir des autres bus de terrain, vu du côté Schneider et notamment de CompoNet utilisant CIP, le concurrent direct d’AS-Interface utilisé par Schneider depuis des années, ou du choix de CanOpen fait par Schneider face à DeviceNet, ce dernier utilisant CIP. Pour la firme française, la réponse est très claire, cet accord ne vise que le monde Ethernet qui reste la stratégie d’avenir, aucun changement en ce qui concerne CanOpen ou AS-Interface ne semble envisagé pour l’instant.
Encadré
Les forces en présence
EtherNet/IP et Modbus/TCP seraient les deux protocoles Ethernet industriel les plus populaires, représentant plus de 50 pour cent de parts de marché dans le monde, selon l’étude la plus récente de l’ARC Advisory Group. « Il s’agit là d’un développement important dans l’industrie d’automatisation » constate Harry Forbes, Senior Analyst auprès de l’ARC Advisory Group. « C’est quelque chose d’inhabituel de voir que plusieurs « géants » de l’automatisation établissent une aussi étroite collaboration notamment dans un domaine stratégique tel que l’Ethernet industriel ».
Après Rockwell à l’origine de DeviceNet et de ControlNet, puis l’apport d’Omron avec dans ses bagages les bases de CompoNet et maintenant Schneider avec Modbus/TCP, la famille ODVA s’agrandit et risque bien de faire bouger quelques lignes. Petit rappel des forces en présence.
CIP
Une photo à scanner
CIP est une technologie orientée objet couvrant les couches Session, Présentation et Application du modèle OSI. Pour l’utilisateur, cela se traduit par une transparence du type de réseau utilisé. Les développeurs d’application n’ont même pas à se soucier de la nature de réseau sur lequel sont connectés les équipements qu’ils programment. CIP définit également des profils d’équipements standards, qui identifient les objets, options de configuration et formats de données d’E/S pour différents types d’équipements. Les équipements possédant le même profil standard répondront aux mêmes commandes, et auront le même comportement sur le réseau.
Un autre élément caractéristique important des réseaux basés sur CIP est leur capacité à générer des messages à partir d’un réseau, puis à les transmettre vers un autre réseau de façon transparente. Cela signifie qu’un ensemble d’objets inclus dans la spécification de CIP défini les mécanismes peuvent être utilisés par un équipement de routage ou une passerelle pour pouvoir transmettre un message d’un port réseau vers un autre sans avoir besoin d’agir sur le contenu du message lui-même. L’un de ses éléments distinctifs est sa capacité à atteindre de grandes vitesses pour la transmission de données de contrôle d’entrées-sorties, tout en restant capable d’échanger des messages explicites avec les couches de niveaux supérieurs.
Parmi les dernières évolutions de la technologie on trouve CompoNet, annoncé à la fin d’année 2005 par l’ODVA. CompoNet, c’est une nouvelle technologie de bus de terrain de niveau capteurs/actionneurs. Celle-ci permettra la transmission rapide de paquets de données de faibles tailles entre contrôleurs, capteurs et actionneurs, au travers d’un media physique économique. Destiné aux applications requérant la mise en œuvre d’un grand nombre de capteurs et d’actionneurs distribués, telles que machines d’assemblage ou systèmes de convoyage, ce bus de terrain entrera en concurrence directe avec AS-Interface. CompoNet s’appuiera sur la même pile protocolaire CIP. Lors de son annonce, l’ODVA a dévoilé que ce bus de terrain serait basé sur une technologie développée à l’origine par l’un des membres fondateurs de l’association, qui n’est autre qu’Omron. Ce dernier a d’ores et déjà accordé les droits nécessaires à l’ODVA pour la réalisation de l’adaptation de sa technologie.
Autre évolution, la sécurité avec CIP Safety. Publiés en janvier 2005, les spécifications de CIP Safety décrivent les extensions fonctionnelles apportées au protocole CIP pour les applications de sécurité. CIP Safety est destiné à des applications de sécurité de niveau SIL 3, suivant le standard IEC 61508. Il a été, à ce titre, approuvé par le TUV Rheinland.
A la fin de la même année, Rockwell a annoncé à l’occasion d’Automation Fair de Saint-Louis, la possibilité de combiner les standards de communication CIP et Ethernet, pour la réalisation d’applications de « Motion Control » distribuées. Cette approche, baptisée CIP Motion, est une solution de contrôle d’axes distribués offrant des possibilités de connectivité controller-to-controller ou controller-to-drive. Elle met en œuvre le mécanisme de synchronisation CIP Sync, basé sur le standard IEEE 1588, qui assure un niveau de précision de la synchronisation des horloges permettant de répondre aux besoins des applications de « Motion Control ».
Modbus/TCP
Modbus/TCP est la variante « encapsulée » dans TCP/IP du protocole Modbus, introduit en 1979 par la société Modicon. Aujourd’hui standard géré par l’organisation Modbus IDA, Modbus/TCP a récemment été approuvé par l’IEC en tant que spécification ouverte au public.
Le protocole Modbus Série est populaire depuis longtemps dans le monde des automatismes. Plus d’un million de produits Modbus sur liaison série ont été installés à ce jour dans le monde, et de nombreuses passerelles avec les diverses variantes d’Ethernet existent. Il faut ajouter le fait que les spécifications de Modbus/TCP sont téléchargeables gratuitement sur Internet, et qu’il existe un grand nombre d’implémentations open source du protocole.
Basé sur un mode de communication client/serveur, le fonctionnement du service de messagerie Modbus TCP permet d’échanger des informations en temps réel entre différents produits d’automatismes sur Ethernet TCP/IP. Il convient de préciser que la notion de temps réel est ici entendue au sens « mou », car si avec des temps de réponse variant entre 0.2 et 1 seconde, Modbus TCP couvre une grande partie des besoins, notamment pour des applications où l’information est centralisée (entrées/sorties déportées), il ne constitue pas une solution idéale pour des applications d’automatismes distribués nécessitant des temps de réponse beaucoup plus faibles (jusqu’à quelques micro-secondes dans le cas du contrôle de mouvements). Notons toutefois qu’il existe des manières d’améliorer les performances de Modbus TCP, mais demain avec CIP Motion, ce problème sera résolvable.
Un système de communication basé sur Modbus TCP/IP peut mettre en jeu différents types d’équipements : des clients et des serveurs Modbus TCP/IP, bien entendu, mais également du matériel d’interconnexion (ponts, routeurs ou passerelles) assurant le lien entre le réseau TCP/IP et une ou plusieurs liaisons Modbus Série, sur lesquelles sont connectés différents terminaux Modbus.
Le protocole Modbus définit une « unité de données de protocole », ou PDU pour Protocol Data Unit, indépendante des couches de communication sous-jacentes. Le mapping du protocole Modbus sur des bus spécifiques ou des réseaux peut introduire des champs supplémentaires au niveau de l’unité de donnée d’application, ou ADU pour Application Data Unit. C’est le client qui initie la transaction Modbus qui construit l’ADU. Le champ Function Code du PDU indique au serveur le type d’action à mener.
Dans le cas d’un mapping sur TCP/IP, une entête spécifique baptisée « MBAP Header » est utilisée pour identifier l’ADU Modbus. Cette entête possède quelques spécificités qui permettent de différencier l’ADU Modbus TCP/IP de l’ADU Modbus RTU, utilisée en liaison série. L’adresse esclave traditionnellement utilisée avec Modbus Série est remplacée par un octet baptisé « Unit Identifier ». Celui-ci permet la communication au travers de ponts, de routeurs ou de passerelles utilisant une adresse IP unique pour supporter plusieurs terminaux Modbus indépendants.
Toute demande ou réponse Modbus est conçue de façon à ce que le récepteur soit en mesure de vérifier que le message est bien terminé. Dans le cas de PDU de longueur fixe, le champ Function Code apporte toutes les informations nécessaires. Ce n’est pas le cas, en revanche, lorsque le PDU transporte une quantité variable de données. Dans ce cas, le champ réservé aux données inclut un compteur d’octets. Par ailleurs, des informations supplémentaires concernant la longueur des messages sont incluses dans l’entête MBAP pour permettre au récepteur de reconnaître les limites des messages, lorsque ceux-ci ont été découpés en plusieurs morceaux pour la transmission.
