Siete na prenos dát v automatizovaných riadiacich systémoch. Stručný popis rozhraní ICS Proces dotazovania decentralizovaného subsystému

softvér ACS čs je klient-server riešenie postavené na platforme MS SQL Server verzie 2005 a vyššej a poskytuje oddelenie prístupových práv k dátam z metrologickej služby podnikov. Verzie komplexu ACS MS sú poskytované pre prácu s jednou aj distribuovanou databázou (objem databázy - až 150 000 SI). Funkcionalita automatizovaného riadiaceho systému MS zabezpečuje účtovníctvo, plánovanie, riadenie údržby a analýzu stavu prístrojového parku. Špeciálna úloha „Prevzatie-výdaj meradiel“ pre kalibračné laboratórium umožňuje minimalizovať mzdové náklady na zadávanie údajov a prípravu podkladov na základe výsledkov servisu. Užívateľské práva pre prácu v rôznych dátových sekciách konfiguruje administrátor MS ACS v závislosti od špecifík metrologickej servisnej organizácie.

Rozhranie ACS MS vám umožňuje v závislosti od úlohy prijímať akékoľvek informačné časti údajov a vytvárať o nich správy. Univerzálny filter je doplnený o zjednodušenú funkciu vzorkovania. Pri prispôsobovaní formulára obrazovky sa poskytujú nasledujúce stupne voľnosti: používateľská definícia požadovanej sady kariet, stĺpcov, ako aj ich poradie a šírka, triedenie údajov podľa ľubovoľnej kombinácie stĺpcov a ľubovoľný výber údajov v tabuľke. Udalosti strojárstva, opravy, poruchy, údržba sú zobrazené na obrazovke v tabuľkovej forme s možnosťou analyzovať nahromadené štatistiky.

Elektronický pas SI okrem základných účtovných informácií a služobných predpisov obsahuje:

• História udalostí v prevádzke.
• Zoznam komponentových zariadení (ak ide o pas pre súpravu alebo kanál).
• Odkazy na pasy kanálov alebo komplexov (ak je zariadenie súčasťou kanála).
• Súbor meraných parametrov.
• Množstvo drahých kovov.
• Ďalšie charakteristiky si.

Správca MS ACS určí účtovnú politiku a nakonfiguruje obraz pasu, pričom skryje nepotrebné polia a karty.

Metrologické plány kontroly a opráv je možné generovať pomocou overovacích (opravných) cyklov. Vytvára sa plán údržby. Na základe harmonogramov a taríf uložených v databáze sa vypočítajú plánované náklady na údržbu. Mzdové náklady na vykonávanie údržby sú vypočítané na základe harmonogramov a časových štandardov uložených v databáze.

Reporty v automatizovanom riadiacom systéme MS sú generované pomocou generátora FastReport; konfiguruje sa množina a šírka stĺpcov, písmo, farba atď.; zostavy sa ukladajú vo formátoch rtf, xls, html. Knižnicu správ, ktorá je súčasťou dodávky MS ACS, je možné doplniť podľa požiadaviek užívateľa.

Moderné metódy navrhovania činností používateľov automatizovaných riadiacich systémov sa vyvinuli v rámci systémového inžinierskeho konceptu projektovania, vďaka čomu je zohľadnenie ľudského faktora obmedzené na riešenie problémov koordinácie „vstupov“ a „výstupov“ človek a stroj. Zároveň pri analýze nespokojnosti používateľov automatizovaných riadiacich systémov je možné odhaliť, že sa často vysvetľuje nedostatkom jednotného, ​​integrovaného prístupu k návrhu interakčných systémov, prezentovaného ako komplexná, prepojená, proporcionálna úvaha. všetkých faktorov, spôsobov a metód riešenia zložitej multifaktoriálnej a multivariačnej úlohy návrhu interakčného rozhrania. Týka sa to funkčných, psychologických, sociálnych a dokonca aj estetických faktorov.

V súčasnosti možno považovať za preukázané, že hlavnou úlohou návrhu používateľského rozhrania nie je racionálne „zapadnúť“ človeka do riadiacej slučky, ale na základe úloh riadenia objektu vyvinúť systém interakcie medzi dvoma rovnakými partnermi (ľudský operátor a hardvérový a softvérový komplex ACS), racionálne riadia objekt riadenia. Ľudský operátor je uzatváracím článkom riadiaceho systému, t.j. predmet riadenia. APK (hardvérovo-softvérový komplex) ACS je implementačný nástroj jeho (prevádzkovateľskej) riadiacej (prevádzkovej) činnosti, t.j. riadiaci objekt. Automatizovaný riadiaci systém je podľa definície V.F. Vendu hybridná inteligencia, v ktorej sú prevádzkový (riadiaci) personál a agropriemyselný komplex automatizovaného riadiaceho systému rovnocennými partnermi pri riešení zložitých problémov riadenia. Rozhranie interakcie človeka s technickými prostriedkami automatizovaného riadiaceho systému možno štrukturálne znázorniť (pozri obr. 1.).

Ryža. 1. Informačná a logická schéma interakčného rozhrania

Racionálna organizácia práce operátorov automatizovaného riadiaceho systému je jedným z najdôležitejších faktorov podmieňujúcich efektívne fungovanie systému ako celku. Riadiaca práca je v drvivej väčšine prípadov nepriamou ľudskou činnosťou, keďže v podmienkach automatizovaného riadiaceho systému sa riadi bez „videnia“ skutočného objektu. Medzi skutočným objektom riadenia a ľudským operátorom existuje objektový informačný model(spôsob zobrazovania informácií). Preto vzniká problém navrhnúť nielen prostriedky na zobrazovanie informácií, ale aj prostriedky interakcie medzi ľudským operátorom a technickými prostriedkami automatizovaného riadiaceho systému, t.j. problém návrhu systému, ktorý by sme mali nazvať používateľské rozhranie.

Pozostáva z APK a interakčných protokolov. Hardvérový a softvérový komplex poskytuje nasledujúce funkcie:

transformácia dát obiehajúcich v automatizovanom riadiacom systéme na informačné modely zobrazované na monitoroch (SOI - information display tools);

regenerácia informačných modelov (IM);

zabezpečenie dialógovej interakcie medzi osobou a automatizovaným riadiacim systémom;

transformácia vplyvov prichádzajúcich z PO (ľudský operátor) na dáta používané riadiacim systémom;

fyzická implementácia interakčných protokolov (harmonizácia dátových formátov, kontrola chýb a pod.).

Účelom protokolov je poskytnúť mechanizmus na spoľahlivé a spoľahlivé doručovanie správ medzi ľudským operátorom a SOI a následne medzi PO a riadiacim systémom. Protokol- ide o pravidlo, ktoré definuje interakciu, súbor postupov na výmenu informácií medzi paralelnými procesmi v reálnom čase. Tieto procesy (fungovanie agropriemyselného komplexu automatizovaného systému kontroly a prevádzkové činnosti subjektu kontroly) sa vyznačujú po prvé absenciou pevných časových vzťahov medzi vznikom udalostí a po druhé absenciou tzv. vzájomná závislosť medzi udalosťami a činmi pri ich výskyte.

Funkcie protokolu súvisia s výmenou správ medzi týmito procesmi. Formát a obsah týchto správ tvoria logické charakteristiky protokolu. Pravidlá pre vykonávanie procedúr určujú akcie vykonávané procesmi, ktoré sa spoločne podieľajú na implementácii protokolu. Súbor týchto pravidiel je procesnou charakteristikou protokolu. Pomocou týchto konceptov môžeme teraz formálne definovať protokol ako súbor logických a procedurálnych charakteristík komunikačného mechanizmu medzi procesmi. Logická definícia tvorí syntax a procedurálna definícia tvorí sémantiku protokolu.

Generovanie obrazu pomocou APC umožňuje získať nielen dvojrozmerné obrazy premietané na rovinu, ale aj realizovať trojrozmernú grafiku pomocou rovín a plôch druhého rádu s prenosom textúry povrchu obrazu.

Pri vytváraní komplexných automatizovaných riadiacich systémov má vývoj softvéru veľký význam, pretože Je to softvér, ktorý vytvára inteligenciu počítača, ktorý rieši zložité vedecké problémy a riadi najzložitejšie technologické procesy. V súčasnosti pri tvorbe takýchto systémov výrazne narastá úloha ľudského faktora a následne aj ergonomická podpora systému. Hlavnou úlohou ergonomickej podpory je optimalizovať interakciu medzi človekom a strojom nielen počas prevádzky, ale aj pri výrobe a likvidácii technických komponentov. Pri systematizácii prístupu k návrhu používateľského rozhrania teda môžeme uviesť niekoľko základných funkčných úloh a princípov návrhu, ktoré by mal systém riešiť.

Princíp minimálnej pracovnej sily vývojár a používateľ softvéru, ktorý má dva aspekty:

minimalizácia nákladov na zdroje na strane vývojára softvéru, čo sa dosiahne vytvorením určitej metodiky a technológie tvorby charakteristickej pre konvenčné výrobné procesy;

minimalizácia nákladov na zdroje na strane užívateľa, t.j. PO by mala vykonávať len prácu, ktorá je nevyhnutná a nemôže ju vykonať systém, nemalo by dochádzať k opakovaniu už vykonanej práce a pod.

Úlohou maximálneho vzájomného porozumenia užívateľ a agropriemyselný komplex reprezentovaný vývojárom softvéru. Tie. PO by sa nemala zapájať napríklad do vyhľadávania informácií alebo informácie zobrazené na zariadení na ovládanie videa by nemali vyžadovať prekódovanie alebo dodatočnú interpretáciu zo strany používateľa.

Používateľ musí zapamätať si čo najmenej informácií, pretože to znižuje schopnosť súkromného podniku robiť operatívne rozhodnutia.

Princíp maximálnej koncentrácie užívateľa o riešenom probléme a lokalizácii chybových hlásení.

Princíp účtovania odborných zručnostíľudský operátor. To znamená, že pri vývoji systému sa na základe niektorých počiatočných údajov o možnom kontingente kandidátov špecifikovaných v technických špecifikáciách navrhne „ľudský komponent“ s ohľadom na požiadavky a charakteristiky celého systému a jeho podsystémov. Vytvorenie konceptuálneho modelu interakcie medzi človekom a technickými prostriedkami automatizovaného riadiaceho systému znamená uvedomenie si a zvládnutie algoritmov pre fungovanie subsystému „človek - technické prostriedky“ a zvládnutie odborných zručností v interakcii s počítačom.

kľúč na tvorbu efektívne rozhranie je v pôste, koľko to len pôjde, operátorova prezentácia jednoduchého koncepčného modelu rozhrania. Zdieľaný používateľský prístup to dosahuje prostredníctvom konzistentnosti. Koncepcia konzistentnosti spočíva v tom, že pri práci s počítačom si používateľ vytvára systém očakávaní rovnakých reakcií na rovnaké akcie, čo neustále posilňuje používateľský model rozhrania. Konzistentnosť, umožnením dialógu medzi počítačom a ľudským operátorom, môže znížiť množstvo času, ktorý používateľ potrebuje na naučenie sa rozhrania a jeho použitie na vykonanie úlohy.

Konzistencia je vlastnosť rozhrania na zlepšenie vnímania používateľov. Ďalším komponentom rozhrania je vlastnosť jeho konkrétnosti a jasnosti. Robí sa to aplikáciou panelového plánu, použitím farieb a iných výrazových techník. Nápady a koncepty sú potom fyzicky vyjadrené na obrazovke, s ktorou používateľ priamo interaguje.

V praxi prvotnému návrhu predchádza návrh používateľského rozhrania na vysokej úrovni, ktorý nám umožňuje identifikovať požadovanú funkcionalitu vytváranej aplikácie, ako aj vlastnosti jej potenciálnych používateľov. Špecifikované informácie možno získať analýzou technických špecifikácií pre automatizovaný riadiaci systém (ACS) a prevádzkovej príručky (OM) pre objekt riadenia, ako aj informácií získaných od používateľov. Za týmto účelom sa vykonáva prieskum potenciálnych operátorov a operátorov pracujúcich na objekte neautomatizovaného riadenia.

Po určení cieľov a cieľov, ktorým čelia, prejdú do ďalšej fázy návrhu. Táto fáza je spojená s tvorbou používateľských scenárov. Scenár je popis akcií vykonaných používateľom na vyriešenie konkrétneho problému na ceste k dosiahnutiu jeho cieľa. Je zrejmé, že určitý cieľ možno dosiahnuť riešením množstva problémov. Každý z nich môže užívateľ vyriešiť niekoľkými spôsobmi, preto je potrebné vygenerovať niekoľko scenárov. Čím viac ich je, tým menšia je pravdepodobnosť, že niektoré kľúčové objekty a operácie budú vynechané.

Zároveň má vývojár informácie potrebné na formalizáciu funkčnosti aplikácie. A po vygenerovaní scenárov je známy zoznam jednotlivých funkcií. V aplikácii je funkcia reprezentovaná funkčným blokom s príslušným formulárom obrazovky. Je možné, že sa niekoľko funkcií spojí do jedného funkčného bloku. V tejto fáze je teda stanovený požadovaný počet obrazoviek. Je dôležité definovať navigačné vzťahy funkčných blokov. V praxi je najvhodnejší počet spojení pre jeden blok nastavený na tri. Niekedy, keď je postupnosť funkcií presne definovaná, je možné vytvoriť procedurálne spojenie medzi zodpovedajúcimi funkčnými blokmi. V tomto prípade sa ich obrazovkové formy volajú postupne jedna od druhej. Nie vždy k takýmto prípadom dochádza, preto sa navigačné prepojenia tvoria buď na základe logiky spracovania údajov, s ktorými aplikácia pracuje, alebo na základe postrehov používateľov (triedenie kariet). Navigačné spojenia medzi jednotlivými funkčnými blokmi sú zobrazené na schéme navigačného systému. Navigačné možnosti v aplikácii sú sprostredkované prostredníctvom rôznych navigačných prvkov.

Hlavným navigačným prvkom aplikácie je hlavné menu.Úloha hlavného menu je tiež skvelá, pretože vykonáva interaktívnu interakciu v systéme používateľ-aplikácia. Menu navyše nepriamo plní funkciu výučby používateľa, ako aplikáciu používať.

Tvorba menu začína analýzou funkcií aplikácie. Na tento účel sa v rámci každého z nich rozlišujú samostatné prvky: operácie vykonávané používateľmi a objekty, na ktorých sa tieto operácie vykonávajú. V dôsledku toho je známe, ktoré funkčné bloky by mali užívateľovi umožniť vykonávať aké operácie na ktorých objektoch. Je vhodné vybrať operácie a objekty na základe užívateľských scenárov a funkčnosti aplikácie. Vybrané prvky sú zoskupené do spoločných sekcií hlavného menu. K zoskupovaniu jednotlivých prvkov dochádza v súlade s predstavami o ich logickom prepojení. teda hlavné menu môže mať kaskádové menu, rozbaľovacia ponuka pri výbere ľubovoľnej sekcie. Kaskádová ponuka sa zhoduje s primárnou sekciou so zoznamom podsekcií.

Jednou z požiadaviek na menu je ich štandardizácia, ktorej účelom je vytvorenie stabilného užívateľského modelu pre prácu s aplikáciou. Z hľadiska štandardizácie existujú požiadavky, ktoré sa týkajú umiestnenia nadpisov sekcií, obsahu sekcií často používaných v rôznych aplikáciách, formy nadpisov, organizácie kaskádových ponúk atď. Najvšeobecnejšie štandardizačné odporúčania sú nasledovné:

skupiny funkčne súvisiacich sekcií sú oddelené oddeľovačmi (čiara alebo prázdne miesto);

nepoužívajte frázy v názvoch sekcií (najlepšie nie viac ako 2 slová);

Názvy sekcií začínajú veľkým písmenom;

názvy sekcií ponuky spojené s volaním dialógových okien sa končia elipsou;

názvy sekcií ponuky, ktoré obsahujú kaskádové ponuky, končia šípkou;

na prístup k jednotlivým častiam ponuky použite klávesové skratky. Sú zvýraznené podčiarknutím;

umožňujú používanie „klávesových skratiek“, zodpovedajúce kombinácie klávesov sa zobrazujú v nadpisoch častí ponuky;

povoliť zahrnutie ikon do ponuky;

zmenené farby indikujú neprístupnosť niektorých častí menu pri práci s aplikáciou;

umožňujú zneviditeľniť neprístupné časti.

Niektoré časti ponuky sú nedostupné z nasledujúcich dôvodov. Hlavné menu je statické a je prítomné na obrazovke počas celej doby práce s aplikáciou. Pri práci s rôznymi formami obrazovky (interakciou s rôznymi funkčnými blokmi) teda nie všetky časti ponuky dávajú zmysel. Takéto úseky sú vo všeobecnosti neprístupné. Preto v závislosti od kontextu úloh, ktoré používateľ rieši (niekedy od kontextu samotného používateľa), hlavné menu aplikácie vyzerá inak. Je zvykom hovoriť o tak odlišných vonkajších zobrazeniach ponuky, ako sú rôzne stavy ponuky. Na rozdiel od skôr zostaveného diagramu navigačného systému, ktorý potrebuje hlavne vývojár, používateľ priamo interaguje s menu. Menu určuje počet okien a ich typ. Celé rozhranie je sprevádzané varovnými oknami, oknami s nápovedami a oknami sprievodcu, ktoré určujú postupnosť akcií používateľa pri vykonávaní určitých potrebných operácií.

Stiahnite si dokument

ŠTÁTNY ŠTANDARD Zväzu ZSSR

ROZHRANIE
PRE AUTOMATIZOVANÉ
KONTROLNÉ SYSTÉMY
DISTRIBUOVANÉ OBJEKTY

VŠEOBECNÉ POŽIADAVKY

K.I. Didenko, Ph.D. tech. vedy; Yu.V. Rosen; K.G. Karnaukh; M.D. Gafanovič, Ph.D. tech. vedy; K.M. Usenko; Zh.A. Guseva; L.S. Lanina; S.N. Kiiko

ZAVEDENÉ Ministerstvom prístrojovej techniky, automatizácie a riadiacich systémov

Člen predstavenstva N.I. Gorelikov

SCHVÁLENÉ A NADÚČANÉ ÚČINNOSTI uznesením Štátneho výboru pre normy ZSSR z 30. marca 1984 č. 1145

ŠTÁTNY ŠTANDARD Zväzu ZSSR

do 01.01.90

Nedodržanie normy sa trestá zákonom

Táto norma sa vzťahuje na rozhranie, ktoré upravuje všeobecné pravidlá organizácie interakcie lokálnych subsystémov ako súčasti automatizovaných riadiacich systémov pre distribuované objekty využívajúce chrbticovú komunikačnú štruktúru (ďalej len rozhranie).

Z hľadiska fyzickej implementácie sa norma vzťahuje na rozhrania agregátov, ktoré na prenos správ využívajú elektrické signály.

1. ÚČEL A ROZSAH POUŽITIA

1.1. Rozhranie je určené na organizovanie komunikácie a výmeny informácií medzi lokálnymi subsystémami ako súčasť automatizovaných riadiacich systémov technologických procesov, strojov a zariadení v rôznych priemyselných odvetviach a nepriemyselných oblastiach.

prepojenie s prevádzkovým a technologickým personálom;

rozhranie s vyššími riadiacimi počítačovými komplexmi v hierarchických systémoch.

2. HLAVNÉ CHARAKTERISTIKY

2.1. Rozhranie implementuje bitovo-sériový synchrónny spôsob prenosu digitálnych dátových signálov cez dvojvodičový hlavný kanál.

2.2. Celkový útlm signálu medzi výstupom vysielacej stanice a vstupom prijímacej stanice by nemal byť väčší ako 24 dB, zatiaľ čo útlm spôsobený komunikačnou linkou (hlavný kanál a odbočky) by nemal byť väčší ako 18 dB. každým komunikačným zariadením s linkou - nie viac ako 0,1 dB.

Poznámka. Pri použití kábla typu RK-75-4-12 je maximálna dĺžka komunikačného vedenia (vrátane dĺžky odbočiek) 3 km.

(Nové vydanie, zmena č. 1).

2.5. Na reprezentáciu signálov sa musí použiť dvojfázová modulácia s kódovaním fázového rozdielu.

2.6. Pre kódovú ochranu prenášaných správ je potrebné použiť cyklický kód s generujúcim polynómom X 16 + X 12 + X 5 + 1.

2.7. Aby sa eliminovali náhodné chyby, musí byť možné opätovne prenášať správy medzi rovnakými lokálnymi subsystémami.

2.8. Prenos správ medzi lokálnymi subsystémami sa musí vykonávať pomocou obmedzeného súboru funkčných bajtov, ktorých postupnosť je určená formátom správy. Rozhranie vytvára dva typy formátov správ (obrázok 1).

Formát 1 má pevnú dĺžku a je určený len na prenos správ rozhrania.

Formát 2 obsahuje informačnú časť s premenlivou dĺžkou určenú na prenos dát.

Formát 2 by mal v závislosti od prenosovej rýchlosti (rozsah nízkej alebo vysokej rýchlosti) vyzerať ako 2.1 alebo 2.2.

Typy formátov správ

Formát 1

2.9. Formáty správ zahŕňajú nasledujúce funkčné bajty:

synchronizácia CH;

adresa volaného lokálneho AB subsystému;

kód vykonávanej funkcie CF;

vlastná adresa lokálneho subsystému AS;

počet dátových bajtov v informačnej časti DS, DS1 alebo DS2;

informačné bajty DN1 - DNp;

bajty riadiaceho kódu KB1 a KB2.

2.8, 2.9.

2.9.1. Synchronizačný bajt CH slúži na označenie začiatku a konca správy. Synchronizačný bajt má priradený kód?111111?.

2.9.2. Bajt adresy podsystému AB identifikuje lokálny podsystém, do ktorého je správa smerovaná.

2.9.3. Vykonaný bajt funkcie CF určuje operáciu, ktorá sa vykoná v danom komunikačnom cykle. Účel bitov vo vnútri CF bajtu je znázornený na obr. 2.

Štruktúra bajtov KF

2.9.4. CF kódy a príslušné vykonané operácie sú uvedené v tabuľke.

Nulový bit určuje typ správy (výzva-odpoveď) prenášanej cez hlavný kanál.

Bit 1 nadobúda jednu hodnotu, keď je podsystém zaneprázdnený (napríklad vytvára vyrovnávaciu pamäť údajov).

Bit 2 nadobudne jednu hodnotu, ak sa v tomto cykle prenesie správa formátu 2.

Bit 3 má hodnotu jedna v opätovne odoslanej správe do rovnakého lokálneho podsystému, ak sa zistí chyba alebo nedôjde k žiadnej odozve.

(Zmenené vydanie, dodatok č. 1).

2.9.5. Vlastná adresa lokálneho subsystému, ktorý generuje AC správu, sa vydáva za účelom informovania volaného subsystému o adrese odpovede a overenia správnosti jej výberu.

2.9.6. Byte DS určuje dĺžku informačnej časti vo formáte 2.1, zatiaľ čo hodnota binárneho kódu bytu DS určuje počet bajtov DN. Výnimkou je kód ?????????, čo znamená, že sa prenesie 256 informačných bajtov.

Bajty DS1, DS2 určujú dĺžku informačnej časti vo formáte 2.2.

(Zmenené vydanie, dodatok č. 1).

2.9.7. Dátové bajty DN predstavujú informačnú časť správy formátu 2 Kódovanie údajov musí byť stanovené regulačnými dokumentmi pre pridružené lokálne podsystémy.

2.9.8. Riadiace bajty KB1, KB2 tvoria riadiacu časť a používajú sa na určenie spoľahlivosti prenášaných správ.

3. ŠTRUKTÚRA ROZHRANIA

3.1. Rozhranie poskytuje možnosť budovať distribuované systémy s chrbticovou komunikačnou štruktúrou (obr. 3).

Štruktúra prepojenia lokálnych subsystémov

LC1 - LCn- miestne subsystémy; MK- hlavný kanál; PC- zodpovedajúci rezistor

3.2. Všetky prepojené lokálne podsystémy musia byť pripojené k hlavnému kanálu, cez ktorý sa vymieňajú informácie.

3.3. Aby bolo možné prepojiť lokálne podsystémy s hlavným kanálom, musia obsahovať komunikačné ovládače. Ovládače komunikácie musia:

konvertovanie informácií z prezentačnej formy akceptovanej v lokálnom subsystéme do formy požadovanej na prenos cez hlavný kanál;

pridávanie a zvýrazňovanie synchronizačných znakov;

rozpoznávanie a prijímanie správ adresovaných tomuto miestnemu subsystému;

generovanie a porovnávanie riadiacich kódov na určenie spoľahlivosti prijatých správ.

3.4. Výmena správ medzi lokálnymi subsystémami musí byť organizovaná vo forme cyklov. Cyklus je chápaný ako postup prenosu jednej správy formátu 1 alebo 2 do hlavného kanála Niekoľko vzájomne prepojených cyklov tvorí proces prenosu.

3.5. Proces prenosu musí byť organizovaný podľa asynchrónneho princípu: lokálny subsystém musí prijímať odpovede na volania odoslané do hlavného kanála (s výnimkou skupinových operácií).

4. FUNKCIE ROZHRANIA

4.1. Rozhranie vytvára nasledujúce typy funkcií, ktoré sa líšia úrovňami riadenia, ktoré zaberajú lokálne podsystémy v procese odosielania správ:

pasívny príjem;

príjem a odozva;

decentralizované riadenie hlavného kanála;

žiadosť o prevzatie hlavného kanála;

centralizované ovládanie hlavného kanála.

(Zmenené vydanie, dodatok č. 1).

4.2. Zloženie funkcií rozhrania implementovaných lokálnym subsystémom je určené zložením problému riešeného týmto subsystémom a jeho funkčnými charakteristikami.

4.3. Typ miestneho subsystému je určený funkciou najvyššej úrovne spomedzi poskytovaných funkcií. Lokálny subsystém sa považuje za aktívny vzhľadom na funkciu, ktorú vykonáva v aktuálnom cykle.

4.4. V súlade so zložením implementovaných funkcií rozhrania sa rozlišujú tieto typy lokálnych subsystémov:

pasívne riadený subsystém;

riadený subsystém;

riadiaci subsystém;

proaktívny kontrolný subsystém;

vedúci subsystém.

4.4.1. Pasívne riadený subsystém vykonáva iba identifikáciu a príjem správ, ktoré sú mu adresované.

4.4.2. Riadený subsystém prijíma správy, ktoré sú mu adresované, a generuje správu s odpoveďou v súlade s prijatým funkčným kódom.

4.4.3. Riadiaci subsystém musí mať schopnosť:

akceptovať kontrolu výmeny cez hlavný kanál v centralizovanom a decentralizovanom režime;

generovať a prenášať správy cez hlavný kanál;

prijímať a analyzovať správy s odpoveďami;

vrátenie alebo prenos kontroly diaľkového kanála po ukončení procesu prenosu.

(Zmenené vydanie, dodatok č. 1).

4.4.4. Subsystém proaktívneho riadenia musí mať okrem funkcie podľa článku 4.4.3 schopnosť generovať signál požiadavky na obsadenie hlavného kanála, prijímať a odosielať zodpovedajúce správy pri vykonávaní procedúry vyhľadávania pre požadujúci podsystém.

4.4.5. Vedúci subsystém koordinuje prácu všetkých lokálnych subsystémov v režime centralizovaného riadenia hlavného kanála. Vykonáva:

rozhodovanie a prenos riadenia hlavného kanála na jeden z riadiacich lokálnych subsystémov;

centrálne riadenie všetkých lokálnych subsystémov;

monitorovanie činnosti aktívneho riadiaceho lokálneho subsystému;

prenos správ so spoločnou adresou pre všetky (alebo viaceré) lokálne podsystémy.

K hlavnému kanálu môže byť pripojený iba jeden podsystém s aktívnou funkciou master.

(Zmenené vydanie, dodatok č. 1).

5. POSTUP VÝMENY SPRÁV

5.1. Každý cyklus prenosu správ cez hlavný kanál musí začať synchronizáciou všetkých podsystémov pripojených cez rozhranie.

5.1.1. Na vykonanie synchronizácie musí hlavný alebo aktívny riadiaci subsystém preniesť synchronizačný bajt CH na hlavný kanál. Je možné prenášať niekoľko synchronizačných bajtov postupne. Ďalšie synchronizačné bajty nie sú zahrnuté vo formáte správy.

5.1.2. Keď sa všetky podsystémy zosynchronizujú, hlavný alebo aktívny riadiaci podsystém odošle správu vo formáte 1 alebo 2 do diaľkového spojenia, vrátane ich vlastných bajtov CH.

5.1.3. Všetky bajty, s výnimkou riadiacich KB1 a KB2, sa prenášajú do hlavného kanála, počnúc od najmenej významného bitu.

Bajty KB1, KB2 sa prenášajú z najvýznamnejšieho bitu.

5.1.4. Aby sa zo správy prenášanej do hlavného kanála vylúčila sekvencia bitov, ktoré sa zhodujú s kódom bajtu CH, každá správa sa musí skonvertovať tak, že po 5 po sebe idúcich znakoch „1“ musí byť zahrnutý ďalší znak „0“. . Prijímajúci subsystém musí zodpovedajúcim spôsobom vylúčiť tento znak zo správy.

5.1.5. Po odoslaní správy vrátane koncového bajtu CH musí odosielajúci subsystém preniesť aspoň 2 ďalšie bajty CH na dokončenie operácií príjmu, po ktorých sa prenosový cyklus skončí.

5.2. Procedúra riadenia diaľkového kanála určuje postupnosť operácií na aktiváciu jedného z riadiacich subsystémov na uskutočnenie procesu prenosu správ. Subsystémy pripojené cez rozhranie môžu pracovať v režime centralizovaného riadenia hlavného kanála.

5.2.1. Postup centralizovaného riadenia hlavného kanála zabezpečuje prítomnosť vedúceho subsystému, ktorý koordinuje interakciu subsystémov riadením prenosu riadenia hlavného kanála.

5.2, 5.2.1. (Nové vydanie, zmena č. 1).

5.2.2. Pri prenose riadenia diaľkového spojenia hlavný subsystém určí aktívny riadiaci subsystém na vykonanie procesu prenosu správ. Na tento účel musí vedúci subsystém poslať správu vo formáte 1 s kódom funkcie KF6 do vybraného riadiaceho subsystému.

5.2.3. Po prijatí správy s funkčným kódom KF6 sa riadiaci subsystém musí aktivovať a môže vykonať niekoľko cyklov výmeny správ v jednom prenosovom procese. Počet výmenných cyklov musí byť riadený a obmedzený nadradeným subsystémom.

5.2.4. Po odovzdaní kontroly nad hlavným kanálom musí vedúci subsystém aktivovať funkciu pasívneho príjmu a zapnúť časovanie riadenia. Ak počas nastaveného času (čakacia doba odpovede by nemala byť dlhšia ako 1 ms) určený aktívny subsystém nezačne vysielať správy cez diaľkový kanál, vedúci subsystém znova odošle správu vo formáte 1 s funkčným kódom KF6 a znak retransmisie do riadiaceho subsystému.

5.2.5. Ak po opakovanom prístupe riadiaci subsystém nezačne vysielať správy (nestane sa aktívnym), vedúci subsystém ho vyhodnotí ako chybný a implementuje postupy stanovené pre takúto situáciu.

5.2.6. Na konci procesu prenosu musí aktívny riadiaci subsystém vykonávať funkciu vrátenia riadenia diaľkového kanála. Aby to urobil, musí poslať správu vedúcemu subsystému s funkčným kódom KF7 alebo KF8.

5.2.7. Postup decentralizovaného riadenia hlavného kanála zabezpečuje postupný prenos aktívnej funkcie do iných riadiacich subsystémov odovzdaním tokenu. Podsystém, ktorý akceptoval token, je aktívny.

5.2.8. Pre počiatočné zachytenie tokenu musia všetky podsystémy pripojené cez hlavný kanál obsahovať intervalové časovače a hodnoty časových intervalov musia byť pre všetky podsystémy odlišné. Subsystém s vyššou prioritou by mal mať priradený menší časový interval.

5.2.9. Ak po vypršaní vlastného časového intervalu podsystému je hlavný kanál voľný, tento podsystém sa musí považovať za vlastníka tokenu a začať proces prenosu ako aktívny riadiaci podsystém.

5.2.10. Po dokončení procesu prenosu musí aktívny riadiaci subsystém preniesť riadenie hlavného kanálu na nasledujúci riadiaci subsystém s adresou AB = AC + 1, pre ktorý musí vydať značku, aktivovať v sebe funkciu pasívneho príjmu a zapnúť ovládať časovanie.

Ako značka sa používa správa formátu 1 (obr. 1) s kódom funkcie KF13 a adresou AB.

Ak v určenom čase podsystém, ktorý token prijal, nezačne proces prenosu, subsystém, ktorý ho poslal, sa musí pokúsiť preniesť token do podsystémov s nasledujúcimi adresami AB = AC + 2, AB = AC + 3 atď. kým nebude token prijatý. Adresu podsystému, ktorý prijal token, si tento podsystém musí zapamätať ako nasledujúcu, až kým sa nezopakuje počiatočné získanie.

5.2.11. Každý aktívny subsystém, ktorý zistí neoprávnený výstup na komunikačný kanál, musí vykonať činnosti uvedené v článku 5.2.8.

5.2.12. V režime decentralizovaného riadenia hlavného kanála musia mať všetky podsystémy funkciu aktívneho pasívneho príjmu. V prípade straty tokenu (napríklad ak zlyhá aktívny riadiaci subsystém) sa musí spustiť počiatočný mechanizmus zachytenia tokenu (články 5.2.8, 5.2.9) a musí sa obnoviť prevádzka.

5.2.13. Každý podsystém, ktorý vlastní token a má aktívnu hlavnú funkciu, môže prevziať centralizované riadenie diaľkového kanála a udržiavať ho, kým sa nezruší aktívna hlavná funkcia, ktorá je mu priradená.

5.2.7 - 5.2.13. (Vložené dodatočne, zmena č. 1).

5.3. V režime centralizovaného riadenia môže byť prenos riadenia hlavného kanála organizovaný na základe požiadaviek od proaktívnych riadiacich subsystémov.

5.3.1. Subsystémy musia mať aktívnu funkciu žiadosti o zachytenie hlavného kanála, aby organizovali prenos riadenia na základe požiadaviek.

5.3.2. Existujú dva možné spôsoby, ako organizovať vyhľadávanie podsystému požadujúceho prístup k hlavnému kanálu – centralizovaný a decentralizovaný.

5.3, 5.3.1, 5.3.2. (Nové vydanie, zmena č. 1).

5.3.3. Pri centralizovanom pollingu musí vedúci subsystém postupne dotazovať všetky proaktívne riadiace subsystémy pripojené k hlavnému kanálu. Vedúci subsystém musí poslať správu vo formáte 1 s funkčným kódom KF5 do každého proaktívneho riadiaceho subsystému.

Iniciačný riadiaci subsystém musí poslať správu s odpoveďou vedúcemu subsystému s jedným z funkčných kódov KF21 - KF24 v závislosti od jeho vnútorného stavu. Postupnosť operácií v postupe centralizovaného prieskumu je znázornená na obr. 4.

5.3.4. Decentralizované dopytovanie poskytuje rýchly proces identifikácie proaktívnych riadiacich subsystémov, ktoré vytvorili požiadavku na prístup do hlavného kanála. Vedúci subsystém musí kontaktovať iba prvý v poradí proaktívny riadiaci subsystém správou vo formáte 1 a funkčným kódom KF9.

Každý proaktívny riadiaci subsystém musí prijať správu, ktorá je mu adresovaná, a poslať svoju vlastnú správu adresovanú ďalšiemu subsystému v poradí na hlavný kanál. Vygenerovaná správa musí obsahovať jeden z funkčných kódov KF9 - KF12, ktorý charakterizuje stav tohto subsystému. Postup decentralizovaného prieskumu je znázornený na obr. 5.

5.3.5. Vedúci subsystém po spustení decentralizovaného hlasovania aktivuje funkciu pasívneho príjmu a prijíma všetky správy odoslané subsystémami proaktívneho riadenia. To umožňuje vedúcemu subsystému po skončení decentralizovaného prieskumu získať informácie o požiadavkách na prístup k hlavnému kanálu zo všetkých proaktívnych riadiacich subsystémov.

Proces centralizovaného podsystému hlasovania

Proces hlasovania v decentralizovanom podsystéme

Posledný podsystém kontroly iniciatívy v reťazci decentralizovaného hlasovania musí adresovať svoju správu vedúcemu subsystému, čo znamená koniec postupu decentralizovaného hlasovania.

5.3.6. Ak niektorý podsystém po prístupe k hlavnému kanálu neposiela správy, hlavný podsystém sa musí prebudiť a poslať mu opakovanú správu identickú s predchádzajúcim. Ak nedôjde k žiadnej odpovedi (alebo chybám) na opakované volanie, vedúci subsystém spustí decentralizovanú anketu z nasledujúceho subsystému v poradí a tento subsystém je z ankety vylúčený.

5.4. Postup prenosu údajov môže byť vykonaný vo forme jedného z nasledujúcich procesov:

skupinové nahrávanie;

písať-čítať.

5.4.1. Skupinové nahrávanie musí vykonávať nadradený subsystém. Pri vykonávaní skupinového záznamu vydá hlavný podsystém správu vo formáte 2 hlavnému kanálu, v ktorej sú ako adresa AB zapísané kód 11111111 (255) a funkčný kód KF1.

5.4.2. Všetky podsystémy odpovedajúce na multicast adresu musia prijať správu z diaľkového spoja a zaregistrovať stav, ktorý indikuje, že správa verejnej adresy bola prijatá. Správy s odpoveďou počas skupinového nahrávania nevydávajú prijímajúce podsystémy.

5.4.3. Potvrdenie prijatia skupinovej správy sa vykonáva v procese centralizovaného alebo decentralizovaného dopytovania, ako aj pri vrátení kontroly nad hlavným kanálom, pre ktorý je príslušný stavový bit zahrnutý vo funkčných kódoch KF7, KF8, KF9 - KF12 a KF21 - KF24.

5.4.4. Počas procesu nahrávania hlavný subsystém alebo aktívny riadiaci subsystém odošle správu formátu 2 s funkčným kódom KF2 na hlavný kanál, určenú na príjem špecifickým riadeným subsystémom, ktorej adresa je uvedená v AB byte. Po vydaní správy aktívny riadiaci podsystém zapne kontrolné odpočítavanie a čaká na správu s odpoveďou.

5.4.5. Adresovaný subsystém rozpozná svoju adresu a prijme správu, ktorá mu bola odoslaná. Ak je správa prijatá bez chyby, prijímací subsystém musí odoslať odpoveď hlavnému kanálu vo forme správy formátu 1 s funkčným kódom KF18.

5.4.6. Ak sa v prijatej správe zistí chyba, prijímajúci subsystém by nemal vydávať odpoveď.

5.4.7. Aktívny riadiaci subsystém, ak počas časového intervalu riadenia nedôjde k žiadnej odozve, musí znova odoslať rovnakú správu.

5.4.8. Ak nedôjde k odozve na opakované hlásenie, tento subsystém sa považuje za chybný a aktívny riadiaci subsystém musí vykonať postup predpísaný pre takúto situáciu (zapnutie alarmu, vyradenie subsystému z používania, zapnutie rezervy a pod.).

5.4.9. V režime centralizovaného riadenia hlavného kanála musí byť dialóg medzi riadiacim a riadeným podsystémom neustále monitorovaný vedúcim podsystémom, ktorý v tomto čase plní funkciu pasívneho prijímania správ.

(Nové vydanie, zmena č. 1).

5.4.10. Proces čítania musí začať odoslaním správy vo formáte 1 s kódom funkcie KF3 aktívnym riadiacim subsystémom.

5.4.11. Subsystém, ktorému je táto správa adresovaná, musí v prípade správneho prijatia vydať správu s odpoveďou vo formáte 2 s funkčným kódom KF19.

5.4.12. Ak volaný subsystém nemôže vydať údaje v rámci špecifikovaného času čakania, potom po prijatí správy pomocou funkcie čítania musí zaznamenať znamenie, že subsystém je zaneprázdnený, a začať vytvárať pole údajov na vydanie.

5.4.13. Tento riadený podsystém si musí zapamätať adresu aktívneho riadiaceho podsystému, ktorý ho adresoval (pre ktorý sa pripravujú údaje) a nastaviť hlásenie o obsadenosti v správach odozvy pre ostatné riadiace podsystémy.

5.4.14. Pre načítanie pripravených údajov musí aktívny riadiaci subsystém opäť kontaktovať riadený subsystém správou vo formáte 1 s funkčným kódom KF3. Ak sú údaje pripravené do tohto času, potom musí riadený podsystém vydať správu s odpoveďou vo formáte 2 s kódom funkcie KF19.

Znak zaneprázdnenia subsystému by sa mal vymazať až po odoslaní správy s odpoveďou vo formáte 2.

5.4.15. Ak správu s odpoveďou prijme aktívny riadiaci subsystém bez chyby, proces čítania sa skončí.

5.4.16. Ak sa zistí chyba alebo nedôjde k žiadnej odozve, aktívny riadiaci subsystém zopakuje volanie a potom prijme opatrenia podobné tým, ktoré sú uvedené v odsekoch. 5.4.7, 5.4.8.

5.4.17. Zápis-čítanie je kombinácia procesov podľa odsekov. 5.4.4 - 5.4.15.

5.4.18. Aktívny riadiaci subsystém odošle správu vo formáte 2 s funkčným kódom KF4 do hlavného kanála.

5.4.19. Adresovaný subsystém musí prijať správu, ktorá mu bola odoslaná, a vygenerovať odpoveď.

5.4.20. Správa s odpoveďou v tomto procese musí byť vo formáte 2 (obsahovať načítané dáta) a mať funkčný kód KF20.

5.4.21. Monitorovanie spoľahlivosti prenášaných správ a činností vykonávaných aktívnym riadiacim subsystémom by malo byť podobné tým, ktoré sú uvedené pre procesy zapisovania a čítania.

6. FYZICKÁ REALIZÁCIA

6.1. Fyzicky je rozhranie implementované vo forme komunikačných liniek, ktoré tvoria chrbticový kanál, a komunikačných kontrolérov, ktoré poskytujú priame spojenie s komunikačnými linkami.

6.2. Komunikačné ovládače musia byť realizované vo forme funkčných celkov, ktoré sú súčasťou subsystému, alebo vo forme konštrukčne samostatných zariadení.

6.3. Pravidlá pre párovanie a interakciu komunikačných ovládačov s funkčnou časťou subsystému táto norma neupravuje.

6.4. Pre diaľkové komunikačné linky by sa mal použiť koaxiálny kábel s charakteristickou impedanciou 75 ohmov.

6.5. Koaxiálny kábel musí byť na oboch koncoch zaťažený zodpovedajúcimi odpormi s odporom (75 ± 3,75) Ohmov. Výkon zodpovedajúcich rezistorov musí byť aspoň 0,25 W.

Zakončovacie odpory musia byť pripojené na konce komunikačných liniek pomocou RF konektorov.

Uzemnenie alebo pripojenie komunikačných liniek k krytom zariadenia v párových podsystémoch nie je povolené.

6.6. Útlm pozdĺž komunikačnej linky hlavného kanála by nemal byť väčší ako 18 dB pre rýchlosť 500 kbit/s.

6.7. Celkový útlm zavedený každou vetvou z komunikačnej linky hlavného kanála by nemal presiahnuť 0,1 dB, vrátane útlmu určeného kvalitou spojovacieho bodu, útlmu na vetve a útlmu v závislosti od vstupno-výstupných parametrov prispôsobovacích obvodov.

6.8. Vetvy z komunikačnej linky hlavného kanála musia byť vytvorené koaxiálnym káblom s charakteristickou impedanciou 75 Ohmov. Dĺžka každej vetvy nie je väčšia ako 3 m Celková dĺžka všetkých vetiev sa započítava do celkovej dĺžky hlavného kanála. Pripojenie ku komunikačnej linke musí byť vykonané pomocou RF konektorov. Vypnutie ktoréhokoľvek z podsystémov by nemalo viesť k prerušeniu komunikačného vedenia.

6.9. Komunikačné ovládače musia obsahovať zosilňovače transceiveru, ktoré poskytujú:

citlivosť príjmu, nie je o nič horšia ................................................ ...... ............. 240 mV

úroveň výstupného signálu ................................................... ..................................... 4 až 5 V

výstupná impedancia ................................................ ...................................... (37,50 ± 1,88) Ohm

6.10. Vytváranie elektrických signálov na prenos do hlavného kanála sa uskutočňuje moduláciou hodinovej frekvencie signálmi prenášanej správy. Každý bit prenášanej správy zodpovedá plnej perióde hodinovej frekvencie a nábežná a zostupná hrana prenášaného signálu sa musí zhodovať s prechodom cez nulu hodinovej frekvencie (obr. 6). Zhoda symbolov prijatých z hlavného kanála so zmysluplnými stavmi je stanovená takto:

symbol „0“ zodpovedá opačnej fáze vzhľadom na predchádzajúci symbol,

Výmena informácií medzi zariadeniami, ktoré sú súčasťou automatizovaného systému (počítače, ovládače, senzory, akčné členy), sa vo všeobecnosti uskutočňuje prostredníctvom priemyselná sieť(Fieldbus, "field bus") [Cucej].

• LAN(Local Area Network) - siete umiestnené v obmedzenom priestore (v dielni, kancelárii, v závode);
• MUŽ(Metropolitan Area Networks) - siete miest;
• WAN(Wide Area Network) - globálna sieť pokrývajúca niekoľko miest alebo kontinentov. Zvyčajne sa na to používa internetová technológia.

V súčasnosti existuje viac ako 50 typov priemyselných sietí (Modbus, Profibus, DeviceNet, CANopen, LonWorks, ControlNet, SDS, Seriplex, ArcNet, BACnet, FDDI, FIP, FF, ASI, Ethernet, WorldFIP, Foundation Fieldbus, Interbus, BitBus , atď. .). Rozšírené sú však len niektoré z nich. V Rusku prevažná väčšina automatizovaných systémov riadenia procesov využíva siete Modbus a Profibus. V posledných rokoch vzrástol záujem o siete založené na CANopen a DeviceNet. Prevaha jednej alebo druhej priemyselnej siete v Rusku súvisí predovšetkým s preferenciami a činnosťou ruských spoločností predávajúcich dovážané zariadenia.

2.1. Všeobecné informácie o priemyselných sieťach

Priemyselná sieť nazývaný komplex zariadení a softvéru, ktoré zabezpečujú výmenu informácií (komunikáciu) medzi viacerými zariadeniami. Priemyselná sieť je základom pre budovanie distribuovaných systémov zberu a kontroly údajov.

Keďže v priemyselnej automatizácii môžu byť sieťové rozhrania integrálnou súčasťou pripojených zariadení a sieťový softvér aplikačnej vrstvy modelu OSI sa vykonáva na hlavnom procesore priemyselného regulátora, niekedy je fyzicky nemožné oddeliť sieťovú časť od zariadení, ktoré sú prepojené do siete. . Na druhej strane, prechod z jednej siete do druhej možno často dosiahnuť zmenou sieťového softvéru a sieťového adaptéra alebo zavedením prevodníka rozhrania, takže často možno rovnaký typ PLC použiť v rôznych typoch sietí.

Spojenie priemyselnej siete s jej komponentmi (zariadenia, sieťové uzly) sa vykonáva pomocou rozhrania. Sieťové rozhranie je logická a (alebo) fyzická hranica medzi zariadením a médiom na prenos informácií. Zvyčajne je touto hranicou súbor elektronických komponentov a súvisiaceho softvéru. Pri výrazných úpravách vnútornej štruktúry zariadenia alebo softvéru zostáva rozhranie nezmenené, čo je jedna z vlastností, ktorá umožňuje rozlíšiť rozhranie ako súčasť výbavy.

Najdôležitejšími parametrami rozhrania sú šírka pásma a maximálna dĺžka pripojeného kábla. Priemyselné rozhrania zvyčajne poskytujú galvanickú izoláciu medzi pripojenými zariadeniami. Najbežnejšie sériové rozhrania v priemyselnej automatizácii sú RS-485, RS-232, RS-422, Ethernet, CAN, HART, AS-interface.

Na výmenu informácií musia mať interagujúce zariadenia to isté výmenný protokol. Vo svojej najjednoduchšej forme je protokol súborom pravidiel, ktorými sa riadi výmena informácií. Definuje syntax a sémantiku správy, riadiace operácie, synchronizáciu a stavy komunikácie. Protokol môže byť implementovaný v hardvéri, softvéri alebo firmvéri. Názov siete sa zvyčajne zhoduje s názvom protokolu, čo sa vysvetľuje jeho rozhodujúcou úlohou pri vytváraní siete. V Rusku sa používajú sieťové protokoly opísané v sérii noriem [GOST - GOST].

Sieť zvyčajne používa niekoľko protokolov, ktoré tvoria zásobník protokolov- súbor súvisiacich komunikačných protokolov, ktoré spolupracujú a využívajú niektoré alebo všetky zo siedmich vrstiev modelu OSI [Príručka]. Pre väčšinu sietí je protokolový zásobník implementovaný pomocou špecializovaných sieťových čipov alebo zabudovaný do univerzálneho mikroprocesora.

Interakcia zariadení v priemyselných sieťach sa uskutočňuje v súlade s modelmi Klientsky server alebo vydavateľ-predplatiteľ (výrobca-spotrebiteľ) [Thomesse]. V modeli klient-server interagujú dva objekty. Server je objekt, ktorý poskytuje službu, t. j. vykonáva nejaké akcie na žiadosť klienta. Sieť môže obsahovať niekoľko serverov a niekoľko klientov. Každý klient môže posielať požiadavky na viacero serverov a každý server môže odpovedať na požiadavky viacerých klientov. Tento model je užitočný na prenos údajov, ktoré sa vyskytujú pravidelne alebo vo vopred určených časoch, ako sú napríklad hodnoty teploty v dávkovom procese. Tento model je však nevhodný na prenos náhodne sa vyskytujúcich udalostí, napríklad udalosti pozostávajúcej z náhodnej aktivácie snímača hladiny, pretože na prijatie tejto udalosti musí klient pravidelne, s vysokou frekvenciou, žiadať o stav snímača a analyzovať ho. preťažuje sieť zbytočnou prevádzkou.