Protocole de communication ModBus

6.5 Architecture Co-Simulée pour la validation de la modélisation du protocole

ModBus/IP serveur ... 131

6.5.1 Scénario de communication et résultats de validation ... 132

6.6 Conclusion ... 135

124

Chapitre 6 : Modélisation et validation des protocoles de communication

6.1 Introduction

Le chapitre précédent a montré les développements effectués pour rendre opérationnelle notre plateforme de Co-Simulation. De plus, nous avons illustré dans {chapitre 4, paragraphe 4.5} les intérêts globaux que peut apporter cette plateforme dans le cadre de notre travail de recherche.

Le présent chapitre va présenter les premiers travaux effectués dans le but de concrétiser les possibilités de cette plateforme de Co-Simulation. En particulier, nous allons montrer la méthodologie permettant la validation des modèles de communication en utilisant les modules de la plateforme. L’aspect principal concerne la validation de la conformité des fonctionnalités de communication, implémentées dans les couches applicatives des modèles, par rapport à la spécification du protocole de communication choisi.

Les trois premiers paragraphes illustrent le développement d’un modèle de communication basé sur un protocole applicatif industriel très répandu et très connu puisqu’il s’agit du ModBus/IP ; ceci lui permettra de nous servir d’exemple efficace pour valider le premier intérêt de la plateforme. Nous allons montrer tout d’abord le développement d’un bloc process OpNet permettant la gestion des connexions TCP/IP. Ce bloc a été développé en utilisant des attributs de modèles du logiciel OpNet Modeler pour servir à simplifier la complexité de programmation des modèles.

Le dernier paragraphe montre l’architecture de Co-Simulation et la stratégie permettant la validation de l’implémentation des fonctionnalités du protocole ModBus/IP dans notre modèle de communication. Les résultats de validation sont montrés à la fin de ce chapitre.

6.2 Gestion des connexions TCP/IP dans les modèles de simulation

Pour assurer une transition des messages entre les couches de communication d’un modèle de simulation (i.e. module), des échanges de commandes et des indications de traitement de messages doivent être établis entre les couches.

OpNet Modeler implémente les protocoles de communication standard du modèle OSI dans les couches de communication des nœuds de simulation en partant de la couche physique jusqu’à la couche transport. Un exemple de ces protocoles est le standard TCP/IP. L’échange des commandes et des indications entre les couches basses (i.e. par rapport à la couche application) est assuré automatiquement par le logiciel OpNet lors de l’implémentation de ces couches dans les nœuds de simulation.

Toutefois, l’implémentation des protocoles de communication dans la couche applicative ainsi que l’échange des commandes et des indications entre cette couche et les couches basses du modèle OSI n’est pas assurée par ce logiciel de simulation. Ceci est dû au fait de la diversité des protocoles existant au niveau de la couche application.

Par conséquent, la programmation des couches applicatives ainsi que leurs cohabitations avec les couches basses, telle que la couche de transport implémentant le protocole standard TCP ou UDP, doivent être développés en fonction des besoins. L’échange des commandes et d’indication entre les couches de communication est crucial à mettre en œuvre pour n’importe

125 Chapitre 6 : Modélisation et validation des protocoles de communication

quelle modélisation protocolaire du fait qu’elles permettent d’une part la gestion des connexions des nœuds de simulation et d’autre part l’échanges des messages de communication.

Le premier sous paragraphe montre le principe ainsi que les différentes fonctions permettant l’échange de commandes et d’indications entre une couche applicative et une couche TCP d’un nœud de simulation. Le deuxième sous-paragraphe explique la construction d’un bloc process qui a été développé dans le but d’assurer d’une part la gestion des connexions et de simplifier d’autre part le développement des modèles de simulation.

6.2.1 Principe de cohabitation entre la couche applicative et la couche transport

OpNet

Plusieurs API ‘Application Protocol Interface’ sont livrées par le logiciel de simulation OpNet pour assurer la tâche de cohabitation. Ces API mettent à la disposition des couches applicatives des fonctions informatiques permettant d’envoyer des commandes et de recevoir des indications vers les couches basses du nœud de simulation.

Etant donné que le protocole ModBus/IP fonctionne au-delà de la couche transport TCP, les deux librairies de fonction ‘tcp_api_v3’ et ‘ip_addr_v4’ (figure 5.1), livrées par le logiciel de simulation OpNet, ont été utilisés dans notre étude pour assurer la cohabitation entre la couche applicative ModBus et la couche transport TCP.

Comme le montre la figure 5.1, pour assurer une gestion des connexions TCP/IP, plusieurs étapes doivent être mise en place en respectant une chronologie de cohabitation entre la couche applicative et la couche transport.

La première étape consiste à faire appel à une fonction intitulée ‘Register’ qui permet de générer une structure contenant les caractéristiques des deux couches de communication. Cette structure est utilisée en tant que paramètre pour toutes les autres fonctions de commandes et de signalisations d’informations entre ces deux couches.

Le mécanisme de connexion TCP intitulé ‘Three Way Hand Shaking’ consiste à ce qu’un client envoie une requête de synchronisation vers un serveur qui répondra par la suite par un acquittement de cette requête pour qu’à la fin le client envoie l’acquittement final indiquant que la connexion a bien été établie. Ce mécanisme est géré par la couche de transport du serveur ou du client suite à des commandes de connexions envoyées par la couche applicative de ces derniers (figure 5.1).

Au niveau serveur, la commande de connexion envoyée par la couche applicative vers la couche TCP doit aboutir à une ouverture d’une connexion passive sur le port de communication correspondant au protocole implémenté dans l’application. A l’issue de cette demande, la couche de transport renvoie une information à l’application indiquant si le serveur a accepté la commande envoyée.

Au niveau client, l’application doit envoyer une commande vers la couche TCP dans le but de se synchroniser avec le serveur considéré à l’écoute. A l’issue de cette commande, la couche transport du client envoie la demande de synchronisation au serveur et informe par la suite la couche applicative du résultat de cette synchronisation.

La fonction ‘tcp_connection_open_with_options ()’ appartenant à la librairie ‘tcp_api_v3’

126

Chapitre 6 : Modélisation et validation des protocoles de communication

constitue l’un des paramètres essentiels de cette fonction. Les autres paramètres permettent d’indiquer les adresses sources et destination des deux équipements client et serveur.

Les adresses IP dans OpNet Modeler sont attribués à un type informatique intitulé

‘InetT_Address’. Une fonction appartenant à la librairie ‘ip_addr_v4’ permet la génération d’une adresse de ce type en partant d’une adresse exprimée en une chaîne de caractères. Une fois la connexion établie, l’échange des paquets de communication protocolaire entre le client et le serveur peut avoir lieu. L’envoi d’un paquet de communication depuis un modèle de simulation est accompli par la fonction ‘tcp_data_send’ de la librairie ‘tcp_api_v3’. Quant à la réception des paquets, la couche applicative du modèle doit en premier temps informer la couche de transport, par l’intermédiaire de la fonction

‘tcp_receive_command_send’ de la librairie ‘tcp_api_v3’, de sa capacité à recevoir. A l’issue de cette commande la couche de transport envoie automatiquement le paquet reçu vers la couche applicative.

Figure 6.1 Commandes et indications échangées entre la couche applicative et la couche transport pour la gestion des connexions TCP/IP

6.2.2 Attributs de modèles et généralisation de la gestion de connexions TCP/IP

La cohabitation entre la couche application et la couche de transport est un point essentiel à intégrer dans le développement de n’importe quel modèle de simulation utilisant le profil TCP/IP. Il a été montré au cours du paragraphe précédent que cet interfaçage nécessite l’utilisation et le paramétrage de plusieurs fonctions OpNet appartenant à deux librairies de l’API TCP.

127 Chapitre 6 : Modélisation et validation des protocoles de communication

Une généralisation de cette cohabitation a été effectuée dans notre étude en créant un bloc process intitulé ‘Connexion Establishment’. Le but de ce bloc est de simplifier la tâche de gestion de connexions TCP/IP des modèles de simulation pour les rendre configurables par l’intermédiaire des attributs de connexion créés dans la couche applicative (figure 5.2).

En effet, chaque couche de communication appartenant à un modèle de simulation est associée à plusieurs attributs permettant la configuration de son comportement. Ces attributs peuvent être de type simple ou composé. Un exemple des attributs simple d’une couche est le type du ‘Process’ associé à cette couche. Les développeurs Modeler peuvent rajouter des

‘attributs utilisateurs’ pour donner plus de flexibilité à la configuration de leur modèles. Dans notre étude, on a utilisé cette notion pour créer deux attributs composés intitulés ‘Active Connection’ et ‘Passive Connection’ (figure 5.2). Ces attributs sont utilisés par le Process

‘Connexion Establishment’ dans le but de rendre la procédure de gestion de connexion TCP complètement configurable (figure 5.2).

Le premier attribut permet de définir le nombre ainsi que toutes les caractéristiques d’une connexion active telles que l’adresse IP source/destination, le numéro de port sources/destination (figure 5.2). Tandis que le deuxième permet de définir le nombre et les caractéristiques d’une connexion passive TCP. Un modèle peut jouer le rôle d’un client et d’un serveur en même temps.

La figure 5.2 montre les différentes étapes constituant le bloc ‘Connexion Establishment’. L’étape ‘Initialization’ permet d’extraire les informations contenues dans les attributs de connexion du nœud de simulation. Les conditions ‘a’, ‘b’ et ‘c’, montrées sur la figure 5.2, sont implémentées dans les transitions de process de manière à ce que ce dernier puisse établir toutes les connexions passives et actives configurées au niveau de ces attributs. La répartition de ces transitions montrent que le process établi en premier les connexions passives en passant par l’étape ‘Passive_con’ pour ensuite transiter vers l’étape ‘Active_Con’ où il procède à l’envoi des commandes de synchronisation pour ouvrir les connexions actives. Chacune de ces deux dernières étapes contient la fonction

‘tcp_connection_open_with_options ()’ expliquée auparavant. Les deux étapes sont de type non forcées du fait qu’elles doivent bloquer le Process en attendant le résultat de leur commande. Le déblocage du ‘Process’ de la couche application aura lieu lors de la réception d’une interruption envoyée par la couche transport. Cette interruption indiquera le résultat de la commande qui sera affiché dans l’étape ‘Connection Status’.

La transition du bloc de l’établissement de connexion ‘Connexion Establishment’ vers le reste du Process de la couche applicative est conditionnée par la variable (!c) indiquant que toutes les connexions définies dans les attributs du modèle ont été établies avec succès.

Le bloc ‘Connexion Establishment’ ainsi que les attributs de connexion sont développés dans notre étude dans le but de simplifier le développement de la modélisation au niveau de la couche applicative. Par conséquent, nous pouvons remarquer que ce bloc sera utilisé dans tous les modèles de simulation développés dans notre étude.

128

Chapitre 6 : Modélisation et validation des protocoles de communication

Figure 6.2 Composition du process connexion establishment et interconnexions avec les attributs de la couche applicative

6.3 Protocole de communication ModBus

ModBus est un protocole de communication qui a été proposé par Modicon (actuellement Schneider Electric) en 1979. Ce protocole était conçu, dans un premier temps, pour fonctionner sur une couche physique OSI de type série basée sur des connecteurs et des câbles RS232 ou RS485.

Les protocoles de communication utilisant cette couche physique sont généralement basés sur le principe maître/esclave pour la génération des flux de communication. Le maître est le seul élément actif à l’origine de la génération de ces flux. Les esclaves attendent une requête de communication protocolaire venant du maître avant d’envoyer leurs réponses.

Une variante ModBus, intitulée ‘ModBus/IP’, a été développée ces dernières années dans le but de permettre l’utilisation de ce protocole sur un réseau de communication Ethernet. Cette variante constitue l’un des protocoles de communication les plus répandus dans les architectures de communication d’un SDEE [Goraj et al, 2006]. La différence entre les composants constituant une architecture ModBus série et une architecture ModBus/IP pour un SDEE a été décrite dans [Haffar et al, 2007].

Nous avons choisi ce protocole de communication pour la réalisation de nos premiers travaux de modélisation et de Co-Simulation du fait de son aspect très répandu dans l’industrie. Ce point nous facilite la tâche de réalisation et de tests des architectures Co-Simulées qui vont nous permettre de montrer et valider les intérêts qu’apportent notre plateforme dans le domaine de la validation de modèles et d’évaluation de performance des architectures de communication mixtes (composées d’équipements virtuels et réels).

129 Chapitre 6 : Modélisation et validation des protocoles de communication

Par ailleurs, ce protocole est ‘Open Source’ ou ‘libre de droit’, ce qui permet d’avoir une connaissance complète du format des messages constituant ses fonctionnalités de communication. Ceci permet de faciliter la tâche de l’implémentation de ces fonctionnalités de communication dans les couches applicatives des modèles de simulation d’OpNet.