Interface homme-machine du système de contrôle automatisé Cours TP. Brève description des interfaces ICS

Mode d'emploi

1. Introduction
1.1. Champ d'application………………………………………………………………. 3
1.2. Brève description opportunité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.

Logiciel et matériel - progiciel ACS TP "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 automatisé "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 les installations industrielles à des fins diverses et tout niveau de complexité, avec leur intégration dans les processus technologiques et le flux documentaire de l’entreprise, ainsi que l’utilisation des 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 divers appareils- Module contrôleur ACS TP "Débit pondéral" +
dans le système

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

5. Supplémentaire lieu de travail- Module ACS TP « 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. 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">

L'échange d'informations entre les appareils faisant partie d'un système automatisé (ordinateurs, contrôleurs, capteurs, actionneurs) s'effectue généralement via réseau industriel(Fieldbus, "bus de terrain") [Cucej].

Réseau local(Local Area Network) - réseaux situés dans une zone limitée (dans un atelier, un bureau, au sein d'une usine) ;
HOMME(Réseaux métropolitains) - réseaux de villes;
BLÊME(Réseau à grande distance) - un réseau mondial couvrant plusieurs villes ou continents. La technologie Internet est généralement utilisée à cet effet.

Il existe actuellement plus de 50 types de réseaux industriels (Modbus, Profibus, DeviceNet, CANopen, LonWorks, ControlNet, SDS, Seriplex, ArcNet, BACnet, FDDI, FIP, FF, ASI, Ethernet, WorldFIP, Foundation Fieldbus, Interbus, BitBus , etc. .). Cependant, seules quelques-unes d’entre elles sont répandues. En Russie, la grande majorité des systèmes de contrôle de processus automatisés utilisent les réseaux Modbus et Profibus. Ces dernières années, l'intérêt pour les réseaux basés sur CANopen et DeviceNet s'est accru. La prédominance de l'un ou l'autre réseau industriel en Russie est liée avant tout aux préférences et à l'activité des entreprises russes vendant des équipements importés.

2.1. Informations générales sur les réseaux industriels

Réseau industriel appelé un ensemble d'équipements et logiciel, qui assurent l'échange d'informations (communication) entre plusieurs appareils. Réseau industriel constitue la base de la création de systèmes distribués de collecte et de contrôle de données.

Étant donné que dans l'automatisation industrielle, les interfaces réseau peuvent faire partie intégrante des appareils connectés et que le logiciel réseau de couche d'application du modèle OSI est exécuté sur le processeur principal du contrôleur industriel, il est parfois physiquement impossible de séparer la partie réseau des appareils mis en réseau. . D'un autre côté, le passage d'un réseau à un autre peut souvent être réalisé en changeant le logiciel réseau et l'adaptateur réseau ou en introduisant un convertisseur d'interface, si bien que le même type d'automate peut souvent être utilisé dans différents types de réseaux.

La connexion d'un réseau industriel avec ses composants (appareils, nœuds de réseau) s'effectue à l'aide interfaces. Une interface réseau est une frontière logique et (ou) physique entre un appareil et le support de transmission d'informations. Généralement, cette frontière est un ensemble de composants électroniques et de logiciels associés. Avec des modifications significatives de la structure interne de l'appareil ou du logiciel, l'interface reste inchangée, ce qui est l'une des caractéristiques qui permettent de distinguer l'interface comme faisant partie de l'équipement.

Les paramètres les plus importants de l'interface sont la bande passante et la longueur maximale du câble connecté. Les interfaces industrielles assurent généralement une isolation galvanique entre les appareils connectés. Les interfaces série les plus courantes dans l'automatisation industrielle sont RS-485, RS-232, RS-422, Ethernet, CAN, HART et AS-interface.

Pour échanger des informations, les appareils en interaction doivent avoir le même protocole d'échange. DANS forme la plus simple Un protocole est un ensemble de règles qui régissent l'échange d'informations. Il définit la syntaxe et la sémantique des messages, les opérations de contrôle, la synchronisation et les états de communication. Le protocole peut être implémenté sous forme matérielle, logicielle ou micrologicielle. Le nom du réseau coïncide généralement avec le nom du protocole, ce qui s'explique par son rôle décisif dans la création du réseau. En Russie, des protocoles réseau sont utilisés, décrits dans une série de normes [GOST - GOST].

Généralement, un réseau utilise plusieurs protocoles qui constituent pile de protocoles- un ensemble de protocoles de communication associés qui fonctionnent ensemble et utilisent tout ou partie des sept couches du modèle OSI [Guide]. Pour la plupart des réseaux, la pile de protocoles est implémentée à l'aide de puces réseau spécialisées ou intégrée à un microprocesseur à usage général.

L'interaction des appareils dans les réseaux industriels est réalisée conformément aux modèles serveur client ou éditeur-abonné (producteur-consommateur) [Thomesse]. Dans le modèle client-serveur, deux objets interagissent. Un serveur est un objet qui fournit un service, c'est-à-dire qui effectue certaines actions à la demande d'un client. Un réseau peut contenir plusieurs serveurs et plusieurs clients. Chaque client peut envoyer des requêtes à plusieurs serveurs et chaque serveur peut répondre aux requêtes de plusieurs clients. Ce modèle est utile pour transmettre des données qui se produisent périodiquement ou à des moments prédéterminés, telles que les valeurs de température dans un processus par lots. Cependant, ce modèle est peu pratique pour transmettre des événements aléatoires, par exemple un événement consistant en une activation aléatoire d'un capteur de niveau, car pour recevoir cet événement, le client doit périodiquement, avec une fréquence élevée, demander l'état du capteur et analyser cela, surchargeant le réseau avec un trafic inutile.

Les méthodes modernes de conception des activités des utilisateurs de systèmes de contrôle automatisés se sont développées dans le cadre d'un concept de conception d'ingénierie système, grâce auquel la prise en compte du facteur humain se limite à résoudre les problèmes de coordination des « entrées » et des « sorties » de une personne et une machine. Dans le même temps, lors de l'analyse de l'insatisfaction des utilisateurs des systèmes de contrôle automatisé, il est possible de révéler qu'elle s'explique souvent par l'absence d'une approche unifiée et intégrée de la conception des systèmes d'interaction, présentée comme une considération globale, interconnectée et proportionnelle. de tous les facteurs, voies et méthodes permettant de résoudre la tâche complexe multifactorielle et multivariée de conception d'une interface d'interaction. Cela fait référence à des facteurs fonctionnels, psychologiques, sociaux et même esthétiques.

À l'heure actuelle, il peut être considéré comme prouvé que la tâche principale de la conception d'une interface utilisateur n'est pas d'« intégrer » rationnellement une personne dans la boucle de contrôle, mais de, sur la base des tâches de contrôle des objets, développer un système d'interaction entre deux égaux. partenaires (opérateur humain et complexe matériel et logiciel ACS), gérant rationnellement l'objet de contrôle. L'opérateur humain est le maillon de fermeture du système de contrôle, c'est-à-dire sujet de gestion. APK (complexe matériel-logiciel) ACS est outil de mise en œuvre ses activités de gestion (opérationnelles) (de l'opérateur), c'est-à-dire objet de contrôle. Selon la définition de V.F. Venda, un système de contrôle automatisé est une intelligence hybride dans laquelle le personnel opérationnel (de direction) et le complexe agro-industriel du système de contrôle automatisé sont des partenaires égaux dans la résolution de problèmes de gestion complexes. L'interface de l'interaction humaine avec les moyens techniques du système de contrôle automatisé peut être représentée structurellement (voir Fig. 1.).

Riz. 1. Informations et schéma logique de l'interface d'interaction

L'organisation rationnelle du travail des opérateurs de systèmes de contrôle automatisés est l'un des facteurs les plus importants déterminant le fonctionnement efficace du système dans son ensemble. Dans l'écrasante majorité des cas, le travail de gestion est une activité humaine indirecte, puisque dans les conditions d'un système de contrôle automatisé, il gère sans « voir » l'objet réel. Entre l'objet de contrôle réel et l'opérateur humain, il y a modèle d'informations sur les objets(moyens d'affichage d'informations). Dès lors, se pose le problème de concevoir non seulement des moyens d'affichage d'informations, mais également des moyens d'interaction entre l'opérateur humain et les moyens techniques du système de contrôle automatisé, c'est-à-dire problème de conception du système, que nous devrions appeler interface utilisateur.

Il se compose d’APK et de protocoles d’interaction. Le complexe matériel et logiciel assure les fonctions suivantes :

transformation des données circulant dans le système de contrôle automatisé en modèles d'informations affichés sur des moniteurs (SOI - outils d'affichage d'informations) ;

régénération des modèles d'information (IM);

assurer l'interaction de dialogue entre une personne et le système de contrôle automatisé ;

transformation des influences provenant du PO (opérateur humain) en données utilisées par le système de contrôle ;

mise en œuvre physique des protocoles d'interaction (harmonisation des formats de données, contrôle des erreurs, etc.).

Le but des protocoles est de fournir un mécanisme permettant la transmission fiable et fiable de messages entre l'opérateur humain et le SOI et, par conséquent, entre le PO et le système de contrôle. Protocole- c'est une règle qui définit l'interaction, un ensemble de procédures d'échange d'informations entre processus parallèles en temps réel. Ces processus (le fonctionnement du complexe agro-industriel du système de contrôle automatisé et les activités opérationnelles du sujet de contrôle) se caractérisent, d'une part, par l'absence de relations temporelles fixes entre l'apparition des événements et, d'autre part, par l'absence de interdépendance entre les événements et les actions lors de leur survenance.

Les fonctions du protocole sont liées à l'échange de messages entre ces processus. Le format et le contenu de ces messages constituent les caractéristiques logiques du protocole. Les règles d'exécution des procédures déterminent les actions effectuées par les processus qui participent conjointement à la mise en œuvre du protocole. L'ensemble de ces règles constitue la caractéristique procédurale du protocole. Grâce à ces concepts, nous pouvons désormais définir formellement un protocole comme un ensemble de caractéristiques logiques et procédurales d'un mécanisme de communication entre processus. La définition logique constitue la syntaxe et la définition procédurale constitue la sémantique du protocole.

Générer une image à l'aide d'APC permet non seulement d'obtenir des images bidimensionnelles projetées sur un plan, mais également de réaliser des graphiques tridimensionnels utilisant des plans et des surfaces du second ordre avec transfert de la texture de la surface de l'image.

Lors de la création de systèmes de contrôle automatisés complexes, le développement de logiciels revêt une grande importance, car C'est un logiciel qui crée l'intelligence d'un ordinateur qui résout des problèmes scientifiques complexes et contrôle les processus technologiques les plus complexes. Actuellement, lors de la création de tels systèmes, le rôle du facteur humain et, par conséquent, le support ergonomique du système augmente considérablement. La tâche principale du support ergonomique est d'optimiser l'interaction entre l'homme et la machine, non seulement pendant le fonctionnement, mais également lors de la fabrication et de l'élimination des composants techniques. Ainsi, lors de la systématisation de l'approche de la conception de l'interface utilisateur, nous pouvons donner quelques tâches fonctionnelles de base et principes de conception que le système doit résoudre.

Principe de l'effectif minimum développeur et utilisateur de logiciels, qui comporte deux aspects :

minimiser les coûts des ressources de la part du développeur de logiciels, ce qui est obtenu en créant une certaine méthodologie et une certaine technologie de création caractéristiques des processus de production conventionnels ;

minimiser les coûts de ressources de la part de l'utilisateur, c'est-à-dire Le PO doit effectuer uniquement le travail nécessaire et ne peut pas être effectué par le système, il ne doit pas y avoir de répétition du travail déjà effectué, etc.

La tâche d’une compréhension mutuelle maximale l'utilisateur et le complexe agro-industriel représenté par l'éditeur du logiciel. Ceux. L'OP ne doit pas, par exemple, rechercher des informations, ou les informations affichées sur le dispositif de contrôle vidéo ne doivent pas nécessiter un recodage ou une interprétation supplémentaire de la part de l'utilisateur.

L'utilisateur doit mémoriser le moins d'informations possible, car cela réduit la capacité de l’entreprise privée à prendre des décisions opérationnelles.

Principe de concentration maximale l'utilisateur sur le problème en cours de résolution et la localisation des messages d'erreur.

Le principe de comptabilisation des compétences professionnelles opérateur humain. Cela signifie que lors du développement d'un système, sur la base de certaines données initiales sur le contingent possible de candidats spécifiés dans les spécifications techniques, un « composant humain » est conçu en tenant compte des exigences et des caractéristiques de l'ensemble du système et de ses sous-systèmes. La formation d'un modèle conceptuel d'interaction entre une personne et les moyens techniques d'un système de contrôle automatisé signifie la connaissance et la maîtrise des algorithmes de fonctionnement du sous-système « moyens humains-techniques » et la maîtrise des compétences professionnelles d'interaction avec un ordinateur.

Clé pour créer interface efficace est dans un jeûne, autant que possible, présentation par l'opérateur d'un modèle conceptuel simple de l'interface. L’accès utilisateur partagé y parvient grâce à la cohérence. Le concept de cohérence est que lorsqu'il travaille avec un ordinateur, l'utilisateur développe un système d'attente des mêmes réactions aux mêmes actions, ce qui renforce constamment le modèle d'interface de l'utilisateur. La cohérence, en permettant le dialogue entre l'ordinateur et l'opérateur humain, peut réduire le temps nécessaire à l'utilisateur pour apprendre l'interface et l'utiliser pour effectuer une tâche.

La cohérence est une propriété d'une interface permettant d'améliorer les perceptions des utilisateurs. Un autre composant de l'interface est la propriété de son caractère concret et de sa clarté. Cela se fait en appliquant un plan de panneau, en utilisant des couleurs et d'autres techniques expressives. Les idées et les concepts sont ensuite exprimés physiquement sur un écran avec lequel l'utilisateur interagit directement.

En pratique, la conception de l'interface utilisateur de haut niveau précède la conception initiale, ce qui permet d'identifier les fonctionnalités requises de l'application en cours de création, ainsi que les caractéristiques de ses utilisateurs potentiels. Les informations spécifiées peuvent être obtenues en analysant les spécifications techniques d'un système de contrôle automatisé (ACS) et le manuel d'utilisation (OM) de l'objet de contrôle, ainsi que les informations reçues des utilisateurs. A cet effet, une enquête auprès des opérateurs potentiels et des opérateurs travaillant sur un objet de contrôle non automatisé est réalisée.

Après avoir déterminé les buts et objectifs auxquels ils sont confrontés, ils passent à l’étape de conception suivante. Cette étape est associée à la création de scénarios utilisateurs. Un scénario est une description des actions effectuées par l'utilisateur pour résoudre un problème spécifique en vue d'atteindre son objectif. Il est évident qu’un certain objectif peut être atteint en résolvant un certain nombre de problèmes. L'utilisateur peut résoudre chacun d'entre eux de plusieurs manières, c'est pourquoi plusieurs scénarios doivent être générés. Plus ils sont nombreux, moins il est probable que certains objets et opérations clés soient manqués.

Parallèlement, le développeur dispose des informations nécessaires pour formaliser les fonctionnalités de l'application. Et une fois les scénarios générés, la liste des fonctions individuelles est connue. Dans une application, une fonction est représentée par un bloc fonction avec le(s) masque(s) correspondant(s). Il est possible que plusieurs fonctions soient combinées en un seul bloc fonctionnel. Ainsi, à ce stade, le nombre requis de formulaires de sélection est établi. Il est important de définir les relations de navigation des blocs fonctionnels. En pratique, le nombre de connexions le plus approprié pour un bloc est fixé à trois. Parfois, lorsque la séquence de fonctions est strictement définie, une connexion procédurale peut être établie entre les blocs fonctionnels correspondants. Dans ce cas, leurs masques sont appelés séquentiellement les uns des autres. De tels cas ne se produisent pas toujours, c'est pourquoi les liens de navigation sont formés soit sur la base de la logique de traitement des données avec lesquelles l'application fonctionne, soit sur la base des perceptions des utilisateurs (tri des cartes). Les connexions de navigation entre les blocs fonctionnels individuels sont affichées sur le diagramme du système de navigation. Les capacités de navigation de l'application sont transmises à travers divers éléments de navigation.

L'élément de navigation principal de l'application est le menu principal. Le rôle du menu principal est également important car il assure une interaction interactive dans le système utilisateur-application. De plus, le menu remplit indirectement la fonction de formation de l'utilisateur à travailler avec l'application.

La création du menu commence par une analyse des fonctions de l'application. Pour ce faire, au sein de chacun d'eux, on distingue des éléments distincts : les opérations effectuées par les utilisateurs et les objets sur lesquels ces opérations sont effectuées. Par conséquent, on sait quels blocs fonctionnels doivent permettre à l'utilisateur d'effectuer quelles opérations sur quels objets. Il est pratique de sélectionner des opérations et des objets en fonction de scénarios utilisateur et des fonctionnalités de l'application. Les éléments sélectionnés sont regroupés dans des sections communes du menu principal. Le regroupement des éléments individuels s'effectue conformément aux idées sur leur connexion logique. Ainsi, le menu principal peut avoir des menus en cascade, liste déroulante lors de la sélection d'une section. Le menu en cascade fait correspondre la liste des sous-sections à la section principale.

L'une des exigences des menus est leur standardisation, dont le but est de créer un modèle utilisateur stable pour travailler avec l'application. Il existe des exigences avancées du point de vue de la normalisation qui concernent l'emplacement des titres de sections, le contenu des sections souvent utilisées dans différentes applications, la forme des titres, l'organisation des menus en cascade, etc. Les recommandations de normalisation les plus générales sont les suivantes :

les groupes de sections fonctionnellement liées sont séparés par des séparateurs (barre ou espace vide) ;

n'utilisez pas d'expressions dans les titres de section (de préférence pas plus de 2 mots) ;

Les noms de sections commencent par une lettre majuscule ;

les noms des sections de menu associées aux boîtes de dialogue d'appel se terminent par des points de suspension ;

les noms des sections de menu qui incluent des menus en cascade se terminent par une flèche ;

utiliser des clés accès rapide aux sections de menu individuelles. Ils sont mis en évidence en soulignant ;

autoriser l'utilisation de " Raccourcis clavier", les combinaisons de touches correspondantes sont affichées dans les en-têtes des sections de menu ;

permettre l'inclusion d'icônes dans le menu ;

les couleurs modifiées indiquent l'inaccessibilité de certaines sections de menu lors de l'utilisation de l'application ;

vous permettent de rendre invisibles les sections inaccessibles.

Certaines sections de menu ne sont pas disponibles pour les raisons suivantes. Le menu principal est statique et est présent à l'écran pendant tout le temps que vous travaillez avec l'application. Ainsi, lorsque vous travaillez avec différentes formes d'écran (en interaction avec différents blocs fonctionnels), toutes les sections de menu n'ont pas de sens. Ces sections sont généralement inaccessibles. Par conséquent, en fonction du contexte des tâches que l'utilisateur résout (parfois du contexte de l'utilisateur lui-même), le menu principal de l'application est différent. Il est habituel de parler de représentations de menu externes aussi différentes que de différents états de menu. Contrairement au schéma du système de navigation élaboré précédemment et principalement nécessaire au développeur, l'utilisateur interagit directement avec le menu. Le menu détermine le nombre de fenêtres et leur type. L'ensemble de l'interface est accompagné de fenêtres d'avertissement, de fenêtres d'indices et de fenêtres d'assistant qui spécifient la séquence d'actions de l'utilisateur lors de l'exécution de certaines opérations nécessaires.

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 au sein systèmes automatisés gestion d'objets dispersés à l'aide de la structure de communication de base (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 de processus technologiques, de machines et d'é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, en fonction de 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 à réaliser
Désignation d'octet		Opération à réaliser
		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 messages. 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 messages. 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. S'il n'y a pas de réponse dans l'intervalle de temps de contrôle, le sous-système de contrôle actif 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,