Što je Microsoft .NET Micro Framework

Microsoft .NET Micro Framework je mala i efikasna .NET runtime okolina za izvršavanje takozvanog upravljanog koda (eng. menaged code) na malim i resursima ograničenim računarskim platformama na kojima se ne može izvršavati operativni sustav Windows CE i njegov .NET Compact Framework.  .NET Micro Framework je sličan .NET Comapact Frameworku kao i punom .NET Frameworku što znači da se aplikacije za njega mogu razvijati istim alatima i razvojnim okruženjima. Ovo je tek uvjetno točno jer  je razvoj mikrokontrolerskih aplikacija ovog trenutka moguć samo u Visual Studiju 2010 s programskim jezicima C# i Visual Basic na Windws platformi te programskim jezikom Mono na Linux platformi. Micro Framework ne zahtjeva temeljni operativni sustav za svoje izvršavanje jer se Common Language Runtime nazvan TinyCLR instalira direktno na hardversku platformu pa se on još naziva i bootable runtim.  On je relativno mali i zauzima  samo nekoliko stotina kilobajta RAM memorije i ne zahtjeva procesor koji im jedinicu  za upravljane memorijom (eng. memory management unit-MMU). Osim toga Micro Framework se može izvršavati na  jeftinim 32-bitnim mikrokontrolerima koji troše vrlo malo energije. Razvoj programa za mikrokontrolerske uređaje upotrebom .NET Micro Framework-a razlikuje se od dosadašnjeg  pristupa. Klasična pristup  uzima u obzir specifičnosti odabrane sklopovske opreme kao što su sabirnice, memorijska mapa, prekidni vektori i slično i napisani program se može izvršavati samo na ciljanoj platformi. Micro Framework ima apstraktni pristup sklopovskoj opremi preko baznih klasa koji tu opremu tretira kao objekte što vam omogućava i objektni pristup programiranju. Stoga  ne morate brinuti o konfiguraciji specifičnih sklopovskih komponenti nego samo postaviti određena svojstava korištenih sklopova u baznoj klasi. Ovaj pristup se još  naziva  upotreba managed driver-a  i omogućava razvoj aplikacija koje nisu vezane uz određenu sklopovsku opremu. Kao i ostali frameworki  i Micro Framework izvršava upravljani kod odnosno kompajler  generira, o procesoru neovisan, kod koji se naziva intermediate language  a onda se TinyCLR brine da se taj kod izvrši na određenoj platformi. Micro Framework nije sustav za rad u realnom vremenu (eng. real-time) i od njega se ne može očekivati strogo determinističko ponašanje. To znači da nemamo pristup definiranju raspoređivanja odnosno ne možemo egzaktno definirati način i parametre raspoređivanja. Isto tako određeni očekivani događaji mogu biti odgođeni za nekoliko milisekundi  a uzrok tome može biti neki  sistemski zahtjev za prekid ili rad sustava za oslobađanje memorije (eng. Garbage collection) bez obzira što se on aktivira u slobodno sistemsko vrijeme. Isto tako moramo znati da je izvršavanje upravljanog koda u pravilu sporije nego nativnog koda. Razlog  je što se s Micro Framework-om upravljani kod izvršava kao interpreter   za razliku od punog Framework-a i Compact Framework-a gdje postoji takozvani just-in-time  kompajler koji kod prvog izvršavanja pretvara upravljani u nativni kod.

Netduino

Netduino je elektronička platforma bazirana na ARM mikrokontrolerima koju možete programirati koristeći Micro Framework. Razvojno okruženje je Microsoft Visual Studio 2010 ali se može koristiti i  besplatna varzija ( Visual Studio 2010 Express). Netduino je hardverski otvorena platforma što znači da se  firmware kod kao i električne sheme i PCB projekti mogu koristi pod Apache 2.0 i BSD open source licencom. Ovoga trena postoje 4 varijante Netduino modula:

1. Netduino
2. Netduino Plus
3. Netduino mini
4. Netduino Go

Moduli su prilagođeni za amatersku primjenu dok se dizajn bazira na popularnom konceptu Arduina koji je napravljen za AVR mikrokontrolere. To zapravo znači da se na Netduino modulima mogu koristiti gotovo svi dodaci, koji se popularno nazivaju shields,  za Arduino module. Ovih dodataka  ima mnogo, od jednostavnih  senzora do složenih sustava kao što su GSM i drugi komunikcijski moduli.   Shodno tome  Netduno moduli imaju digitale ulaze/izlaze, analoge ulaze, serijske portove te I2C i SPI sučelja. Napajanje modula je izvedeno korištenjem nestabiliziranog napona 9-12 V koji se potom stabilizira te su na konektore izvedeni naponi 5V i 3.3V koje možete koristiti za ostatak  hardvera. Napajati module moguće je i preko USB porta koji istovremeno služi i za programiranje modula.

Netduino i Netduino Plus (najnovija inačica Netduino Plus 2 ) dizajnirani su upravo na Arduino konceptu i razlikuju se po količini memorije i korištenim sučeljem (Netduino Plus 2 ima Ethernet) dok je Netduino mini baziran na Basic Stamp dizajnu. Netduino mini je modul je izveden kao 24 pinski DIP chip i njega možete koristiti u svojim projektima upravo kao da  je riječ o standardnom mikrokontroleru. Netduino Go je najnovija inačica i od ostali  se razlikuje po konektorima  i filozofiji univerzalnog sučelja za proširenja koji je nazvan GoBus . GoBus je zapravo virtualni  hadrversko/softverski I/O koncept definiran kao open source protokol baziran na master-slave principu.    Na bilo koji GoBus port se može priključiti bilo koji GoBus modul sa podržanom  plug and play funkcionalnošću.

Da bi mogli programirati Netduino module potrebna nam je i određena programska oprema. To se u prvom redu odnosi na Visual Studio prilagođen za Netduino platformu. Potrebne alate možemo podjeliti u tri skupine a to su:

1. Visual Studio  2010 razvojna okolina
2. .Net Micro Framework razvojni SDK (eng. Software Development Kit)
3. Netduino razvojni SDK

Ove programske pakete najbolje je i instalirati ovim redoslijedom. Kao što sam prije napisao kao razvojna okolin koristi se Microsoft Visual Studio 2010 i o tome kako se on koristi možete naći puno materijala na internetu. Valja samo napomenuti da se može koristiti i besplatna inačica Visual Studio 2010 Express koji možete skinuti sa stranica http://www.microsoft.com/express/downloads/ . Kao osnovni jezik za programiranje zamišljen je   C# ali je kasnije napravljeno da se može koristi i Visual Basic te Mono na Linux platformi. Ove mogućnost  ovisi o firmware-u koji se nalazi u modulu koji ste kupili. Trenutno je aktualna varijanta NETMF4.2 koja podržava i Visual Basic. Ako nabavite module  koji imaju firmaware 4.1 a želite programirati u Visual Basicu potrebno je upisati novi firmware koji možete skinuti s službenih stranica Netduino projekta http://forums.netduino.com/index.php?/topic/5120-announcing-net-mf-42-upgrade-for-all-netduino-hardware/  a proceduru kako to napraviti  možete naći nai wiki stranicama Netduina. Zamjena firmware ne mora biti isključivo radi ovoga razloga nego, kao što je slučaj sa svim platformama otvorenog koda, neke nove mogućnosti i funkcije te ispravljanje grešaka iz prethodnih verzija te će te vjerojatno jednom u budućnosti mijenjati firmware.  .Net Micro Framwork SDK je su sistemske datoteke Visual Studia za spomenuti framework dok je Netduino razvojni SDK prilagođenje Visual Studia za podršku Netduino modula. Zahvaljući njemu će te nakon instalacije u svom VS imati pridodane predloške (eng. template ) za sve spomenute Nedtuino module.

Prvi program

Nakon uspješne instalacije navedenih programskih pakete i otvaranja kutije s vašim Netduinom spremni ste za pisanje prvog programa.Nakon startanja VS uz ostale predloške naći će se i predlošci za Netduino module. Na vama je da odaberete predložak koji odgovara vašem moduli i VS će izgenerirati vaš prvi projekt.

Kao i ostali VS projekti i Neduino projekti se spremanju u jedan folder gdje se nalazi sve vezano uz projekt. Ako do sada niste radili s Visual Studiom pogledajte strukturu projekt foldera koji se po defaultu nalazi na …userDocumentsVisual Studio 2010Projects.  Struktura foldera projekta je gotovo identična kao i za ostale tipove VS projekata osim razlike u Debug i Release subfolderu gdje  će te naći subfoldere [be] i [Ie].  Nakon otvaranja projekta na zaslonu će te imati otvoren editor za pisanje vašeg koda. Za razliku od oubičajnog Visual Basic projekta ovdje nećete imati formu kao polazišnu klasu  nego VB  modul.

Kao što sam rekao program se piše unutar klase Module1.vb a jednostavan program može izgledati ovako:

Module Module1
	Sub Main()
		Dim led As OutputPort = New OutputPort(Pins.ONBOARD_LED, False)
	        Do
	            led.Write(True)
	            Thread.Sleep(1000)
	            led.Write(False)
	            Thread.Sleep(1000)
	        Loop
	End Sub
End Module

Ovaj primjer ima zadatak da na Netduinu pali i gasi ugrađenu LE diodu  Pins.ONBOARD_LED u taktu od 1 Hertza a to se izvršava unutar beskonačne DO…Loop petlje.

Nakon što ste napisali kod potrebno je program prebaciti u Netduino. Za razliku od programiranja mikrokontrolera na klasičan način ovdje vam nije potreban nikakav programator (niti hardverski niti softverski)  već je sve spremno za programiranje i startanje vašeg programa. Naravno na početku rada ste trebali spojiti Netduino na vaše računalo korištenjem micro usb kabela koji ste dobili uz modul. Ako je sve ispravno instalirano nakon priključivanja modula računalo će prepoznati modul i instalirati potrebne drivere kao i kod priključivanja  drugog usb uređaja. Da bi ste provjerili da li imate vezu s vašim Netduino modulom kliknite na  My Project    na desnoj strani i otvorit će vam se prozor sa svojstvima vaše aplikacije (Project  Properties). Ovdje možete vidjeti postavke aplikacije, kompajlera, referenci i slično.  Izaberite  .NET Micro Framework i provjerite aktivne postavke.  U polju Device trebao bi se pojaviti vaš Neduino modul dok bi polje Transport  trebalo biti postavljeno na USB. Ako je to tako spremni ste za programiranje vašeg Netduino modula  odnosno “deplojanje” kako se to ovdje naziva. To će te učinit na nači da odete u glavni izbornik i izaberete Debug/Start Debug ili jednostavno kliknete na zeleni trokutić (strelicu) u osnovnoj  traci s alatima. U  donjem statusnom  prozoru možete pratiti trenutne operacije programiranja i nakon nekog vremena LED dioda na vašem Netduini bi trebala veselo žmirkati. Sada kada je vaš program u Netduini vi možete zatvoriti VS  bez utjecaja na program u modulu koji je trajno pohranjen. Svaki put kad uključite napajanje (na bilo koji način ) program u Netduinu će se početi izvršavati.

Moram napomenuti da sam pri pisanju ovoga posta polazio od pretpostavke da ste bar jednom pokušali pisati program u Visual Basicu. Ako to nije tako i ako se, uz upoznavanja s Netdunom, trebate upoznati i sa  osnovama pisanja Visual Basic programa to će te morati učinit sami.  Nadam se da  sam vam bar približio metodologiju programiranja mikrokontrolera u .Net okruženju i želim puno zabavnih trenutaka s Netduinom .

Još jednom ću ponoviti linkove gdje možete dobiti više informacija i preuzeti potrebne alate:

Službene stranice Netduino projekta: http://netduino.com/

Microsoft Micro Framework: http://www.microsoft.com/net/multiple-platform-support

Microsoft Visual Studio 2010 Express : http://www.microsoft.com/visualstudio/eng/products/visual-studio-2010-express

Netduino forum: http://forums.netduino.com/

Netduino Wiki stranice: http://wiki.netduino.com/

Prva računala za kontrolu industrijskih procesa praktički i nisu imala nikakvu interakciju sa ljudima koji su nadzirali proizvodnju. Ako su i imali to su bile kontrolne ploče naslijeđene od ranijih relejnih sustava upravljanja. Razvojem informatičke  tehnologije monitori su postali sastavni dio i industrijskih postrojenja  te je nadzor i interakcija ljudi i strojeva postala mnogo jednostavnija i efikasnija. Razvoj aplikacija u ovom segmentu automatizacijskih sustava dugo je bio moguć  samo sa specijalnim razvojnim alatima. Pojavom OPC tehnologije stvari su se bitno promjenile te se sada ovaj dio posla  može obaviti s gotovo bilo kojim programom i razvojnim okolinom opće (programske) namjene.  Ovdje ću pokušati objasniti razvoj malog programa pisanog u Visual Basicu 6 koji koristi OPC tehnologiju za komunikaciju s procesnim računalom i može poslužiti kao operatorsko sučelje (HMI).

Visual Basic 6

Basic (Beginners All-Purpose Symbolic Instruction Code) je programski jezik kojeg koriste, ili su koristili, najviše programera u povijesti računalstva. Visual Basic 6 je inaćica koja sadrži više stotina naredbi i funkcija te je integriran u razvojnu okolinu  (IDE) za brzi i pregledni razvoj aplikacija s grafičkim sučeljem. Osim  Visual Studija, Visual Basic 6 je sastavni dio i Microsoft Office paketa  gdje služi za automatizaciju Excela, Worda ili PowerPointa. Upravo ta inaćica nazvana VBA (Visual Basic for Application) je i skriptni jezik mnogih komercijalnih razvojnih okolina za razvoj SCADA i HMI aplikacija kao što su WinCC  (Simatic)   ili FactoryTalk  (RockwelSoftware). Ova činjenica te relativna jednostavnost učenja i primjene dobar su razlog da se pozabavite Visual Basicom  mada će vas mnogi profesionalni programeri gledati s prezirom. Iako ne možemo reći u potpunosti, VB6  je objektni programski jezik i za razvoj aplikacije koristimo objekte . Objektima možemo podešavati svojsta (Properties) i definirati akcije na  pojedine događaje (Events). Isto tako objektima možemo definirati aktivnosti koje će izvršati i to se zovu metode (Methode). Razvojna okolina VB6 sastoji se od nekolko cijelina :

• u sredini zaslona je objekt koji se naziva forma (Form) i on predstavlja grafičko sučelje naše aplikacije. Na formu stavljamo ostale objekte grafičkog sučelja kao što su tipke (Buttons), natpisi (Labels), padajuči izbornici (DropdownBoxs), slike (Images) i tako dalje.  Isto tako u na tome mjestu može biti programski editor gdje pišemo programski kod. Klikom miša na pojedini objekt prelazimo iz grafičkog u tekstalni mod izrade aplikacije odnosno prelazimo u programski editor.
• s lijeve strane zaslona  nalazi se traka s dostupnim objetima (Toolbox) koje možemo prebaciti na formu  jednostavnim potezanjem  mišom.
• s desne strane uobićajeno je da se nalaze tablični preglednici svojstava i strukture našeg projekta. Kada kliknemo na pojedini objekt na  formu (selektiramo ga) u ovom pregledniku se automatski izlistavaju svojstva dotičnog objeka gdje ta  svojstva možemo i mijenjati.

Osim toga na vrhu zaslona nalazi se standarni izbornik (Menu) sa svim alatima potrebnim za manipulaciju s programskim elementima, kompaliranjem programa, traženjem pogrešaka i definiranjem opcija razvojne okoline. Na dnu zaslona se u pojedinim fazama  programiranja pojavljuju prozori s rezultatima kompajliranja i eventualnim pogreškama. Dakle ako niste nikada programirali u VB6 potrebno je malo detaljinije se upoznati s načinom  rada u njemu. Na interentu imate mnogo tutorijala od početnih koraka do naprednih opcija pa se ja ovdje neću više baviti time.

OPC server – simulator procesa

Da bi zrada bilo koje HMI/SCADA aplikacije bila komforna, odnosno da se ne piše na slijepo, potrebno je imati i vezu prema sklopovskoj opremi (PLC-u). Kako je kanal komunikacije  prilkom pisanja ovakvih aplikacija korištenjem VB6  OPC server neophodno je imati i OPC server sposoban za komunikaciju prema ciljanom PLC-u. Da bi  vam demonstrirali primjer pisanja male HMI aplikcaije koje  vi možete modificirati i testirati napisan je poseban OPC server. Ovaj OPC server ne treba nikakvu slopovsku opremu nego u svom kodu mijenja vrijednosti tag varijabli. Ovakve simulatorske OPC server možete naći kod svih proizvođača OPC servera ali ono što ovaj server razlikuje od njih je to da on u potpunosti simulira mali stvarni proces. To znaći da vi ne morate ručno mijenjati vrijednosti OPC tagova (na strani simulatora) nego se OPC server ponaša kao da je spojen na PLC koji upravlja industrijskim procesom. Radi se o jednostavnom procesu punjenja i pražnjenja spremnika tekućine.

OPC server QuercusLab.ProcesSimulatorLite.1.0 sadrži sljedće OPC stavke:

Punjenje spremnika ostvaruje se uključivanjem dobavne pumpe  Tank.SourcePump.ON  a pražnjenje uključivanjem ventila za ispuštanje Tank.DrainValve.ON. Razina u spremniku Tank.Level.Value se može kontrolirati  definiranjem stavke Tank.AutomaticMode. Ručni mod omogućava neovisnu kontrolu rada dobavne pumpe i ispusnog ventila. Automatski mod osigurava konstantnu zadanu razinu  Tank.Level.Preset  upravljanjem  radom dobavne pumpe. Dobavna pumpa se uključuje nakon što razina padne ispod zadane za vrijednost definiranog postotka Tank.Level.Hystersis a isključuje kada razina dostigne zadanu vrijednost. Mod rada nema utjecaja na ventil za ispuštanje i on se uvijek može uključivati i isključivati.

Visual Baisc 6 HMI aplikacija

Izgradnja OPC klijent HMI aplikacije korištenjem VB6 programskog jezika  se može razvrstati na dva osnovna načina:

• pisanje programa korištenjem  osnovnih univerzalnih objekta korisničkog sučelja
• pisanje programa korištenjem specijaliziranih objekta namijenjenih radu sa OPC serverom

Prvi način zahtjeva više posla jer je potrebno pisanje vlastitih rutina dohvata podataka s OPC servera korištenjem poziva specificiranim u DA Automatizacijskom sučelju. Brigu o dobivenim podacima također mora voditi programer te ih obrađivati i prosljeđivati univerzalnim objektima korisničkog sučelja ili baze podataka. Ovakav način uz svoje nedostatke ima i prednosti u vidu potpune kontrole nad aplikacijom i maksimalne prilagodljivosti klijent aplikacije zahtjevima korisnika. Drugi način oslobađa programera ovih poslova jer se o tome brinu odabrani specijalizirani objekti.  Zadatak programera je da odabere objekte koji će najbolje odgovarati zahtjevima OPC klijent aplikacije, implementira  ih u svoj projekt te ih parametrira. Današnja ponuda takvih objekata je dosta velika i ona uključuje kontrole vizualizacije procesa, obrade i prezentacije alarma, pripreme i implementacije recepata, generiranja izvještaja te kontrole baza podataka. Osnovna prednost ovakvog načina izgradnje OPC klijent aplikacije je brzina izrade i smanjena mogućnost skrivenih grešaka jer su korištene kontrole već prošle testiranje. Negativni aspekti su uniformnost aplikacija i dodatna sredstva za nabavku kontrola koja poskupljuju aplikaciju. Naravno da je moguće i kombinacija ova dva načina tako da se maksimalno iskoriste prednosti i eliminiraju  mane obiju načina

Grafičko sučelje – HMI vizualizacija

U ovoj OPC klijent HMI aplikaciji pokazati ćemo upravo taj kombinirani način. Aplikacija će se bazirati isključivo na vizualizaciji procesa i upravljanju osnovnim aktuatorima procesa radi jednostavnosti i boljeg razumijevanja početnicima. Shodno tome i elementi za njenu izgradnju su zaparavo grafički objekti vizualizacije. Kao primjer korištenja gotovih  objekta,koji mogu biti komercijalni ili besplatni,  imat ćemo jednostavne grafičke prekidače i lampice. Ovi objekti su zapravo ActiveX kontrole koje smo razvili isto tako korištenjem Visual Basica te su kompajlirani zasebno.  ActiveX  objekt koje ćemo koristi nosi naziv Mini_HMI.ocx i sadrži kontrole qlSwitch, qlLamp i qlSwitchFaceplate.

Drugi način je kreiranje vlastiti kontrola unutar samog programskog koda koji se koriste isto kao i prije opisane komercijalne kontrole. Generiranje ovih kontrola je na način da se u projekt doda takozvani UserControl objekt. UserControl može sadržavati sve što i Form objekt tako da se više standardnih VB kontrola može implementirati u novu, vlastitu. Ponašanje ovakvog objekta unutar HMI aplikacije definirate u programskom kodu.  Programski kod korisničkih kontrola je,  kao i izvršni kod, integralni dio Visual Basic projekta. Programiranje ovih kontrola je , uz neke specifičnosti, identično kao i programiranje ostalih elementa VB6 projekta. Važno je napomenuti da se prilkom kreiranja  UserControl objekta vodi idejom da se on piše što je više moguće  univerzalno da bi se mogao upotrebiti više puta  unutar samog projekta ili na nekim drugim projektima. Dobro napisani UserControl se može izdvojiti iz projekta i iz njega se može kompajlirati ActiveX kontrola koju smo spomenuli prije.  U našoj HMI aplikaciji koristit ćemo UserControl objekt qlTank koji će vizualizirat sam spremnik. Korisnička kontrola se sastoji od dvije  Label kontrole te jedne Shape kontrole. Label kontrole služe za ispis naziva spremnika i ispisa razine tekućine u spremniku dok Shape kontrola predstavlja senzor razine. Sama dinamička vizualizacija razine u spremniku odrađena je korištenjem grafičkih API poziva. Ovaj način programiranja je malo složeniji i zahtjeva  bolje poznavanje programiranja ali omogućava efektivniju i složeniju vizualizaciju. Ako niste vični ovakvom načinu programiranja na raspolaganju su vam milijuni besplatnih UserControl objekta koje možete skinuti s interneta i koristiti prilikom razvoja  vlastite HMI aplikacije.

Treći način je da ne koristite ništa od ovoga navedenog nego da svoju HMI aplikaciju gradite korištenjem standardnih kontrola koje dolaze uz VisualBasic 6 i pisanjem programskog koda u osnovnim procedurama.

Kreiranje grafičkog sučelja odnosno vizualizacije započinjete postavljanjem gore navedenih objekta na glavnu (u ovom slučaju i jedinu) formu aplikacije. Prilikom pokretanja VB6 automatski se generiranja jedan Form objekt koji je ujedno i glavni odnosno startni. Po potrebi možete dodavati još formi korištenjem menu komandi Project.AddForm te ih pozivati iz programskog koda u skladu s vašim idejama. Elemente  korisničkog sučelja jednostavno dovlačite iz trake s alatima i postavljate na formu. Prilikom postavljanja automatski se generiraju imena objekta i oni se pojavljuju u tablici na desnoj strani ekrana. Tamo im možete mijenjati nazive kao i većinu svojstava. U traci s alatima se nakon prvog pokretanja mogu naći samo standardne kontrole. U našem slučaju se koristimo s dodatnim kontrolama te ih moramo dodati u traku s alatima. ActiveX kontrole su datoteke s ekstenzijom *.ocx i uobičajno je da se nalaze u sistemskom folderu …windows/system32  ali će raditi s bilo koje lokacije ako se dobro registriraju. Dakle  nakon što ste kopirali ActiveX datoteku u željeni direktorij potrebno je kontrolu registrirati i to činite tako da odete na  Windows StartButon/Run te u Open upišete  “regsrv32 <puna putanja/naziv activex datoteke>”.  Nakon što ste uspješno registrirali ActiveX kontrolu možete ju dodati u traku s alatima tako što će te kliknuti (desni klik)  na traku s alatima i izbrati komandu Components. Na zaslonu će se pojaviti lista svih regsitriranih ActiveX kontrola te će te ju odabrati i kliknuti OK. U našem slučaju će te odabrati “Quercus Lab mini HMI Components” i nakon što ste kliknuli Ok gore opisane kontrole odnosno njihove ikone će se pojaviti u traci s alatima.

UserControl  ikone se automatski pojavljuju u traci s alatima kada se dodaju u projekt. Dodati se mogu na dva načina. Prvi je da se iz menija aktivira komanda Project/Add UserControl i tada se dodaje korisnička kontrola bez koda. Dakle ovo će te raditi kada želite napraviti novu korisničku kontrolu. U slučaju da ju već imate, bilo iz prijašnjeg projekta ili ste ju skinuli s interneta, dodat će te ju na način da kliknete na Project drvo ( na desnoj strani zaslona) te aktivirate komandu Add/User Control te iz dijaloga Add UserControl/Existing izaberete  datoteku s programskim kodom kontrole.

Spajanja na OPC server

Nakon što ste pripremili i kreirali svoje HMI grafičko sučelje možete priječi na pisanje koda za komunikaciju s procesnom opremom. Ovdje se pristup bitno razlikuje od rada na komercijalnim SCADA razvojnim alatima. Ako je kreiranje izgleda grafičkog sučelje bilo slično komunikacijski dio je morate odraditi isključivo pisanjem programskog koda. Još je nešto neophodno da napravite prije samog kodiranja a to je podešavanje komunikacijskog kanala. U VB 6 on može biti isključivo OPC server i moramo u projekt dodati ActivX objekt koji zna komunicirati s njim. Taj objekt se naziva DA Automation Wraper  i može se besplatno skinuti s web stranica OPC fondacije. Kao i kontrole i ovaj wraper se mora prvo registrirati u sustav po gore opisanoj proceduri a tek potom ga se može  dodati u reference projekta. Dodavanje se vrši izborom komande Project/References iz glavnog menija.

Sada smo spremni za pisanje koda: Pisanje koda započinjemo u području deklaracija tako da deklariramo neophodne OPC objekte. Radi se o objektima tipa OPCServer, OPCGroups i OPCGroup. Objekte koji imaju događaje deklarirat ćemo s  ključnom riječju WithEvents  da bi mogli koristiti iste. Drugi dio deklaracija odnosi se na varijable u koje spremamo podatke. To će biti varijable tipa polje u koje ćemo spremati nazive tagova (OPCItemIDs), korisničke šifre tagova (OPCItemsClientHandles), serverske šifre (ItemServerHandles) te greške prilikom transakcija s OPC serverom (ItemServerErrors). Na kraju dodajemo ostale varijable koje će služiti u algoritmima prezentacije podataka.

Dim WithEvents simOPCServer  As OPCServer
Dim simGroups As OPCGroups
Dim WithEvents simOPCGroup As OPCGroup
Dim OPCItemCollection As OPCItems
 
Dim OPCItemCount As Integer                         ' količina opc stavki
Dim OPCItemIDs() As String                          ' polje identifikacijskih oznaka (naziva) stavki
Dim OPCItemsClientHandles() As Long                 ' polje šifri stavki definiranih od strane klijenta
Dim ItemServerHandles() As Long                     ' polje šifri stavki definiranih od strane servera
Dim ItemServerErrors() As Long                      ' polje za spremanje greški servera
Dim RemoveItemServerErrors() As Long                '
Dim WriteServerHandles() As Long                    ' polje za upis stavki na opc server - serverska sifra
Dim ItemsValue() As Variant                         ' polje za vrijednosti stavki

Nakon što smo deklarirali neophodne varijable OPC objekte potrebno je na početku izvršavanja programa i kreirati ih. To  ćemo  napraviti u događaju Form _Load:

Private Sub Form_Load()
' EVENT: kada se ucita form (prakticki na pocetku programa)

Set simOPCServer = New OPCServer                                ' kreira se objekt OPCServer
Call OPC_Connect("QuercusLab.ProcesSimulatorLite.1.0")          ' poziv potprograma spajanja na OPC server
Call OPCValue_Init                                              ' poziv potprograma inicijalizacije vrijednosti procesa

End Sub

Za spajanje i prekid veze s OPC serverom pisat ćemo posebne procedure i onda ih pozivati po potrebi. Procedura za spajanje naziva se OPC_Connect a kao parametar prosljeđujemo naziv OPC servera.  Pozivom metode simOPCServer.Connect spajamo se na isti. Slijedi kreiranje OPCGruop objekta te definiranje njegovih svojstava. Neophodno je kreirati bar jednu OPC grupu metodom  simGroups .Add(“Tank”) te definirati vrijeme osvježavanja podataka svojstvom simGroups.UpdateRate.  Potom ćemo proglasiti grupu aktivnom s svojstvom simGroups.DefaultGroupIsActive = True. Želimo li zaprimati podatke svaki puta kada se promjene vrijednosti tagova definirati ćemo to svojstvom simGroups.IsSubscribed = True. Dodavanje tagova (u OPC terminologiji Items– stavki) započinjemo dimenzioniranjem polja u koja spremamo simboličke nazive i korisničke  šifre tagova.  Nazive spremamo u u polje OPCItemIDs a korisničke šifre u polje OPCItemClientHandles. Završetak dodavanje tagova je pozivanje metode OPCItemCollection.OPCItems.AddItems  a parametri koji su neophodni su broj stavki (broj članova definiranih polja), polje s nazivima stavki (OPCItemsIDs), polje s korisničkim šiframa (OPCItemClientHandles), polje serverskih šifri (ItemServerHandles) te polje za eventualne greške prilikom transakcije (ItemsServerErrors). Polje serverski šifre je prazno polje koje dimenzionira server i u njega upisuje vlastite šifre naših tagova koje korespondiraju indeksom s korisničkim šiframa.

Private Sub OPC_Connect(ByVal OPC_ServerName As String)
' PODPROGRAM: SPAJANJE NA OPC SERVER
' aktiviram OPCserver objekt , spajam se na njega i dodajem (prijavljujem) tagove

simOPCServer.Connect (OPC_ServerName)                   ' spajanje na OPC server

Set simGroups = simOPCServer.OPCGroups                  ' kreira se objekt OPCGroups
simGroups.DefaultGroupIsActive = True                   ' objekt aktivan
simGroups.DefaultGroupDeadband = 0                      ' definicija "mrtvog pojasa" analognih stavki (globalno)

Set simOPCGroup = simGroups.Add("Tank")                 ' kreira se objekt OPCGroup s nazivom "Tank"
simOPCGroup.UpdateRate = 300   ' milisekunda            ' period osvježavanja podataka  u milisekundama
simOPCGroup.DeadBand = 0                                ' definicija "mrtvog pojasa" analognih stavki
simOPCGroup.IsSubscribed = True                         ' pretplate stavki aktivne

Set OPCItemCollection = simOPCGroup.OPCItems            ' kreira se objekt OPCItems
OPCItemCollection.DefaultIsActive = True                ' objekt aktivan

' priprema  polja stavki za dodavanje na OPC server
OPCItemCount = 6                                        ' broj stavki
ReDim OPCItemIDs(6)                                     ' dimenzioniranje polja naziva stavki
ReDim OPCItemsClientHandles(6)                          ' dimenzioniranje polja šifri stavki
' definiranje stavki
OPCItemsClientHandles(1) = 1: OPCItemIDs(1) = "Tank.Level.Value"         '
OPCItemsClientHandles(2) = 2: OPCItemIDs(2) = "Tank.Level.Preset"
OPCItemsClientHandles(3) = 3: OPCItemIDs(3) = "Tank.Level.Hysteresis"
OPCItemsClientHandles(4) = 4: OPCItemIDs(4) = "Tank.SourcePump.ON"
OPCItemsClientHandles(5) = 5: OPCItemIDs(5) = "Tank.DrainValve.ON"
OPCItemsClientHandles(6) = 6: OPCItemIDs(6) = "Tank.AutomaticMode"
 
' dodavanje stavki na server
' OPCItemCount - broj stavki  koje se  dodaju
' ItemsIDs - polje s nazivima tagova
' OPCItemsClientHandles - polje s siframa stavki definirani od strane klijenta
' ItemServerHandles - polje u koje ce OPC server upisati (vratiti) serverske sifre stavki
' (ove sifre ce se koristiti prilikom upisa vrijednosti tagova na OPC server)
' ItemServerErrors - polje u koje ce server upisati eventualne greske prilkom ove transakcije
OPCItemCollection.AddItems OPCItemCount, OPCItemIDs, OPCItemsClientHandles, ItemServerHandles, ItemServerErrors
 
' ako je nesto poslo krivo ispisujem gresku i zaustavlja aplikaciju
For i = LBound(ItemServerErrors) To UBound(ItemServerErrors)
    If ItemServerErrors(i) <> 0 Then
        MsgBox "Greška prilkom dodavanja stavki na OPC server!" & OPCItemIDs(i), vbOKOnly, "Error"
        Unload Me
        Stop
    End If
Next
End Sub

Primanje i slanje podataka

Zahvaljujući tome što smo se prilikom spajanja pretplatili (.IsSusctibed=True) na podatke ne trebamo provjeravati stanje vrijednosti tagova. OPC server će svaki put kada se vrijednost bilo kojega taga promjeni generirati događaj DataChange i proslijediti nam nove vrijednosti. Prosljeđuje se broj stavki NumItems (praktički broj elementa polja podataka), polje s šiframa stavki ClientHandles, polje s vrijednostima tagova ItemValues, polje s kvalitetom veze Qualities, polje s vremenom očitanja TimeStamps te oznake transakcije TransactionID. Na nama je zadatak  da prođemo kroz polje korisnički šifri, dekodiramo tagove te vrijednosti istih ispišemo u kontrole na našem ekranu. To uobičajno činimo koristeći se Case petljom za dekodiranje i For…Next petljom za provjeru svih članova polja.

Private Sub simOPCGroup_DataChange(ByVal TransactionID As Long, ByVal NumItems As Long, ClientHandles() As Long, ItemValues() As Variant, Qualities() As Long, TimeStamps() As Date)
' EVENT: kada se promjeni stanje "pretplacenih" tagova OPC server generira ovaj event i salje vrijednosti tih tagova
' NumItems - broj (kolicina) tagova
' ClinetHandles() - korisnicke sifre tagova
' ItemsValue() - vrijednosti tagova
Dim i As Integer
 
' obrada svih tagova
For i = 1 To NumItems
    'Debug.Print ClientHandles(i)
    'Debug.Print
    Select Case ClientHandles(i)
    Case 1
        Me.tnkMain.Value = ItemValues(i)
        If Me.tnkMain.Maxlevel = True Or Me.tnkMain.MinLevel = True Then
            Me.lmpAlarm.Value = True
            If Me.tnkMain.Maxlevel = True Then Me.labAlarmText.Caption = "Razina iznad dozvoljene"
            If Me.tnkMain.MinLevel = True Then Me.labAlarmText.Caption = "Razina ispod dozvoljene"
        Else
            Me.lmpAlarm.Value = False: Me.labAlarmText.Caption = ""
        End If
    Case 2
        Me.txtlevelPreset.Text = Str(ItemValues(i))
    Case 3
        Me.txtHystersis.Text = Str(ItemValues(i))
    Case 4
        Me.lmpSourcePump.Value = ItemValues(i)
        Call SourcePipeAnimation(ItemValues(i))
    Case 5
        Me.lmpDrainValve.Value = ItemValues(i)
        Call DrainPipeAnimation(ItemValues(i))
    Case 6
        Me.swfAutomatic.LampValue = ItemValues(i)
    End Select
Next i
 
End Sub

Želimo li promjeniti vrijednost neke stavke na raspolaganju su nam funkcije za sinkroni i asinkroni  upis. Sinkroni upis ćemo napravit funkcijom SyncWrite dok su nam parametri: broj stavki koje upisujemo , polje s serverskim šiframa, polje s vrijednostima stavki i polje za eventualne greške prilikom ove operacije. Ovdje valja primjetiti da se kao parametar koriste serverske a ne korisničke šifre stavki. Serverske šifre su upravo one koje nam je OPC server vratio prilkom dodavanja naši korisničkih šifri. U našem primjeru na početku programa u OPC server zapisujemo inicijalna stanja nekih stavki da bi nam simulator počeo raditi  a to radimo u proceduri OPCValue_Init.

Private Sub OPCValue_Init()
' PODPROGRAM : POCETNE POSTAVKE
' upisujem u OPC server zadanu vrijednost

ReDim WriteServerHandles(3): ReDim ItemsValue(3)
WriteServerHandles(1) = ItemServerHandles(2): ItemsValue(1) = 1900                          ' "Tank.LevelPreset" = 1900
WriteServerHandles(2) = ItemServerHandles(3): ItemsValue(2) = 80                            ' "Tank.LevelHysteresis" = 80
WriteServerHandles(3) = ItemServerHandles(6): ItemsValue(3) = Me.swfAutomatic.SwitchValue   ' "Tank.AutomaticMode" = stanje prekidaca MAN-AUTO
' sinkrono zapisivanje vrijednosti
' 3 - broj stavki
' WriteServerHandles - polje s siframa definiranim od servera
' ItemsValue - polje se definiranim novim vrijednostima
' ItemServerErrors - polje s greškama prilkom zapisivanja
simOPCGroup.SyncWrite 3, WriteServerHandles, ItemsValue, ItemServerErrors
' obrada greske
For i = LBound(ItemServerErrors) To UBound(ItemServerErrors)
    If ItemServerErrors(i) <> 0 Then
        MsgBox "Greška prilkom dodavanja stavki na OPC server!", vbOKOnly, "Error"
    End If
Next
End Sub

Na kraju rada  neophodno je da se uredno odjavimo s OPC servera. Ovdje ćemo to ućiniti u događaju Form_Unload. Brisanje stavki  radimo metodom simOPCGroup.OPCItems.Remove a grupe simGroups.Remove. Na kraju oslobodimo memoriju brisanjem objekta koje smo koristili.

Private Sub Form_Unload(Cancel As Integer)
' EVENT: prije nego se program završi

Dim RemoveItemServerErrors() As Long
' brišemo naše prijavljenje stavke sa servera
' 6 - broj stavki koje brišemo (sve!)
' ItemServerHandles - polje serverskih šifri koje brisemo
' RemoveItemServerErrors - polje s greskama kod brisanja
simOPCGroup.OPCItems.Remove 6, ItemServerHandles, RemoveItemServerErrors
' brišemo korištenu grupu
' brišemo korištene objekte za grupu
simGroups.Remove ("Tank")
Set simOPCGroup = Nothing
Set simGroups = Nothing
' odspajamo se sa server
' brišemo objekt za server
simOPCServer.Disconnect
Set simOPCServer = Nothing
End Sub

Ovo će biti dovoljno za osnovnu komunikaciju vaše HMI aplikacije i procesnog računala a dalje je na vama da ju nadogradite s željenom, odnosno potrebnom, funkcionalnošću koristeći se standardnim i dodatnim VB6 rutinama.

Preuzimanje

Ovdje su opisane samo one programske rutine koje se tiću OPC servera dok  rad sa VB objektima možete vidjeti u programskom kodu. Sve potrebno, uključujući i OPC Srever ProcesSimulatorLite.1.0, da pokušate napraviti vlastiti VB6 OPC klijent ili samo da vidite kako se to radi   možete skinuti ovdje: VB6ClientSetup.exe

Za pokretanje OPC servera ProcesSimulatorLite.1.0 potrebno je imati instaliran NET Framework3.5 kojega možete skinuti sa službenih Microsoftovih stranica: dotNetFx35setup.exe

Ako nemate instaliran Visual Basic 6 razvojni  paket za pokretanje iskompajliranog primjera bit će vam potreban VB6 Runtime koji možete skinuti ovdje: VBRun60.exe

OPC DA sučelje (interface)

OPC tehnologija se temelji na  Microsoft OLE (ActiveX) tehnologiji i komunikacijskim modelima COM (Component Object Model) i DCOM (Distributed Component Object Model). OPC sadrži standardni set sučelja, svojstva i metoda koje se koriste u aplikacijama kontrola procesa i automatizacije. OLE/COM tehnologije definiraju se kako individualne programske komponente koje mogu međudjelovati i dijeliti podatke.

OPC specifikacije sadrže dva seta sučelja:

1. Prilagođeno  sučelje (Custom Interface)
2. Automatizacijsko sučelje (Automation Interface)

OPC poslužitelji moraju implementirati prilagođeno sučelje i opcijski  mogu implementirati automatizacijska  sučelja.

U neki m slučajevima OPC Foundation  osigurava omotnicu (wrapper) za standardno automatizacijsko sučelje . Ovaj wrapperDLL može biti korišten za bilo koji specifični proizvođački  (Vendor) poslužitelj.  Općenito, OPC klijent programi koji se kreiraju koristeći skriptno bazirane programske jezike će koristiti automatizacijsko sučelje. Klijent programi koji su kreirani u C++ će lakše koristiti prilagođeno sučelje za postizanje najbolje performanse.

Ono što ovaj standard želi definirati je zajednički način na koji aplikacije u oblasti upravljanja i vođenja procesa mogu pristupiti podacima o procesu. Automatizacijsko sučelje treba osigurati istu funkcionalnost kao i prilagođeno (Custom) sučelje, ali na način koji je blizak trendovima u načinu programiranja  u automatizaciji. Osnovni cilj dizajna sučelja je da radi kao omotnica (wrapper) za OPC DataAcces Custom Interface te da osigurava pogodan mehanizam funkcionalnosti. Klijent koji koristi OPC Data Automation sučelje koristi wrapper DLL kao sponu ka OPC Data Custom Interface serveru. Na ovaj način bilo koja aplikacija koja ima OLE Automation Interface funkcionalnost (VBA,VB.Net, Delphi,  Excel) ima mogućnost pristupa lokalnom OPC serveru  a preko wraper-a udaljenom OPC Custom Interface serveru.

OPC DA Server  model

OPCServer objekt je osnovna instanca OPC poslužitelja. Korisnik mora kreirati OPCServer objekt  prije nego se mogu dobiti reference za druge objekte. Sadrži OPCGroups kolekciju i kreira OPCBrowser objekte.

OPCServer objekt

OPCServer objekt osigurava  korisniku pristupi (za čitanje i pisanje) ili komunikaciju sa skupom izvora podataka. Tipovi izvora koji su na raspolaganju su funkcija implementacije poslužitelja. OPC Automation klijent se povezuje sa OPC Automation serverom koji komunicira sa izvorom podataka (odnosno sa DA Serverima), putem funkcionalnosti koju osiguravaju automatizacijski objekti koji su opisani u ovom standardu. OPCServer osigurava jedan OPCGroups objekt za Automation kolekciju da bi održavao sakupljanje OPCGroup objekata. Korisnik pristupa poslužitelju izvršavajući OPCServer.Connect metodu birajući jedan od dostupnih OPC poslužitelja čiju listu može dobiti pomoću OPCServer.GetOPCServers metode. Nakon uspješnog pristupa dostupna su mu podaci o karakteristici, statusu i postavkama izabranog poslužitelja kao što su verzija poslužitelja, proizvođač, ime poslužitelja i slično. Od događaja dostupan je samo jedan, OPCServer.ServerShutDown, koji obavještava da poslužitelj nije više dostupan.

 OPC Browser objekt

Objekt  koji  izlistava  (brows-a)  imena  stavki  (items)  u  konfiguraciji  poslužitelja.  Postoji  samo  jedna  instanca  OPCBrowser  objekta  za  instancu  OPCServer  objekta.  Ako  server  ne  podržava  izlistavanje  CreateBrowser  metoda OPCServer  objekta  neće  kreirati  ovaj  objekt.    Korisnik  su  dostupna  eventualna  hijerarhijska  organizacija  stavki  pomoću  OPCBrowser.ShowBranches  i  OPCBrowser.ShowLeafs  metoda  kao  i  navigacija  kroz  istu  metodama OPCBrowser.MoveToRoot, OPCBrowser.MoveUp, OPCBrowser.MoveDown i OPCBrowser.MoveTo metodama

OPCGroups i OPCGroup objekt

OPCGroups objekt je automatizacijska kolekcija koja sadrži sve OPCGroup objekte. Ovaj objekt klijent kreirao unutar opsega OPCServera sa kojim se automatizacijska  aplikacija povezala putem OPCServer.Connect metode. Osigurava korisniku dodavanje, modificiranje i upravljanje s kolekcijom OPCGrup objekta.

OPCGroup objekt je instanca OPCGroups objekta. Namjena ovog objekta je održavanje informaciju o stanju i osiguranje mehanizma kreiranja servisa akvizicije podataka za OPCItem Collection objekta koji OPCGroup objekt referencira. Korisnik dodaje novu grupu u kolekciju metodom OPCGruop.Add. Nakon  toga može svojstvom OPCGroup.IsActive kontrolirati status dostupnih podataka unutar grupe. Pomoću  svojstva OPCGroup.IsSubscribed se korisnik preplaćuje na asinkrono primanje podatak kada se promjeni vrijednost odabranih stavki na poslužitelju. Promjena vrijednosti inicira aktiviranje OPCGroup.DataChange događaja te se servisiranjem istog zaprimaju vrijednosti promijenjenih podataka. Definiranjem svojstva OPCGropu.UpdataRate kontrolira se period sinkrone razmjene (Read/Write) odabranih podataka u milisekundama. Razmjena se ostvaruje OPCGroup.SincWrite i OPCGroup.SincRead metodama. Asinkrona razmjena podataka moguća je metodama OPCGroup.AsincRead, OPCGroup.AsincWrite te     OPCGroup.AsincRefresh metodama. Završetkom asinkrone razmjene podataka generiraju se događaji OPCGroupe.AsincReadComplete i OPCGroup.AsincWriteComplete.

OPCItems i OPCItem objekt

OPCItems je  kolekcija koja sadrži sve OPCItem objekte koje  klijent kreira unutar opsega OPCServer-a, i odgovarajućeg OPCGroup objekta koji je automatizacijska aplikacija kreirala. OPCItem je Automation objekt koji održava definiciju stavki (Item-a), trenutnu vrijednost, statusnu informaciju i posljednje vrijeme ažuriranja (Update).

OPC DA tipovi podataka

Kao što je spomenuto u početki OPC koristi COM a osnovni tip podataka u njemu je Variant. Variant je tip  podataka duljine 16 byte koji u sebi može sadržavati većinu ostalih   tipova. Prva dva byta su cijelobrojni podaci koji definiraju tip podataka koji su pohranjeni od 7 do 15 byte.

Svi OPC serveri podržavaju slijedeće tipove Variant podataka:

Arhitektura informacijskog sustava u procesnoj industriji

Uvođenjem inteligentnih uređaja u postrojenjima kao dijelova sistema vođenja nadzora i upravljanja pojavljuje se obilje informacija, o uređajima ali i o postrojenju, koji nisu prije bili raspoloživi. Ove informacije osiguravaju podatke o stanju uređaja, njegovim konfiguracijskim parametrima te okruženju u kojem se uređaj nalazi. Spomenute informacije  se trebaju prikazati korisniku na konzistentan način. Brigu nad njima preuzimaju procesna računala (PLC-i) koristeći suvremene industrijske računalne mreže kao podatkovne magistrale na razini postrojenja (polja). Instaliranje distribuiranih sistema upravljanja (DCS) i SCADA sustava sa zadaćom  da nadziru upravljanje   procesima čine ove podatke raspoložive i u elektronskoj formi, za razliku od ranijih sustava kada su mnogi od njih bili ručno prikupljani i zapisivani. Zahtjev za kontrolom financijskih aspekata proizvodnih procesa ostvaruje se integracijom ovih prikupljenih informacija iz procesa u poslovne sustave. Držeći se ovih smjernica pri  razvoju informacijskih sustava  u procesnoj industriji dolazimo do tipične arhitekture sustava u kojoj uočavamo tri osnovne razine:

1. Poslovni menedžment
2. Menadžment procesa
3. Menadžment u postrojenju (polju)

OPC – novi koncept sustava automatizacije

Dosadašnji sustavi automatizacije podrazumijevali su komunikacije između uređaja na razini automatizacije u polju i nadzornih sustava koji su se temeljili na komunikacijskim protokolima koji su bili svojstveni sklopovlju uređaja koje povezujemo. Takav način povezivanja zahtijevao je isporuku ili izradu komunikacijskih programskih sučelja (software driver-a) za svaki uređaj u sustavu. Ta programska sučelja isporučivala su se u sklopu SCADA sustava samo za poznatije uređaje (PLC, mjerni uređaji, itd.). Često se događalo da potrebe povezivanja nekih specifičnih, a često vrlo važnih, uređaja u sustav predstavlja tešku a nekad i nepremostivu poteškoću. U tom slučaju koristili su se takozvani konverteri protokola koji su često bili skuplji od samih uređaja. Te i slične poteškoće poskupljivale su složenije sustave, te tako pridonijele opće priznatom mišljenju da se složenija sustavi automatizacije ekonomski ne isplate.

Cijene integracija različitih podsustava znatno su rasle zbog činjenice da je za svaki uređaj bilo potrebno izrađivati posebno programsko sučelje. Statistike govore da je za programski razvoj tipične nadzorno – kontrolne aplikacije bilo potrebno utrošiti za pisanje programskog sučelja oko 25-30% inženjerskog razvojnog vremena. Integratori sustava trošili su veoma mnogo razvojnog vremena za takve poslove te je konačna cijena sustava bila skupa kao i održavanje budući da je zahtijevalo specijalistička znanja. Rezultat tog  je bio da je krajnji kupac kupovao skup sustav čije je održavanje i eventualno proširenja bilo isto tako komplicirano i skupo. Rješenje se ogledavalo u razvoju standardnog sučelja koji će omogućiti jednostavnu primjenu (plug & play) te jednostavno održavanje i buduće proširenje. Takav standard trebao je da bude prikladan i za jednostavne i složene sustave koji bi se gradili na osnovu  otvorene i jednostavne komunikacije od osnovne razine automatizacije do složenih informacijskih MIS sustava (Management Information System).

Rješenje je ponuđeno kao novi koncept baziran na OPC tehnologiji. Na priloženim slikama prikazana je razlika novog koncepta OPC strukture (Sl. 2a) i stare komunikacijske strukture (Sl. 2b). Terminologija OPC izvodi se kao  skraćenica (OLE for Process Control) koja označava Microsoft tehnologiju OLE (Object Linking and Embedding) primijenjenu u kontroli procesa. Iz toga slijedi kompatibilnost OPC tehnologije sa MS Windows aplikacijama i činjenica da je moguće izraditi veoma prikladne i cijenom povoljni male aplikacije vizualizacije koje kao podlogu (OPC Client) koriste npr. neku od komponenata MS Office paketa (npr. Excel). Tijekom protekle decenije OPC je postao industrijski standard kojeg razvijaju najuglednije svjetske kompanije sa područja automatizacije u suradnji sa tvrtkom Microsoft. U tom smislu osnovana je neprofitabilna zaklada OPC Foundation koja okuplja preko 150 članova, pretežno svjetski poznatih razvojnih ustanova i tvrtki. OPC tehnologija se temelji na već spomenutom Microsoft OLE (ActiveX) tehnologiji i komunikacijskim modelima COM (Component Object Model) i DCOM (Distributed Component Object Model). OPC sadrži standardni set sučelja, svojstva i metoda koje se koriste u aplikacijama kontrola procesa i automatizacije. OLE/COM tehnologije definiraju se kako individualne programske komponente koje mogu međudjelovati i dijeliti podatke.

OPC specifikacije i smjernice razvoja

OPC specifikacije definiraju skup sučelja (Interface) koji se lako implementiraju primjenom objektno orijentiranog programiranja i omogućava laku manipulaciju tim objektima. Softver pomoću koga korisnik upravlja procesom  (Human-Machine Interface), upravljački softver ili softver za akviziciju podataka (SCADA) može obrađivati ili prikupljati podatke sa različitih računara u mreži. Specifikacije definiraju standardne mehanizme za pristupanje podacima na serveru po nazivima. Projektanti koji razvijaju hardver i softver mogu jednostavno razmjenjivati informacije pomoću širokog spektra sistemskih aplikacija, u koje se ubrajaju distribuirana kontrola sistema (DCS), SCADA sustavi, procesna računala PLC (Programmable Logical Controler) kao i razni inteligentni uređaji, povezani preko računarske mreže.

Prva verzija OPC standarda V1.0 je objavljena u kolovozu 1996. godine. Tijekom  1997. godine vršene su korekcije na standardu a krajem 1998. godine se pojavila verzija V2.0 sa značajnim izmjenama. Standard je podržan od strane najvećih svjetskih kompanija koje se bave izradom PLC-a i softvera za vizualizaciju procesa. OPC je baziran na tehnologijama OLE, ActiveX, COM  i DCOM i dostupan je na 32-bitnom operativnom sistemu Microsoft Windows. Pomoću DCOM tehnologije mogu  se razmjenjivati podaci (objekti) i sa drugim operativnim sistemima kao što su Unix ili Linux. Do danas je izdano desetak OPC specifikacija od kojih možemo izdvojiti tri osnovne:

1. OPC Data Access (OPC DA) – Koristi se za razmjenu podataka između servera i procesne opreme u realnom vremenu.  OPC Data Access je  najvažnija specifikacija i sučelje  koje je najviše implementiranu u svim primjenama OPC tehnologije danas. Ono omogućava čitanje i pisanje varijabli procesa u realnom vremenu.
   OPC Complex Data, OPC Batch, and OPC Data eXchange (DX) su ekstenzije OPC DA servera za poboljšanu funkcionalnost. Complex Data  definira način pristupa kompleksno strukturiranim varijablama procesa dok  OPC Batch  je specifikacija namijenjena klijentima kod slijednih (batch) procesa (S88). OPC Data eXchange  (DX)  specifikacija definira način razmjene podataka između DA servera  kada je klijent definiran unutar servera.
2. OPC Alarms & Events (OPC A&E) – Omogućava  pozive alarma i događaja na zahtjev za razliku od kontinuiranog protoka podataka OPC DA servera.  To uključuje obradu alarma, aktivnosti operatora, informacijske poruka i poruke o praćenju procesa. Pri tome se pod pojmom  Alarms  i Events  smatraju jednokratne poruke o stanju procesa i nedozvoljenim promjenama unutar njega.
3. OPC Historical Data Access (OPC HDA) – Za razliku od OPC DA servera koji omogućava praćenje procesa u realnom vremenu OPC HDA te podatke sprema i čuva. Koristeći se OPC HDA serverom SCADA sustavi se transformiraju iz jednostavnog (data logging) sustava u kompleksne alate za praćenje i analizu procesa u bilo koje vrijeme.

Od ostalih  OPC XML-DA  je prva OPC specifikacija koja nije bila vezana uz određenu programsku platformu kod koje je DCOM/COM komunikacija zamijenjena s HTTP/SOAP protokolima i tehnologijom web-servisa. OPC Security definira kontrole pristupa serveru  da bi se zaštitile važne  informacije i onemogućilo neovlašteno mijenjanje parametara procesa. OPC Commands definira mehanizme za pozivanje metode ili za izvršavanje programa putem OPC. Ova specifikacija nikada nije objavljen  budući da je završena  nakon što je započet rad na OPC Unified Architecture ali je sadržaj i funkcionalnost u potpunosti je uklopljen u UA.

Slijedeća generacija OPC specifikacija trebala je napustiti koncept ograničene Microsoft Windows platforme a OPC Foundation bi trebala osigurati portabilnost na ostale operativne sustave. Ova specifikacija nazvana OPC Unified (OPC UA) podržava skalabilnost kompletnog protokola što omogućava implementaciju na  embeded platforme za razliku od dosadašnje DCOM platforme koja troši razmjerno puno memorijskih resursa . Sadašnje specifikacije DA, A&E i HDA servera zahtijevaju zasebno memorijsko prostore adresiranje dok ih UA specifikacija ujedinjuje što pojednostavljuje programske pozive. Sigurnost današnji servera je vrlo mala jer komunikacija zahtjeva otvoren port 135.  OPC Unified arhitektura predviđa sigurnosni sustav baziran na W3C specifikacijama koji uključuju autorizaciju korisnika, razmjenu digitalnih certifikata i opcionalnu enkripciju poruka.

Performanse danas korištenih servera  uvelike su ograničene performansama DCOM sučelja dok novi standard predviđa mnogo bolje jer definira dvije transportne opcije:

• Web bazirani protokol SOAP (XML kodirana razmjena podataka preko HTTP) kojije u osnovi tekstualan što daje mogućnost lagane integracije u razne sustave ali je i do nekoliko puta sporiji od DCOM prijenosa

• UA binarni protokol (binarno kodirana razmjena podataka preko TCP/IP) čija brzinaje usporediva, pa čak i brža od DCOM karakteristika

Osim ovoga nova OPC UA specifikacija donosi bolje rezultate na polju robusnosti aplikacija, redundancije podataka, te mogućnosti upotrebe  kompleksnih i strukturiranih podataka.

Princip rada

Osnovni princip rada kapacitivnih senzora osjetljivih na dodir je promjena kapaciteta područja dodira. Metoda detekcije promjena je različita a ovdje će se objasniti metoda koja je uobičajena u većini mjerača kapaciteta a radi se integracijskoj metodi mjerenja. Algoritam metode je usporedba vremena trajanja nabijanja kondenzatora poznatog kapaciteta sa vremenom nabijanja nepoznatog a na osnovu njihovog omjera se izračunava kapacitet nepoznatog kondenzatora. Za primjenu metode kod dodirne tipke nama treba samo sigurna detekcije promjene kapaciteta i to je osnovni zahtjev jer je promjena kapaciteta vrlo mala.Poznato je iz osnova elektrotehnike da svaka  elektronska komponenta pa tako i mikrokontroler odnosno njegov I/O port posjeduje parazitni kapacite i on se koristi kao etalonski kondenzator C_s. Nepoznati kondenzator  C_x je kapacitet ljudskog tijela  koji po modelu za ESD ima kapacitet do 100 pF  i koji se formira kada se prstom dodirne metalna  površina izolirana nekim tankim izolatorom. Ako za mikrokontroler izaberemo ATTiny2313 odnosno  parazitni kapacitet  je oko 15 pF i prijelazna pojava punjenja toga kondenzatora na napon koji  se detektira kao logička 1 ( a to je po specifikacijama 2,65 V kod napajanja 5V) traje oko 9 mikrosekundi. Ako kao jednu elektrodu drugog kondenzatora pripremimo područje bakra na tiskanoj pločici površine 16×16 mm to vrijeme punjenja se produžuje na oko 16 mikrosekundi  i to je ta vremenska razlika koju moramo iskoristiti kao detekciju dodira odnosnu “pritisnute” tipke.

Da bi osigurali detekciju promjene kapaciteta poslužit će mo se standardnim I/O portom mikrokontrolera Atmel ATTiny2313 jer on sadrži sve električne i programske komponente potrebne za to. Koristit ćemo registre DDRx.n, PORTx.n i PINx.n gdje x označava korišteni port (A,B ,C, D) dok n označava broj bita porta(0-7). DDR registar služi za definiranje da li će port biti korišten kao ulazni ili izlazni. Ako je njegova vrijednost 0 port se koristi kao ulaz te će  registar PORT biti odspojen od pina mikrokontrolera tako da stanje registra PORT neće imati utjecaja na stanje pina. Druga namjena DDR registra je uključivanje pull-up otpornika koji su integrirani u mikrokontroler. Ako je  port definiran kao ulaz (DDRx.n=0)  s registrom PORTx.n se uključuje (PORTx.n=1)  odnosno  isključuje (PORTx.n=0) navedeni otpornik. Osnovna namjena registra PORTx.n  je jasno odnosno on spaja pin mikrokontrolera na Vcc odnosno Gnd ako je I/O  port definiran kao izlaz (DDRxn=1).  Namjena Registar PINx.n  je  uvijek ista a to je da čita logičko stanje pina mikrokontrolera. Od ostalih vanjskih komponenti potrebna nam je jedan otpornik preko kojeg ćemo trajno spojiti pin mikrokontrolera na Vcc napajanje te površina bakra tiskane pločice koja će služiti kao jedna ploča kondenzatora odnosno imati ulogu senzora i  ova površina mora biti pokrivena nekim  izolatorom.

Navedene komponente će nam poslužiti za generiranje dva osnovna stanja a to je pražnaje i punjenje kondenzatora. Pražnjenje se ostvaruje na način da se stanje registra  PORTx.n postavi u logičku nulu a potom se stanje DDRx.n registra promjeni u logičku jedinicu. Na taj način će se pin mikrokontrolera postaviti u nulu  što će rezultirati pražnjenjem kondenzatora C_s.  i sada je sustav spreman za mjernu sekvencu. Postavljanjem DDRx.n registra u logiču nulu odspaja se pin mikrokontrolera od PORTx.n registra te je omogućeno  punjenje kondenzatora preko vanjskog otpornika R.

Istovremeno s početkom punjenja aktivira se mjerenje vremena i  čitajući stanje registra PINx.n provjerava se logičko stanje ulaza odnosno napon na kondenzatoru. Kada je vrijednost PINx.n registra logička jedinica zapamti se vrijeme punjenja i to etalonsko vrijeme i označava stanje “dodir nije detektiran” odnosno “tipka nije stisnuta”. Kada se prstom dodirne površina “senzora” na tiskanoj pločici spaja se kondenzatoru Cs još jedan Cx (paralelno) a vrijeme potrebno da se detektira logička jedinica registra PNx.n se produžava. To prekoračenje prije izmjerenog etalonskog vremena omogućava da se detektira prisutnost prsta na senzoru odnosno stanje “taster je stisnut”.

Programska izvedba

Gore opisane sekvence vrlo je jednostavno izvesti i to ćemo napravit u BASCOM programskom jeziku. Na početku je potrebno izmjeriti vrijeme da se parazitni kondenzator Cs bez prisutnosti prsta na senzoru nabije na logičku jedinicu i to spremiti u varijablu TouchTreshold. Učiniti ćemo to u DO… LOOP u petlji  u koji će biti sekvenca pražnjenja kondenzatora (2 milisekunde), početak punjenja, čekanje od TouchTreshold mikrosekundi  te provjeravanje da li je pin u logičkoj jednici. Poslije toga na početku slijedeće  iteracije  petlje povečavamo varijablu TouchTreshold za 1. Kada se detektira logička jedinica na pinu izlazimo iz DO ..LOOP petlje i trenutna vrijednost  varijable TouchTreshold   je  prije spomenuto etalonsko vrijeme . Tom vremenu dodajemo još 2 mikrosekunde da bi sa sigurnošću  detektirali neprisutnost prsta.

DO
   TouchTreshold = TouchTreshold + 1
   DDRD.3 = 1 : PORTD.3 = 0                      ' prazni
   waitms 2
   PORTD.3 = 0 : DDRD.3 = 0                      ' start punjenja
   waitus TouchTreshold
   IF PIND.3 = 1 THEN                            ' provjera napunjenosti
      TouchTreshold = TouchTreshold + 2
      EXIT DO
   endif
LOOP

Nakon što smo ovo napravili možemo u glavnom programu skenirati sve naše senzor, detektirati dodir i izvršiti određene akcije. Program je sličan inicijalizacijskom dijelu samo što ovdje kao rezultat na provjeru  napunjenosti palimo ili gasimo signalizacijsku diodu. Dakle nakon što smo ispraznili kondenzator počinjemo ga puniti  te  testiramo da li je on pun nakon  vremena koje je dobiveno u inicijalizacijskoj sekvenci. Ako je nakon toga vremena pin nije logičkoj jedinici znači da je ukupni kapacitet  koji se puni veći od parazitnog kapaciteta C_s odnosno površina senzora je dotaknuta prstom. U listingi programa je kod samo za 1 kanal i koristi se pin 7 (PD3) kao senzor a pin 18 (PB6) kao indikacija  dodirnutog senzora.

LED1 ALIAS PORTB.6
DO
   ' Channel 1
   DDRD.3 = 1 : PORTD.3 = 0                     ' prazni
   waitms 2
   PORTD.3 = 0 : DDRD.3 = 0                     ' start punjenja
   waitus TouchTreshold
   IF PIND.3 = 0 THEN                           ' provjera napunjenosti
      LED1=1
   ELSE
      LED1=0
   endif
LOOP

Praktična realizacija

Kao prototip je napravljena tipkovnica s četiri dodirne tipke. To je ustvari elektronski modul koji  bi trebao zamijeniti četiri standarne tipke na malom operatorskom panelu u  mojem projektu kučne automatizacije. Svaka dodirna tipka ima svjetlosnu  indikaciju kao povratnu informaciju  “pritiska” tipke. Upotrebljeni mikrokontroler je ATtiny2313 a sam modul nema   stabilizirano napajanje već se napaja s 5V iz uređaja na kojem će biti. Izlazni signali su četiri digitalna izlaza koji poprimaju  stanje dodirne tipke a pomoću kratkospojnika na pinu 3 (PD1) može se definirati signal “pritisnute” tipke . Izlazni signal da je tipka  “pritisnuta” bit će onog  logičkog nivoa koji je trenutno na pinu 3.

Tipkovnica je napravljena na dvostranom  tiskanoj pločici  tako da su na gornjem layeru dodirni senzori odnosno bakrene površine velićine 16×16 milimetara.  Ostali elementi su smješteni odozdola te  su,  iako standarne veličine, lemljeni su  kao smd elementi  dok bi finalna variajanta svakako trebala biti prava smd.  Žice koje se vide su za napajanje (plava i crvena) i za eksterni ISP programator.

Električna shema je jedostavn i iz nje se vidi da je korišten ATtiny2313  s vlastitim  generatorom takta i rudimentarnim reset krugom. Otpornici na senzorima dodira su 680 kilooma i njihova vrijednost je utvrđeni  eksperimentalno. Oni ovise površini dodirnog senzora te debljine i tipu izolacije (prednje maske) pa će te vjerojatno njih morati utvrditi eksperimentalno u neki drugim izvedbama. Prototipni modul je u  fazi testiranja radio vrlo pouzdano ali nije testiran u težem radnom okruženu (što mu nije bila ni namjena).

[jwplayer mediaid=”1030″]

Datoteku koja sadrži  shemu, tiskanu pločicu, izvorni te izvršni kod možete skinuti ovdje: TouchKeypad_quercus-lab

Princip rada Interbus-S mreže

Interbus-S senzorsko-aktorska mreža je digitalni serijski komunikacijski sustav za prijenos podataka između kontrolnog sustava i raznoraznih senzora i aktora. Interbus-S je koncipiran kao serijski podatkovni prsten koji radi isključivo u realnom vremenu u okviru master/slave metode kontrole prijenosa a strukturiran je kao pozadinski posmični registar.  Svaki  član mreže (slave) sa svojim registrima dio je tog prstenastog posmičnog registra.  Interbus master u mrežnom modulu  čini centralni dio Interbus sustava koji kontrolira  čitav sustav te omogućava da su ulazno-izlazni podaci dostupni slici procesa. Tijekom jednog mrežnog ciklusa serijski se isporučuju izlazni podaci  članovima mreže ali se istovremeno od njih  zaprimaju ulazni podaci. Na kraju ciklusa svi izlazni podaci su distribuirani  a ulazni upisani u ulaznu mapu slike procesa. Koristeći prstenastu strukturu moguće je ostvariti  istovremenu predaju i zaprimanje podataka (full dupleks) a predvidljivo vrijeme pristupa  za  sve članove mreže je zajamčeno.

Interbus-S mrežna toplogija

Topologija ove mreže je prsten koji sve  članove mreže integrira u jedinstven transportnu  putanju. Dodatna karakteristika Interbus-S mreže je prijenos podataka u oba smjera za sve članove. Fizički izgled mreže je radi toga  linijska ili razgranate struktura s pojedinačnim  ograncima.  Spajanje na mrežu ostvaruje se mnogostrukim serijskim spojevima tako da svaki član svojim ulazom zaprima podatke od prethodnog  člana te ga odašilje prema slijedećem. U tom kontekstu linije se označavaju kao  DO (DataOut) linija ako je tok podataka od  nadređenog (mastera) te kao DI (DataIn) ako je tok podataka ka nadređenom.  Analizirajući realnu  strukturu mreže mogu se izvući slijedeće prednosti:

• Adresiranje članova mreže pomoću kodnih prekidača nije potrebno jer je fizičkim položajem svaki član jasno određen u mreži.
• Nisu potrebni skupi pojačivači signala jer se signal u svakom članu mreže regenerira.
• Omogućen je istovremeni prijam i odašiljanje podataka što karakterizira prijenos kao full dupleks.
• Point to point struktura omogućava zamjenu transportnih medija (svjetlovoda  naprimjer) u bilo kome dijelu mreže ako je to potrebno s obzirom na smetnje u tom dijelu.
• Omogućena je implementacija rutina samodijagnostike svakog člana mreže.

Ovako opisana topologija omogućava spajanje najviše 512 mrežnih  članova dok je ukupna količina podataka 4098 bita što je uobičajena ulazno-izlazna mapa većine procesnih računala. U fizičkoj strukturi Interbus-S industrijske mreže razlikujemo dvije vrste mrežnih segmenata. Jedan od tih segmenata nazivamo   Remote bus i on predstavlja vezu između  mrežnih  čvorova koji ne nose informaciju nego omogućavaju daljnje grananje strukture . Na svaki mrežni čvor nastavlja se segment koji se naziva Local bus i koji spaja ulazno-izlazne mrežne članove u prsten. Maksimalna duljina  Remote bus-a odnosno udaljenost između dva  Remote bus mrežna  adaptera (BA–BusAdapter) je 400 metara dok je ukupna duljina mreže limitirana na 13 km.  Udaljenost između dva mrežna člana unutar Local Bus-a je 20 metara.

OSI model Interbus-S protokola

Interbus-S protokol baziran je na OSI referentni model ali zbog gore navedenih specifičnosti  koristi samo 1,2 i 7 sloj .  Ostale funkcije od 3 do 6 sloja implementirane su u 7 (aplikacijskom) sloju. Koristeći fizički sloj  signali se odašilju standardnom brzinom od 500 kbps koristeći NRZ  (non-return to zero) metodu. Podatkovni sloj se brine za integritete podataka i  upravlja  cikličkim prijenosom podatka koristeći   summation frame method.  Ovaj sloj prosljeđuje  podatke aplikacijskom sloju preko dva različita podatkovna kanala:

• Podatkovni kanal procesa (Process Data Channel) je primarni kanal Interbus-S mreže i  koristi se za prijenos procesnih informacija koje se obrađuju skupom senzora i aktuatora.
• Parametarski kanal (Parameter Channel) omogućava cikličku razmjenu parametarskih  podataka između složenijih  članova uključenih u mrežu. Ovaj kanal zahtjeva veći komunikacijski paket i koristi servise bazirane na master-slave strukturi.

Svaki Interbus-S mrežni član sadrži procesni kanal dok je parametarski dodan kao mogućnost  (opcija). Ovakva hibridna struktura protokola koja koristi dvije neovisne kanala podataka omogućava u istoj mreži implementaciju složenih (inteligentnih) mrežnih  članova i  jednostavnih senzora i aktora. Osim toga u svakom sloju se tijekom rada mreže izvršavaju dijagnostičke rutine o kjima se brine rutina koji se naziva Network Menegment  (upravljanje mrežom) .

Summation Frame Protokol

Interbus-S je jedina industrijska mreža koja koristi summation frame method  pomoću kojeg se razmjenjuje podaci između nadređenog i podređenih  članova mreže u  samo jednom komunikacijskom ciklusu i to simultano u oba smjera (full duplex).  Ova metoda omogućuje  predviđeno trajanje komunikacijskog ciklusa što mu daje prednost  u procesima koji se kontroliraju u realnom vremenu. U   summation okviru, koji se sastoji od  zaglavlja (haeder), povratne riječi (loop-back word), podataka i kontrolne sekvence, podaci za sve članove mreže su grupirani u jedan podatkovni blok.

Razmjena podataka koristeći ovaj protokol izvršava se u s slijedećim sekvencama:

1. Svi mrežni članovi se resetiraju te se identifikacijski kodovi  dotičnog člana učitava u posmični registar.
2. Nadređeni član  inicira početak identifikacijskog ciklusa u kome se metodom posmaka transportiraju identifikacijski kodovi svih trenutno prisutnih članova zajedno sa količinom podataka koji pojedinačno obrađuju.
3. Završetkom ID-ciklusa nadređeni ažurira trenutnu topologiju mreže i uspoređuje je sa  zahtijevanom konfiguracijom te ako nema greške spreman je za početak podatkovnog ciklusa.
4. U slučaju greške slijedeći identifikacijskim ciklusom moguće je rekonfigurirati mrežu te ponovo startati podatkovni ciklus.
5. Pokreće se podatkovni ciklus koji se ciklički izvršava sve dok se CRC metodama ne utvrdi greška u prijenosu podataka što uzrokuje ponavljanje opisane sekvence.

Procesni podatkovni kanal

Procesni podaci su oni koji neposredno opisuju kontrolirani proces i predstavljaju u realnom vremenu stanja izvršnih i senzorskih uređaja koji sudjeluju u procesu. Kompleksnost tih podataka gledana sa stanovišta pojedinačnih mrežnih  članova nije velika i kreče se od nekoliko bitova do d nekoliko bytova. Ova karakteristika omogućava umrežavanje u Interbus-S mrežu velikog broja mrežnih članova sa karakterističnom širinom podataka od 8 do 16 bita(1 word). Nakon što je utvrdio konfiguraciju mreže nadređeni može početi sa prijenosom podataka između procesnog računala i ulazno-izlaznih uređaja. Podatkovni ciklus uključujeposmak podatkovnih blokova prema podređenim članovima mreže i to po, u identifikacijskom ciklusu,  utvrđenom redoslijedu i količini podataka. Kada podatkovni blok dospije do mrežnog  člana provjerava se pripada li taj podatak tom  članu. Ako je odgovor potvrdan mrežni  član prihvaća dobavljene podatke u svoj izlazni registar te iz svog ulaznog registra prosljeđuje u posmični  registar. Na ovaj način se nakon punog posmaka posmičnog registra razmjeni cjelovita slika procesa .

Parametarski podatkovni kanal

Parametarski podatkovni kanal koristi se da bi neovisni proizvođači razmjenjivali kompleksne  podatke za svoje uređaje unutar Interbus-S mreže. Za razliku od procesnih podataka koji se  prenose ciklički parametarski podaci se razmjenjuj samo na zahtjev određenog mrežnog  člana. Kompleksnost tih podataka je u mnogome veća od procesnih i uobičajeno iznosi od 10  do 100 baytova. Tipični Interbus-S uređaji koji koriste  parametarski podatkovni kanal su  frekvencijski i tiristorski motorni pretvarači, servo-pozicioneri te operatorski i upravljački  paneli. Implementacija parametarskog podatkovnog kanala u  summation frame  zahtjeva  razdavanje kompleksnih parametarskih poruka na više dijelova. Tako razdvojeni parametri se potom prenose zajedno sa procesnim podacima unutar podatkovnog ciklusa i na taj se način  proširuje podatkovni blok  summation frame.   Komunikacija koja koristi parametarski podatkovni kanal bazira se na klijent/server modelu:

1. Mrežni  član koji želi komunicirati šalje zahtjev (request) i on u komunikacijskom  odnosu predstavlja klijenta.
2. Interbus master prenosi  zahtjev  na ciljani podređeni  član koji reagira odgovorom  (response) i on predstavlja server.
3. Ovaj se  odgovor prenosi do člana koji je inicirao komunikaciju i na taj način mu se  poručuje da može početi sa slanjem parametara.
4. Slijedi  razmjena parametara koristeći Interbus-S nadređeni uređaj kao posrednika u komunikaciji.

Parametarski podatkovni kanal može se koristiti i  za razmjenu podataka između nadređenih  (slave) članova mreže i između nadređenog i podređenog člana (što je češći slučaj).

Konektori i kablovi

Interbus-S standard (IEC 61158) se bazira na RS-485 standardu kao električnoj specifikaciji za prijenos podataka  u Remote bus segmentu mreže.

Raspored priključaka standardnog ožičenja Interbus-S mreže  s DB-9 konektorima:

Raspored priključaka standardnog ožičenja Interbus-S mreže  s IP 65 konektorima:

Raspored spajanja Interbus-S mreže  s terminalskim priključnicama:

Interbus-S ASICs

ASICs (Application  Specific  Integrated  Circuit) je integrirani krug za primjenu u točno  definiranoj aplikaciji za razliku od integriranih krugova opće namjene. Razvojem ASICs  čipova pojednostavljen je i ubrzan razvoj krajnjih uređaja posebno u otvorenim industrijskim  mrežama kao što je Interbus-S. Isto tako pojednostavljeno je razumijevanje i implementacija  mrežnog protokola kod krajnjeg korisnika. Korisnicima Interbu-S mreže dostupna su dva ASICs čipa:

• Slave  SuPI – implementacija podređenog mrežnog člana  Interbus-S mreže s ulazno-izlaznim funkcijama
• Master  IPMS  – sučelje između Interbus-S mreže s jedne strane i mikroprocesorskog   upravljanja s druge

Model proračuna optimalnih količina rezervnih dijelova

Asortiman rezervnih  dijelova zavisi od strukture tehničkog sustava, pogodnosti za održavanje i mogućnosti popravka uređaja. Količine pričuvnih dijelova zavise od pokazatelja pouzdanosti, broja jednakih dijelova u tehničkom sustavu, broja tehničkih sustava na održavanju (za koje se nabavljaju pričuvni dijelovi), zahtjeva za raspoloživost tehničkog sustava te prihvatljivosti troškova zaliha pričuvnih dijelova. Jedan od načina za normiranje pričuvnih dijelova je i matematičko modeliranje koje povezuje vjerojatnost da će pričuvni dio biti u zalihi kad zatreba,  pouzdanost dijela,  ekonomske parametre troškova zaliha i zastoja,  parametre količina i rasporeda tehničkih sredstava, te strukturu i parametre sustava snabdijevanja zalihama. Kako za većinu dijelova vrijedi da je intenzitet kvara  λ  konstantan, zahtjev za  količinom pričuvnih dijelova računamo po Poissonovoj raspodjeli pa vrijedi izraz:

Gdje je   P(r) vjerojatnost da će biti r ili manje zahtjeva za i-ti pričuvni dio, N broj tehničkih sustava na održavanju (za koje se osiguravaju zalihe), n broj i-tih dijelova, koji se proračunavaju kao pričuvni dijelovi u tehničkom sustavu, λ intenzitete otkaza i-tog dijela, t vrijeme rada tehničkog sustava, za koje se proračunavaju zalihe, r količina (broj) pričuvnih dijelova za i-ti dio.

Intenzitet otkaza elemenata

Razdoblje korisnog životnog vijeka je razdoblje aktivnog korištenja elemenata ili uređaja a karakteriziraju ga slučajni otkazi, različitog uzroka ili porijekla, uz koje se povremeno  pojavljuju poneki otkaz usred starosti ili istrošenosti. Zbog toga intenzitete otkaza  λ(t)   lagano raste s vremenom. No za praksu stvarna kosa linija  λ(t)  aproksimira horizontalnom,  čija vrijednost na ordinati je srednja vrijednost u toku razdoblja. Na taj način dobiva se  konstantna vrijednost intenziteta otkaza s kojom je mnogo jednostavnije računati s  zanemarivim greškama. U primjeni se nalazi više modela za proračun intenziteta otkaza elektroničkih elemenata i  sustava. Jedan od najpoznatijih modela za proračun intenziteta otkaza elektroničkih elemenata, koji je izrađen za potrebe američkih oružanih snaga, a rabi ga većina proizvođača  profesionalnih elektroničkih uređaja u svijetu je priručnik za predviđanje pouzdanosti MIL- HDBK – 217 B, C, D, E i F. Slovne oznake označavaju inačicu priručnika, koji se svakih nekoliko godina ažurira temeljem raščlambi podataka o otkazima i novih tehničkih i tehnoloških dostignuća (novi sastavni dijelovi, tehnologije izrade i sl.).  Podaci o intenzitetu otkaza elemenata po vrstama i podvrstama sistematizirani su u odgovarajuće tablice. Modeli za proračun intenziteta otkaza elemenata, prema ovom priručniku, zavise od vrste elemenata, ali imaju opći oblik:

Izraz se sastoji od tri osnovna parametra: temeljnog intenzitete otkaza koji se isčitava iz tablica, čimbenika okoline rada sredstva i pokazatelja kvalitete elementa. Na  to se dodaju čimbenici koji se odnose na grupu, način konstrukcije, način korištenja, primijenjeni napon itd. Recipročna vrijednost intenzitetu otkaza je prosječno srednje vrijeme između dva kvara MTBF  (mean time between failures) a izražava se u satima rada.

SpareParts Calculator

Aplikacija SpareParts Calculator  je mali grafički kalkulator optimalnih količina rezervnih dijelova. Postoji nekoliko načina proračuna potrebnih rezervnih dijelova, a u programu se  koristiti metoda za jednostavni model kada je intenzitete kvara konstantan. Proračun se bazira na matematičkom modelu razvijenom od vodećih eksperata na području održavanja tehnoloških sustava u svijetu.  Za proračun je neophodno da znate, izračunate ili procijenite intenzitet otkaza dijelova ili elementa tehnološkog sustava. Rezultat proračuna su vjerojatnosti da će traženi rezervni dio biti na raspolaganju u trenutku kvara.

Rad s aplikacijom

Prije aktiviranja proračuna potrebno  je pravilno definirati ulazne parametre:

Osnovni ulazni  parametar je intenzitet otkaza elementa  ili srednja vrijednost između dva kvara (MTBF). Oba ova unosa su jednakovrijedna za proračun i izborom jednog od njih drugi se izračunava automatski. Dodatni parametri su broj istovrsnih elemenata u u sustavu (tehničkom sredstvu) te broj sustava za koje se proračunavaju rezervni dijelovi. Proračun se bazira na vremenskom periodu koji se unosi kao broj radnih sati i željenoj (ciljanoj) vjerojatnosti zaliha. Ovaj podatak je se unosu kao  postotak ( 1 je 100 posto).  Način proračuna definira se izborom Optimalno/Definirano  pri čemu optimalno znači da će se na izlaznom grafikonu prikazati vrijednosti vjerojatnosti da će se određeni dio naći u skladištu  i to za količine od 1 komada do količine koja zadovoljava uvjet  željene vjerojatnosti  zadan kao parametar. Ta količina, čija je vjerojatnost prva koja je jednaka ili veća željenoj, se ispisuje  u polju Definirano. Izaberemo li modus Definirano u grafikonu će biti prikazane sve vjerojatnosti od 1 komad  do broja komada upisanog u polje Definirano.

Ova aplikacija se nudi  “onakva kakva je”, bez jamstva i podrške bilo koje vrste. Aplikaciju možete koristiti na vlastitu odgovornost i  autor ne prihvaća nikakvu odgovornost za bilo koju štetu koju ova aplikacija može prouzročiti neposredno ili posredno

Za preuzimanje aplikacije kliknite ovdje: SPCalc_setup

ProConOS soft-PLC

ProConOS (Progammable Controller Operating System) je programsko bazirani PLC sustav koji osigurava PLC specificiran servis na standardnim ili specijalnim hardverskim platformama. To uključuje učitavanje i procesiranje PLC programa kao i mogućnost testiranje i ispravljanja programa (debug) pri pokretanju i održavanju strojeva i postrojenja upravljanih procesnim računalom. Druga definicija za ProConOS je da je on visoko učinkoviti PLC runtime sustav za kompleksne upravljačke aplikacije. Dizajniran je specijalno za IEC61131 normu i sadrži cijeli niz IEC61131 značajki. Dakle da bi ste dobili upotrebljivo procesno računalo trebate prvo izabrati neku stanadardnu sklopovsku opremu  (hardware) podesnu za automatizaciju vašeg procesa ili napraviti svoju baziranu na podržanim procesorima. Na takav hardver instaliarate neki od podržanih realtime operativni sustav. Sada je vaše računalo spremno za instaliranje softPLC-a ProConOS.  Nakon svega toga imate procesno računalo spremno za programiranje vašeg sustava automatizacije na manje ili više uobičajeni način programiranja PLC-a. PorConOS se isporučuje se s IEC61131 programskom razvojnom okolinom KW Multiprog koja omogućuje lagano programiranje u SFC, LD, STL ili IL programskim jezicima.

Jedna od bitnih razlika programiranja podržanih od IEC 61131 norme , u odnosu na standarne PLC-e,  je mogućnost vremenskog upravljanja izvršavanjem pojednih programskih zadataka (taskova). Za razliku od kontinuiranog izvršavanja vašeg programskog koda  IEC 61131 standard  opisuje različite modele raspoređivanja vremena rada programskih taskova:

• Default task , svaki resource sadržava jedan default task koji ima najniži prioritete. Taj task nije vremenski raspoređen.
• Cyclice task koji se izvršava periodično u određenim vremenskim intervalima
• System task poziva operacijski sustav PLC-a ako je došlo do promjena stanja PLC-a ili nekakve greške.
• Event or interrupt tasks  se aktivira na određeni definirani događa ili stanje

Svaki task ima određeni prioritete. U sustavima s takozvanim raspoređivanja sa preuzimanjem (preemptivnim scheduling) , koji je implementiran u softPLC-u ProConOS-u, task koji ima niži prioritete prekida se odmah kada se aktivira task s višim prioritetom za razliku od none-preemptivnim sustavima gdje nije moguć prekid trenutnog taska od strane taska s višim prioritetom.

Radna memorija ProConOS-a podjeljana je  na slijedeće dijelove:

• PLC program – aktualni izvršni korisnički program
• Međuspremnik (buffer) za interne aktualne podatke
• Procesna memorija koja sadrži sliku procesa a razlikuje:
  • I –  ulazne podatke
  • Q – izlazne podatke
  • M – memorijske varijable
  • RM – retentivne memorijske varijable
• memorija za takozvani bootproject
• memorija za kompresirani project (kompletan)

Shodno kompatibilnošću s IEC smjernicama ProConOS podržava sve tipove varijabli definirane u standardu a samo programiranje zahtjeva simbolično adresiranje kako memorijskih tako i ulazno/izlaznih varijabli.

Razvojno okruženje KW Multiprog

Za programiranje PLC-a i PAC-a koji podržavaju standard IEC61131 postoji nekoliko razvojnih  okolina a jedno od njih je i KW Multiprog. Multiprog je 32-bitna PC aplikacija sa intuitivnim sučeljem i sustavom za pomoć napravljenim po uzoru na razvojna okruženje za programiranju u ostalim modernim programskim jezicima opće namjene. Podržava gotovo se smjernice IEC61131 standarda. Podržani su programski jezici LD, IL, ST, FBD i SCF te njihovo slobodno miješanje u zajedničkom projekt radi primjene najefikasnijeg načina programiranja zahtijevanog algoritma. Administracija projekta te reprezentacija pojedinih elementa projekta i njihova terminologija je po IEC smjernicama. Kompajleri za pojedine hardverske platforme su modularni. Podržana je instalacija, puštanje u pogon te testiranje koristeći ugrađene alate kao što su osciloskopski prikaz statusa i simulator. Korisničko sučelje striktno podržava Windows standarde upravljanja objektima kao i dodatne elemente kao što su čarobnjaci i sustav za pomoć baziran na HTML standardu.

Upravljane projektom u Multiprogu je jednostavno i oslanja se na Windows Explorer strukturu u obliku drva baziranu na  IEC61131 softverskom modelu. Pisanja programa moguće je svi 5 programskih jezika definirani EEC61131 standardom a to su:

• • Instruction List (IL)
• • Structured Text (ST)
• • Function Block Diagram (FBD)
• • Ladder Diagram (LD)
• • Sequential Function Chart (SFC)

Kao što je i nabrojano neki od ovih programskih jezika se programiraju u tekstualnom a neki u grafičkom editoru. Tekstualni editor automatski ispisuje ključne riječi programskih jezika u određenim bojama u ovisnosti o sintaksi a podržano je i automatsko kompletiranje imena korištenih varijabli i strukturnih elementa funkcijski blokova. Grafički editor omogućava slobodno manipuliranje funkcijski blokovima, automatsko povezivanje pojedinih elementa te naknadno ubacivanje ili brisanje bez gubitka strukture. Pojedini programski elementi se ispisuje, kao i kod tekstualnog editora, u posebnim bojama   radi što jasnije strukture programa. Na istom radnom prostoru (worksheetu) moguće je miješati sva tri programska jezika: LD, FBD i SFC. Klikom miša na određeno mjesto u grafičkom okruženje moguće je prebaciti se u tekstualni editor i nastavka pisanja programa željenim programskim jezikom. Dodatne dijagnostičke funkcije skraćuju vrijeme puštanja u pogon i testiranja korištenih algoritama u realnom vremenu a to su:

• Logički analizator (Logic Analyzer)
  
• Sustav recepata (Recipes)
• Prekidne točke u programu (Breakpoints)
• Pregled  memorijskih lokacija (Address debug)
• Izvršavanje programa korak po korak (Single step)
• Prepisivanje vrijednosti u programu ( Overwriting and forcing)
• Izmjene programa  u samom PLC-u (Online changes)
• Simulacija programa (PLC simulation)

Osnove standarda

Nekoliko većih kompanija  koje se bave razvojem prenosivog (portabilnog) softverom  za programiranje SoftPLC-a su formirali PLCopen Trade Association. PLCOpen je svjetska vendor i product  neovisna udruga koja  podržava IEC61131-3 normu. Osnovana je 1992 u Nizozemskoj a danas ima svoje urede u Kanadi i Japanu. Organizacija  informira korisnike i programere o standardu preko internetske stranice  www.plcopen.org, besplatnim kvartalnim novostima te organizira konferencije po sajmovima.   PLCOpen definira tri različita compliance classes o prenosivosti kontrolnog sustava softvera.

1. Bazna razina (Base Level ) definira samo jezgru standarda (core kernal) pa, iako je ograničena,  moguće je razvijati aplikacije na temelju nje. Ona ustvari samo pokazuje opredijeljenost proizvođača k standardu.
2. Razina  prenosivost (Portability Level ) sadrži veliki skup značajki, uključujući korisnički definiranih funkcija i funkcija bloka. Ova razina zahtijeva da sustav ima opciju izvoz / uvoz  za jednostavnu razmjenu programskog koda između sustava različitih proizvođača
3. Najviša razina, potpuna usklađenost  (Full Compliance), nudi razmjenu potpune aplikacije, uključujući i konfiguracijskih informacija, između različitih sustava kontrole

Po standardu  svi programi trebaju se rastaviti na funkcionalne elemente, programske organizacione jedinice (POU). Jedna POU sadrži funkcije, funkcijske blokove ili programe. Ako je moguče treba izvršavati  pojedine dijelove aplikacijskog programa razlčitom dinamikom u smislu da  sustav treba podržavati individualne vremenske intervale za različite POU (Time Scheduling)

Programski jezici

Pisanja programa treba biti moguće u svim programskim jezicima koje definiran IEC61131 norma a to su:

•  Instruction List (IL)- lista instrukcija grupiranih u korake programa koja uvelike podsječa na programiranje u asembleru
•  Structured Text (ST) – struktuirani tekst je standardni programski jezik više razine nalik na Pascal
•  Function Block Diagram (FBD) – funkcijski blok dijagram izgledom podsjeća na električne sheme digitalnih sklopova
•  Ladder Diagram (LD) – Ljestvičasti dijagram koji je prvi program za programiranje u sustavima automatizacije a izgledom oponaša električne sheme spajanja
•  Sequential Function Chart (SFC) – sekvencijalni funkcijski dijagram izgledom podsjeća na dijagrame  tijeka a posebno je prihvatljiv za brzo i pregledno programiranje sekvencijalnih procesa

Sekvencijalni funkcijski diagram – SFC

Jedan od zahtjeva standarda je da složena sekvencijalna događanja treba razložiti na događaje (events) s konciznim grafičkim jezikom a to se postiže upravo s SFC-om. U biti SFC nije programski jezik nego prezentacijski okvir sekvencijalne strukture koji objedinjuje programske algoritme napisane u ostalim jezicima.  SFC programski jezik razlikuje dvije osnovna elementa grafikona a to su korak  (step) i prijelaz ili tranzicija (transition). Koraci se predstavljaju četverokutima a povezani su okomitim linijama koje označavaju vremenski tijek. Svaki korak ima jedinstveni naziv a povezuje se (asocira) s jednom ili više akcija. Akcija može biti jednostavna binarna naredba ili , što je češći slučaj, poziv funkcije ili POU. POU može ravnopravno biti pisana u jednom od ostala 4 normirana programska jezika. Prijelaz iz jednog u drugi korak moguć je kad je ispunjen uslov prijelaza koji se  grafički prezentira kao vodoravna linija. To je  binarna varijabla koja se automatski generira a na nju je moguće   djelovati u bilo kojem dijelu programa.

Primjer jednog jednostavnog SFC programa imamo na slici. Program započinje inicijalnim korakom S0 uz koji nij asocirana nikakva akcija.Izvršavanje programa iz koraka u korak uslovljeno je prijelazima Tr1, Tr2, Tr3, Tr4 i Tr5.  Zadovoljavajući  ove uslove aktiviraju se redom korak S0 do S4.  Kada je aktivan korak S1 on izvršava binarnu komandu  SET nad varijablom Var1. Slijedći korak S2 poziva programsku organizacionu jedinicu  POU1 koja se izvršava samo dok je taj korak aktivan. Nakon prelaska na korak S3 resetira se varijabla Var1 i ako je uslov Tr3 ispunjen aktivira  se korak  S4. Ovaj korak poziva program POU2 ali s odgodom od 10 vremenskih jedinica. Konačno, ispunjavanjem uslova Tr5 zatvara se petlja a izvršavanje tijeka programa se vrača na početak.

Kvalifikacije za akciju

Izvršavanje pojednačnog koraka poziva se akcija koje je asocirana uz njega a karakteristika akcije definira se  kvalifikacijama akcije (Action Qualifiers). To su  slovčane oznake koje definiraju način aktiviranja i trajanja  asociranog programskog segmeta ili POU.

• N (Non-Stored)
  Akcija se izvršavao onoliko dugo koliko traje korak (step).
  
• S (Set)
  Akcija se pokreče početkom koraka koji je asociran sa S a prekida se početkom koraka koji je asociran s R.
  
• R (Overiding Reset)
  Akcije koje su pokrenute s S, SD, DS,  i SL prekidaju se početkom koraka asociranom s R.
• L (Time Limited)
  Akcija se pokreče početkom koraka asociranim  s L a trajanje je limitirano parametrom T čija vrijednost  mora biti manji od trajanja samog koraka.
  
• D (Time Delayed)
  Akcija se pokreče nakon isteka definiranog vremena T (odgoda uklapanja) a traje do kraja trajanja koraka.
  
• P (Pulse)
  Akcija traje samo jedan scan ciklus unutar trajanja koraka.
  
• SD (Stored & Time Delayed)
  Akcija se pokreče nakon isteka vremena T od početka koraka s kojim je asocirana a traje do početka koraka asociranog  s R.
  
• SL(Stored & Time Limited)
  Akcija se pokreče početkom koraka, trajanje joj je definirano parametrom T koji može biti veći od trajanja koraka.  Akcija se može prekinuti početkom koraka koji je asociran s R

  

Grananja tijeka

Standardni tijek izvršavanja SFC programa je jednostruka petlja ali ona ne može zadovoljiti sve potrebe procesnih algoritama. Često nam je potrebno da se istovremeno izvršavaju nekoliko programskih akcija ili da se neke od njih uslovno pokreču.  U tim slučajevima koristimo grananje tijeka u SFC dijagramu a postoje dva osnovana tipa grananja:

• Uslovno grananje kod kojega se prijelaz na slijedeći korak ostvaruje kada se ispune uslovi paralelno postavljenih prijelaza. Na slici  je jedan primjer uslovnog grananja kojega ću pokušati pojasniti. Nakon inicijalnog koraka S0 i zadovoljenja uslova Tr1 prelazi se na korak S1. Iz toga koraka je moguće prijeći na korake S2 i S3 i to na način da se ostvare uslovi Tr2 ili Tr3. Ovi uslovu su obično komplementarni odnosno možemo reči da je to programska struktura IF THEN ELSE . Dakle ako je uspunjen uslov Tr2 prelazi se u granu S2-S4 koja se potom izvršava. Ispunjenjem uslova Tr6 ponovno se vračamo na glavni tijek. Ekvivalentna je priča i s granom S2. Postavlja se pitanje što će se dogoditi ako su nakon koraka S1 oba uslova Tr2 i Tr3 zadovoljena. U tom slučaju program se izvršava u obje grane ali je trajanje determinirano uslovima u grani dijagrama koja je NA LIJEVOJ strani.  U našem slučaju nakon koraka S1 izvršavati će  se koraci S2-S4 te S3 istovremeno ali u slučaju da se uslov Tr5  zadovolji  prije uslova Tr6 program se neće prebaciti na glavni tijek. Isto tako kada se ostvare uslovi Tr4 i Tr6 bezuvjetno će se prekinut  izvršavanje koraka   S3 i i izvršavanje će se vratiti na glavni tijek.

• Paralelno grananje kod kojega se bezuslovno ulazi u izvršavanje paralelnih grana dijagrama. U našem primjeru  nako zadovoljenja uslova Tr2 prekida se izvršavanje koraka S1 te se simultano započinje s izvršavanjem koraka S2 i S4 u lijevoj grani te koraka S3 u desnoj grani. Kada obje grane dođu do kraja, u našem slučaju kada se izvršavanju koraci S3 i S4 ispituje se uslov Tr4. Kada se uslov zadovolji prekida se izvršavanje koraka S3 i S4, započinje  izvršavanje koraka S5 i program se vrača u glavni tijek. 
  

Koristeći se ovdje navedenim pravilima i njihovim kombiniranjem možemo napraviti vrlo efikasni sekvencijalni dijagram  našega procesa. Zahvaljujući tome što koristimo grafičke elemente kojim definiramo  strukture našeg programa mi zapravo već u fazi programiranja procesnog algoritma gradimo rudimentarnu dokumentaciju koja nam olakšava testiranje programa u fazi puštanja u pogon . Isto tako dobro definiran dijagram omogućava efikasno razvijanje i nadogradnju našeg programa od strane drugih programera te razvoj programa u timovima.

Pozdrav svima!

Otvaranje ovoga bloga je na tragu prijašnje web stranice istoga imena gdje smo predstavljali naše radove i sfere interesa.

Nadamo se da će i ovaj blog biti koristan i zanimljiv.