CANopen standard je rezultat razvojnog projekta finanasiranog od strane zemalja EU, i podržan je od strane organizacije CiA (CAN-in Automation). Iz tog razloga je ovaj standard daleko rasprostranjeniji u Evropi nego u Severnoj Americi i Aziji, gde se dominantno koristi  DeviceNet protokol.

 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.

cpm-support-service_automatika_obrada_signala

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.

POSTAVI ODGOVOR

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.