Korisnički vodič

1. Uvod
1.1. Područje primjene…………………………………………………………………………. 3
1.2. Kratki opis mogućnosti………………………………………………………………………… 3
1.3. Korisnički nivo…………………………………………………………………… 3

2. Svrha i uslovi korišćenja automatizovanog sistema upravljanja procesima „VP”………………………………………………. 4

3. Rješenje automatizovanog sistema upravljanja procesom “VP”…………………………………………………………………. 5

4. Pokretanje sistema……………………………………………………………………………..……… 6

1. Uvod.

1.1. Područje primjene

Zahtjevi ovog dokumenta primjenjuju se kada:

· preliminarna sveobuhvatna ispitivanja;

· probni rad;

· testovi prihvatanja;

· industrijski rad.

1.2. Kratak opis karakteristika

Softverski proizvod “Protok težine” dizajniran je za obavljanje analitičkih poslova, automatizaciju i optimizaciju procesa toka dokumenata i međuodjelske logistike različitih odjela poduzeća. Sistem takođe pruža mogućnost brzog praćenja i prilagođavanja rada tehničkih procesa u preduzećima koja su povezana sa upotrebom opreme za merenje u liftovima, brodovima i skladištima gasa, železničkim teretnim stanicama i drugim industrijskim objektima.

Softver i hardver - softverski paket ACS TP "Weight Flow" imaju modularnu strukturu.

Prilikom rada sa izvještavanjem često se koriste: softver OLE 1C sa funkcijom onlajn sinhronizacije (omogućava pokretanje vaganja iz računovodstvenog sistema) i SAP RFC softver sa funkcijom onlajn sinhronizacije (generira vaganje u računovodstveni sistem), koji omogućava sljedeće:

· provera mogućnosti prolaska vozila na teritoriju preduzeća;

· kreiranje dokumenta u 1C o činjenici vaganja vozila u preduzeću;

· vraćanje podataka o stanju sredstava na računu druge ugovorne strane u 1C sistemu;

· potražite dokument po broju vozila i vratite broj dokumenta. Ako postoji više dokumenata, redosled izlaza određuje programer, funkcija uvek vraća jedan dokument;

vratiti informacije o dokumentu; povratni element direktorija; unošenje težine robe u dokument; izdavanje spiska dokumenata na dan.

1.3. Korisnički nivo

Korisnik mora imati iskustvo u radu sa MS Windows OS (95/98/NT/2000/XP, XP-7), vještinu rada sa MS Officeom, kao i sljedeća znanja:

· poznaju relevantnu predmetnu oblast;

· poznaju princip rada kamionske vage;

· biti u stanju povezati periferne uređaje.

2. Svrha i uslovi korišćenja automatizovanog sistema upravljanja procesima "VP".

Dispečerstvo proizvodnje, transporta, puteva, uspešno se primenjuje u mnogim oblastima delatnosti, od komercijalnih puteva i prelaza, automatskih parkinga, do automatizacije industrije proizvodnje gasa.

Softversko-hardverski kompleks automatizovanog sistema upravljanja procesom "Protok težine" dizajniran je za automatizaciju industrijskih sistema za merenje težine (vozne vage, vagonske vage, itd.) i toka dokumenata, konfiguraciju uzimajući u obzir industriju preduzeća i računovodstvene karakteristike.

Svi sistemi imaju mogućnost lake integracije u druge sisteme, na primer, računovodstvene sisteme (1C, Turbobukhgalter, SAP, BAAN, itd.) Sistemi su takođe opremljeni opcijom daljinskog/daljinskog upravljanja. Svi naši projekti uključuju najnaprednija i jedinstvena softverska i hardverska rješenja koja koriste RFID tehnologije (radio frekvencijska identifikacija), aktivne i pasivne.

Sistem upravljanja procesima "Weight Flow" obuhvata ugradnju sigurnosnih i video nadzornih sistema, sistema kontrole pristupa na industrijskim objektima. za razne namjene i bilo koji nivo složenosti, sa njihovom integracijom u tehnološkim procesima preduzeća i toka dokumenata, kao i korišćenje savremenih RFID tehnologija (aktivno/pasivno).

3. Rješenje automatizovanog sistema upravljanja procesima “VP”

Tipične opcije za kompletiranje automatizovanih sistema kontrole procesa „Protok težine“

Opcije identifikacije događaja. „Događaj“ je važna komponenta koja vam omogućava da organizujete rad sistema bez osobe, što eliminiše „rizike“ povezane sa aktivnostima nepoštenih zaposlenih.

1. Inteligentna video analitika - sistem za prepoznavanje vozila, brojeva vozila/vagona/kontejnera;
2. RFID - radio frekvencijska identifikacija (aktivna ili pasivna);
3. Razni senzori- indukcijski, termalni senzori;
4. Ljudski unos podataka o događajima

Aktuatori: - svi digitalni uređaji čiji dizajn uključuje priključne portove (COM USB, RS 232/485, IP mreža, itd.);
- bilo koji analogni uređaj sa funkcijama za uključivanje/isključivanje (semafori / motori / sijalice / barijere / amortizeri, itd.);
- digitalni senzori/analizatori, elektronski i sa suhim kontaktima.

Softverske komponente automatizovanog sistema upravljanja procesima "VP"
Imamo nekoliko APCS modula - njihova funkcionalnost je ukratko opisana u specifikaciji, a detaljnije u priručniku. Ispod su glavne softverske komponente sistema za kontrolu procesa „Protok težine“. Svaki modul ima određene osnovne funkcije:

1. Server - APCS softver "Weight Flow"
Centralno sjeverno od skale (WEB, SQL, URDB)

2. Program za vaganje - automatizirani sistem upravljanja procesom "Protok težine" Auto vaganje/željeznički modul za vaganje
3.Usage razni uređaji- ACS TP "Protok težine" Kontrolni modul +
u sistemu

4. Podešavanja, vidljivo/nevidljivo - automatizovani sistem upravljanja procesom modul „VP” Laboratorija

5. Dodatni radno mjesto- ACS TP “VP” Modul dodatno radno mjesto
(mogućnost povezivanja na daljinu ili putem mreže na automatizovanu upravljačku radnu stanicu)

4. Pokretanje sistema

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

Rice. 2. Interfejs automatizovanog sistema upravljanja procesom “Protok težine”

Interfejs sastoji se od sljedećih elemenata:

1.Navigacijski meni. Služi za konfiguraciju i upravljanje sistemom.

2.Tasteri za prebacivanje između vage. Služi za prebacivanje prikaza statusa različitih vaga i označavanje trenutno aktivnih vaga ako je na sistem priključeno više od jedne vage.

3.Operatorski meni. Služi za upravljanje vaganjem, dokumentima i sistemom kontrole pristupa. Mijenja izgled i funkcije upravljačke ploče.

4.Operator panel. Služi za upravljanje vaganjem, dokumentima i sistemom kontrole pristupa. Izgled a funkcije zavise od trenutno odabrane kartice u korisničkom meniju (pozicija 3). Kada se sistem pokrene, prikazuje se kontrolni panel vage (kao na slici 2).

5.Kalendar. Služi za odabir rezultata vaganja prikazanih na panelu protokola vaganja (pozicija 7) prema datumu i prikaz trenutnog datuma.

6. Dugme “Snimi dokument”. Koristi se za kreiranje novog dokumenta.

7. Panel protokola vaganja. Služi za prikaz rezultata vaganja za određeni datum odabran u kalendaru (pozicija 5).

8.Video panel. Prikazuje video emitovanje sa CCTV kamera.

Navigacijski meni(Sl. 3) nalazi se u gornjem levom uglu monitora i sastoji se od sledećih delova: “Datoteka”, “Konfiguracija”, “Moduli”, “Windows”, “O programu”.

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

Rice. 4. Meni "Datoteka".

Meni "Konfiguracija" (sl. 5)

Omogućava pristup parametrima sistemske usluge

"Dizajner štampanih ploča" - služi za registraciju izgleda dokumenata

"Postavke sistema" - služi za konfiguraciju sistema u skladu sa potrebnim parametrima

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

Rice. 6. Meni "Moduli".

Meni "prozor" (sl. 7)

Prikazuje listu otvorenih prozora i omogućava vam da prelazite između njih

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

Razmjena informacija između uređaja koji su dio automatiziranog sistema (računari, kontroleri, senzori, aktuatori) uglavnom se odvija kroz industrijska mreža(Fieldbus, "sabirnica polja") [Cucej].

• LAN(Local Area Network) - mreže koje se nalaze u ograničenom području (u radionici, kancelariji, unutar pogona);
• MAN(Metropolitan Area Networks) - mreže gradova;
• WAN(Wide Area Network) - globalna mreža koja pokriva nekoliko gradova ili kontinenata. Obično se za to koristi internet tehnologija.

Trenutno postoji više od 50 tipova industrijskih mreža (Modbus, Profibus, DeviceNet, CANopen, LonWorks, ControlNet, SDS, Seriplex, ArcNet, BACnet, FDDI, FIP, FF, ASI, Ethernet, WorldFIP, Foundation Fieldbus, Interbus, BitBus itd.). Međutim, samo su neke od njih rasprostranjene. U Rusiji, velika većina automatizovanih sistema za kontrolu procesa koristi Modbus i Profibus mreže. Posljednjih godina poraslo je interesovanje za mreže zasnovane na CANopen-u i DeviceNetu. Prevalencija jedne ili druge industrijske mreže u Rusiji povezana je, prije svega, sa preferencijama i aktivnostima ruskih kompanija koje prodaju uvezenu opremu.

2.1. Opće informacije o industrijskim mrežama

Industrijska mreža nazvan set opreme i softver, koji omogućavaju razmjenu informacija (komunikaciju) između više uređaja. Industrijska mreža je osnova za izgradnju distribuiranih sistema prikupljanja i kontrole podataka.

Budući da u industrijskoj automatizaciji mrežna sučelja mogu biti sastavni dio povezanih uređaja, a mrežni softver aplikacijskog sloja OSI modela se izvršava na glavnom procesoru industrijskog kontrolera, ponekad je fizički nemoguće odvojiti mrežni dio od uređaja koji se umrežavaju. . S druge strane, promjena iz jedne mreže u drugu često se može postići promjenom mrežnog softvera i mrežnog adaptera ili uvođenjem pretvarača interfejsa, tako da se često isti tip PLC-a može koristiti u različitim tipovima mreža.

Povezivanje industrijske mreže sa njenim komponentama (uređaji, mrežni čvorovi) vrši se pomoću interfejsi. Mrežni interfejs je logička i (ili) fizička granica između uređaja i medija za prenos informacija. Obično je ova granica skup elektronskih komponenti i povezanog softvera. Uz značajne modifikacije interne strukture uređaja ili softvera, interfejs ostaje nepromenjen, što je jedna od karakteristika koja omogućava razlikovanje interfejsa kao dela opreme.

Najvažniji parametri interfejsa su propusni opseg i maksimalna dužina priključenog kabla. Industrijski interfejsi obično obezbeđuju galvansku izolaciju između povezanih uređaja. Najčešći serijski interfejsi u industrijskoj automatizaciji su RS-485, RS-232, RS-422, Ethernet, CAN, HART, AS-interfejs.

Za razmjenu informacija, uređaji u interakciji moraju imati iste protokol razmene. IN najjednostavniji oblik Protokol je skup pravila koja regulišu razmjenu informacija. Definira sintaksu i semantiku poruke, kontrolne operacije, sinhronizaciju i stanja komunikacije. Protokol se može implementirati u hardveru, softveru ili firmveru. Naziv mreže obično se poklapa sa nazivom protokola, što se objašnjava njegovom odlučujućom ulogom u stvaranju mreže. U Rusiji se koriste mrežni protokoli opisani u nizu standarda [GOST - GOST].

Tipično, mreža koristi nekoliko protokola koji čine stek protokola- skup povezanih komunikacijskih protokola koji rade zajedno i koriste neke ili svih sedam slojeva OSI modela [Vodič]. Za većinu mreža, stek protokola se implementira pomoću specijalizovanih mrežnih čipova ili ugrađen u mikroprocesor opšte namene.

Interakcija uređaja u industrijskim mrežama odvija se u skladu sa modelima klijent-server ili izdavač-pretplatnik (proizvođač-potrošač) [Thomesse]. U modelu klijent-server, dva objekta su u interakciji. Server je objekat koji pruža uslugu, tj. koji izvodi neke radnje na zahtjev klijenta. Mreža može sadržavati nekoliko servera i nekoliko klijenata. Svaki klijent može slati zahtjeve na više servera, a svaki server može odgovoriti na zahtjeve više klijenata. Ovaj model je koristan za prijenos podataka koji se javljaju periodično ili u unaprijed određeno vrijeme, kao što su vrijednosti temperature u batch procesu. Međutim, ovaj model je nezgodan za prijenos nasumično nastalih događaja, na primjer, događaja koji se sastoji od nasumične aktivacije senzora nivoa, jer da bi primio ovaj događaj, klijent mora periodično, sa velikom frekvencijom, tražiti status senzora i analizirati to, preopterećujući mrežu beskorisnim saobraćajem.

Savremene metode za projektovanje aktivnosti korisnika automatizovanog sistema upravljanja razvile su se u okviru sistemsko inženjerskog koncepta projektovanja, zbog čega je uzimanje u obzir ljudskog faktora ograničeno na rešavanje problema koordinacije „ulaza” i „izlaza” osoba i mašina. Istovremeno, kada se analizira nezadovoljstvo korisnika automatizovanog sistema upravljanja, moguće je otkriti da se ono često objašnjava nedostatkom jedinstvenog, integrisanog pristupa projektovanju sistema interakcije, predstavljenog kao sveobuhvatno, međusobno povezano, proporcionalno razmatranje. svih faktora, načina i metoda rješavanja složenog multifaktorskog i multivarijantnog zadatka projektovanja interakcijskog interfejsa. To se odnosi na funkcionalne, psihološke, socijalne, pa čak i estetske faktore.

Trenutno se može smatrati dokazanim da glavni zadatak dizajniranja korisničkog sučelja nije racionalno „uklopiti“ osobu u kontrolnu petlju, već da, na osnovu zadataka upravljanja objektom, razvije sistem interakcije između dva jednaka partneri (ljudski operater i ACS hardversko-softverski kompleks), racionalno upravljajući objektom upravljanja. Ljudski operater je završna karika sistema upravljanja, tj. subjekt upravljanja. APK (hardversko-softverski kompleks) ACS je alat za implementaciju njegove (operaterove) upravljačke (operativne) aktivnosti, tj. kontrolni objekat. Prema definiciji V.F. Vende, automatizovani sistem upravljanja je hibridna inteligencija u kojoj su operativni (upravljački) kadar i agroindustrijski kompleks automatizovanog sistema upravljanja ravnopravni partneri u rešavanju složenih problema upravljanja. Interfejs ljudske interakcije sa tehničkim sredstvima automatizovanog sistema upravljanja može se strukturno prikazati (vidi sliku 1.).

Rice. 1. Informacijski i logički dijagram interfejsa interakcije

Racionalna organizacija rada operatera sistema automatizovanog upravljanja jedan je od najvažnijih faktora koji determinišu efikasno funkcionisanje sistema u celini. U ogromnoj većini slučajeva, upravljački rad je indirektna ljudska aktivnost, budući da u uslovima automatizovanog sistema upravljanja on upravlja a da ne „vidi“ pravi objekat. Između stvarnog kontrolnog objekta i ljudskog operatera postoji objektni informacioni model(sredstvo za prikazivanje informacija). Stoga se javlja problem projektovanja ne samo sredstava za prikazivanje informacija, već i sredstava interakcije između čoveka operatera i tehničkih sredstava automatizovanog sistema upravljanja, tj. problem dizajna sistema, koji bismo trebali nazvati korisnički interfejs.

Sastoji se od APK-a i protokola za interakciju. Kompleks hardvera i softvera pruža sljedeće funkcije:

transformacija podataka koji kruže u agroindustrijskom kompleksu automatizovanog sistema upravljanja u informacione modele prikazane na monitorima (SOI - information display tools);

regeneracija informacioni modeli(ONI);

osiguravanje interakcije dijaloga između osobe i automatiziranog sistema upravljanja;

transformacija uticaja koji dolaze od PO (ljudski operater) u podatke koje koristi sistem upravljanja;

fizička implementacija protokola interakcije (usklađivanje formata podataka, kontrola grešaka, itd.).

Svrha protokola je da obezbede mehanizam za pouzdanu i pouzdanu isporuku poruka između ljudskog operatera i SOI, a samim tim i između PO i kontrolnog sistema. Protokol- ovo je pravilo koje definira interakciju, skup procedura za razmjenu informacija između paralelnih procesa u realnom vremenu. Ove procese (funkcionisanje agroindustrijskog kompleksa automatizovanog sistema upravljanja i operativne aktivnosti subjekta kontrole) karakteriše, prvo, odsustvo fiksnih vremenskih odnosa između nastanka događaja i, drugo, odsustvo međuzavisnost između događaja i radnji po njihovom nastanku.

Funkcije protokola odnose se na razmjenu poruka između ovih procesa. Format i sadržaj ovih poruka čine logičke karakteristike protokola. Pravila za izvršavanje procedura određuju radnje koje izvode procesi koji zajednički učestvuju u implementaciji protokola. Skup ovih pravila je proceduralna karakteristika protokola. Koristeći ove koncepte, sada možemo formalno definirati protokol kao skup logičkih i proceduralnih karakteristika komunikacijskog mehanizma između procesa. Logička definicija čini sintaksu, a proceduralna definicija čini semantiku protokola.

Generiranje slike pomoću APC-a omogućava vam da dobijete ne samo dvodimenzionalne slike projicirane na ravan, već i implementaciju trodimenzionalne grafike pomoću ravnina i površina drugog reda s prijenosom teksture površine slike.

Prilikom kreiranja složenih automatizovanih sistema upravljanja, razvoj softvera je od velikog značaja, jer To je softver koji stvara inteligenciju kompjutera, koji rješava složene naučne probleme i kontroliše najsloženije tehnološke procese. Trenutno se pri kreiranju ovakvih sistema značajno povećava uloga ljudskog faktora, a samim tim i ergonomske podrške sistema. Glavni zadatak ergonomske podrške je da optimizira interakciju između čovjeka i mašine, ne samo tokom rada, već i tokom proizvodnje i odlaganja tehničkih komponenti. Dakle, pri sistematizaciji pristupa dizajnu korisničkog interfejsa možemo dati neke osnovne funkcionalne zadatke i principe projektovanja koje sistem treba da reši.

Princip minimalne radne snage programer i korisnik, što ima dva aspekta:

minimiziranje troškova resursa od strane programera, što se postiže stvaranjem određene metodologije i tehnologije kreiranja karakteristične za konvencionalne proizvodne procese;

minimiziranje troškova resursa od strane korisnika, tj. PO treba da obavlja samo posao koji je neophodan i koji sistem ne može da izvrši, ne bi trebalo da bude ponavljanja već obavljenog posla, itd.

Zadatak maksimalnog međusobnog razumijevanja korisnika i agroindustrijskog kompleksa kojeg predstavlja programer softvera. One. PO ne bi trebalo da se bavi, na primer, traženjem informacija, ili informacije prikazane na uređaju za kontrolu video zapisa ne bi trebalo da zahtevaju kodiranje ili dodatno tumačenje od strane korisnika.

Korisnik mora zapamtite što je moguće manje informacija, jer to smanjuje sposobnost privatnog preduzeća da donosi operativne odluke.

Princip maksimalne koncentracije korisnika o problemu koji se rješava i lokalizaciji poruka o grešci.

Princip obračuna profesionalnih vještina ljudski operater. To znači da se pri razvoju sistema, na osnovu nekih početnih podataka navedenih u tehničkim specifikacijama o mogućem kontingentu kandidata, osmišljava „ljudska komponenta“ uzimajući u obzir zahtjeve i karakteristike cijelog sistema i njegovih podsistema. Formiranje konceptualnog modela interakcije između osobe i tehničkih sredstava automatizovanog sistema upravljanja podrazumeva poznavanje i savladavanje algoritama za funkcionisanje podsistema „ljudsko-tehnička sredstva” i ovladavanje profesionalnim veštinama u interakciji sa računarom.

Ključ za stvaranje efikasan interfejs je u postu, koliko god je moguce, operatorska prezentacija jednostavnog konceptualnog modela interfejsa. Zajednički korisnički pristup to postiže dosljednošću. Koncept konzistentnosti je da prilikom rada sa računarom korisnik razvija sistem očekivanja istih reakcija na iste radnje, čime se konstantno pojačava korisnički model interfejsa. Dosljednost, omogućavanjem dijaloga između računara i ljudskog operatera, može smanjiti količinu vremena potrebnog korisniku kako da nauči interfejs tako i da ga koristi za obavljanje posla.

Konzistentnost je svojstvo interfejsa za poboljšanje percepcije korisnika. Druga komponenta interfejsa je svojstvo njegove konkretnosti i jasnoće. To se postiže primjenom panelnog plana, korištenjem boja i drugih izražajnih tehnika. Ideje i koncepti zatim dobijaju fizički izraz na ekranu sa kojim korisnik direktno komunicira.

U praksi, dizajn korisničkog interfejsa visokog nivoa prethodi početnom dizajnu, što nam omogućava da identifikujemo potrebnu funkcionalnost aplikacije koja se kreira, kao i karakteristike njenih potencijalnih korisnika. Navedene informacije mogu se dobiti analizom tehničkih specifikacija za automatizovani upravljački sistem (ACS) i uputstva za upotrebu (OM) za objekat upravljanja, kao i informacija dobijenih od korisnika. U tu svrhu provodi se anketa potencijalnih operatera i operatera koji rade na neautomatiziranom objektu upravljanja.

Nakon određivanja ciljeva i zadataka s kojima se suočavaju, oni prelaze na sljedeću fazu dizajna. Ova faza je povezana sa kreiranjem korisničkih scenarija. Scenarij je opis radnji koje korisnik izvodi kako bi riješio određeni problem na putu do postizanja svog cilja. Očigledno je da se određeni cilj može postići rješavanjem niza problema. Svaki od njih korisnik može riješiti na nekoliko načina, stoga se mora generirati nekoliko scenarija. Što ih je više, to je manja vjerovatnoća da će neki ključni objekti i operacije biti propušteni.

Istovremeno, programer ima informacije potrebne za formalizaciju funkcionalnosti aplikacije. A nakon generiranja scenarija, lista pojedinačnih funkcija postaje poznata. U aplikaciji, funkcija je predstavljena funkcionalnim blokom s odgovarajućim ekranskim obrascima. Moguće je da se nekoliko funkcija kombinira u jedan funkcionalni blok. Dakle, u ovoj fazi se uspostavlja potreban broj ekranskih formi. Važno je definirati navigacijske odnose funkcionalnih blokova. U praksi je najprikladniji broj veza za jedan blok postavljen na tri. Ponekad, kada je slijed funkcija strogo definiran, može se uspostaviti proceduralna veza između odgovarajućih funkcionalnih blokova. U ovom slučaju, njihovi ekranski oblici se pozivaju jedan od drugog. Takvi slučajevi se ne dešavaju uvijek, pa se navigacijske veze formiraju ili na osnovu logike obrade podataka s kojima aplikacija radi, ili na osnovu percepcije korisnika (sortiranje kartica). Navigacijske veze između pojedinih funkcionalnih blokova prikazane su na dijagramu navigacijskog sustava. Mogućnosti navigacije u aplikaciji se prenose kroz različite elemente navigacije.

Glavni navigacijski element aplikacije je glavni meni. Uloga glavnog menija je takođe velika jer obavlja interaktivnu interakciju u sistemu korisnik-aplikacija. Pored toga, meni indirektno obavlja funkciju osposobljavanja korisnika za rad sa aplikacijom.

Kreiranje menija počinje analizom funkcija aplikacije. Da biste to učinili, unutar svakog od njih izdvajaju se zasebni elementi: operacije koje izvode korisnici i objekti na kojima se te operacije izvode. Posljedično, poznato je koji funkcionalni blokovi trebaju omogućiti korisniku da izvrši koje operacije na kojim objektima. Pogodno je odabrati operacije i objekte na osnovu korisničkih scenarija i funkcionalnosti aplikacije. Odabrani elementi su grupirani u uobičajene dijelove glavnog izbornika. Grupisanje pojedinačnih elemenata odvija se u skladu sa idejama o njihovoj logičkoj povezanosti. dakle, glavni meni može imati kaskadne menije, padajući meni prilikom odabira bilo kojeg odjeljka. Kaskadni meni povezuje listu pododeljaka sa primarnim odeljkom.

Jedan od zahtjeva za menije je njihova standardizacija, čija je svrha stvaranje stabilnog korisničkog modela za rad sa aplikacijom. Postoje zahtjevi koji se postavljaju sa stanovišta standardizacije koji se odnose na postavljanje naslova odjeljaka, sadržaj odjeljaka koji se često koristi u različitim aplikacijama, oblik naslova, organizaciju kaskadnih menija itd. Najopćenitije preporuke za standardizaciju su sljedeće:

grupe funkcionalno povezanih sekcija su odvojene separatorima (crta ili prazan prostor);

nemojte koristiti fraze u naslovima odjeljaka (po mogućnosti ne više od 2 riječi);

Nazivi sekcija počinju velikim slovom;

nazivi sekcija menija povezanih sa pozivanjem dijaloških okvira završavaju se trotočkom;

nazivi sekcija menija koji uključuju kaskadne menije završavaju se strelicom;

koristiti ključeve brz pristup na pojedinačne sekcije menija. Naglašeni su podvlačenjem;

dozvoliti upotrebu " Hotkeys", odgovarajuće kombinacije tastera su prikazane u naslovima sekcija menija;

dozvoli uključivanje ikona u meni;

promenjene boje ukazuju na nedostupnost nekih delova menija tokom rada sa aplikacijom;

omogućavaju vam da nepristupačne dijelove učinite nevidljivima.

Neki dijelovi menija su nedostupni zbog sljedećeg. Glavni meni je statičan i prisutan je na ekranu sve vreme dok radite sa aplikacijom. Stoga, kada radite sa različitim oblicima ekrana (u interakciji sa različitim funkcionalnim blokovima), nemaju svi delovi menija smisla. Takve sekcije su uglavnom nepristupačne. Stoga, ovisno o kontekstu zadataka koje korisnik rješava (ponekad o kontekstu samog korisnika), glavni meni aplikacije izgleda drugačije. Uobičajeno je da se o takvim različitim prikazima eksternih menija govori kao o različitim stanjima menija. Za razliku od dijagrama navigacijskog sistema koji je ranije napravljen i koji je uglavnom potreban programeru, korisnik direktno stupa u interakciju s menijem. Meni određuje broj prozora i njihov tip. Cijelo sučelje popraćeno je prozorima upozorenja, prozorima nagoveštaja i prozorima čarobnjaka koji određuju redoslijed radnji korisnika prilikom izvođenja određenih neophodnih operacija.

Preuzmite dokument

DRŽAVNI STANDARD SSSR-a

INTERFACE
ZA AUTOMATIZACIJU
KONTROLNI SISTEMI
DISTRIBUTIVE OBJEKTI

OPŠTI ZAHTJEVI

K.I. Didenko, dr.sc. tech. nauke; Yu.V. Rosen; KG. Karnaukh; M.D. Gafanovich, dr.sc. tech. nauke; K.M. Usenko; Zh.A. Guseva; L.S. Lanina; S.N. Kiiko

UVEDENO od strane Ministarstva instrumentacije, automatizacije i upravljačkih sistema

Član Upravnog odbora N.I. Gorelikov

ODOBREN I STUPAN NA SNAGU Rezolucijom Državnog komiteta SSSR-a za standarde od 30. marta 1984. br. 1145

DRŽAVNI STANDARD SSSR-a

do 01.01.90

Nepoštivanje standarda je kažnjivo po zakonu

Ovaj standard se odnosi na interfejs koji reguliše opšta pravila za organizovanje interakcije lokalnih podsistema unutar automatizovani sistemi upravljanje dispergovanim objektima korišćenjem okosne komunikacione strukture (u daljem tekstu interfejs).

U smislu fizičke implementacije, standard se primjenjuje na interfejse agregata koji koriste električne signale za prijenos poruka.

1. SVRHA I OBIM PRIMJENE

1.1. Interfejs je dizajniran da organizuje komunikaciju i razmjenu informacija između lokalnih podsistema kao dio automatizovanih sistema upravljanja tehnološkim procesima, mašinama i opremom u različitim industrijama i neindustrijskim područjima.

povezivanje sa operativnim i tehnološkim osobljem;

interfejs sa upravljačkim kompjuterskim sistemima višeg nivoa u hijerarhijskim sistemima.

2. GLAVNE KARAKTERISTIKE

2.1. Interfejs implementira bit-serijski sinhroni metod prijenosa digitalnih signala podataka preko dvožičnog magistralnog kanala.

2.2. Ukupno slabljenje signala između izlaza odašiljačke i ulaza prijemne stanice ne bi trebalo da bude veće od 24 dB, dok prigušenje koje unosi komunikaciona linija (glavni kanal i slavine) ne bi trebalo da bude veće od 18 dB, doprinelo po svakom komunikacijskom uređaju sa linijom - ne više od 0,1 dB.

Bilješka. Kada se koristi kabl tipa RK-75-4-12, maksimalna dužina komunikacione linije (uključujući dužinu krakova) je 3 km.

(Novo izdanje, izmjena br. 1).

2.5. Za predstavljanje signala, mora se koristiti dvofazna modulacija sa kodiranjem fazne razlike.

2.6. Za kodnu zaštitu poslanih poruka mora se koristiti ciklički kod sa generirajućim polinomom X 16 + X 12 + X 5 + 1.

2.7. Da bi se eliminisale slučajne greške, mora biti moguće ponovno slanje poruka između istih lokalnih podsistema.

2.8. Prijenos poruka između lokalnih podsistema mora se izvršiti korištenjem ograničenog skupa funkcijskih bajtova, čiji je redoslijed uspostavljen formatom poruke. Interfejs uspostavlja dva tipa formata poruka (slika 1).

Format 1 ima fiksnu dužinu i namenjen je samo za prenos poruka interfejsa.

Format 2 uključuje dio informacija promjenjive dužine namijenjen za prijenos podataka.

Format 2, ovisno o brzini prijenosa (opseg male ili velike brzine), trebao bi izgledati kao 2.1 ili 2.2, respektivno.

Vrste formata poruka

Format 1

2.9. Formati poruka će uključivati ​​sljedeće funkcijske bajtove:

sinhronizacija CH;

adresa pozvanog lokalnog AB podsistema;

šifra izvršene funkcije CF;

vlastitu adresu lokalnog podsistema AS;

broj bajtova podataka u informacionom delu DS, DS1 ili DS2;

informacioni bajtovi DN1 - DNp;

bajtovi kontrolnog koda KB1 i KB2.

2.8, 2.9.

2.9.1. Sinhronizacijski bajt CH služi za označavanje početka i kraja poruke. Bajtu za sinhronizaciju je dodeljen kod?111111?.

2.9.2. Adresni bajt AB podsistema identificira lokalni podsistem na koji se poruka usmjerava.

2.9.3. Izvedeni bajt CF funkcije određuje operaciju koja se izvodi u datom komunikacijskom ciklusu. Svrha bitova unutar CF bajta prikazana je na Sl. 2.

KF struktura bajtova

2.9.4. CF kodovi i odgovarajuće izvršene operacije prikazane su u tabeli.

Oznaka bajtova	Kôd funkcije								Operacija koju treba izvesti
									Multicast (općenito adresiranje)
									Pišite-čitajte
									Centralizovano ispitivanje kontrolora
									Prijenos kontrole nad glavnim kanalom
									Povratna kontrola magistralnog kanala. Poruka sa opštom adresom nije prihvaćena
									Povratna kontrola magistralnog kanala. Poruka sa opštom adresom prihvaćena
									Decentralizovano ispitivanje kontrolora. Nema zahtjeva za preuzimanje kanala. Poruka sa opštom adresom nije prihvaćena
									Zahtjev za zauzimanje glavnog kanala. Poruka sa opštom adresom nije prihvaćena
									Zahtjev za zauzimanje glavnog kanala. Poruka sa opštom adresom prihvaćena
									Dodavanje tokena
									Potvrda poruke
									Potvrda izdavanja poruke
									Potvrda prijema i naknadno izdavanje poruke. Odgovori na centraliziranu anketu
									Nema zahtjeva za preuzimanje kanala. Poruka sa opštom adresom nije prihvaćena
									Nema zahtjeva za preuzimanje kanala. Poruka sa opštom adresom prihvaćena
									Zahtjev za preuzimanje kanala. Poruka sa opštom adresom nije prihvaćena
									Zahtjev za preuzimanje kanala. Poruka sa opštom adresom prihvaćena

Nulti bit određuje tip poruke (izazov-odgovor) koja se prenosi preko magistralnog kanala.

Bit 1 poprima jednu vrijednost kada je podsistem zauzet (na primjer, formiranje bafera podataka).

Bit 2 poprima jednu vrijednost ako se u ovom ciklusu prenosi poruka formata 2.

Bit 3 uzima vrijednost jedan u ponovno poslanoj poruci istom lokalnom podsistemu ako je otkrivena greška ili nema odgovora.

(Promijenjeno izdanje, izmjena br. 1).

2.9.5. Vlastita adresa lokalnog podsistema koji generiše AC poruku se izdaje kako bi se pozvani podsistem obavijestio o adresi odgovora i provjerio ispravnost svog izbora.

2.9.6. DS bajt određuje dužinu informacijskog dijela u 2.1 formatu, dok vrijednost binarnog koda DS bajta određuje broj DN bajtova. Izuzetak je kod ?????????, što znači da se prenosi 256 bajtova informacija.

Bajtovi DS1, DS2 određuju dužinu informacijskog dijela u 2.2 formatu.

(Promijenjeno izdanje, izmjena br. 1).

2.9.7. DN bajtovi podataka predstavljaju informacijski dio poruke formata 2. Kodiranje podataka mora biti uspostavljeno regulatornim dokumentima za pridružene lokalne podsisteme.

2.9.8. Kontrolni bajtovi KB1, KB2 čine kontrolni dio i koriste se za određivanje pouzdanosti poslanih poruka.

3. STRUKTURA INTERFEJSA

3.1. Interfejs pruža mogućnost izgradnje distribuiranih sistema sa komunikacijskom strukturom okosnice (slika 3).

Struktura povezivanja lokalnih podsistema

LC1 - LCn- lokalni podsistemi; MK- glavni kanal; PC- odgovarajući otpornik

3.2. Svi povezani lokalni podsistemi moraju biti povezani na glavni kanal kroz koji se razmjenjuju informacije.

3.3. Za povezivanje lokalnih podsistema s glavnim kanalom, oni moraju uključivati ​​komunikacijske kontrolere. Kontrolori komunikacija moraju:

pretvaranje informacija iz prezentacijske forme prihvaćene u lokalnom podsistemu u formu koja je potrebna za prijenos preko glavnog kanala;

dodavanje i isticanje znakova sinhronizacije;

prepoznavanje i prijem poruka upućenih ovom lokalnom podsistemu;

generisanje i poređenje kontrolnih kodova za određivanje pouzdanosti primljenih poruka.

3.4. Razmjena poruka između lokalnih podsistema mora biti organizirana u obliku ciklusa. Ciklus se podrazumijeva kao postupak za slanje jedne poruke formata 1 ili 2 na glavni kanal Nekoliko međusobno povezanih ciklusa formira proces prijenosa.

3.5. Proces prijenosa mora biti organiziran prema asinhronom principu: lokalni podsistem mora primati odgovore na pozive poslane glavnom kanalu (sa izuzetkom grupnih operacija).

4. FUNKCIJE INTERFEJSA

4.1. Interfejs uspostavlja sljedeće vrste funkcija, koje se razlikuju po nivoima kontrole, koje zauzimaju lokalne podsisteme u procesu razmjene poruka:

pasivni prijem;

prijem i odgovor;

decentralizovano upravljanje glavnim kanalom;

zahtjev za zauzimanje glavnog kanala;

centralizovana kontrola glavnog kanala.

(Promijenjeno izdanje, izmjena br. 1).

4.2. Sastav funkcija interfejsa koje implementira lokalni podsistem određen je sastavom problema koji ovaj podsistem rješava i njegovim funkcionalnim karakteristikama.

4.3. Tip lokalnog podsistema je određen funkcijom najvišeg nivoa među onima koje su predviđene. Lokalni podsistem se smatra aktivnim u odnosu na funkciju koju obavlja u trenutnom ciklusu.

4.4. U skladu sa sastavom implementiranih funkcija interfejsa, razlikuju se sljedeće vrste lokalnih podsistema:

pasivno kontrolirani podsistem;

kontrolirani podsistem;

kontrolni podsistem;

proaktivni kontrolni podsistem;

vodeći podsistem.

4.4.1. Pasivno kontrolirani podsistem obavlja samo identifikaciju i prijem poruka upućenih njemu.

4.4.2. Upravljani podsistem prima poruke koje su mu adresirane i generira odgovornu poruku u skladu s primljenim kodom funkcije.

4.4.3. Kontrolni podsistem mora imati sposobnost:

prihvataju kontrolu razmene preko glavnog kanala u centralizovanim i decentralizovanim režimima;

generirati i prenositi poruke preko glavnog kanala;

primati i analizirati poruke odgovora;

povratak ili prijenos kontrole nad trunk kanalom nakon završetka procesa prijenosa.

(Promijenjeno izdanje, izmjena br. 1).

4.4.4. Proaktivni kontrolni podsistem, pored funkcije prema klauzuli 4.4.3, mora imati mogućnost generiranja signala zahtjeva za zauzimanje glavnog kanala, primanje i slanje odgovarajućih poruka prilikom obavljanja procedure pretraživanja za podsistem koji zahtjeva.

4.4.5. Vodeći podsistem koordinira rad svih lokalnih podsistema u načinu centralizirane kontrole glavnog kanala. Ona obavlja:

arbitraža i prenos kontrole glavnog kanala na jedan od kontrolnih lokalnih podsistema;

centralna kontrola svih lokalnih podsistema;

praćenje rada lokalnog podsistema aktivne kontrole;

prijenos poruka sa zajedničkom adresom za sve (ili više) lokalnih podsistema.

Samo jedan podsistem sa aktivnom glavnom funkcijom može biti povezan na glavni kanal.

(Promijenjeno izdanje, izmjena br. 1).

5. POSTUPAK RAZMJENE PORUKA

5.1. Svaki ciklus prenosa poruke preko glavnog kanala mora započeti sinhronizacijom svih podsistema povezanih preko interfejsa.

5.1.1. Da bi izvršio sinhronizaciju, glavni ili aktivni kontrolni podsistem mora prenijeti sinhronizacijski bajt CH na glavni kanal. Moguće je prenijeti nekoliko sinhronizacijskih bajtova uzastopno. Dodatni bajtovi za sinhronizaciju nisu uključeni u format poruke.

5.1.2. Kada se svi podsistemi sinhronizuju, glavni ili aktivni kontrolni podsistem šalje poruku u formatu 1 ili 2 na trunk link, uključujući njihove vlastite CH bajtove.

5.1.3. Svi bajtovi, sa izuzetkom kontrolnih KB1 i KB2, prenose se na glavni kanal, počevši od najmanjeg bita.

Bajtovi KB1, KB2 se prenose od najznačajnijeg bita.

5.1.4. Da bi se iz poruke koja se prenosi na glavni kanal isključio niz bitova koji se poklapaju sa kodom CH bajta, svaka poruka mora biti konvertirana na način da nakon 5 uzastopnih znakova "1" mora biti uključen još jedan znak "0" . Podsistem za prijem mora shodno tome isključiti ovaj znak iz poruke.

5.1.5. Nakon slanja poruke, uključujući CH krajnji bajt, podsistem za slanje mora prenijeti još najmanje 2 CH bajta da bi završio operacije prijema, nakon čega se ciklus prijenosa završava.

5.2. Procedura kontrole magistralnog kanala određuje redoslijed operacija za aktiviranje jednog od kontrolnih podsistema za izvođenje procesa prijenosa poruke. Podsistemi povezani preko interfejsa mogu raditi u režimu centralizovane kontrole glavnog kanala.

5.2.1. Procedura za centralizovanu kontrolu glavnog kanala predviđa prisustvo vodećeg podsistema, koji koordinira interakciju podsistema upravljajući prenosom kontrole glavnog kanala.

5.2, 5.2.1. (Novo izdanje, izmjena br. 1).

5.2.2. Prilikom prijenosa kontrole nad magistralnom vezom, glavni podsistem određuje aktivni kontrolni podsistem da izvrši proces prijenosa poruka. Da bi to učinio, vodeći podsistem mora poslati poruku formata 1 s kodom funkcije KF6 odabranom upravljačkom podsistemu.

5.2.3. Nakon prijema poruke s kodom funkcije KF6, upravljački podsistem mora postati aktivan i može izvršiti nekoliko ciklusa razmjene poruka u jednom procesu prijenosa. Broj ciklusa razmjene mora biti kontroliran i ograničen od strane glavnog podsistema.

5.2.4. Nakon prijenosa kontrole nad glavnim kanalom, vodeći podsistem mora aktivirati funkciju pasivnog prijema i uključiti kontrolu vremena. Ako unutar zadatog vremena (vrijeme čekanja odgovora ne bi trebalo biti više od 1 ms) određeni aktivni podsistem ne počne sa slanjem poruka preko magistralnog kanala, vodeći podsistem ponovo šalje poruku formata 1 sa kodom funkcije KF6 i znak retransmisije u kontrolni podsistem.

5.2.5. Ako pri ponovljenom pristupu upravljački podsistem ne počne sa slanjem poruka (ne postane aktivan), vodeći podsistem ga utvrđuje kao neispravan i provodi procedure predviđene za takvu situaciju.

5.2.6. Na kraju procesa prijenosa, aktivni kontrolni podsistem mora izvršiti funkciju povratne kontrole nad magistralnim kanalom. Da bi to učinio, mora poslati poruku vodećem podsistemu s kodom funkcije KF7 ili KF8.

5.2.7. Procedura za decentraliziranu kontrolu glavnog kanala predviđa sekvencijalni prijenos aktivne funkcije na druge kontrolne podsisteme prosljeđivanjem tokena. Podsistem koji je prihvatio token je aktivan.

5.2.8. Za početno hvatanje tokena, svi podsistemi povezani preko trunk kanala moraju uključiti intervalne tajmere, a vrijednosti vremenskih intervala moraju biti različite za sve podsisteme. Podsistemu sa višim prioritetom treba dodijeliti manji vremenski interval.

5.2.9. Ako je, nakon isteka vremenskog intervala podsistema, trunk kanal slobodan, ovaj podsistem mora sebe smatrati vlasnikom tokena i započeti proces prijenosa kao aktivni kontrolni podsistem.

5.2.10. Nakon završetka procesa prijenosa, aktivni upravljački podsistem mora prenijeti kontrolu glavnog kanala na sljedeći upravljački podsistem sa adresom AB = AC + 1, za koji mora izdati marker, aktivirati funkciju pasivnog prijema u sebi i uključiti kontrola vremena.

Kao marker se koristi poruka formata 1 (slika 1) sa kodom funkcije KF13 i adresom AB.

Ako u navedenom vremenu podsistem koji je primio token ne započne proces prijenosa, podsistem koji ga je poslao mora pokušati prenijeti token podsistemima sa sljedećim adresama AB = AC + 2, AB = AC + 3, itd. dok se token ne prihvati. Adresu podsistema koji je primio token ovaj podsistem mora zapamtiti kao narednu sve dok se početna akvizicija ne ponovi.

5.2.11. Svaki aktivni podsistem koji detektuje neovlašćeni izlazak na komunikacioni kanal mora izvršiti radnje u klauzuli 5.2.8.

5.2.12. U režimu decentralizovane kontrole glavnog kanala, svi podsistemi moraju imati aktivnu pasivnu prijemnu funkciju. U slučaju gubitka tokena (na primjer, ako aktivni kontrolni podsistem zakaže), početni mehanizam za hvatanje tokena mora biti aktiviran (klauzule 5.2.8, 5.2.9) i rad mora biti obnovljen.

5.2.13. Svaki podsistem koji posjeduje token i koji je primio aktivnu glavnu funkciju može preuzeti centraliziranu kontrolu nad magistralnim kanalom i održavati je sve dok se aktivna glavna funkcija koja mu je dodijeljena ne poništi.

5.2.7 - 5.2.13. (Dodatno uveden, amandman br. 1).

5.3. U centralizovanom režimu upravljanja, prenos kontrole glavnog kanala može se organizovati na osnovu zahteva proaktivnih kontrolnih podsistema.

5.3.1. Podsistemi moraju imati aktivnu funkciju zahtjeva za hvatanje trank kanala kako bi organizirali prijenos kontrole na zahtjeve.

5.3.2. Postoje dva moguća načina da se organizuje potraga za podsistemom koji zahteva pristup glavnom kanalu - centralizovan i decentralizovan.

5.3, 5.3.1, 5.3.2. (Novo izdanje, izmjena br. 1).

5.3.3. Sa centraliziranim prozivanjem, vodeći podsistem mora sekvencijalno anketirati sve proaktivne kontrolne podsisteme povezane na glavni kanal. Vodeći podsistem mora poslati poruku formata 1 s kodom funkcije KF5 svakom proaktivnom upravljačkom podsistemu.

Početni upravljački podsistem mora poslati poruku odgovora vodećem podsistemu s jednim od kodova funkcije KF21 - KF24, ovisno o svom internom stanju. Redoslijed operacija u postupku centraliziranog snimanja prikazan je na Sl. 4.

5.3.4. Decentralizovano ispitivanje obezbeđuje brz proces za identifikaciju proaktivnih kontrolnih podsistema koji su uspostavili zahtev za pristup glavnom kanalu. Vodeći podsistem mora kontaktirati samo prvi proaktivni kontrolni podsistem sa porukom formata 1 i kodom funkcije KF9.

Svaki proaktivni kontrolni podsistem mora primiti poruku adresiranu na njega i poslati svoju vlastitu poruku adresiranu sljedećem podsistemu redom glavnom kanalu. Generirana poruka mora sadržavati jedan od kodova funkcije KF9 - KF12, koji karakterizira stanje ovog podsistema. Postupak decentralizovanog istraživanja ilustrovan je na Sl. 5.

5.3.5. Vodeći podsistem, nakon pokretanja decentralizovane ankete, aktivira funkciju pasivnog prijema i prima sve poruke koje šalju proaktivni kontrolni podsistemi. Ovo omogućava vodećem podsistemu, nakon završetka decentralizovane ankete, da ima informacije o zahtjevima za pristup glavnom kanalu od svih proaktivnih kontrolnih podsistema.

Proces centraliziranog anketiranja podsistema

Decentralizovani proces anketiranja podsistema

Posljednji podsistem kontrole inicijative u lancu decentralizovanog glasanja mora svoju poruku uputiti vodećem podsistemu, što znači kraj postupka decentralizovanog glasanja.

5.3.6. Ako bilo koji podsistem ne šalje poruke glavnom kanalu nakon što mu pristupi, vodeći podsistem se mora probuditi i poslati mu ponavljajuću poruku identičnu prethodnom. Ako nema odgovora (ili grešaka) na ponovljeni poziv, vodeći podsistem pokreće decentraliziranu anketu iz sljedećeg podsistema, a ovaj podsistem se isključuje iz ankete.

5.4. Postupak prijenosa podataka može se izvesti u obliku jednog od sljedećih procesa:

grupno snimanje;

pisati-čitati.

5.4.1. Grupno snimanje mora biti izvedeno od strane glavnog podsistema. Prilikom grupnog snimanja, glavni podsistem izdaje poruku formata 2 glavnom kanalu, u kojoj su kod 11111111 (255) i kod funkcije KF1 upisani kao AB adresa.

5.4.2. Svi podsistemi koji odgovaraju na multicast adresu moraju prihvatiti poruku sa magistralnog linka i registrirati stanje koje pokazuje da je poruka javne adrese prihvaćena. Poruke odgovora tokom grupnog snimanja ne izdaju podsistemi za prijem.

5.4.3. Potvrda prijema grupne poruke vrši se u procesu centraliziranog ili decentraliziranog prozivanja, kao i pri vraćanju kontrole glavnog kanala, za koji je odgovarajući statusni bit uključen u kodove funkcije KF7, KF8, KF9 - KF12 i KF21 - KF24.

5.4.4. U toku procesa snimanja, glavni podsistem ili aktivni upravljački podsistem šalje poruku formata 2 sa kodom funkcije KF2 glavnom kanalu, namenjenu za prijem od strane određenog kontrolisanog podsistema, čija je adresa naznačena u AB bajtu. Nakon izdavanja poruke, aktivni kontrolni podsistem uključuje kontrolno odbrojavanje i čeka poruku odgovora.

5.4.5. Adresirani podsistem prepoznaje svoju adresu i prima poruku koja mu se šalje. Ako je poruka primljena bez greške, prijemni podsistem mora izdati odgovor glavnom kanalu u obliku poruke formata 1 sa kodom funkcije KF18.

5.4.6. Ako se otkrije greška u primljenoj poruci, podsistem primatelja ne bi trebao izdati odgovor.

5.4.7. Ako nema odgovora unutar kontrolnog vremenskog intervala, aktivni kontrolni podsistem mora ponovo prenijeti istu poruku.

5.4.8. Ukoliko nema odgovora na ponovljenu poruku, ovaj podsistem se smatra neispravnim i podsistem aktivnog upravljanja mora izvršiti proceduru propisanu za takvu situaciju (uključivanje alarma, vađenje podsistema iz upotrebe, uključivanje rezerve i sl.).

5.4.9. U režimu centralizovanog upravljanja glavnim kanalom, dijalog između upravljačkog i kontrolisanog podsistema mora biti stalno praćen od strane vodećih podsistema, koji u ovom trenutku obavlja funkciju pasivnog prijema poruka.

(Novo izdanje, izmjena br. 1).

5.4.10. Proces čitanja mora započeti slanjem poruke formata 1 s kodom funkcije KF3 od strane aktivnog upravljačkog podsistema.

5.4.11. Podsistem na koji je ova poruka upućena, ako je ispravno primljena, mora izdati odgovornu poruku formata 2 sa funkcijskim kodom KF19.

5.4.12. Ako pozvani podsistem ne može izdati podatke unutar navedenog vremena čekanja, tada nakon prijema poruke s funkcijom čitanja, mora zabilježiti znak da je podsistem zauzet i početi formirati niz podataka za izdavanje.

5.4.13. Ovaj upravljani podsistem mora zapamtiti adresu aktivnog kontrolnog podsistema koji ga je adresirao (za koji se podaci pripremaju) i postaviti poruke odgovora za prijavu zauzeća drugim kontrolnim podsistemima.

5.4.14. Za čitanje pripremljenih podataka, aktivni upravljački podsistem mora ponovo kontaktirati kontrolirani podsistem s porukom u formatu 1 s funkcijskim kodom KF3. Ako su podaci pripremljeni do tog vremena, tada kontrolirani podsistem mora izdati odgovornu poruku formata 2 s kodom funkcije KF19.

Znak zauzetosti podsistema treba obrisati tek nakon prijenosa poruke odgovora u formatu 2.

5.4.15. Ako aktivni kontrolni podsistem primi poruku odgovora bez greške, tada se proces čitanja završava.

5.4.16. Ako se otkrije greška ili nema odgovora, aktivni kontrolni podsistem ponavlja poziv i zatim preduzima mjere slične onima datim u paragrafima. 5.4.7, 5.4.8.

5.4.17. Pisanje-čitanje je kombinacija procesa prema paragrafima. 5.4.4 - 5.4.15.

5.4.18. Aktivni kontrolni podsistem šalje poruku formata 2 sa kodom funkcije KF4 glavnom kanalu.

5.4.19. Adresirani podsistem mora prihvatiti poruku koja mu je poslana i generirati odgovor.

5.4.20. Poruka odgovora u ovom procesu mora biti u formatu 2 (sadržati očitane podatke) i imati funkcijski kod KF20.

5.4.21. Praćenje pouzdanosti poslanih poruka i radnji koje preduzima aktivni kontrolni podsistem treba da bude slično onima datim za procese pisanja i čitanja.

6. FIZIČKA IMPLEMENTACIJA

6.1. Fizički, sučelje je implementirano u obliku komunikacijskih linija koje čine okosnicu kanala i komunikacijskih kontrolera koji obezbjeđuju direktnu vezu sa komunikacijskim linijama.

6.2. Komunikacijski kontroleri moraju biti implementirani u obliku funkcionalnih jedinica koje su dio podsistema, ili u obliku strukturno odvojenih uređaja.

6.3. Pravila za uparivanje i interakciju komunikacijskih kontrolera sa funkcionalnim dijelom podsistema nisu regulisana ovim standardom.

6.4. Za magistralne komunikacijske linije treba koristiti koaksijalni kabel s karakterističnom impedancijom od 75 Ohma.

6.5. Koaksijalni kabl mora biti opterećen na oba kraja odgovarajućim otpornicima sa otporom (75 ± 3,75) Ohma. Snaga odgovarajućih otpornika mora biti najmanje 0,25 W.

Završni otpornici moraju biti povezani na krajeve komunikacionih linija pomoću RF konektora.

Uzemljenje ili povezivanje komunikacionih vodova na kućišta uređaja u podsistemima za spajanje nije dozvoljeno.

6.6. Prigušenje duž komunikacijske linije glavnog kanala ne smije biti veće od 18 dB za brzinu od 500 kbit/s.

6.7. Ukupno prigušenje koje unosi svaka grana iz komunikacione linije glavnog kanala ne bi trebalo da prelazi 0,1 dB, uključujući slabljenje određeno kvalitetom spojne tačke, slabljenje na grani i slabljenje u zavisnosti od ulazno-izlaznih parametara odgovarajućih kola.

6.8. Ogranci iz glavnog kanala komunikacione linije moraju biti izvedeni koaksijalnim kablom sa karakterističnom impedancijom od 75 Ohma. Dužina svakog kraka nije veća od 3 m. Ukupna dužina svih grana je uključena u ukupnu dužinu glavnog kanala. Povezivanje na komunikacijsku liniju mora se izvršiti pomoću RF konektora. Onemogućavanje bilo kojeg od podsistema ne bi trebalo da dovede do prekida komunikacijske linije.

6.9. Komunikacijski kontroleri moraju sadržavati primopredajna pojačala koja osiguravaju:

osetljivost prijema, ništa lošije.................................................. ........ 240 mV

nivo izlaznog signala ................................................ ........................................ 4 do 5 V

izlazna impedancija ................................................................ ........................................ (37,50 ± 1,88) Ohm

6.10. Formiranje električnih signala za prijenos na glavni kanal vrši se modulacijom taktne frekvencije sa signalima prenesene poruke. Svaki bit prenesene poruke odgovara punom periodu frekvencije takta, a prednja i opadajuća ivica odašiljanog signala moraju se poklapati sa prelazom kroz nulu frekvencije takta (slika 6). Korespondencija simbola primljenih iz glavnog kanala sa značajnim stanjima uspostavlja se na sljedeći način:

simbol "0" odgovara suprotnoj fazi u odnosu na prethodni simbol,