CANopen je originalno razvijan za primenu u aplikacijama koje upravljaju kretanjem, tj. za najkompleksniju oblast industrijske automatizacije. Tu su zahtevi veoma rigorozni: poruke moraju biti što kraće, sa visokim stepenom iskorišćenosti sadržaja poruke za prenos korisne informacije. Takođe, pouzdanost prenosa uz ispunjenje strogih vremenskih zahteva po pitanju odziva na zahtev za prenosom poruke, jasno su ukazivali da CAN protokol mora biti osnova na kojoj će biti razvijan ovaj viši protokol. Neke od ovih zahteva zadovoljavo je i bazični CAN protokol. Međutim, on je imao i mnogo ograničenja (npr. korisna informacija u komunikaciji između dva uređaja je limitirana na 8 bajtova), što je neizostavno zahtevalo razvoj nadređenog protokola koji koji bi u sebe uključio bazični CAN protokol.

 Ciljna grupa za primenu CANopen protokola su distribuirani sistemi sa lokalnom inteligencijom, dakle, ona ista oblast primene u kojoj su za sada dominantni fieldbus sistemi kao što je recimo Profibus. Međutim, prednosti CANopen protokola su jednostavnost realizacije, visoka pouzdanost i izuzetno kratko vreme reagovanja. Pored toga, CANopen ima veoma kratko vreme oporavka nakon detektovane greške u prenosu. Često se zbog toga kaže će da CANopen bazirana mreža pre detektovati grešku i ponovo poslati ispravnu poruku, nego što će TCP/IP bazirana mreža i detektovati da je nastupila greška u prenosu. CANopen protokol vrši segmentaciju velikih poruka u osmobajtne pakete i šalje ih, paket po paket, u okviru poruke dužine 111 bitova. To omogućava da poruka većeg prioriteta uvek prekine prenos velike poruke nakon što se prenos jednog paketa završi. Prenos preostalih paketa će biti nastavljen čim mreža ponovo postane slobodna. Nasuprot tome, TCP/IP protokol zahteva integritet i neprekidnost čak 1500 bajtova, što je krajnje nepovoljno za primenu u real time aplikacijama.

 Još jedna vrlo važnu osobina CANopen protokola, a koju poseduje i DeviceNet, je zamenljivost i međusobni rad proizvoda različitih proizvođača koji podržavaju CANopen protokol. O toj karakteristici ovog protokola će biti više reči kasnije.

 CANopen je otvoreni sistem, ne samo u smislu da nije vlasništvo nijednog većeg proizvo đača ili grupacije, već i u pogledu njegove fleksibilnosti. Naime, CANopen se može konfigurisati da podržava najrazličitije mrežne strukture i topologije. On čak omogućava međusobnu komunikaciju slave uređaja. Sve to je moguće zbog njegove jednostavnosti što prouzrokuje i male memorijske zahteve. Na primer, veličina koda za osmobitni mikrokontroler koji piše i čita osmobitne podatke preko CANopen mreže je manja od 5k bajtova.

 CANopen podržava dva puta više čvorova na mreži od DeviceNet-a, čak 127, dok je izbor mogućih brzina prenosa podataka daleko veći: 1 Mb/s, 800 kb/s, 500 kb/s, 250 kb/s, 125 kb/s, 50 kb/s, 20 kb/s i 10 kb/s.

Osnovna struktura CANopen protokola

 Dva osnovna elementa u strukturi CANopen protokola su: komunikacioni profil (Communication profile) i profil uređaja (Device profile).

Profil uređaja

 Koncept profila uređaja je uveden da bi bilo moguće umrežavanje uređaja različitih proizvođača bez potrebe za pisanjem specijalizovanog softvera za svaki pojedinačni uređaj. U tom cilju CiA je prezentovala precizno uputstva koja omogućavaju proizvođačima uređaja da realizuju svoje uređaje u skladu sa predefinisanim profilima. Tek za uređaje koji su u skladu sa predefinisanim profilima, CANopen može da garantuje osnovi set mrežnih funkcija. Da bi se omogućilo postizanje dodatnih funkcionalnosti, u okviru profila je određen i jedan opcioni deo u kome proizvođači mogu definisati dodatne karakteristike uređaja, opet na kontrolisan način. Kao pomoć proizvođačima, dostupan je veliki broj standardnih profila za različite tipove uređaja: I/O module, kontrolere, merne uređaje i sl.

 Ovi profili su implementirani u obliku standardizovane baze podataka koja se naziva rečnik objekata (object dictionary). Taj rečnik objekata je u obliku ASCII karaktera zapisan u fajl koji se najčešće susreće pod nazivom EDS (Electronic Data Shit). Uz pomoć specijalnog softverskog alata, ova baza se može konfigurisati prema željenom uređaju, nakon čega se dobija tzv. DCF (Device Configuration File). Važno je razumeti da ovaj fajl sa rečnikom objekata ne mora biti prisutan na uređaju, ali mora u procesu instalacije tog uređaja na mrežu biti dostupan master-u (aplikaciji) koji tu inicijalizaciju vrši, bilo preko CANopen mreže, bilo putem Interneta, ili na bilo koji drugi razumljiv način.

CANopen rečnik objekata je tipično podeljen u 4 segmenta:

• Segment tipova podatak – u ovom segmentu je definisano koje sve tipove podataka podržava posmatrani uređaj; među njima mogu biti i tipovi podataka definisani od strane proizvođača.
• Segment komunikacionog profila -u ovom segmenu se, pored podataka o tome koji se konkretni uređaj koristi, nalaze i neki osnovni podaci o samom uređaju; takođe, ovde je mapirano i koji je tip svake vrste poruke koju konkretni uređaj razmenjuje preko mreže.
• Segment profila uređaja – ovaj segment predstavlja opis onih bazičnih osobina uređaja koji obezđuje da svi uređaji istog tipa, a od različitih proizvođača povezani na CANopen mrežu pokazuju isto bazično ponašanje.
• Segment definisan od strane proizvođača – ovo je opcioni segmen u kome proizvođač može da definiše neke dodatne funkcionalnosti specifične za njegov uređaj, ali na unapred propisan način.

Komunikacioni profil

 Komunikacioni profil zahteva da na mreži mora postojati bar dva čvora od kojih u svakom trenutku bar jedan mora biti master a drugi slave. Za takvu mrežu, CANopen protokol definiše nekoliko metoda za prenos i prijem poruka preko CAN linija. Te poruke za nas predstavljaju tzv. komunikacione objekte. CANopen razlikuje sinhroni i asinhroni mehanizam prenosa podataka.

 Sinhroni prenos je podržan preko dva tipa poruka: predefinisanih poruka (Sync Object, Time Stamp Object i Emergency Object), kao i PDO tipa poruka. Ovaj mod omogućava uređaju na mreži da bude strogo sinhronizovan sa taktom master-a. To je izuzetno bitno u nekim primenama vezanim za kontrolu kretanja. U takvim aplikacijmama je upravljačka petlja najčešće zatvorena preko CANopen linije, što zahteva sinhronizovano uzorkovanje podataka. U ovom modu rada, na raspolaganju je nekoliko parametara koji ga mogu prilagoditi konkretnoj aplikaciji. Na primer, moguće je definisati da se odbirci nekog ulaznog signala uzimaju i proseđuju preko mreže svaki n-ti ciklus i sl.

 Asinhroni prenos je podržan preko tri tipa poruka: poruka za administriranje na mreži (Network administration message), SDO i PDO tipova poruka. Asinhroni prenos omogućava uređaju da automatski obavesti druge uređaje da se neki događaj ostvario, smanjujući na taj način vreme reagovanja. Ovaj mod rada omogućava redukovanje opterećenja mreže, kao i visoke performanse u komunikaciji uz relativno malu brzinu prenosa.

Tipovi komunikacionih objekata (tipovi poruka)

 CANopen protokol pravi razliku između četiri osnovna tipa podataka (komunikacionih objekata):

• Poruke za administriranje na mreži (Layer Management (LM) i Network Management (NMT)) – ove poruke se koriste u svrhu kontrole uređaja na mreži; pod tim se podrazumeva dinamička distribucija identifikatora pojedinačnim uređajima, kontrolu stanja i komunikacionog moda jednog ili više čvorova na mreži, periodačan polling čvorova na mreži ne bi li se detektovao eventualni otkaz nekog od njih i sl.
• Poruke sa servisnim podacima (Service Data Object (SDO)) – ove poruke se šalju asinhrono, i tipično se primenjuju u dva slučaja; prva primena je u procesu konfigurisanja uređaja na CANopen mrežu; pod tim se podrazumeva inicijalizacija parametara čvora, kao i učitavanje određenog programa u uređaj; druga primena SDO je za prenos poruka koje su veće od 8 bajtova u formi više CAN telegrama; zajednička osobina za obe primene SDO je da se radi o porukama relativno niskog prioriteta.
• Poruke sa podacima procesa (Process Data Object (PDO)) – PDO se tipično koristi za poruke velike brzine i visokog prioriteta; podaci u PDO poruci su ograničeni na dužinu od 8 bajtova; format ovih poruka, kao i dužina i tip podataka koji se njima prenose se mogu konfigurisati korišćenjem SDO poruka; ovaj tip poruke se može odaslati od bilo kog čvora mreže ka jednom ili više drugih čvorova na mreži; PDO poruke se mogu prenositi i asinhronim i sinhronim mehanizmom; u slučaju asinhronog mehanizma, taj proces može biti iniciran bilo zahtevom od nekog drugog čvora (remote request), bilo određenim događajem na konkretnom uređaju.
• Predefinisane poruke, kao što su Sync Object, Time Stamp Object i Emergency Object –  emergency message je poruka najvišeg prioriteta i rezervisana je da izvesti o havarijskom stanju na uređaju koji je odašilje; Sync Object predstavlja podršku za razvoj aplikacija u realnom vremenu.

CANopen upravljanje mrežom – proces inicijalizacije

 Za razliku od DeviceNet protokola, CANopen protokol ne koristi predefinisanu šemu za raspodelu identifikatora. Po priključenju na mrešu svaki uređaj dobija tzv. inicijalizacioni identifikator poruke koji je najčešće određen stanjem nekih DIP prekidača na samom uređaju. Nakon podizanja mreže, master najpre uspostavlja dijalog sa svakim pojedinačnim slave-om preko NMT servisa. Kada je veza uspostavljna, master najpre svakom od slave-ova prosleđuje identifikatore za njihove SDO-PDO poruke. Nakon toga master upisuje potrebni kod i inicijalizuje preostale parametre svakom od slave-ova. Ove operacije master realizuje preko svojih 5 različitih NMT poruka (Start_Remote_Node, Stop_Remote_Node, Enter_Pre-Operational _State, Reset_Node i Reset_Communication), a sa druge strane slave podržava preko svoje mašine stanja (state machine) sa 4 predefinisana stanja: Initialisation, Pre_Operational, Operational i Prepared.

The post CANopen – Viši CAN protokol appeared first on Automatika.rs.

 Oba imaju zadatak da preko DeviceNet mreže uspostave tzv. Explicit Message Connection koji ne predstavlja ništa drugo do sposobnost novopriključenog, nekonfigurisanog porta da prihvata poruke sa mreže sa unapred predifinisanim identifikatorima. Preko tog “kanala” od strane nekog drugog čvora na mreži šalju se takozvane eksplicitne poruke. Eksplicitna poruka predstavlja 8-bitnu informaciju neophodnu za konfiguraciju novopriključenog čvora i locirane su u polju podataka standardne poruke sa podacima CAN protokola. Kao identifikator u CAN poruci koriste se dva specijalno rezervisana identifikatora, tako da ostali čvorovi na mreži neće reagovati na ove poruke.

 Po završetku konfigurisanja zatvara se komunikacioni “kanal“, nakon čega se konfigurisani čvor ponaša kao standardni DeviceNet čvor sa pridruženim setom identifikatora. U toku procesa konfiguracije čvor koji se konfiguriše pošalje 27 i primi 1701 eksplicitnu poruku.

Raspodela indentifikatora poruka unutar DeviceNet mreže

 Metode za raspodelu identifikatora poruka predstavljaju jedan od najznačajnijih segmenata sistema baziranih na CAN protokolu. Od raspodele identifikatora u velikoj meri zavisi efikasnost sistema, sposobnost filtriranja poruka i opterećenost mreže. Posmatrajući ovaj segment viših CAN protokola, može se konstatovati da DeviceNet i CANopen po ovom pitanju imaju sasvim različit pristup. Naime, izuzimajući određeni broj identifikatora rezervisanih u svrhu upravljanja mrežom, CANopen protokol ne koristi nikakvu predefinisanu šemu za dodelu identifikatora. Nasuprot tome, DeviceNet protokol koristi predefinisane identifikatore.

 DeviceNet mreža postavlja specifične zahteve po pitanju dužine identifikatora poruka. Naime, upotreba 29–bitnog identifikatora ne samo da se ne zahteva, već nije ni dozvoljena. Ovaj protokol definiše podelu 11-bitnog identifikatora u 3 različite grupe. Svakom od maksimalno 64 čvora pripada set identifikatora iz svake od grupa, pri čemu su ovi raspodeljeni ravnomerno na svaki od čvorova. Rezervacija maksimalnog broja identifikatora za maksimalni broj čvorova na mreži implicira da za mrežu sa manje od 64 čvora identifikatora nepostojećih čvorova neće biti dostupni za ostatak sistema. Identifikatori prve grupe se koriste za poruke visokog prioriteta. Svakom čvoru pripada po 16 identifikatora iz ove grupe. Identifikatori treće grupe su namenjeni za poruke niskog prioriteta i u ovom slučaju svakom čvoru pripada po pet. Druga grupa identifikatora je namenjena kao podrška za starije uređaje sa smanjenim mogućnostima filtracije identifikatora. To su tzv. osnovni CAN kontroleri (Basic CAN Type Controllers) koji imaju mogućnost filtriranja samo osam najznačajnijih bitova identifikatora.

Implementacija master-slave komunikacije na DiviceNet mreži

 Iako je osnovna namena DeviceNet protokola tzv. Peer-to-peer ili Multi-Master komunikacija, on implementira i uprošćenu komunikacionu šemu baziranu na master-slave relacijama. Ova predefinisana šema se naziva set predefinisanih master-slave veza (Predefined Master-Slave Connection Set). Ovaj uprošćeni model povezivanja pojednostavljuje prenos I/O poruka koje se i najčešće koriste u upravljačkim aplikacijama. Naime, mnogi senzori i aktuatori su dizajnirani tako da izvršavaju neke predefinisane funkcije u kojima je tip i količina podataka koje uređaj proizvodi i/ili koristi poznat odmah po uključenju. Takvi uređaji poseduju objekte za konekciju na mrežu koji su, zbog jednostavnosti postavljenog zadatka, skoro u potpunosti konfigurisani samim ukuljučenjem uređaja. Po priključenju na mrežu takvog uređaja master-u preostaje da jedino interno označi “vlasništvo” nad novouvedeni slave-om, nakon čega može odmah da se započne sa prenosom podataka.

 Slave može generisati podatke koristeći jedan od više unapred definisanih tipova, kao i koristiti specifične, aplikacijski definisane, tipove podataka. On može primati poruke metodom prozivanja (polling). Slave-ovi konfigurisani za ovaj mod komunikacije primaju poruke od master-a na sekvencijalan način, po redosledu definisanom u internoj listi master-a. Učestanost sa kojom se određeni slave proziva zavisi od broja čvorova u internoj listi master-a, realizovane brzine prenosa DeviceNet mreže, veličine poruka koja se predaje pojedinačnom čvoru, ali i od internog vremenskog rasporeda master-a. Podaci koje generiše master mogu biti Unicast ili Multicast tipa. Metod master-slave komunikacije se odlikuje najvećim stepenom determinističkog ponašanja DeviceNet mreže.

 Slave može biti konfigurisan da ciklično, na precizno definisane vremenske intervale generiše poruke master-u. Ovaj tip komunikacije omogućava da se učestanost prenosa podataka prilagodi zahtevima aplikacije. To opet, zavisno od same aplikacije, može značajno redukovati protok informacije po mreži, i omogućiti bolje iskorišćenje raspoloživog propusnog opsega. Detaljnija analiza ovog metoda razmene poruka je data u poglavlju koje se bavi TTCAN protokolom.

 Konačno, slave uređaj može biti konfigurisan tako da poruke generiše na promenu nekog od svojih stanja (Change of State (COS) Message). Za ovaj mod rad vezana su dva dodatna konfiguraciona parametra. Prvi od njih definiše vremenski interval nakon koga slave mora da pošalje unapred definisanu poruku (tzv. Heartbeat Message) u slučaju da se u toku tog intervala ne desi promena nijednog od analiziranih stanja. Ovim se obezbeđuje da se master obavesti da je slave “živ” i aktivan bez obzira što ne šalje očekivane I/O poruke. Drugi, korisnički podesivi parametar, je tzv. Production Inhibit Time parametar, čiji je zadatak da ograniči frekvenciju pojavljivanja COS poruke i tako spreči da posmatrani čvor zaguši komunikacionu liniju. Ova dva parametra pružaju dizajneru mreže moćno sredstvo da optimalno prilagodi karakteristike aplikacije propusnom opsegu mreže.

Više o DeviceNet protokolu pronađite OVDE.

 Naponema: Dalja objašnjenja pojmova korišćenih u ovom tekstu možete naći u  radu Implementacija CAN protokola. Autori: Željko Pantić, Igor Stamenković

The post Konfiguracija uređaja na DeviceNet mreži appeared first on Automatika.rs.