De plus en plus dans l’industrie, les unités de fabrication fonctionnent en réseau. Nous allons voir comment établir une communication client/serveur qui soit fiable. Pour cela nous allons prendre pour exemple une liaison entre un automate programmable industriel (API). Celle-ci fera ici office de serveur et un robot qui sera notre client. Notre connexion s’effectuera sur deux canaux. C’est-à-dire que l’API enverra des données  au client sur un canal. Le client pourra seulement dire, sur celui-ci, qu’il a bien reçu le message. Si le client veut envoyer des données, il le fera sur un autre canal (que le serveur utilisera pour valider la réception).

Tout cela peut être schématisé ainsi :

Pour chacun des deux canaux de transmission, le serveur commence d’abord par ouvrir un socket. Autrement dit une porte par laquelle il va écouter les requêtes du client. Une fois cette « interface de connexion » ouverte, le serveur se met en écoute. C’est-à-dire qu’il attend qu’un client lui envoi des données.

De son côté, le client ouvre également un socket pour chaque canal. Il envoie une demande de connexion au serveur. Lorsque le serveur accepte sa demande, la connexion est établie.

Le fait d’utiliser deux canaux pour la transmission de données entre deux appareils permet une stabilité de la connexion. En utilisant un seul canal, si un problème de communication survient du côté du serveur, le client ne pourra pas le savoir. Il se contentera d’attendre une trame (qui finalement n’arrivera jamais), et inversement.

De plus, une fois la connexion établie, les deux systèmes peuvent «  parler » en même temps, de manière asynchrone.

Avec deux canaux de transmission. Le client et le serveur peuvent détecter à tout moment que l’autre n’a pas accusé réception de la trame qui l’a envoyé. Il se mettra alors en défaut. Cela permettra à un technicien d’être averti de la panne et il pourra réinitialiser la communication.

En plus de cette sécurité là, pour être capable de repérer un problème de communication d’un côté comme de l’autre. Chaque système envoie à l’autre une « trame de vie ». Il s’agit simplement d’un message envoyé en boucle à intervalle régulier. Ceci parallèlement aux échanges nécessaires au fonctionnement du système. Le contrôleur sensé recevoir la trame de vie, peut ainsi détecter que la liaison est interrompue. Dans le cas où la trame de vie n’est pas arrivée dans l’intervalle définit.

Les données envoyées par l’un ou l’autre de nos systèmes sont émises sous forme de trames. Ces trames sont lues et analysées dans leur ordre d’arrivée. C’est le principe du FIFO (First In, First Out).

Lorsqu’une trame est prête à être envoyée (« Trame à envoyer5 »), elle est stockée dans un tableau « buffer ». C’est une sorte de salle d’attente utilisant le principe FIFO, jusqu’à ce que le canal de transmission dédié aux envois de trames. Les trames dans ce tableau remontent au fur et à mesure que les autres sont envoyées.

Lorsque le port dédié à l’envoi de trame est libre. La trame qui est entrée dans le tableau en premier (donc celle à la position 0, ici « Trame à envoyer1 ») est envoyée. Elle est ensuite archivée dans un autre tableau dans lequel la première place est systématiquement libérée.

Les trames reçues doivent être analysées avant d’être archivées. Pour cela, elles sont d’abord stockées dans un tableau « buffer ». Les trames dans ce tableau remontent au fur et à mesure que les autres sont traitées.

Une fois qu’une trame est à traiter (la plus ancienne dans le tableau), elle en est extraite pour être analysée. Elle est ensuite stockée dans un tableau d’archive.

Prenons un exemple où 5 trames sont en attente de traitement :

Quand le traitement de la trame précédente est terminé, la première trame du tableau est extraite. On l’appellera désormais « TrameEnCours ». Les autres trames remontent toute de manière à remplir la première case :

La trame en cours de traitement est alors analysée et en même temps rajoutée dans un tableau d’archive qui fonctionnent exactement comme le tableau d’archivage des trames envoyées vu ci-dessus.