Contacts

Protocoles de communication dans les systèmes de contrôle de processus automatisés. Protocoles de communication dans les systèmes de contrôle de processus automatisés Structure de connexion des sous-systèmes locaux

Il existe trois formes de communication pour la transmission série de données numériques :

UN) communication simplexe suppose la présence d'un émetteur et d'un récepteur ; les informations sont transmises dans un sens, la communication s'effectue via une paire de fils distincte ;

B) communication semi-duplex permet le transfert de données bidirectionnel, mais pas simultanément ; la communication s'effectue via un câble composé de deux ou quatre fils ;

DANS) communication recto-verso assure une transmission de données bidirectionnelle simultanée, et la communication s'effectue également via un câble composé de deux ou quatre fils.

Chacune des formes de communication ci-dessus nécessite que le dispositif de réception soit prêt à recevoir et à identifier chaque ensemble de données transmis par l'émetteur. Il existe deux manières de résoudre ce problème. À transmission asynchrone chaque paquet de données est précédé de peu de démarrage, et une fois la transmission de ce paquet de données terminée, peu d'arrêt. De cette manière, le destinataire identifie clairement le début et la fin du message. Cependant, en raison de la nécessité de vérifier constamment les bits de démarrage et d'arrêt, la vitesse de transmission pour ce type de communication est limitée et ne dépasse généralement pas 1 200 bps.

La transmission asynchrone est utilisée dans des conditions de réception incertaine et de niveaux d'interférences élevés. Transmission synchrone ne nécessite pas de bits de démarrage et d'arrêt, d'émetteur et de récepteur synchronisé. Le début de la transmission et de la réception des données est pré-synchronisé par une impulsion d'horloge, puis chaque mot du paquet de données est reconnu comme un bloc de sept ou huit bits. Le transfert de données synchrone peut fournir des vitesses supérieures à 1 200 bps et est le plus souvent utilisé pour transférer des flux de données tels que des fichiers de programme.

Des capteurs et des commandes intelligents modernes aux côtés des capteurs traditionnels Interface RS-232C peut également inclure un sous-système d'entrée/sortie série basé sur Interface RS-485. Les contrôleurs logiques programmables de la plupart des fabricants contiennent l'une ou l'autre implémentation d'interfaces comme moyen d'organiser des systèmes d'acquisition et de contrôle de données géographiquement répartis. RS-422A/RS-485.



RS-232C– une interface série standard largement utilisée. Il peut être utilisé pour la transmission de données synchrone à des vitesses allant jusqu'à 20 000 bps sur des distances allant jusqu'à 15 mètres ; sur de longues distances, la vitesse de transmission diminue. interface RS-449– il s'agit d'une norme plus récente, elle présente des caractéristiques améliorées en termes de vitesse et de distance de transmission par rapport au RS-232 ; ici, des vitesses allant jusqu'à 10 000 bps sont réalisables sur une distance allant jusqu'à 1 km. Les niveaux de tension correspondant à la norme RS-232 sont de +12 V pour le « 0 » logique et de –12 V pour le « 1 » logique. L'interface RS-232 est actuellement standard pour COM-ports d'ordinateurs personnels. Puisque la grande majorité des microprocesseurs sont construits sur Durée de vie-structure(logique transistor-transistor), où le niveau du zéro logique est de 0 V et le niveau du un logique est de +5 V, alors, évidemment, les niveaux de signal doivent être convertis pour correspondre. Cette dernière est réalisée à l'aide de circuits intégrés - convertisseurs de niveau, tels que : MS1488 pour convertir les niveaux TTL en niveaux RS-232 et MS1489 pour convertir les niveaux RS-232 en niveaux TTL.

Interface RS-485(AIE-485) est l'une des normes de couche de communication physique les plus courantes (canal de communication + méthode de transmission du signal).

Un réseau construit sur l'interface RS-485 se compose d'émetteurs-récepteurs connectés via paire torsadée– deux fils torsadés. L'interface RS-485 est basée sur le principe différentiel (équilibré) transferts données. Son essence est de transmettre un signal sur deux fils. De plus, sur un fil (sous condition UN) le signal original part, et l'autre (conventionnellement B) est sa copie inverse. Ainsi, il existe toujours une différence de potentiel entre les deux fils d'une paire torsadée (Fig. A1.1).

Graphique A1.1

Cette méthode de transmission offre une haute immunité aux interférences de mode commun, qui affectent également les deux fils de la ligne. Si le signal est transmis par le potentiel d'un fil par rapport au commun, comme dans RS-232, alors les interférences sur ce fil peuvent déformer le signal par rapport au commun (terre) qui absorbe bien les interférences. De plus, la différence de potentiel des points communs chutera à travers la résistance d'un long fil commun, ce qui constituera une source supplémentaire de distorsion. Avec la transmission différentielle, de telles distorsions ne se produisent pas, car dans une paire torsadée, le capteur sur les deux fils est le même. Ainsi, le potentiel des fils également chargés change de la même manière, tandis que la différence de potentiel informative reste inchangée.

Implémentation matérielle de l'interface - puces émetteur-récepteur avec entrées/sorties différentielles (vers la ligne) et ports numériques (vers les ports du contrôleur UART). Il existe deux options pour cette interface : RS-422 Et RS-485.

RS-422 – interface duplex. La réception et la transmission sont assurées sur deux paires de fils distinctes. Il ne peut y avoir qu'un seul émetteur sur chaque paire de fils.

RS-485 est un analogue de ligne réseau semi-duplex de l'interface RS-422. La réception et la transmission sont effectuées sur une paire de fils avec un intervalle de temps. Il peut y avoir de nombreux émetteurs dans un réseau, car ils peuvent s'éteindre pendant la réception.

Tous les appareils sont connectés à un câble à paire torsadée de la même manière : sorties directes ( UN) à un fil, inverse ( B) - à un autre.

L'impédance d'entrée du récepteur côté ligne est généralement de 12 kOhm. La puissance de l'émetteur n'étant pas infinie, cela crée une limite sur le nombre de récepteurs connectés à la ligne. Selon la norme RS-485, compte tenu des résistances adaptées, l'émetteur peut piloter jusqu'à 32 récepteurs. Cependant, en utilisant des microcircuits à impédance d'entrée accrue, vous pouvez connecter un nombre beaucoup plus important d'appareils à la ligne (plus de 100 appareils). Dans ce cas, les appareils sont connectés à la ligne en parallèle et le contrôleur (ordinateur) doit être équipé d'un appareil supplémentaire - un convertisseur de port série RS-485/RS-232.

La vitesse de communication maximale en RS-485 peut atteindre 10 Mbit/s et la longueur maximale de la ligne de communication est de 1 200 M. S'il est nécessaire d'organiser la communication à une distance supérieure à 1 200 m, ou de connecter plus d'appareils que la capacité de charge de l'émetteur le permet, des répéteurs spéciaux sont alors utilisés ( répéteurs).

La plage de tension du « 1 » et du « 0 » logiques dans l'émetteur RS-485 est respectivement de +1,5...+6 V et –1,5...–6 V, et la plage de tension en mode commun de l'émetteur est (–1 ...+3 V).

Les valeurs des paramètres sont déterminées de telle manière que tout appareil faisant partie du système d'information de mesure reste opérationnel en présence de bruit de type général à ses bornes connectées à la ligne de communication, dont la tension est comprise entre –7 à +7 V.

Pour le transfert de données parallèle dans les systèmes d'information de mesure, une interface standard est souvent utilisée IEEE-488 (Institut d'ingénieurs en électricité et électronique), aussi appelé HP-IB(Bus d'interface Hewlett-Packard) ou GPIB(Bus d'interface à usage général – bus d'interface à usage général). Commission internationale en électrotechnique ( CEI) a recommandé cette norme comme norme internationale, pour cette raison dans l'espace post-soviétique, elle est appelée Interface numérique CEI.

L'interface IEEE-488 a été développée pour les instruments de mesure et convertisseurs électroniques programmables et non programmables. Il est conçu pour l'échange d'informations asynchrone, axé sur le couplage d'appareils situés les uns par rapport aux autres à une distance allant jusqu'à 20 m, et assure le fonctionnement d'appareils de complexité variable dans IIS, permet un échange direct d'informations entre eux, à distance et local contrôle des appareils. L'interface décrite a une structure de base (Fig. A1.2).

Le réseau d'interface se compose de 24 lignes de signal, dont huit sont des lignes de terre, et les lignes restantes sont divisées en trois groupes. Le premier groupe, composé de huit lignes de signaux bidirectionnels, est bus de données. Il est conçu pour transmettre des données et des commandes entre différents appareils connectés à l'interface. Un autre groupe de cinq lignes de signal - bus de commande générale, les signaux de contrôle et d'état y sont transmis. Le dernier groupe de trois lignes est utilisé pour contrôler le transfert de données ( bus de poignée de main).


Les appareils connectés à l'interface peuvent fonctionner comme récepteurs ou sources de messages. À un moment donné, un seul appareil peut être une source d’informations, tandis que plusieurs appareils peuvent simultanément agir comme récepteurs de messages. L'un des appareils sur le backbone est manette interface.

Le nombre total de récepteurs et de sources d'informations dans IEEE-488 ne doit pas dépasser 31 avec un adressage sur un seul octet, et le nombre de périphériques connectés en parallèle doit être de 15 (y compris le contrôleur de contrôle).

Dans la norme IEEE-488, un niveau de signal haut dans une ligne correspond à une valeur de tension égale ou supérieure à 2 V, et un niveau bas correspond à une valeur de tension égale ou inférieure à 0,8 V.

Annexe A2

Mode d'emploi

1. Introduction
1.1. Champ d'application………………………………………………………………. 3
1.2. Brève description des fonctionnalités……………………………………………..... 3
1.3. Niveau utilisateur………………………………………………………... 3

2. Objet et conditions d'utilisation du système automatisé de contrôle des processus « VP »……………………………………. 4

3. Solution du système de contrôle de processus automatisé « VP »………………………………………………………. 5

4. Démarrage du système………………………………………………………………..……… 6

1. Introduction.

1.1. Champ d'application

Les exigences de ce document s'appliquent lorsque :

· tests préliminaires complets ;

· opération d'essai;

· tests d'acceptation ;

· exploitation industrielle.

1.2. Brève description des fonctionnalités

Le produit logiciel « Weight Flow » est conçu pour le travail analytique, l'automatisation et l'optimisation des processus de flux de documents et de la logistique interservices des différents départements de l'entreprise. Le système offre également la possibilité de surveiller et d'ajuster rapidement le fonctionnement des processus techniques dans les entreprises associés à l'utilisation d'équipements de pesage dans les ascenseurs, les nefs et les installations de stockage de gaz, les gares de marchandises ferroviaires et autres installations industrielles.

Le complexe logiciel, matériel et logiciel du système de contrôle de processus automatisé « Weight Flow » a une structure modulaire.

Lorsque l'on travaille avec le reporting, on utilise souvent : le logiciel OLE 1C avec une fonction de synchronisation en ligne (permet de lancer la pesée à partir du système comptable) et le logiciel SAP RFC avec une fonction de synchronisation en ligne (génère des pesées dans le système comptable), qui fournit ce qui suit:


· vérifier la possibilité de passage des véhicules sur le territoire de l'entreprise ;

· créer un document en 1C sur le fait de peser les véhicules dans l'entreprise ;

· restitution des données sur le solde des fonds sur le compte de la contrepartie dans le système 1C ;

· rechercher un document par numéro de véhicule et renvoyer le numéro du document. S'il y a plusieurs documents, l'ordre de sortie est déterminé par le développeur, la fonction renvoie toujours un document ;

    renvoyer des informations sur le document ; retourner l'élément de répertoire ; saisir le poids de la marchandise dans le document ; délivrer une liste de documents à ce jour.

1.3. Niveau de l'utilisateur

L'utilisateur doit avoir une expérience de travail avec le système d'exploitation MS Windows (95/98/NT/2000/XP, XP-7), des compétences dans l'utilisation de MS Office et également posséder les connaissances suivantes :

· connaître le domaine pertinent ;

· connaître le principe de fonctionnement des ponts-bascules pour camions;

· être capable de connecter des périphériques.

2. Objet et conditions d'utilisation du système automatisé de contrôle des processus « VP ».

Répartition de la production, transport, routes, appliquée avec succès dans de nombreux domaines d'activité, depuis les routes et passages commerciaux, le stationnement automatique, jusqu'à l'automatisation de l'industrie de production de gaz.

Le complexe logiciel et matériel du système de contrôle de processus automatisé "Weight Flow" est conçu pour l'automatisation des systèmes de pesage industriels (balances pour véhicules, balances pour wagons, etc.) et du flux de documents, la configuration prenant en compte le secteur d'activité de l'entreprise et les caractéristiques comptables.

Tous les systèmes ont la capacité de s'intégrer facilement à d'autres systèmes, par exemple des systèmes comptables (1C, Turbobukhgalter, SAP, BAAN, etc.). Les systèmes sont également équipés d'une option de contrôle à distance/à distance. Tous nos projets incluent les solutions logicielles et matérielles les plus avancées et uniques utilisant les technologies RFID (identification par radiofréquence), actives et passives.

Le système de contrôle de processus « Weight Flow » comprend l'installation de systèmes de sécurité et de vidéosurveillance, de systèmes de contrôle d'accès dans des installations industrielles à des fins diverses et à tout niveau de complexité, avec leur intégration dans les processus technologiques et le flux de documents de l'entreprise, ainsi que l'utilisation de technologies RFID modernes (actives/passives) .

3. Solution du système de contrôle de processus automatisé « VP »

Options typiques pour compléter les systèmes de contrôle de processus automatisés « Débit de poids »

Options d'identification d'événement. « Événement » est un élément important qui permet d'organiser le fonctionnement du système sans personne, ce qui élimine les « risques » associés aux activités d'employés malhonnêtes.

1. Analyse vidéo intelligente – système de reconnaissance des véhicules, numéros de véhicules/wagons/conteneurs ;
2. RFID - identification par radiofréquence (active ou passive) ;
3. Divers capteurs - capteurs à induction, thermiques ;
4. Saisie humaine des données d'événement

Actionneurs : - tous appareils numériques dont la conception comporte des ports de connexion (COM USB, RS 232/485, réseau IP, etc.) ;
- tous appareils analogiques dotés de fonctions marche/arrêt (feux tricolores / moteurs / ampoules / barrières / registres, etc.) ;
- capteurs/analyseurs numériques, électroniques et à contacts secs.

Composants logiciels du système de contrôle de processus automatisé "VP"
Nous disposons de plusieurs modules APCS - leurs fonctionnalités sont décrites brièvement dans les spécifications, plus en détail dans le manuel. Vous trouverez ci-dessous les principaux composants logiciels du système de contrôle de processus « Débit de poids ». Chaque module a certaines fonctions de base :

1. Serveur - Logiciel APCS "Weight Flow"
Centre nord des échelles (WEB, SQL, URDB)

2. Programme de pesage - système de contrôle de processus automatisé "Weight Flow" Module de pesage automatique/pesage ferroviaire
3. Utilisation de divers appareils - système de contrôle de processus automatisé Module contrôleur "Weight Flow" +
dans le système

4. Ajustements, visible/invisible - Laboratoire du module « VP » du système de contrôle de processus automatisé

5. Poste de travail supplémentaire - système de contrôle de processus automatisé Module "VP" poste de travail supplémentaire
(possibilité de se connecter à distance ou en réseau au poste de contrôle automatisé)


4. Démarrage du système

https://pandia.ru/text/80/223/images/image002_125.jpg" width="672 hauteur=361" hauteur="361">

Riz. 2. Interface du système de contrôle de processus automatisé « Débit de poids »

Interface se compose des éléments suivants :

1.Menu de navigation. Sert à configurer et à gérer le système.

2. Boutons pour basculer entre les échelles. Servir à changer l'affichage de l'état des différentes balances et à indiquer les balances actuellement actives si plus d'une balance est connectée au système.

3.Menu opérateur. Sert à gérer le système de pesée, de documents et de contrôle d’accès. Change l'apparence et les fonctions du panneau de commande.

4. Panneau de commande. Sert à gérer le système de pesée, de documents et de contrôle d’accès. L'apparence et les fonctions dépendent de l'onglet actuellement sélectionné dans le menu opérateur (position 3). Lorsque le système démarre, le panneau de commande de la balance s'affiche (comme sur la Fig. 2).

5.Calendrier. Permet de sélectionner les résultats de pesée affichés sur le panneau du protocole de pesée (position 7) par date et d'afficher la date du jour.

6.Bouton « Enregistrer le document ». Utilisé pour créer un nouveau document.

7. Panneau de protocole de pesage. Sert à afficher les résultats de pesée pour une date spécifique sélectionnée dans le calendrier (position 5).

8. Panneau vidéo. Affiche la diffusion vidéo des caméras de vidéosurveillance.

Le menu de navigation(Fig. 3) est situé dans le coin supérieur gauche du moniteur et comprend les sections suivantes : « Fichier », « Configuration », « Modules », « Windows », « À propos du programme ».

https://pandia.ru/text/80/223/images/image004_81.jpg" align="left" width="120" height="76">

Riz. 4. Menu "Fichier".

Menu "Configuration" (Fig.5)

Donne accès aux paramètres du service système

"Concepteur de plaques d'impression" - sert à l'enregistrement des mises en page des documents

"Les paramètres du système" - sert à configurer le système conformément aux paramètres requis

https://pandia.ru/text/80/223/images/image006_48.jpg" align="left" width="171" height="92 src=">

Riz. 6. Menu "Modules".

Menu "Fenêtre" (Fig.7)

Affiche une liste des fenêtres ouvertes et vous permet de basculer entre elles

https://pandia.ru/text/80/223/images/image008_40.jpg" width="675 hauteur=356" hauteur="356">

Les réseaux de données industrielles sont l'un des principaux éléments des systèmes de contrôle de processus automatisés modernes. L'émergence des protocoles de communication industriels a marqué le début de l'introduction de systèmes de contrôle géographiquement répartis, capables de couvrir de nombreuses installations technologiques, fédérant des ateliers entiers, et parfois des usines. Aujourd'hui, le domaine des communications industrielles se développe à pas de géant : plus de 50 normes de réseaux de communication sont connues, spécialement adaptées aux applications industrielles, et de nouvelles technologies avancées de transmission de données apparaissent chaque année. Cela n'est pas surprenant, puisque ce sont les réseaux de communication qui déterminent en grande partie la qualité, la fiabilité et la fonctionnalité des systèmes de contrôle de processus automatisés dans leur ensemble.

Les réseaux de transmission de données utilisés dans les systèmes de contrôle de processus automatisés peuvent être divisés en deux classes :

  1. Bus de terrain ;
  2. Réseaux de niveau supérieur (niveau opérateur, bus terminaux).


1. Bus de terrain

La fonction principale du bus de terrain est de fournir une interaction réseau entre les contrôleurs et les périphériques distants (par exemple, les nœuds d'E/S). De plus, divers instruments et actionneurs (Field Devices), équipés d'interfaces réseau appropriées, peuvent être connectés au bus de terrain. De tels appareils sont souvent appelés appareils de terrain intelligents car ils prennent en charge des protocoles de communication réseau de haut niveau.

Comme indiqué, il existe de nombreuses normes de bus de terrain, dont les plus courantes sont :

  1. Profibus-DP ;
  2. Profibus PA ;
  3. Bus de terrain de la Fondation ;
  4. Modbus RTU ;
  5. CERF;
  6. DeviceNet.

Malgré les nuances de mise en œuvre de chacune des normes (taux de transfert de données, format de trame, environnement physique), elles ont une caractéristique commune : l'algorithme d'échange de données réseau utilisé, basé sur le principe classique Maître-Esclave ou ses légères modifications. Les bus de terrain modernes répondent à des exigences techniques strictes, ce qui les rend adaptés à une utilisation dans des environnements industriels difficiles. Ces exigences comprennent :

1. Déterminisme. Cela signifie que la transmission d'un message d'un nœud du réseau à un autre prend un laps de temps strictement fixé. Les réseaux de bureau construits à l'aide de la technologie Ethernet sont un excellent exemple de réseau non déterministe. L'algorithme d'accès à un support partagé par la méthode CSMA/CD ne détermine pas le temps pendant lequel une trame d'un nœud du réseau sera transmise à un autre et, à proprement parler, il n'y a aucune garantie que la trame parviendra même à destination. C’est inacceptable pour les réseaux industriels. Le temps de transmission des messages doit être limité et, en général, peut être calculé à l'avance en tenant compte du nombre de nœuds, de la vitesse de transmission des données et de la longueur du message.

2. Assistance longue distance. Il s'agit d'une exigence essentielle, car la distance entre les objets de contrôle peut parfois atteindre plusieurs kilomètres. Le protocole utilisé doit être orienté pour une utilisation dans les réseaux longue distance.

3. Protection contre les interférences électromagnétiques. Les longues lignes sont particulièrement sensibles aux effets nocifs des interférences électromagnétiques émises par divers équipements électriques. De fortes interférences sur la ligne peuvent déformer les données transmises au point de les rendre méconnaissables. Pour se protéger contre de telles interférences, des câbles blindés spéciaux sont utilisés, ainsi que des fibres optiques qui, en raison de la nature légère du signal d'information, sont généralement insensibles aux interférences électromagnétiques. De plus, les réseaux industriels doivent utiliser des méthodes spéciales de codage des données numériques qui empêchent la distorsion des données pendant la transmission ou, au moins, permettent aux données déformées d'être détectées efficacement par le nœud de réception.

4. Conception mécanique renforcée des câbles et des connecteurs. Il n'y a rien d'étonnant ici non plus, si l'on imagine les conditions dans lesquelles les lignes de communication doivent souvent être posées. Les câbles et connecteurs doivent être solides, durables et adaptés à une utilisation dans les conditions les plus sévères (notamment atmosphères agressives, conditions de niveaux de vibrations élevés, humidité).

En fonction du type de support physique de transmission des données, les bus de terrain sont divisés en deux types :

  1. Bus de terrain construits sur la base d'un câble à fibre optique. Les avantages de l'utilisation de la fibre optique sont évidents : la possibilité de construire de longues lignes de communication (jusqu'à 10 km ou plus de longueur) ; grande bande passante ; insensibilité aux interférences électromagnétiques; Possibilité d'installation en zones dangereuses. Inconvénients : coût du câble relativement élevé ; complexité de la connexion physique et de la connexion par câble. Ces travaux doivent être réalisés par des spécialistes qualifiés.
  2. Bus de terrain construits à base de câble en cuivre. En règle générale, il s'agit d'un câble à paire torsadée à deux fils avec une isolation et un blindage spéciaux. Avantages : prix raisonnable ; facilité de pose et de réalisation de connexions physiques. Inconvénients : sensible aux interférences électromagnétiques ; longueur limitée des lignes de câbles ; bande passante inférieure à celle de la fibre optique.

Un exemple de module qui connecte un contrôleur Simatic S7-300 à un réseau Profibus DP avec un câble à fibre optique est le processeur de communication CP 342-5 FO. Pour connecter le S7-300 à un réseau Profibus DP avec un câble en cuivre, vous pouvez utiliser le module CP 342-5.


2. Réseaux de niveau supérieur

Des réseaux de niveau supérieur de systèmes de contrôle de processus automatisés sont utilisés pour transférer des données entre les contrôleurs, les serveurs et les postes de travail des opérateurs. Parfois, ces réseaux incluent des nœuds supplémentaires : un serveur d'archives central, un serveur d'applications industrielles, une station d'ingénierie, etc. Mais ce sont déjà des options.

Quels réseaux sont utilisés au niveau supérieur du système de contrôle des processus ? Contrairement aux normes de bus de terrain, il n'y a pas beaucoup de variété ici. En fait, la plupart des réseaux de niveau supérieur utilisés dans les systèmes de contrôle de processus modernes sont basés sur la norme Ethernet (IEEE 802.3) ou sur ses variantes plus rapides Fast Ethernet et Gigabit Ethernet. Dans ce cas, le protocole de communication TCP/IP est généralement utilisé. À cet égard, les réseaux de niveau opérateur sont très similaires aux réseaux locaux conventionnels utilisés dans les applications bureautiques. L'utilisation industrielle généralisée des réseaux Ethernet est due aux évidences suivantes :

1) Les réseaux industriels de niveau supérieur connectent de nombreux postes opérateur et serveurs, qui sont dans la plupart des cas des ordinateurs personnels. La norme Ethernet est excellente pour organiser de tels réseaux locaux ; Pour ce faire, vous devez équiper chaque ordinateur uniquement d'un adaptateur réseau (NIC, carte d'interface réseau). De nombreux automates modernes disposent de modules de communication pour la connexion aux réseaux Ethernet (par exemple, le processeur de communication CP 343-1 permet de connecter le S7-300 à un réseau Ethernet industriel).

2) Il existe sur le marché un large choix d'équipements de communication bon marché pour les réseaux Ethernet, y compris ceux spécialement adaptés à un usage industriel.

3) Les réseaux Ethernet ont des taux de transfert de données élevés. Par exemple, la norme Gigabit Ethernet permet le transfert de données à des vitesses allant jusqu'à 1 Go par seconde à l'aide d'un câble à paire torsadée de catégorie 5. Comme nous le verrons plus tard, un débit réseau élevé devient extrêmement important pour les applications industrielles.

4) L'utilisation d'un réseau Ethernet au niveau supérieur du système de contrôle de processus automatisé permet de connecter simplement le réseau de contrôle de processus automatisé au réseau local de l'usine (ou de l'entreprise). En règle générale, le réseau local existant d'une usine est basé sur la norme Ethernet. L'utilisation d'une norme de réseau unique permet de simplifier l'intégration des systèmes de contrôle de processus automatisés dans le réseau global de l'entreprise.

Cependant, les réseaux industriels du niveau supérieur des systèmes de contrôle de processus automatisés ont leurs propres spécificités, déterminées par les conditions d'application industrielle. Les exigences typiques pour de tels réseaux sont :

1. Bande passante élevée et vitesse de transfert de données. Le volume de trafic dépend directement de nombreux facteurs : le nombre de paramètres technologiques archivés et visualisés, le nombre de serveurs et de postes opérateur, les applications applicatives utilisées, etc. Contrairement aux réseaux de terrain, il n'y a pas d'exigence stricte de déterminisme : à proprement parler, peu importe le temps qu'il faut pour transférer un message d'un nœud à un autre - 100 ms ou 700 ms (bien sûr, cela n'a pas d'importance tant qu'il est dans des limites raisonnables). L'essentiel est que le réseau dans son ensemble puisse faire face au volume total de trafic sur une certaine période. Le trafic le plus intense transite par des sections du réseau reliant les serveurs et les postes opérateurs (clients). Cela est dû au fait qu'au poste opérateur, les informations technologiques sont mises à jour en moyenne une fois par seconde et plusieurs milliers de paramètres technologiques peuvent être transmis. Mais même ici, il n'y a pas de restrictions de temps strictes : l'opérateur ne remarquera pas si les informations sont mises à jour, par exemple toutes les secondes et demie au lieu de celles requises. Dans le même temps, si le contrôleur (avec un cycle de scrutation de 100 ms) rencontre un retard de 500 ms dans l'arrivée de nouvelles données du capteur, cela peut entraîner un traitement incorrect des algorithmes de contrôle.

2. Tolérance aux pannes. Ceci est généralement réalisé grâce à des équipements de communication et des lignes de communication redondants selon le schéma 2*N, de sorte qu'en cas de panne de commutateur ou de rupture de canal, le système de contrôle soit capable de localiser l'emplacement de la panne dans le temps le plus court possible (pas plus de 1 à 3 s) et effectuez une restructuration automatique de la topologie et une redirection du trafic vers des routes de secours.

3. Conformité des équipements réseau aux conditions d'exploitation industrielles. Cela implique des mesures techniques aussi importantes que : - la protection des équipements de réseau contre la poussière et l'humidité ; - plage de température de fonctionnement étendue ; - cycle de vie augmenté; - possibilité d'installation pratique sur un rail DIN ; - alimentation basse tension avec redondance ; -Connecteurs et connecteurs durables et résistants à l'usure.

Les fonctions des équipements de réseau industriels ne diffèrent pratiquement pas de celles de leurs homologues de bureau, mais en raison de leur conception spéciale, cela coûte un peu plus cher. La figure 1 montre, à titre d'exemple, des photographies de commutateurs de réseau industriels prenant en charge une topologie de réseau redondante.

Fig. 1 Commutateurs industriels SCALANCE X200 de Siemens (à gauche) et LM8TX de Phoenix Contact (à droite) : montage sur rail DIN

Lorsqu'on parle de réseaux industriels construits sur la technologie Ethernet, le terme Ethernet industriel est souvent utilisé, faisant ainsi allusion à leur vocation industrielle. Il existe actuellement de nombreuses discussions sur la séparation de l'Ethernet industriel en une norme industrielle distincte, mais pour le moment, l'Ethernet industriel n'est qu'une liste de recommandations techniques pour l'organisation des réseaux dans les environnements industriels et constitue, à proprement parler, un ajout non formalisé à la spécification de la couche physique de la norme Ethernet.

Il existe un autre point de vue sur ce qu'est l'Ethernet industriel. Le fait est que récemment, de nombreux protocoles de communication ont été développés sur la base de la norme Ethernet et optimisés pour la transmission de données à temps critique. De tels protocoles sont classiquement appelés protocoles temps réel, ce qui signifie qu'ils peuvent être utilisés pour organiser des échanges de données entre des applications distribuées dont le temps est critique et nécessitent une synchronisation temporelle précise. Le but ultime est d’atteindre un déterminisme relatif dans le transfert de données. Exemples d'Ethernet industriel :

  • Profinet ;
  • EtherCAT ;
  • Ethernet Powerlink ;
  • Éther/IP.

Ces protocoles modifient le protocole TCP/IP standard à des degrés divers, en ajoutant de nouveaux algorithmes d'échange réseau, des fonctions de diagnostic, des méthodes d'autocorrection et des fonctions de synchronisation. Dans le même temps, la liaison de données Ethernet et les couches physiques restent inchangées. Cela permet d'utiliser de nouveaux protocoles de transfert de données sur les réseaux Ethernet existants à l'aide d'équipements de communication standard.

Protocoles de communication dans les systèmes de contrôle de processus automatisés

Dans les systèmes d'automatisation modernes, en raison de la modernisation constante de la production, la tâche de construire des réseaux industriels distribués utilisant des protocoles de transfert de données flexibles est de plus en plus rencontrée.


Il est révolu le temps où une immense armoire contenant des équipements était placée quelque part dans la salle de contrôle, avec des kilomètres d'épais faisceaux de câbles menant à des capteurs et à des actionneurs. Aujourd'hui, dans la grande majorité des cas, il est beaucoup plus rentable d'installer plusieurs contrôleurs locaux regroupés en un seul réseau, économisant ainsi sur l'installation, les tests, la mise en service et la maintenance par rapport à un système centralisé.


Pour organiser les réseaux industriels, de nombreuses interfaces et protocoles de transfert de données sont utilisés, par exemple Modbus, Ethernet, CAN, HART, PROFIBUS, etc. Ils sont nécessaires à la transmission des données entre capteurs, contrôleurs et actionneurs (AM) ; étalonnage du capteur ; alimentation pour capteurs et MI ; connexions entre les niveaux inférieurs et supérieurs du système de contrôle de processus automatisé. Les protocoles sont développés en tenant compte des spécificités des systèmes de production et techniques, garantissant une connexion fiable et une grande précision du transfert de données entre les différents appareils. Outre un fonctionnement fiable dans des conditions difficiles, la fonctionnalité, la flexibilité de conception, la facilité d'intégration et de maintenance ainsi que le respect des normes industrielles deviennent des exigences de plus en plus importantes dans les systèmes de contrôle de processus automatisés.


Le système de classification le plus courant pour les protocoles réseau est le modèle théorique OSI ( modèle de référence de base pour l'interaction des systèmes ouverts, anglais. Modèle de référence de base pour l'interconnexion des systèmes ouverts). La spécification de ce modèle a finalement été adoptée en 1984 par l'Organisation internationale de normalisation (ISO). Conformément au modèle OSI, les protocoles sont divisés en 7 couches, situées les unes au-dessus des autres, selon leur finalité - du physique (génération et reconnaissance de signaux électriques ou autres) à l'application (API de transfert d'informations par applications). L'interaction entre les niveaux peut s'effectuer aussi bien verticalement qu'horizontalement (Fig. 1). Dans la communication horizontale, les programmes nécessitent un protocole commun pour échanger des données. Dans la verticale - à travers les interfaces.


Riz. 1. Modèle OSI théorique.


Couche d'application

Couche d'application - couche d'application ( Anglais Couche d'application). Fournit une interaction entre le réseau et les applications utilisateur qui va au-delà du modèle OSI. Les protocoles suivants sont utilisés à ce niveau : HTTP, Gopher, Telnet, DNS, SMTP, SNMP, CMIP, FTP, TFTP, SSH, IRC, AIM, NFS, NNTP, NTP, SNTP, XMPP, FTAM, APPC, X.400. , X .500, AFP, LDAP, SIP, ITMS, Modbus TCP, BACnet IP, IMAP, POP3, SMB, MFTP, BitTorrent, eD2k, PROFIBUS.


Niveau exécutif

Niveau exécutif ( Anglais Couche de présentation) - niveau de présentation des données. Cette couche peut effectuer une conversion de protocole et une compression/décompression ou un encodage/décodage des données, ainsi que rediriger les requêtes vers une autre ressource réseau si elles ne peuvent pas être traitées localement. Il convertit les requêtes d'application reçues de la couche application dans un format de transmission sur le réseau et convertit les données reçues du réseau dans un format compréhensible par les applications. Les protocoles suivants appartiennent traditionnellement à ce niveau : HTTP, ASN.1, XML-RPC, TDI, XDR, SNMP, FTP, Telnet, SMTP, NCP, AFP.


Couche de session

Niveau de session ( Anglais Couche de session) gère la création/termination d'une session de communication, l'échange d'informations, la synchronisation des tâches, la détermination du droit de transférer des données et le maintien d'une session pendant les périodes d'inactivité des applications. La synchronisation de la transmission est assurée en plaçant des points de contrôle dans le flux de données, à partir desquels le processus reprend si l'interaction est interrompue. Protocoles utilisés : ASP, ADSP, DLC, Named Pipes, NBT, NetBIOS, NWLink, Printer Access Protocol, Zone Information Protocol, SSL, TLS, SOCKS.


Couche de transport

Couche de transport ( Anglais Couche de transport) organise la livraison des données sans erreurs, pertes et duplications dans l'ordre dans lequel elles ont été transmises. Divise les données en fragments de taille égale, en combinant les plus courts et en divisant les longs (la taille des fragments dépend du protocole utilisé). Protocoles utilisés : TCP, UDP, NetBEUI, AEP, ATP, IL, NBP, RTMP, SMB, SPX, SCTP, DCCP, RTP, TFTP.


Couche réseau

Couche réseau ( Anglais Couche réseau) définit les chemins de transfert de données. Responsable de la traduction des adresses et des noms logiques en adresses physiques, de la détermination des itinéraires les plus courts, de la commutation et du routage, et de la surveillance des problèmes et de la congestion du réseau. Protocoles utilisés : IP, IPv6, ICMP, IGMP, IPX, NWLink, NetBEUI, DDP, IPSec, ARP, RARP, DHCP, BootP, SKIP, RIP.


Couche de liaison de données

Couche de liaison ( Anglais Couche de liaison de données) est conçu pour assurer l'interaction des réseaux au niveau physique. Les données reçues de la couche physique sont vérifiées pour détecter les erreurs, corrigées si nécessaire, regroupées dans des trames, vérifiées pour leur intégrité et envoyées à la couche réseau. La couche liaison de données peut communiquer avec une ou plusieurs couches physiques. La spécification IEEE 802 divise cette couche en 2 sous-couches - MAC (Media Access Control) régule l'accès au support physique partagé, LLC (Logical Link Control) fournit le service de couche réseau. Protocoles utilisés : STP, ARCnet, ATM, DTM, SLIP, SMDS, Ethernet, FDDI, Frame Relay, LocalTalk, Token ring, StarLan, L2F, L2TP, PPTP, PPP, PPPoE, PROFIBUS.


Couche physique

Couche physique ( Anglais Couche physique) est destiné directement à transmettre un flux de données. Transmet des signaux électriques ou optiques dans une émission par câble ou radio et, en conséquence, les reçoit et les convertit en bits de données conformément aux méthodes de codage des signaux numériques. Protocoles utilisés : RS-232, RS-422, RS-423, RS-449, RS-485, ITU-T, xDSL, RNIS, T1, E1, 10BASE-T, 10BASE2, 10BASE5, 100BASE-T, 1000BASE-T , 1000BASE-TX, 1000BASE-SX.


Comme vous l’avez peut-être remarqué, de nombreux protocoles sont mentionnés à plusieurs niveaux à la fois. Cela indique que le modèle théorique est incomplet et éloigné des protocoles réseau réels, de sorte que la liaison de certains d'entre eux aux niveaux OSI est conditionnelle.


Dans la pratique mondiale, parmi les réseaux d'usage général, le protocole le plus utilisé est HTTP (Anglais HyperText Transfer Protocol - « protocole de transfert hypertexte »). Fait référence aux couches d'application et de présentation du modèle théorique OSI. HTTP est basé sur la technologie client-serveur, c'est-à-dire qu'il existe un consommateur (client) qui initie la connexion et envoie une demande, et un fournisseur (serveur) qui attend que la connexion reçoive la demande, effectue les actions nécessaires et renvoie un message avec le résultat. Le principal type de client HTTP est un navigateur, tel que Mozilla Firefox, Opera ou Microsoft Internet Explorer. HTTP est désormais largement utilisé sur le World Wide Web pour récupérer des informations sur des sites Web.


Riz. 2. Technologie client-serveur.


Des protocoles étendus ont été développés basés sur HTTP : HTTPS ( Anglais Protocole de transfert hypertexte sécurisé de), qui prend en charge le chiffrement, et HTTP-NG ( Anglais HTTP nouvelle génération), augmentant les performances du Web et élargissant les possibilités des applications industrielles.


Côtés positifs : facilité de développement d'applications client, possibilité d'étendre le protocole en ajoutant vos propres en-têtes, utilisation généralisée du protocole.


Côtés négatifs : taille de message importante par rapport aux données binaires, manque de navigation dans les ressources du serveur, impossibilité d'utiliser l'informatique distribuée.


création de centres de contrôle à distance, applications Web pour systèmes SCADA, logiciels pour contrôleurs industriels, organisation de vidéosurveillance.


Aujourd'hui, le protocole HTTP et ses modifications sont pris en charge par le matériel et les logiciels de la plupart des fabricants. Examinons quelques-uns d'entre eux.


Dans les équipements Korenix de la série JetNet, JetRock, JetPort, JetI/O, JetBox (réseau basé sur Ethernet industriel), JetWave (solutions sans fil) de la famille HTTP sont utilisés pour organiser l'accès, configurer et gérer les appareils.


ICPDAS propose les équipements et logiciels suivants pour travailler avec le protocole HTTP. Les contrôleurs des séries HRAK, WinPAC, WinCon, LinPAC, ViewPAC fonctionnent sous les systèmes d'exploitation Windows et Linux, avec un serveur HTTP intégré. Les progiciels InduSoft (SCADA), ISaGRAF, Web HMI, VXCOMM, MiniOS7 Studio utilisent également un serveur HTTP pour communiquer et interagir avec les appareils.


Les commutateurs gérés, les ordinateurs embarqués et les équipements de réseaux sans fil industriels fabriqués par Moha ne peuvent se passer de l'utilisation des protocoles de la famille HTTP.


Riz. 3. Compatibilité des protocoles de la famille Modbus.


Pour organiser l'interaction entre les éléments d'automatisation dans les réseaux de données industriels, le protocole de communication Modbus est largement utilisé. Il existe trois implémentations principales du protocole Modbus, deux pour la transmission de données sur des lignes de communication série, toutes deux en cuivre EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485). , optique et radio : Modbus RTU et Modbus ASCII, et pour la transmission de données sur réseaux Ethernet via TCP/IP : Modbus TCP.


La différence entre les protocoles Modbus ASCII et Modbus RTU réside dans la manière dont les caractères sont codés. En mode ASCII, les données sont codées à l'aide d'une table ASCII, où chaque caractère correspond à deux octets de données. En mode RTU, les données sont transmises sous forme de caractères binaires de 8 bits, ce qui offre des taux de transfert de données plus élevés. ASCII autorise des délais allant jusqu'à 1 seconde, contrairement à RTU, où les messages doivent être continus. De plus, le mode ASCII dispose d'un système de décodage et de gestion des données simplifié.


La famille de protocoles Modbus (Modbus ASCII, Modbus RTU et Modbus TCP/IP) utilise le même protocole d'application, ce qui garantit leur compatibilité. Le nombre maximum de nœuds de réseau dans un réseau Modbus est de 31. La longueur des lignes de communication et la vitesse de transfert des données dépendent de la mise en œuvre physique de l'interface. Les éléments du réseau Modbus communiquent à l'aide d'un modèle client-serveur basé sur des transactions de requête et de réponse.


En règle générale, le réseau ne comporte qu'un seul client, appelé appareil « maître », et plusieurs serveurs, appelés appareils « esclaves ». L'appareil maître initie les transactions (transmet les requêtes). Les appareils esclaves transmettent les données demandées par l'appareil maître ou effectuent les actions demandées. Le maître peut s'adresser à l'esclave individuellement ou lancer un message diffusé à tous les esclaves. Le dispositif esclave génère un message et le renvoie en réponse à une requête qui lui est spécifiquement adressée.


Applications industrielles:


La facilité d’utilisation des protocoles de la famille Modbus dans l’industrie a conduit à leur généralisation. Aujourd'hui, les équipements de presque tous les fabricants prennent en charge les protocoles Modbus.


La société ICPDAS propose une large gamme d'équipements de communication pour organiser des réseaux basés sur les protocoles de la famille Modbus : série I-7000 (passerelles DeviceNet, serveurs Modbus, contrôleurs de communication adressables) ; contrôleurs programmables des séries HRAK, WinPAC, WinCon, LinPAC, ViewPAC.


Les panneaux de commande fabriqués par Weintek et les convertisseurs de fréquence Control Techniques utilisent également le protocole Modbus pour communiquer avec les contrôleurs.


Traditionnellement, les protocoles de la famille Modbus sont pris en charge par les serveurs OPC des systèmes SCADA (Clear SCADA, Control Microsystems, InTouch Wonderware, TRACE MODE) pour la communication avec les éléments de contrôle (contrôleurs, VFD, régulateurs, etc.).


Riz. 4. Réseau Profibus.


En Europe, le réseau industriel ouvert PROFIBUS (PROcess FIeld BUS) s'est largement répandu. Dans un premier temps, un prototype de ce réseau a été développé par Siemens pour ses contrôleurs industriels.


PROFIBUS combine les caractéristiques technologiques et fonctionnelles de la communication série au niveau du terrain. Il vous permet de combiner des dispositifs d'automatisation disparates en un seul système au niveau des capteurs et des variateurs. Le réseau PROFIBUS s'appuie sur plusieurs standards et protocoles, utilisant l'échange de données entre maître et esclaves (protocoles DP et PA) ou entre plusieurs maîtres (protocoles FDL et FMS).


Le réseau PROFIBUS peut être associé à trois couches du modèle OSI : couche physique, liaison de données et couche application.


Le protocole unique d'accès au bus pour toutes les versions de PROFIBUS est le protocole PROFIBUS-FDL implémenté au deuxième niveau du modèle OSI. Ce protocole utilise une procédure d'accès par jeton. Tout comme les réseaux basés sur les protocoles Modbus, un réseau PROFIBUS se compose d'appareils maîtres et esclaves. L'appareil maître peut contrôler le bus. Lorsqu'un appareil maître dispose de droits d'accès au bus, il peut transmettre des messages sans requête à distance. Les appareils esclaves sont des périphériques ordinaires et ne disposent pas de droits d'accès au bus, c'est-à-dire qu'ils ne peuvent accuser réception des messages reçus ou transmettre des messages au périphérique maître que sur demande. Dans une configuration minimale, le réseau peut être constitué soit de deux maîtres, soit d'un maître et d'un esclave.


Les mêmes canaux de communication du réseau PROFIBUS permettent l'utilisation simultanée de plusieurs protocoles de transfert de données. Regardons chacun d'eux.


PROFIBUS DP (Decentralized Peripheral) est un protocole visant à assurer un échange de données à haut débit entre les appareils maîtres DP et les appareils d'E/S distribués. Le protocole se caractérise par un temps de réponse minimal et une résistance élevée aux champs électromagnétiques externes. Optimisé pour les systèmes à grande vitesse et à faible coût.


PROFIBUS PA (Process Automation) est un protocole d'échange de données avec des équipements de terrain situés dans des zones normales ou dangereuses. Le protocole permet de connecter des capteurs et des actionneurs à un bus linéaire ou à un bus en anneau.


PROFIBUS FMS (Fieldbus Message Spécification - Field Level Message Specification) est un protocole universel permettant de résoudre les problèmes d'échange de données entre les dispositifs de réseau intelligents (contrôleurs, ordinateurs/programmeurs, systèmes d'interface homme-machine) au niveau du terrain. Un analogue de l'Ethernet industriel, généralement utilisé pour la communication à haut débit entre les contrôleurs et les ordinateurs de niveau supérieur.


Tous les protocoles utilisent les mêmes technologies de transfert de données et une méthode d'accès au bus commune, afin de pouvoir fonctionner sur le même bus.


Côtés positifs : ouverture, indépendance vis-à-vis du fournisseur, prévalence.


Applications industrielles: organisation de la communication des capteurs et actionneurs avec le contrôleur, communication des contrôleurs et des ordinateurs de contrôle, communication avec les capteurs, contrôleurs et réseaux d'entreprise, dans les systèmes SCADA.


L'essentiel des équipements utilisant le protocole PROFIBUS sont des équipements de la société SIEMENS. Mais depuis peu, ce protocole est utilisé par la plupart des constructeurs. Cela est dû en grande partie à la prédominance des systèmes de contrôle basés sur les contrôleurs Siemens.


Riz. 5. Réseau Profibus basé sur l'équipement ICP DAS.


Pour la mise en œuvre de projets basés sur PROFIBUS, ICPDAS propose un certain nombre de dispositifs esclaves : passerelles PROFIBUS/Modbus de la série GW, convertisseurs PROFIBUS vers RS-232/485/422 de la série I-7000, modules et cadres d'E/S déportés. du PROFIBUS de la série PROFI-8000. Actuellement, les ingénieurs ICPDAS mènent des développements intensifs dans le domaine de la création d'un appareil maître PROFIBUS.

Télécharger le document

NORME D'ÉTAT DE L'UNION URSS

INTERFACE
POUR AUTOMATISÉ
SYSTÈMES DE CONTRÔLE
OBJETS DISTRIBUÉS

EXIGENCES GÉNÉRALES


K.I. Didenko, doctorat technologie. les sciences; Yu.V. Rosen ; KG. Karnaukh ; MARYLAND. Gafanovitch, doctorat technologie. les sciences; K.M. Oussenko ; Zh.A. Guseva ; L.S. La fille; S.N. Kiiko

INTRODUIT par le Ministère de l'Instrumentation, de l'Automatisation et des Systèmes de Contrôle

Membre du Conseil N.I. Gorelikov

APPROUVÉ ET ENTRÉ EN VIGUEUR par la résolution du Comité d'État des normes de l'URSS du 30 mars 1984 n° 1145

NORME D'ÉTAT DE L'UNION URSS


jusqu'au 01/01/90

Le non-respect de la norme est puni par la loi

Cette norme s'applique à l'interface qui réglemente les règles générales d'organisation de l'interaction des sous-systèmes locaux dans le cadre de systèmes de contrôle automatisés d'objets distribués utilisant une structure de communication fédérée (ci-après dénommée l'interface).

En termes de mise en œuvre physique, la norme s'applique aux interfaces des agrégats qui utilisent des signaux électriques pour transmettre des messages.

1. OBJECTIF ET CHAMP D'APPLICATION

1.1. L'interface est conçue pour organiser la communication et l'échange d'informations entre les sous-systèmes locaux dans le cadre de systèmes de contrôle automatisés pour les processus technologiques, les machines et les équipements dans diverses industries et zones non industrielles.


interface avec le personnel opérationnel et technologique;

interface avec les complexes informatiques de contrôle de niveau supérieur dans les systèmes hiérarchiques.

2. PRINCIPALES CARACTÉRISTIQUES

2.1. L'interface implémente une méthode synchrone bit-série de transmission de signaux de données numériques sur un canal interurbain à deux fils.

2.2. L'atténuation totale du signal entre la sortie de la station émettrice et l'entrée de la station réceptrice ne doit pas dépasser 24 dB, tandis que l'atténuation introduite par la ligne de communication (canal principal et prises) ne doit pas dépasser 18 dB, a contribué par chaque appareil de communication avec la ligne - pas plus de 0, 1 dB.

Note. Lors de l'utilisation d'un câble de type RK-75-4-12, la longueur maximale de la ligne de communication (y compris la longueur des branches) est de 3 km.


(Nouvelle édition, Amendement n°1).

2.5. Pour représenter les signaux, il faut utiliser une modulation biphasée avec codage par différence de phase.

2.6. Pour la protection par code des messages transmis, un code cyclique avec un polynôme générateur doit être utilisé X 16 + X 12 + X 5 + 1.

2.7. Afin d'éliminer les erreurs aléatoires, il doit être possible de retransmettre des messages entre les mêmes sous-systèmes locaux.

2.8. La transmission de messages entre sous-systèmes locaux doit être effectuée à l'aide d'un ensemble limité d'octets de fonction, dont la séquence est établie par le format du message. L'interface établit deux types de formats de message (Figure 1).

Le format 1 a une longueur fixe et est destiné uniquement à la transmission de messages d'interface.

Le format 2 comprend une partie informationnelle de longueur variable destinée à la transmission de données.

Le format 2, selon la vitesse de transmission (plage basse ou haute vitesse), devrait ressembler respectivement à 2.1 ou 2.2.

Types de formats de messages

Format 1

2.9. Les formats de message doivent inclure les octets de fonction suivants :

synchronisation CH ;

adresse du sous-système AB local appelé ;

code de la fonction réalisée CF ;

propre adresse du sous-système local de l'AS ;

nombre d'octets de données dans la partie information de DS, DS1 ou DS2 ;

octets d'informations DN1 - DNp ;

octets de code de contrôle KB1 et KB2.

2.8, 2.9.

2.9.1. L'octet de synchronisation CH sert à indiquer le début et la fin d'un message. L'octet de synchronisation reçoit le code ?111111?.

2.9.2. L'octet d'adresse du sous-système AB identifie le sous-système local vers lequel le message est acheminé.

2.9.3. L'octet de fonction CF effectué détermine l'opération qui est effectuée dans un cycle de communication donné. La fonction des bits à l’intérieur de l’octet CF est illustrée à la Fig. 2.

Structure d'octet KF

2.9.4. Les codes CF et les opérations correspondantes effectuées sont indiqués dans le tableau.

Désignation d'octet

Code de fonction

Opération à effectuer

Multicast (adressage général)

Écrire lire

Interrogation centralisée des contrôleurs

Transfert de contrôle de la chaîne principale

Reprendre le contrôle du canal principal. Le message avec l'adresse générale n'a pas été accepté

Reprendre le contrôle du canal principal. Message avec adresse générale accepté

Interrogation décentralisée des contrôleurs. Aucune demande de saisie de la chaîne. Le message avec l'adresse générale n'a pas été accepté

Demande de saisie de la chaîne principale. Le message avec l'adresse générale n'a pas été accepté

Demande de saisie de la chaîne principale. Message avec adresse générale accepté

Passer un jeton

Confirmation des messages

Confirmation de l'émission du message

Confirmation de réception et émission ultérieure d'un message. Réponses à une enquête centralisée

Aucune demande de saisie de la chaîne. Le message avec l'adresse générale n'a pas été accepté

Aucune demande de saisie de la chaîne. Message avec adresse générale accepté

Demande de saisie d'une chaîne. Le message avec l'adresse générale n'a pas été accepté

Demande de saisie d'une chaîne. Message avec adresse générale accepté

Le bit zéro détermine le type de message (défi-réponse) transmis sur le canal interurbain.

Le bit 1 prend une valeur unique lorsque le sous-système est occupé (par exemple, formation d'un tampon de données).

Le bit 2 prend une seule valeur si un message de format 2 est transmis dans ce cycle.

Le bit 3 prend la valeur un dans un message renvoyé au même sous-système local si une erreur est détectée ou s'il n'y a pas de réponse.

(Édition modifiée, amendement n° 1).

2.9.5. La propre adresse du sous-système local qui génère le message AC est émise afin d'informer le sous-système appelé de l'adresse de réponse et de vérifier l'exactitude de son choix.

2.9.6. L'octet DS détermine la longueur de la partie information au format 2.1, tandis que la valeur du code binaire de l'octet DS détermine le nombre d'octets DN. L'exception est le code ?????????, ce qui signifie que 256 octets d'informations sont transmis.

Les octets DS1, DS2 déterminent la longueur de la partie information au format 2.2.

(Édition modifiée, amendement n° 1).

2.9.7. Les octets de données DN représentent la partie information d'un message de format 2. Le codage des données doit être établi par les documents réglementaires pour les sous-systèmes locaux associés.

2.9.8. Les octets de contrôle KB1, KB2 forment la partie contrôle et sont utilisés pour déterminer la fiabilité des messages transmis.

3. STRUCTURE DE L'INTERFACE

3.1. L'interface offre la possibilité de créer des systèmes distribués avec une structure de communication de base (Fig. 3).

Structure de connexion des sous-systèmes locaux

LC1 - LCn- les sous-systèmes locaux ; MK- canal principal ; PC- résistance adaptée

3.2. Tous les sous-systèmes locaux interfacés doivent être connectés au canal principal par lequel les informations sont échangées.

3.3. Pour interfacer les sous-systèmes locaux avec le canal principal, ils doivent inclure des contrôleurs de communication. Les contrôleurs de communication doivent :

convertir les informations de la forme de présentation acceptée dans le sous-système local en la forme requise pour la transmission sur le canal principal ;

ajouter et mettre en évidence des signes de synchronisation ;

reconnaissance et réception de messages adressés à ce sous-système local ;

génération et comparaison de codes de contrôle pour déterminer la fiabilité des messages reçus.

3.4. Les échanges de messages entre sous-systèmes locaux doivent être organisés sous forme de cycles. Par cycle, on entend la procédure de transmission d'un message de format 1 ou 2 vers le canal principal. Plusieurs cycles interconnectés forment le processus de transmission.

3.5. Le processus de transmission doit être organisé selon le principe asynchrone : le sous-système local doit recevoir des réponses aux appels envoyés vers le canal principal (à l'exception des opérations de groupe).

4. FONCTIONS DE L'INTERFACE

4.1. L'interface établit les types de fonctions suivants, différant par les niveaux de contrôle, qui occupent les sous-systèmes locaux dans le processus de messagerie :

réception passive;

réception et réponse;

gestion décentralisée du canal principal ;

demande de saisie de la chaîne principale ;

contrôle centralisé du canal principal.

(Édition modifiée, amendement n° 1).

4.2. La composition des fonctions d'interface mises en œuvre par le sous-système local est déterminée par la composition du problème résolu par ce sous-système et ses caractéristiques fonctionnelles.

4.3. Le type de sous-système local est déterminé par la fonction de niveau le plus élevé parmi celles proposées. Le sous-système local est considéré comme actif par rapport à la fonction qu'il remplit dans le cycle en cours.

4.4. Conformément à la composition des fonctions d'interface implémentées, on distingue les types de sous-systèmes locaux suivants :

sous-système contrôlé passif ;

sous-système contrôlé ;

sous-système de contrôle ;

sous-système de contrôle proactif ;

sous-système leader.

4.4.1. Le sous-système contrôlé passif effectue uniquement l'identification et la réception des messages qui lui sont adressés.

4.4.2. Le sous-système contrôlé reçoit des messages qui lui sont adressés et génère un message de réponse conformément au code de fonction reçu.

4.4.3. Le sous-système de contrôle doit avoir la capacité de :

accepter le contrôle des échanges sur le canal principal en modes centralisé et décentralisé ;

générer et transmettre des messages sur le canal principal ;

recevoir et analyser les messages de réponse ;

contrôle de retour ou de transfert du canal principal après la fin du processus de transfert.

(Édition modifiée, amendement n° 1).

4.4.4. Le sous-système de contrôle proactif, en plus de la fonction conforme à la clause 4.4.3, doit avoir la capacité de générer un signal de demande pour saisir le canal principal, recevoir et envoyer des messages correspondants lors de l'exécution de la procédure de recherche pour le sous-système demandeur.

4.4.5. Le sous-système principal coordonne le travail de tous les sous-systèmes locaux en mode de contrôle centralisé du canal principal. Elle réalise :

arbitrage et transfert du contrôle du canal principal à l'un des sous-systèmes locaux de contrôle ;

contrôle central de tous les sous-systèmes locaux ;

surveiller le fonctionnement du sous-système local de commande active ;

transmission de messages avec une adresse commune pour tous (ou plusieurs) sous-systèmes locaux.

Un seul sous-système doté d'une fonction maître active peut être connecté au canal principal.

(Édition modifiée, amendement n° 1).

5. PROCÉDURE D'ÉCHANGE DE MESSAGES

5.1. Chaque cycle de transmission de messages sur le canal principal doit commencer par la synchronisation de tous les sous-systèmes connectés via l'interface.

5.1.1. Pour effectuer la synchronisation, le sous-système maître ou de contrôle actif doit transmettre l'octet de synchronisation CH au canal principal. Il est possible de transmettre plusieurs octets de synchronisation de manière séquentielle. Les octets de synchronisation supplémentaires ne sont pas inclus dans le format du message.

5.1.2. Une fois que tous les sous-systèmes se sont synchronisés, le sous-système maître ou de contrôle actif envoie un message de format 1 ou 2 à la liaison réseau, comprenant ses propres octets CH.

5.1.3. Tous les octets, à l'exception des contrôles KB1 et KB2, sont transmis au canal principal, en commençant par le bit le moins significatif.

Les octets KB1, KB2 sont transmis à partir du bit de poids fort.

5.1.4. Pour exclure du message transmis au canal principal une séquence de bits qui coïncide avec le code de l'octet CH, chaque message doit être converti de telle manière qu'après 5 caractères « 1 » consécutifs, un caractère « 0 » supplémentaire doit être inclus. . Le sous-système récepteur doit donc exclure ce caractère du message.

5.1.5. Après avoir transmis le message, y compris l'octet de fin CH, le sous-système émetteur doit transmettre au moins 2 octets CH supplémentaires pour terminer les opérations de réception, après quoi le cycle de transmission se termine.

5.2. La procédure de commande de canal interurbain détermine la séquence d'opérations permettant d'activer l'un des sous-systèmes de commande pour exécuter le processus de transmission de message. Les sous-systèmes connectés via une interface peuvent fonctionner en mode de contrôle centralisé du canal principal.

5.2.1. La procédure de contrôle centralisé du canal principal prévoit la présence d'un sous-système leader, qui coordonne l'interaction des sous-systèmes en gérant le transfert de contrôle du canal principal.

5.2, 5.2.1. (Nouvelle édition, Amendement n°1).

5.2.2. Lors du transfert du contrôle de la liaison interurbaine, le sous-système maître désigne le sous-système de contrôle actif pour effectuer le processus de transfert de message. Pour ce faire, le sous-système leader doit envoyer un message de format 1 avec le code fonction KF6 au sous-système de contrôle sélectionné.

5.2.3. Après avoir reçu un message avec le code de fonction KF6, le sous-système de contrôle doit devenir actif et peut effectuer plusieurs cycles d'échange de messages en un seul processus de transmission. Le nombre de cycles d'échange doit être contrôlé et limité par le sous-système maître.

5.2.4. Après avoir transféré le contrôle du canal principal, le sous-système principal doit activer la fonction de réception passive et activer la synchronisation de contrôle. Si, dans le délai défini (le temps d'attente de réponse ne doit pas dépasser 1 ms), le sous-système actif désigné ne commence pas à transmettre des messages sur le canal interurbain, le sous-système principal renvoie un message de format 1 avec le code de fonction KF6 et le signe de retransmission au sous-système de contrôle.

5.2.5. Si, lors d'accès répétés, le sous-système de contrôle ne commence pas à transmettre des messages (ne devient pas actif), le sous-système principal le détermine comme défectueux et met en œuvre les procédures prévues pour une telle situation.

5.2.6. À la fin du processus de transfert, le sous-système de contrôle actif doit remplir la fonction de retour du contrôle du canal interurbain. Pour ce faire, il doit envoyer un message au sous-système leader avec le code fonction KF7 ou KF8.

5.2.7. La procédure de contrôle décentralisé du canal principal prévoit le transfert séquentiel de la fonction active vers d'autres sous-systèmes de contrôle en passant un jeton. Le sous-système qui a accepté le jeton est actif.

5.2.8. Pour la capture initiale du jeton, tous les sous-systèmes connectés via le canal principal doivent inclure des minuteries d'intervalle et les valeurs des intervalles de temps doivent être différentes pour tous les sous-systèmes. Le sous-système ayant une priorité plus élevée doit se voir attribuer un intervalle de temps plus petit.

5.2.9. Si, après l'expiration de l'intervalle de temps propre au sous-système, le canal interurbain est libre, ce sous-système doit se considérer comme propriétaire du jeton et commencer le processus de transmission en tant que sous-système de commande actif.

5.2.10. Une fois le processus de transfert terminé, le sous-système de contrôle actif doit transférer le contrôle du canal principal au sous-système de contrôle suivant avec l'adresse AB = AC + 1, pour lequel il doit émettre un marqueur, activer lui-même la fonction de réception passive et allumer le contrôler le timing.

Un message de format 1 (Fig. 1) avec le code fonction KF13 et l'adresse AB est utilisé comme marqueur.

Si dans le délai spécifié, le sous-système qui a reçu le jeton ne commence pas le processus de transmission, le sous-système qui l'a envoyé doit tenter de transmettre le jeton aux sous-systèmes avec les adresses suivantes AB = AC + 2, AB = AC + 3, etc. jusqu'à ce que le jeton soit accepté. L'adresse du sous-système qui a reçu le jeton doit être mémorisée par ce sous-système comme une adresse ultérieure jusqu'à ce que l'acquisition initiale soit répétée.

5.2.11. Tout sous-système actif qui détecte une sortie non autorisée vers le canal de communication doit effectuer les actions décrites à la clause 5.2.8.

5.2.12. En mode de contrôle décentralisé du canal principal, tous les sous-systèmes doivent avoir une fonction de réception passive active. En cas de perte de jeton (par exemple, si le sous-système de contrôle actif tombe en panne), le mécanisme initial de capture de jeton doit être déclenché (clauses 5.2.8, 5.2.9) et le fonctionnement doit être rétabli.

5.2.13. Tout sous-système qui possède un jeton et a reçu une fonction de maître actif peut prendre le contrôle centralisé du canal interurbain et le maintenir jusqu'à ce que la fonction de maître actif qui lui est attribuée soit annulée.

5.2.7 - 5.2.13. (Introduit en plus, amendement n° 1).

5.3. En mode de contrôle centralisé, le transfert de contrôle du canal principal peut être organisé en fonction des demandes des sous-systèmes de contrôle proactifs.

5.3.1. Les sous-systèmes doivent disposer d'une fonction de demande de capture de canal principal active pour organiser le transfert de contrôle sur demande.

5.3.2. Il existe deux manières possibles d'organiser la recherche d'un sous-système demandant l'accès au canal principal : centralisée et décentralisée.

5.3, 5.3.1, 5.3.2. (Nouvelle édition, Amendement n°1).

5.3.3. Avec l'interrogation centralisée, le sous-système principal doit interroger séquentiellement tous les sous-systèmes de contrôle proactif connectés au canal principal. Le sous-système principal doit envoyer un message de format 1 avec le code de fonction KF5 à chaque sous-système de contrôle proactif.

Le sous-système de contrôle initiateur doit envoyer un message de réponse au sous-système principal avec l'un des codes de fonction KF21 - KF24, en fonction de son état interne. La séquence des opérations dans la procédure d'enquête centralisée est illustrée à la Fig. 4.

5.3.4. L'interrogation décentralisée fournit un processus rapide pour identifier les sous-systèmes de contrôle proactifs qui ont établi une demande d'accès au canal fédérateur. Le sous-système principal doit contacter uniquement le premier sous-système de contrôle proactif avec un message de format 1 et le code de fonction KF9.

Chaque sous-système de contrôle proactif doit recevoir un message qui lui est adressé et envoyer tour à tour son propre message adressé au sous-système suivant vers le canal principal. Le message généré doit contenir l'un des codes fonction KF9 - KF12, qui caractérise l'état de ce sous-système. La procédure d'enquête décentralisée est illustrée dans la Fig. 5.

5.3.5. Le sous-système principal, après avoir lancé l'interrogation décentralisée, active la fonction de réception passive et reçoit tous les messages envoyés par les sous-systèmes de contrôle proactif. Cela permet au sous-système leader, après la fin de l'interrogation décentralisée, d'avoir des informations sur les demandes d'accès au canal principal émanant de tous les sous-systèmes de contrôle proactif.

Processus d'interrogation centralisée du sous-système

Processus d'interrogation du sous-système décentralisé

Le dernier sous-système de contrôle d'initiative dans la chaîne du scrutin décentralisé doit adresser son message au sous-système leader, ce qui signifie la fin de la procédure de scrutin décentralisé.

5.3.6. Si un sous-système n'envoie pas de messages au canal principal après y avoir accédé, le sous-système principal doit se réveiller et lui envoyer un message répété identique au précédent. S'il n'y a pas de réponse (ou d'erreurs) à un appel répété, le sous-système leader lance à son tour une interrogation décentralisée à partir du sous-système suivant, et ce sous-système est exclu de l'interrogation.

5.4. La procédure de transfert de données peut être effectuée sous la forme de l'un des processus suivants :

enregistrement de groupe;

écrire lire.

5.4.1. L'enregistrement de groupe doit être effectué par le sous-système maître. Lors de l'exécution d'un enregistrement de groupe, le sous-système maître émet un message de format 2 sur le canal principal, dans lequel le code 11111111 (255) et le code de fonction KF1 sont écrits comme adresse AB.

5.4.2. Tous les sous-systèmes répondant à l'adresse de multidiffusion doivent accepter le message provenant de la liaison interurbaine et enregistrer un état indiquant que le message d'adresse publique a été accepté. Les messages de réponse lors de l'enregistrement de groupe ne sont pas émis par les sous-systèmes de réception.

5.4.3. La confirmation de réception d'un message de groupe est effectuée lors du processus d'interrogation centralisée ou décentralisée, ainsi que lors du retour du contrôle du canal principal, pour lequel le bit d'état correspondant est inclus dans les codes de fonction KF7, KF8, KF9 - KF12 et KF21 - KF24.

5.4.4. Pendant le processus d'enregistrement, le sous-système maître ou le sous-système de contrôle actif envoie au canal principal un message de format 2 avec le code de fonction KF2, destiné à la réception par un sous-système contrôlé spécifique, dont l'adresse est indiquée dans l'octet AB. Après avoir émis un message, le sous-système de contrôle actif active le compte à rebours de contrôle et attend un message de réponse.

5.4.5. Le sous-système adressé reconnaît son adresse et reçoit le message qui lui est envoyé. Si le message est reçu sans erreur, le sous-système récepteur doit émettre une réponse au canal principal sous la forme d'un message de format 1 avec le code fonction KF18.

5.4.6. Si une erreur est détectée dans un message reçu, le sous-système récepteur ne doit pas émettre de réponse.

5.4.7. Le sous-système de contrôle actif, s'il n'y a pas de réponse pendant l'intervalle de temps de contrôle, doit retransmettre le même message.

5.4.8. S'il n'y a pas de réponse à un message répété, ce sous-système est considéré comme défectueux et le sous-système de contrôle actif doit exécuter la procédure prescrite pour une telle situation (activation de l'alarme, mise hors service du sous-système, activation de la réserve, etc.).

5.4.9. En mode de contrôle centralisé du canal principal, le dialogue entre les sous-systèmes de contrôle et contrôlés doit être constamment surveillé par le sous-système principal, qui remplit à ce moment la fonction de réception passive des messages.

(Nouvelle édition, Amendement n°1).

5.4.10. Le processus de lecture doit commencer par l'envoi d'un message de format 1 avec le code fonction KF3 par le sous-système de contrôle actif.

5.4.11. Le sous-système auquel ce message est adressé, s'il est reçu correctement, doit émettre un message de réponse de format 2 avec le code fonction KF19.

5.4.12. Si le sous-système appelé ne peut pas émettre de données dans le délai d'attente spécifié, après avoir reçu le message avec la fonction de lecture, il doit enregistrer le signe indiquant que le sous-système est occupé et commencer à former un tableau de données à émettre.

5.4.13. Ce sous-système géré doit mémoriser l'adresse du sous-système de contrôle actif qui l'a adressé (pour lequel des données sont en cours de préparation) et définir les messages de réponse de connexion occupé aux autres sous-systèmes de contrôle.

5.4.14. Pour lire les données préparées, le sous-système de contrôle actif doit à nouveau contacter le sous-système contrôlé avec un message au format 1 avec le code fonction KF3. Si les données sont préparées à ce moment-là, le sous-système contrôlé doit alors émettre un message de réponse de format 2 avec le code fonction KF19.

Le signe d'occupation du sous-système ne doit être effacé qu'après la transmission d'un message de réponse de format 2.

5.4.15. Si le message de réponse est reçu par le sous-système de contrôle actif sans erreur, le processus de lecture se termine.

5.4.16. Si une erreur est détectée ou s'il n'y a pas de réponse, le sous-système de contrôle actif répète l'appel et prend ensuite des mesures similaires à celles données dans les paragraphes. 5.4.7, 5.4.8.

5.4.17. L'écriture-lecture est une combinaison de processus selon les paragraphes. 5.4.4 - 5.4.15.

5.4.18. Le sous-système de contrôle actif envoie un message de format 2 avec le code de fonction KF4 au canal principal.

5.4.19. Le sous-système adressé doit accepter le message qui lui est envoyé et générer une réponse.

5.4.20. Le message de réponse dans ce processus doit être au format 2 (contenir les données lues) et avoir le code fonction KF20.

5.4.21. La surveillance de la fiabilité des messages transmis et des actions prises par le sous-système de contrôle actif doit être similaire à celle donnée pour les processus d'écriture et de lecture.

6. MISE EN ŒUVRE PHYSIQUE

6.1. Physiquement, l'interface est implémentée sous la forme de lignes de communication qui forment un canal fédérateur et de contrôleurs de communication qui assurent une connexion directe aux lignes de communication.

6.2. Les contrôleurs de communication doivent être mis en œuvre sous la forme d'unités fonctionnelles faisant partie du sous-système, ou sous la forme de dispositifs structurellement séparés.

6.3. Les règles d'appariement et d'interaction des contrôleurs de communication avec la partie fonctionnelle du sous-système ne sont pas réglementées par cette norme.

6.4. Pour les lignes de communication principales, un câble coaxial avec une impédance caractéristique de 75 Ohms doit être utilisé.

6.5. Le câble coaxial doit être chargé aux deux extrémités avec des résistances correspondantes d'une résistance de (75 ± 3,75) Ohms. La puissance des résistances correspondantes doit être d'au moins 0,25 W.

Les résistances de terminaison doivent être connectées aux extrémités des lignes de communication à l'aide de connecteurs RF.

La mise à la terre ou la connexion des lignes de communication aux boîtiers d'appareils dans les sous-systèmes correspondants n'est pas autorisée.

6.6. L'atténuation le long de la ligne de communication du canal principal ne doit pas dépasser 18 dB pour une vitesse de 500 kbit/s.

6.7. L'atténuation totale introduite par chaque branche à partir de la ligne de communication du canal principal ne doit pas dépasser 0,1 dB, y compris l'atténuation déterminée par la qualité du point de jonction, l'atténuation sur la branche et l'atténuation dépendant des paramètres d'entrée-sortie des circuits d'adaptation.

6.8. Les dérivations de la ligne de communication du canal principal doivent être réalisées avec un câble coaxial d'une impédance caractéristique de 75 Ohms. La longueur de chaque branche ne dépasse pas 3 m. La longueur totale de toutes les branches est incluse dans la longueur totale du canal principal. La connexion à la ligne de communication doit être effectuée à l'aide de connecteurs RF. La désactivation de l'un des sous-systèmes ne doit pas entraîner une rupture de la ligne de communication.

6.9. Les contrôleurs de communication doivent contenir des amplificateurs émetteurs-récepteurs qui fournissent :

sensibilité de réception, pas pire.................................................. ...... ...... 240 mV

niveau du signal de sortie ............................................ ..................................... 4 à 5 V

impédance de sortie................................................. ........ .............................. (37,50 ± 1,88) Ohms

6.10. La formation des signaux électriques à transmettre au canal principal est réalisée en modulant la fréquence d'horloge avec les signaux du message transmis. Chaque bit du message transmis correspond à une période complète de la fréquence d'horloge, et les fronts montant et descendant du signal transmis doivent coïncider avec la transition par zéro de la fréquence d'horloge (Fig. 6). La correspondance des symboles reçus du canal principal avec les états significatifs est établie comme suit :

le symbole « 0 » correspond à la phase inverse par rapport au symbole précédent,



Avez-vous aimé l'article? Partagez-le