Specialistino delo Smer: Organizacija in management delovnih sistemov AVTOMATSKI PRENOS PODATKOV PREKO SCADE V POSLOVNI INFORMACIJSKI SISTEM

Transcription

1 Smer: Organizacija in management delovnih sistemov AVTOMATSKI PRENOS PODATKOV PREKO SCADE V POSLOVNI INFORMACIJSKI SISTEM Mentor: izred. prof. dr. Tone Ljubi Kandidat: Igor Koselj Kranj, november 2006

2 ZAHVALA Zahvaljujem se mentorju prof. dr. Tonetu Ljubiu, ki je sprejel mentorstvo in mi pomagal pri snovanju zakljunega dela. Zahvaljujem se podjetju Lek, ki mi je omogoilo študij in mag. Robertu Ljolju za podporo in mentorstvo s strani podjetja. Zahvaljujem se tudi svoji družini, ki mi je stala ob strani in verjela v uspešno zakljuitev.

3 POVZETEK Delo je osnovano na primeru avtomatskega odkrivanja napak in dogodkov iz strojev v farmacevtski družbi Lek, v kateri se bo izvajal kot pilotni projekt. Delo je razdeljeno na teoretini in praktini del. V splošnem so prikazani podatki, ki jih spremljamo za uinkovitost proizvodne linije. Ti podatki so izraunani iz natannih zastojev in dogodkov. Takšni zastoji nam bodo pomagali pri hitri realizaciji napak na stroju in daljnorono gledano tudi pri preventivnem vzdrževanju. Pomembno vlogo bo odigralo tudi dejstvo, da so ti zastoji spremljani v asu, ko so odvija redna proizvodnja, zato se bomo predvsem trudili, da bi bilo takšnih zastojev immanj. Poglavitni del za merjenje uinkovitosti je realni produkcijski as in nam kot rezultat vrne uinkovitost proizvodnega podroja, kjer bomo zajemamo te avtomatske zastoje. KLJUNE BESEDE MES (oznaka za proizvodni informacijski sistem) ERP (oznaka za nadzorni informacijski sistem) SCADA (oznaka za nadzorni raunalnik procesa proizvodnje) Kljuni kazalci uinkovitosti Neplanirani zastoji Vitka proizvodnja Relacijska baza podatkov

4 ABSTRACT This work is based on the example of automatic detection and capturing of events from machines in company Lek, where it will be performed as pilot project. The graduation paper consists of two parts: theoretical and practical. In general, there is shown how and which data will be monitored for Key Performance Indicators (KPI). They will be calculated by pinpointing downtime and capturing of events. Such downtime will help us in future for quick realization and abolishing errors in machines and furthermore at preventive maintenance. Another important role of this downtimes and events will be also information with which we trace those two processes at the time of real production, therefore we will try to minimise this unscheduled downtimes. The main point for this KPIs will be the time of real production and as a result will be efficiency of production areas in which we will try to capture these data. KEY WORDS MES (Manufacturing Execution Solutions) ERP (Enterprise Resource Planning) SCADA (System Control And Data Acquisition) KPI (Key performance indicators) Unscheduled downtimes Lean manufacturing RDB (Relation Data Base)

5 KAZALO 1 Uvod Predstavitev problema Metode dela in omejitve Just-in-time jit (kanban) Pristopi k vitki proizvodnji Vloga informatike v uvajanju principov Vitke proizvodnje Merjenje uinkovitosti Ukinitev nepotrebnih opravil Uveljavljanje spremenjenih principov dela Avtomatski prenos podatkov s kljunimi kazalci uinkovitosti Informacijski nivoji v podjetju in mes sistemi MES sistemi Programska oprema za avtomatski zajem podatkov Procesni historian Intellution ihistorian Arhiv Arhiviranje Administracija sistema Odjemalske tehnologije znotraj historiana Dodatne lastnosti historiana FIX Intellution Downtime SCADA SCADA pri dogodkih s asovno znako OPC Strežnik Povezava stroja s SCADO Industrijske komunikacijske mreže Industrijska izvedba opreme za Ethernet Industrijska Ethernet stikala Vmesnik za prikljuitev serijskih naprav na Ethernet (Model DE 211) Pretvornik iz UTP na FO (ME 51 - Media Convertor) Klasini pristop zajema podatkov Alternativni pristop Dejstva realnih procesnih podatkov Povezava svetov Orodja za obdelavo podatkov MS Access Internet/Intranet tehnologija Kocka OLAP (Cognos) Implamentacija OLAP tehnologije Organizacija in transformacija podatkov Gradnja in procesiranje OLAP kocke Namestitev orodij za prikaz podatkov Podatkovni Jezik MDX Lastnosti Jezika MDX... 49

6 10 Praktina rešitev Stanje stroja pred nadgradnjo Arhitektura sistema Vmesnik Signali Vloga SCADE v projektu Poroila Analiza tveganja Vrednotenje dela Zakljuek Literatura Priloga Priloga Kazalo slik Kazalo tabel Kazalo grafov... 78

7 1 UVOD Svet se spreminja vedno hitreje in to najbolj utijo podjetja, kjer so edina stalnica spremembe. Na kakršne koli spremembe pa naj bodo to spremembe v okolju ali pa mogoe odstopanja v procesu se je potrebno hitro odzvati. Treba je poskrbeti, da prave informacije pridejo do pravih ljudi v najkrajšem možnem asu. V poplavi podatkov je potrebno znati izlušiti kljune informacije in jih predstaviti na pravilen nain glede na nivo uporabnika (delavec na liniji produktivnost linije, vodja delovne enote širši pogled in bolj agregirani podatki, vodja podroja še širši pogled bolj primerjalen itd.). Hkrati morajo biti informacije dostopne tudi vsem ostalim (ne samo v proizvodnji), ki lahko kakorkoli vplivajo na izboljšanje procesa dela. Na voljo je dovolj tehnologije in znanj, da zgoraj našteto zaživi v praksi. Treba je le nekaj zdrave pameti, da se pri gradnji takega sistema vnaprej predvidi racionalno zajemanje podatkov. Kjer na primer lahko stroji v povezavi z raunalniki sami zajemajo podatke, se to omogoi. Razline sisteme je treba med seboj imbolj integrirati. 1.1 PREDSTAVITEV PROBLEMA V našem podjetju se že dalj asa ugotavlja, kako bi poveali zanesljivost in uinkovitost pakirnih linij. Na podlagi vse vejih naroil naših kupcev mora biti vedno manjše število odstopov strojev na linijah, zato se je naše vodstvo odloilo, da bi k boljši analizi uinkovitosti linij za zaek pripomogel pilotni projekt avtomatskega zajema napak z analitinim prikazom v obliki poroila v poslovnem informacijskem sistemu. Takšen avtomatski prikaz napak seveda pripomore k hitrejši realizaciji odprave napake, saj nam v tem primeru ni potrebno iskati vzroka ali vsote vzrokov zakaj prihaja do neplaniranih zastojev. Hkrati bomo v poroila zajemali tudi število proizvedenih kosov istoasno pa bomo spremljali tudi vzroke za slabo proizvedne koliine v delovni izmeni. 1.2 METODE DELA IN OMEJITVE Pri izdelavi specialistinega dela bo uporabljena opisna metoda, kako bi pilotni projekt avtomatskega odkrivanja napak v našem podjetju realizirali tudi v praksi. Najprej se bomo teoretino spoznali z osnovami programov in njihovo logiko, kako pretvoriti podatke iz stroja v logino obliko, ki bo razumljiva preko poroil. K temu bomo dodali še strojno opremo, ki je skladna z zahtevami našega globalnega lastnika. Pri specialistinem delu bo uporabljeno znanje in izkušnje iz razline literature s podroja avtomatskega zajemanja napak, kjer bodo že upoštevana dejstva naših notranjih zahtev za uspešno relizacijo projekta. Pri izdelavi specialistine naloge bodo v pomo naslednji metodološki prijemi: Predstavitev teoretinih osnov programov, njihove logike delovanja sistema in strojne opreme. Na podlagi teoretinih znanj in želja našega vodstva predlagana realizacija v praksi. Analitina ocena rezultatov. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 1 od 78

8 2 VIZIJA PODJETJA VITKA PROIZVODNJA Avtomatsko zajemanje napak iz strojev je seveda še najbolj pomembno v smislu bodoih projektov. Eden takšnih, ki se trenutno izvaja v podjetju tudi kot pilotni, je uvajanje Vitke proizvodnje. Naela Vitke proizvodnje (ang. Lean manufacturing) niso nekaj novega in revolucionarnega. Izvirajo iz tovarne Toyota, kjer so v sredini petdesetih let prieli z racionalizacijo proizvodnje. Ker pogosto slišimo izraze kanban, kaizen ipd... Osnovna ideja je izvajanje samo tistih aktivnosti, ki poveujejo vrednost izdelka ali storitve. V procesu uvajanja sistematino izloamo ali vsaj zmanjšujemo vse aktivnosti, ki s stališa izdelka ali storitve nimajo dodane vrednosti (skladišenje, prevozi, pripravljalno zakljuni asi...). Merilo uspeha je proizvodnja maksimalnega števila izdelkov zahtevane kakovosti ob minimalnih stroških in im manjših zalogah. Nujnost poveevati svojo konkurennost smo v zadnjih letih spoznali tudi farmacevtski panogi. Po eni strani je na trgu vedno ve konkurennih podjetij, ki povzroajo pritiske na cene, po drugi strani pa tudi veliko priložnosti zaradi novih nastajajoih trgov in poveevanja zneskov namenjenih za zdravila. Ker ni mogoe dovolj hitro poveevati kapacitet z gradnjo, je ena izmed rešitev maksimalno izkoristiti obstojee vire. Vsaka proizvodnja panoga ima svoje znailnosti, zato je bilo potrebno izbrati tista vitka orodja, ki bodo najve prinesla k konnemu cilju. Uvajanje Vitke proizvodnje je kompleksen proces, ki mora zajemati vsa funkcijska podroja poleg proizvodnje še razvoj in raziskave, nabavo, prodajo, nartovanje in kontrolo. Ko govorimo o Vitki proizvodnji, se torej ne omejujemo le neposredno na proizvodnjo. 2.1 JUST-IN-TIME JIT (KANBAN) Koncept je konec 50-ih let razvila Toyota. Njegovo bistvo je v naroanju materiala za as, ko je le-ta potreben v proizvodnji. To pomeni, da se material ali komponente ne naroajo na zalogo, temve tako, da jih dobavitelj dostavi na dan prej, kot jih v procesu potrebujemo. V zaetku je JIT uporabljala predvsem avtomobilska industrija, danes pa je to v svetu zelo razširjen nain dela z dobavitelji. JIT prinaša nekatere prednosti pred naroanjem na zalogo. Manjši inventar zaseda manj skladišnih zmogljivosti in pomeni manj vezanega kapitala. Obenem pomeni manjša zaloga tudi hitrejšo možnost odziva na zahteve kupca po spremenjenih izdelkih. Kakšna je primerna raven zalog, se mora vsako podjetje odloiti samo in pri tem upoštevati posamezne dejavnike, kot so sistem beleženja porabe in naroanja. Slaba stran koncepta JIT je vsekakor poveana verjetnost motenj v procesu, ki lahko pripeljejo do nezmožnosti dobave v asu, ko se v proizvodnji potrebuje material. 2.2 PRISTOPI K VITKI PROIZVODNJI V okviru priprave projekta Vitke proizvodnje je potrebno najprej dobro oceniti kateri pristopi so primerni za tip proizvodnje, ki ga obravnavamo. Prav gotovo ne moremo enostavno prenesti vseh nael iz npr. avtomobilske v farmacevtsko industrijo. Lahko pa nam ostali primeri služijo za zgled. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 2 od 78

9 Skrajšanje potrebnih poti e želimo dosei cilj im krajšega izdelavnega asa moramo, preden se lotimo pregleda vsake delovne operacije, najprej opraviti pogled z vrha. To pomeni, da preverimo ali naš trenutni nart tovarne resnino omogoa optimalni pretok materialov in ljudi. Želimo namre, da so poti im krajše. Vasih lahko ugotovimo, da je mogoe z relativno majhnim vložkom dela in ostalih služb, ki podpirajo proizvodnjo (npr. kontrola kakovosti), razporediti veliko bolj uinkovito. Zmanjšanje prestavitvenih asov in neplaniranih zastojev Kadar imamo opravka s saržno proizvodnjo je pomemben element tudi as, ki ga porabimo za prenastavitev delovnega stroja za drug izdelek. To velja še toliko bolj, e imamo opravka s proizvodnjo, ki proizvaja veliko število (>100) razlinih izdelkov. Zato je dramatino zmanjšanje asov prestavitev (za faktor in ne za odstotek) nujno potrebno. Ob tem uporabljamo razline pristope kot npr. priprava im vejega dela procesa predhodno (izven linije), analiza dela operaterja ipd. Ker nam dodano vrednost prinaša samo tisti as uporabe linije, ko proizvajamo, moramo maksimalno zmanjšati tudi neplanirane zastoje. Neplanirani zastoji praviloma tudi pomembno vplivajo na ostale procese v proizvodni verigi in povzroajo podaljševanje proizvodnih asov. Metodologija, ki se ukvarja neposredno z zmanjševanjem zastojev se imenuje Celovito produktivno vzdrževanje (Total productive maintenance - TPM). V tem primeru nam pride avtomatsko zaznavanje napak še posebej v prav, saj dobimo vzrok za zastoj skladno z ustavitvijo stroja in tako hitreje ukrepamo glede na zastoj. Sinhronizacija ob-proizvodnih aktivnosti Proizvodnja mora imeti za svoje delovanje vedno na voljo zadostne koliine surovin in ostalih delovnih sredstev. To pomeni, da je potrebno ostale službe (npr. kontrola kakovosti) organizirati v takšnem pomenu, da ne pomenijo ozkega grla proizvodnim aktivnostim. Planiranje proizvodnje Proizvodni proces je najlažje sinhronizirati, e imamo dovolj v naprej jasno sliko zahtev za proizvodnjo. Planiranje tako postaja kljuni element uspešnosti uvajanja vitkih nael. Samo tako bomo namre lahko dosegli, da bodo vsi procesi lahko vitki. Ni namre mogoe uvajati Just in time principa, e se nam proizvodni plan spreminja v zadnjem trenutku. Proces spreminjanja nael planiranja je še toliko bolj zahteven, ker direktno posega tudi v prodajne službe in jih sili v spreminjanje njihovih nainov dela. Produktni portfelj Produktni portfelj je zaradi vpliva, ki ga ima na razdrobljenost proizvodnje, eden vplivnejših dejavnikov na delovanje proizvodnje. Sprememb na kratek rok sicer ni možno dosegati, potrebno pa je proces prieti imprej. V primeru globalnih podjetij je možno bolj optimalno planirati produktni portfelj, ker lahko uvedemo t.i centre odlinosti (centers of excellence), ki so odgovorni za proizvodnjo samo doloenega (omejenega) nabora izdelkov. S tem se mono poenostavi proizvodnja, kot tudi ostali procesi, ki podpirajo proizvodnjo. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 3 od 78

10 2.3 VLOGA INFORMATIKE V UVAJANJU PRINCIPOV VITKE PROIZVODNJE Informatika pri projektu uvajanja nael Vitke proizvodnje seveda ni kljuna aktivnost. Naela so uvajali veliko prej, preden je informatika dosegla proizvodne procese. Se pa z upoštevanjem zmožnosti, ki jih informatika ponuja pri poenostavljanju procesov razširi nabor možnosti. 2.4 MERJENJE UINKOVITOSTI Pred prietkom uvedbe katerihkoli ukrepov (ne samo nael Vitke proizvodnje) se moramo vprašati, kako bomo vedeli, ali gredo ukrepi v pravo smer. Zato moramo definirati nabor kazalcev, ki bodo nekakšen lakmusov papir pri spremljanju uvedenih ukrepov. Ko prinemo s spremljanjem kazalcev, odigra informatika kljuno vlogo. Ne želimo namre porabiti preve asa samo z zbiranjem potrebnih podatkov za izraun naših kazalcev. Prav tako je pomembna tudi hitrost, ko nam je informacija na voljo. Samo tako lahko namre spremljamo uinke ukrepov in jih po potrebni pravoasno spremenimo. Informacijski sistem, ki je pogoj, da lahko spremljamo uinkovitosti, mora temeljiti na tem, da ne zahteva dodatnega dela operaterjev oz. da operaterji zahtevane podatke vnesejo v okviru rednih delovnih operacij. Npr. zaetek proizvodne linije oz. zastoj sistem avtomatsko zazna in operaterju ni potrebno vnašati podatkov rono v sistem. S tem pridobimo tako na asu, kot tudi na kvaliteti zbranih podatkov. 2.5 UKINITEV NEPOTREBNIH OPRAVIL Proces, ki ga prinaša Vitka proizvodnja je tudi stalno razmišljanje o nainu dela in o možnostih ukinitve (e je le mogoe) oz. imveje racionalizacije procesa. Ob tem se je potrebno zavedati vseh možnosti, ki jih prinaša informacijska tehnologija. Še posebno v regulirani industriji, kot je farmacevtska je ob tem potrebno upoštevati tudi zahteve, ki jih proizvajalcem postavlja zakonodaja. Tako lahko npr. popolnoma ukinemo delovno mesto kontrolorja procesa, e dokažemo da raunalniški sistem opravlja nadzor vsaj enako varno, kot prej kontrolor. Prav tako lahko z uvedbo novih tehnologij (kot npr. radijsko frekvenna identifikacija RFID) dosežemo avtomatski nadzor nad doloenimi tokami procesa. 2.6 UVELJAVLJANJE SPREMENJENIH PRINCIPOV DELA Ko se odloimo, da bomo nekatere operacije opravljali drugae, moramo dosei, da bodo vsi zaposleni enako razumeli nova navodila. Pri tem nam je v pomo sistem, ki operaterju posreduje nova navodila in ga sili v spremenjen nain dela. Prav tako mu je v podporo pri izvajanju opravil. S tem dosežemo, da navodil ni potrebno ve distribuirati po klasini poti preko papirja in skrbeti za ažurne verzije, temve smo lahko gotovi, da je sprememba v veljavi tako, ko jo spremenimo v sistemu. S tem, ko podatke o delu zbiramo v elektronski obliki pridobimo tudi obsežno bazo podatkov. Podatke uporabimo pri izvedbi analiz, ki nam služijo za nartovanje novih ukrepov. Tako lahko npr. statistino obdelamo podatke o izmetu in ugotovimo povezave med izmetom in dobaviteljem surovine, strojem, ki je bil uporabljen, delavcem, ki je opravljal operacije ipd.. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 4 od 78

11 Kot reeno Vitka proizvodnja ni cilj, temve pot. Ko se podjetje enkrat odloi zavestno stopiti na pot stalnih izboljšav procesov, mora poskrbeti tudi zato, da izkoristi celoten potencial zaposlenih. Samo tako bodo lahko maksimalno prispevali k uspehu podjetja. Tako je potrebno zajeti znanje na razline naine. Med bolj uveljavljene štejemo organiziranje timov za stalne izboljšave, zbiranje koristnih predlogov in princip rotacije zaposlenih na delovnih mestih. Ob tem pa se mora podjetje zavedati tudi, da uvajanje nael Vitke proizvodnje neizbežno pomeni tudi ukinjanje nepotrebnih delovnih mest oz. odpravo nekaterih funkcij in privilegijev posameznih delovnih mest. S tem lahko povzroi povratni uinek, ko zaposleni ne želijo sodelovati pri izboljšavah, ker se bojijo za svoja delovna mesta oz. pridobljeni položaj v podjetju. Podjetje mora torej znati upoštevati vse potrebe, tako podjetja z doseganjem veje uinkovitosti, kot tudi posameznikov za lastno samouresniitev. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 5 od 78

12 3 AVTOMATSKI PRENOS PODATKOV S KLJUNIMI KAZALCI UINKOVITOSTI V proizvodnji je pomembno, da se kvalitetno naredijo izdelki, ki jih v plan postavi planski oddelek. Roki izdelave artikla so pogosto asovno zelo omejeni, zato se je potrebno nagibati k im manjšim odstopom na liniji. S tem se zagotavlja maksimalen izkoristek linije in asovno usklajenost glede na plan. Za nas je kljunega pomena kako spremljamo proizvodnjo linijo. Spremljamo jo lahko preko kazalcev, s katerimi si pomagamo ugotavljati, e se zadeva odvija v pravo smer. Na podlagi tega definiramo nabor kazalcev in si pomagamo razviti nekakšen pregled, s katerim lahko doloamo preventivne ali korektivne ukrepe. Od nas pa je seveda odvisno kateri kazalci so za nas bistvenega pomena. Kazalci navadno izražajo nekakšno primerjavo med dvema stanjema ali pa nam preprosto posredujejo samostojno informacijo o npr. porazdelitvah asov delavcev. V povezavi s kazalci nas v tem primeru zanima masksimalna uinkovitost linije v asu, ko se odvija redna proizvodnja. To pomeni, da želimo spremljati le tisti as, ko stroj na liniji obratuje in proizvaja izdelek, ki je v aktualnem trenutku v planu. Da bi se kar najbolje približali kazalcu uinkovitosti linije je potrebno najprej razistiti kako trenutno merimo uinkovitost kazalcev. Do sedaj smo v našem podjetju spremljali kazalce z ronim vnosom podatkov. To pomeni, da operater na liniji vnaša podatke o ažurnem statusu linije, v katerega zajema tudi podatke o proizvedenih koliinah. Iz prakse lahko predvidevamo, da so takšni podatki o statusih linij pogostokrat, kljub naporom operaterjev niso toni ali pa so celo napani. Takšen pristop, ki ga naredi loveška napaka, pa je tudi z ekonomskega vidika estokrat vprašljiva, saj je takšne napake potrebno tudi popraviti v informacijskem sistemu. Informacijski sistem, ki v tem primeru spremlja uinkovitosti, mora biti dovolj zmogljiv in hiter, da lahko v želenem trenutku dobimo informacijo in nanjo tudi vplivamo. V izogib ronemu vnosu smo zaeli»pobirati«podatke iz strojev, tam kjer je stroj to omogoa. Tipini podatki, ki jih lahko zajemamo in so v okviru projekta za nas kljuni so: podatki o trenutnem statusu linije podatki o proizvedenih koliinah podatki o koliini izmeta Pri avtomatskem zbiranju lahko še naprej loimo med popolnoma avtomatiziranim zbiranjem podatkov, kjer se podatki neposredno zbirajo iz proizvodnih naprav ter sprotno (deloma avtomatizirano) zbiranje podatkov o proizvodnih dogodkih. Pri prvem nainu je vasih vprašljiva ekonomska upravienost (vrednost izvedbe povezave z opremo, tehnološke omejitve - vasih je težko povezati tehnološko heterogeno opremo). Vedno tudi ni možno zajeti vseh potrebnih podatkov (npr. malica delavcev, vzrok zastoja, e ni neposredno povezan s strojem ipd..). Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 6 od 78

13 Drugi nain še vedno zahteva udeleženost delavcev, ki vnašajo proizvodne dogodke (npr. zaetek/konec dela ipd...). Take rone vnose pa je možno avtomatizirati npr. z uporabo rtne kode (branje rtne kode posameznega dogodka) oz. s proženjem enega dogodka z neko drugo akcijo (npr. konec išenja avtomatsko pomeni prietek proizvodnje ipd..). Ugotavljamo, da je najboljša kombinacija obeh avtomatiziranih nainov, saj s tem zberemo najbolj popoln spekter potrebnih podatkov. Proizvodni informacijski sistem mora biti sposoben nuditi enotno podlago za zajem podatkov in omogoati vnos tako avtomatsko zajetih, kot tudi rono vnešenih podatkov. Prav tako mora sistem podatke kombinirati s poslovnimi podatki kot so šifra izdelka na liniji in nalog na liniji, normativi, plan proizvodnje ipd. Zaradi velikih koliin specifinih podatkov o zastojih, kar otežuje sumaren pregled uinkovitosti linije in primerjavo med razlinimi proizvodnimi linijami, se definirajo, raunajo in s pomojo intraneta prikazujejo proizvodni kazalci uinkovitosti (KPI-ji), ki celostno prikazujejo dogajanje v proizvodnji in omogoajo primerjave med razlinimi proizvodnimi linijami. Zaradi potreb po prikazu proizvodnih kazalcev vezanih na podatke sistema zastojev in proizvodnega informacijskega sistema, se je sistem zastojev integriral v proizvodni informacijski sistem, s imer je dosežena celovitejša informacijska pokritost proizvodnega procesa. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 7 od 78

14 4 INFORMACIJSKI NIVOJI V PODJETJU IN MES SISTEMI V našem podjetju loimo tri nivoje informacijskih sistemov: a) nivo ERP (Enterprise Resource Planning) Je najvišji nivo informacijskega sistema v podjetju. Znailni predstavniki teh informacijskih sitemov pokrivajo predvsem finance, nabavo, distribucijo, proizvodnjo ipd. b) nivo MES (Manufactoring Execution Solutions) MES predstavlja vmesni nivo med višjim ERP nivojem in najnižjim nivojem nadzora tehnologije. V tem nivoju so združene funkcije, ki jih realiziramo v višjem nivoju informacijekga sistema. Gre predvsem za planiranje, izvajanje proizvodnje, izdelavo postopkov in standardnih navodil za delo. 4.1 MES SISTEMI c) nivo SCADA (System Control And Data Acquisition) V preteklosti je veljalo, da e želi podjetje uspešno informatizirati vse svoje poslovne procese, lahko izbere en sam kompleksen informacijski sistem (ERP), ki bo pokril vse potrebe podjetja. Proizvajalci programske opreme so želeli prilagoditi predvsem svoje poslovne informacijske sisteme (MRP, ERP) tudi za uporabo v proizvodnih procesih. Vendar se proizvodnih procesov ni mogoe lotevati na enak nain kot npr. finanno-raunovodskih, kjer so podatki bolj strukturirani in operacije definirane, vasih tudi zakonsko doloene. ERP sistemi sicer do doloene mere podpirajo tudi proizvodne procese, vendar pri prilagajanju podrobnostim pogosto odpovedo (obratno sorazmerno s kompleksnostjo proizvodnega procesa). Prilagajanje proizvodnim procesom je namre problematino in tudi dolgotrajno. Zato so se ERP sistemi osredotoali na pokrivanje proizvodnje predvsem s stališa materialnega knjigovodstva, knjiženja porabe materialov ipd... Torej predvsem z "zgornjega" konca vodenja proizvodnje. V kolikor pa želi podjetje dejansko pridobiti z informatizacijo proizvodnje je potrebno informacijski sistem približati tistim, ki ga uporabljajo in ki jim pomaga pri vsakdanjem delu. Zato pa je potrebno uvesti "namenski" IS, ki obvladuje specifike proizvodnega procesa in se mu je sposoben prilagajati. To pomeni npr. direktno oditavanje podatkov s tehtnice in takojšen prenos podatkov tudi v ERP sistem in izvedbo materialih knjižb. Šele po uspešni uvedbi informacijskega sistema in pokritju proizvodnih procesov lahko raunamo, da nam bo sistem pripomogel tudi k vodenju proizvodnje. Takrat lahko govorimo o tem, da smo uvedli t.i. "povratno zanko" v proizvodnem procesu, kjer s takojšnjimi podatki prikazanimi v ustrezni obliki lahko vplivamo na proizvodni proces. Kot glaven razlog uvedbe MES sistema v našem podjetju bi lahko torej navedli predvsem možnost integracije direktno v proizvodni proces in možnost nudenja pomoi (in ne samo zbiranja podatkov) na veini proizvodnih delovnih mest. MES sistem naj bo torej sposoben pokriti: Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 8 od 78

15 operativno nartovanje proizvodnje (vzdrževanje kosovnic, tehnoloških listov, razporejanje proizvodnje) vodenje proizvodnje (spremljanje izvedbe posameznih operacij, kontrola materialnih premikov, prepreevanje napak, avtomatska povezava s proizvodno opremo); poroanje o poteku proizvodnje Bistvena prednost uvedbe proizvodnih IS je predvsem zbiranje podatkov med procesom in uravnavanje samih procesov. Izogibati se želimo naknadnim vnosom podatkov. Za trenutno spremljanje stanja na doloeni proizvodni liniji zadostuje le vpogled v pregled, ki prikaže status posamezne proizvodne linije in trenuten nalog, ki se na liniji izdeluje. Na tak nain lahko tako vodja posamezne delovne enote, kot tudi ostale službe (planiranje, vzdrževanje) lahko pridobijo neposreden vpogled v stanje. S pomojo barvnih oznak lahko opazovalec tudi takoj opazi morebitno težavo (zastoj, okvaro). Prav tako se neposredno iz sistema za planiranje prikazuje trenutni plan proizvodnje (tudi za poljubno število dni v naprej). Plan se drsno prilagaja stanju v proizvodnji. e se npr. nek nalog še ni priel, je to tudi barvno oznaeno. Prav tako se lahko že na osnovnem prikazu seznanimo z osnovnimi podatki o zahtevanih naroilih (izdelkih, koliinah ipd..) Bistvena prednost uvedbe MES sistemov je takoj in ob koncu vsake proizvodne izmene prikazovanje in izraunavanje izdelane koliine. Na osnovi normativov in dejanskega asa proizvodnje tudi plastino prikaže, koliko kosov bi bilo teoretino možno izdelati, v kolikor bi proizvodnja potekala brez težav. Prikaz je tudi takojšnja povratna informacija samih proizvodnim delavcem, ki lahko sami ugotovijo svojo uspešnost po posameznih izmenah in se tudi primerjajo med seboj. Na osnovi izdelanih koliin tudi prikazujemo produktivnost posamezne linije (ali združen rezultat za ve linij), kjer prav tako prikažemo dosegljivo in dejansko doseženo produktivnost. Prav tako lahko prikazujemo trend na posamezni liniji. S tem plastino prikažemo morebitne težave. Pri analizi težav namre lahko vodja linije takoj preveri dejanske proizvodne dogodke na neki liniji in ukrepa za odpravo vzrokov slabe produktivnosti. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 9 od 78

16 5 PROGRAMSKA OPREMA ZA AVTOMATSKI ZAJEM PODATKOV Pri izgradnji proizvodnih informacijskih sistemov se sreujemo z razlinimi naini implementacije in z razlinimi orodji, ki jih pri tem uporabljamo. Tudi kljuni cilji in z njimi povezane funkcije proizvodnega informacijskega sistema se lahko od primera do primera razlikujejo. Vendar lahko trdimo, da je zajem realnih procesnih podatkov eno kljunih vprašanj, s katerim se pri gradnji proizvodnih informacijskih sistemov sreujemo skoraj vedno. Zajem podatkov - realnih meritev iz proizvodnega procesa predstavlja osnovo za vzpostavitev proizvodnega informacijskega sistema. Znano je, da proizvodni informacijski sistem v poljubnem segmentu težko uporabnikom nudi zadovoljive informacije, e ne temelji na realnih podatkih iz procesa. Spremljanje uinkovitosti proizvodnega procesa je na primer zelo težko izvajati, e ni urejen zajem realnih podatkov, e podatki niso ustrezno obdelani oziroma mesebojno odvisni z drugimi informacijami iz proizvodnje in v primeru, da dostop do obdelanih podatkov ni dovolj poenostavljen. Pasti na poti do uspešnega zajema procesnih podatkov je veliko: podatkov je obiajno zelo veliko, so neobdelani in v surovi obliki neprimerni za proizvodni informacijski sistem, z vsako spremembo v proizvodnem procesu se pojavljajo novi podatki itd. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 10 od 78

17 5.1 PROCESNI HISTORIAN INTELLUTION IHISTORIAN V nadaljevanju predstavljamo pristop za zajemanje in analizo podatkov za proizvodno informatiko, ki temelji na uvedbi specifinega procesnega podatkovnega skladiša procesnega historiana. Ta pristop primerjamo s trenutno najpogosteje uporabljanimi koncepti. Predstavljam konkretno rešitev za procesni historian ihistorian. Ameriški proizvajalec SCADA programske opreme Intellution je pred kratkim predstavil procesni historian ihistorian, ki na podroje zajemanja, arhiviranja in analize procesnih podatkov prinaša nekaj bistvenih lastnosti, ki so bile v preteklosti na voljo samo v posebnih (zelo velikih in dragih) sistemih. ihistorian predstavlja sistem za arhiviranje in analizo procesnih podatkov, ki ga sestavljajo štiri osnovne komponente: Arhiv procesnih podatkov, zbiralci, ki zajemajo procesne podatke, odjemalci in tehnologije, s pomojo katerih je mogoa analiza arhiviranih podatkov, oziroma poizvedovanje po njih neposredno iz informacijskih sistemov. Arhitektura ihistoriana je zelo skalabilna, kar pomeni, da lahko vse štiri komponente teejo na enem raunalniku, lahko pa so razmešene po mreži. Arhitekturo sistema prikazuje slika Arhiv Slika 1: Arhitektura ihistoriana Jedro ihistorian-a predstavlja njegova podatkovna baza, ki je optimirana za zelo hitro in uinkovito zajemanje podatkov ter poizvedovanje po njih. Lahko reemo, da gre za posebno hitro in enostavno relacijsko bazo, v kateri doloa odnos med podatki as. Posebna lastnost te baze, skladno z lastnostmi pravih relacijskih baz, so mehanizmi poizvedovanja po podatkih. Interna podatkovna struktura omogoa ne samo dostop do zahtevanih podatkov, ampak tudi interno obdelavo podatkov. V poizvedovanje je tako mogoe vkljuiti zahtevek po obdelavi, pri tem pa baza vrne Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 11 od 78

18 konen rezultat obdelave. V primerjavi s pravimi relacijskimi bazami so te obdelave bolj preproste in optimirane prav za procesne podatke. Pomembno je omeniti tudi dejstvo, da je možno dostopati do podatkovne baze ihistoriana neposredno prek funkcij ali prek vmesnika, kar odjemalcem daje vtis, da imajo opravka s tabelo prave relacijske baze. Za gradnjo celovitih proizvodnih informacijskih sistemov ima ta lastnost veliko težo Arhiviranje Zbiranje podatkov poteka prek zbiralcev (Collectors). Osnovna znailnost zbiralcev je, da so naloženi na raunalniku, kjer je obenem tudi vir podatkov. Zbiralec zbira podatke in jih posreduje v Arhiv. ihistorian omogoa neposreden dostop do zbiralca in sprotno (online) konfiguriranje. V primeru prekinitve povezave med zbiralcem in arhivom strežnikom (na primer, e se prekine LAN povezava ali e pade strežnik), zbiralec lokalno shranjuje podatke in jih ob ponovni vzpostavitvi povezave posreduje strežniku. Ta lastnost je za potrebe proizvodne informatike zelo pomembna, saj je zagotovljeno, da ne prihaja do izgube podatkov. Vsak zbiralec v vsakem trenutku omogoa vpogled v statistine podatke o svojem delovanju (koliina podatkov, ki se zajema itd.) Odvisno od tipa zbiralca in vrste podatkov sta na voljo dva tipa zbiranja podatkov. Prvi je "polling" nain, ki omogoa ciklini zajem podatkov s hitrostjo 100 ms. Drugi nain je dogodkovni nain zajema podatkov. ihistorian lahko zbira podatke iz razlinih podatkovnih virov. Na voljo je pet tipov zbiralcev: zbiralec OPC, ifix/fix, CSV/XML, simulacijski in kalkulacijski zbiralec. Zbiralec OPC zajema podatke iz poljubnega OPC strežnika. Zbiralec ifix/fix zajema podatke neposredno iz Intellution-ovih SCADA sistemov ifix oziroma FIX-a. Zbiralec CSV/XML zbira podatke, ki se nahajajo v tekstovnih datotekah ali datotekah tipa XML. Simulacijski zbiralec je na voljo za testne namene. Kalkulacijski zbiralec ni namenjen zajemu, ampak obdelavi podatkov znotraj ihistoriana. Kot tak je še posebej zanimiv za potrebe proizvodne informatike, saj nad arhiviranimi podatki opravlja kompleksne analize in obdelave in rezultate teh obdelav shranjuje nazaj v ihistorian kot neodvisen podatkovni vir. Kalkulacijski zbiralec se proži asovno ali dogodkovno. eprav proizvodni informacijski sistem lahko do ustreznih podatkov iz ihistoriana pride preko obdelave, ki se sproži ob poizvedbi, se izkaže, da je za delovanje sistema v celoti veliko bolj uinkovito, e se nekatere obdelave izvajajo že vnaprej kar na samem ihistorianu Administracija sistema Administriranje in konfiguriranje sistema poteka s pomojo administratorskega vmesnika. Na voljo je mrežni administratorski vmesnik, ki omogoa administriranje ihistoriana prek Intraneta/Interneta s pomojo spletnega brskalnika. Druga možnost je klasini administratorski vmesnik, ki omogoa administriranje ihistoriana na raunalniku, kjer se nahaja strežnik ihistorian. S pomojo administratorskega vmesnika lahko spremljamo kljune parametre in delovanje ihistoriana, zaženemo ali vstavimo zbiralce (Collectors), pregledujemo sporoila in alarme, ki jih je generiral strežnik ihistorian, upravljamo z arhivom (metoda imenovana BackUp in Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 12 od 78

19 Restore arhiva, odpiranje novih arhivov, konfiguracija arhiva,...), konfiguriramo bloke, ki jih zajemamo iz procesa ali izvajamo sprotne spremembe na strežniku Odjemalske tehnologije znotraj historiana Ena najpomembnejših lastnosti ihistoriana so razline tehnologije, prek katerih je možen dostop do arhiviranih podatkov in njihova analiza. Na voljo je ve vrst orodij za pregled in analizo arhiviranih podatkov: SCADA sistem ifix, Excel Add-In; makroji, ki se izvajajo in omogoajo pregled ter analizo podatkov znotraj Excela, InfoAgent, orodje za prikaz in analizo podatkov neposredno iz spletnih brskalnikov, podatkovni vmesnik, prek katerega je iz relacijskih podatkovnih baz (ki so osnova za informacijske sisteme) možen neposreden dostop do arhiviranih podatkov, namenske aplikacije, ki jih je mogoe zasnovati z orodji kot so Visual Basic ali C++. ifix kot odjemalec je zelo zmogljivo grafino orodje za prikaz arhiviranih podatkov, namenjen predvsem prikazu trendov v okviru SCADA aplikacij. Arhivirane podatke je mogoe prikazovati v posebnih grafinih objektih, ali pa jih obdelovati znotraj programerskih aplikacij. Takšen primer programa je Visual Basic. Excel Add-In omogoa preprosto izdelavo zelo obsežnih in uporabnih poroil z orodjem Excel. Ob nalaganju ihistoriana se v Excel doda meni "ihistorian", ki omogoa dostop do surovih, filtriranih, izraunanih ali indeksiranih arhiviranih procesnih podatkov. Podatki se nato lahko dokonno obdelajo v okolju Excel, ki omogoa razne preraune podatkov, prikaz podatkov s skoraj neomejenim številom razlinih grafov ali uporabo vgrajenih funkcij. InfoAgent je mrežni odjemalec za analizo in razporejanje procesnih podatkov, zbranih v ihistorianu in arhiviranih v njem. Uporabljamo ga s pomojo spletnega brskalnika prek Intraneta/Interneta. Uporabnik lahko tako prek spletnega brskalnika pregleduje gibanja (trende) in spremlja meritve glede na številko obdobja, stroškovno mesto, proizvod ali kaj drugega. Pomembno je poudariti, da pri vseh omenjenih tehnologijah ne gre samo za dostop do surovih podatkov, ampak tudi za možnost proženja internih mehanizmov za analizo, ki so že vgrajeni v ihistorian. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 13 od 78

20 5.1.5 Dodatne lastnosti Historiana ihistorian ima še nekaj pomembnih lastnosti: Namenjen je za uporabo v majhnih in velikih aplikacijah, saj je na voljo v velikostih od 100 tok pa do tok na strežnik. Je zelo uinkovit, saj zmore shranjevati in brati do podatkov v sekundi. Podpira sekundni nivo zbiranja podatkov. Vsi podatki, ki jih shranjuje ihistorian, so opremljeni s asovno znako loljivosti 1 ms. Periodini zajem podatkov lahko poteka s periodo 100 ms, podprto pa je tudi dogodkovno gnano zbiranje podatkov, ki lahko dosega tudi bistveno višje hitrosti zbiranja podatkov. Arhitektura ihistoriana je zelo prilagodljiva. Vsi našteti sestavni deli se lahko izvajajo na enem samem raunalniku, lahko pa so poljubno razpršeni po mreži. ihistorian podpira arhiviranje podatkov, ki so navzven opremljeni s asovno znako (loljivost 1 ms). ihistorian shranjuje podatke v izredno komprimirani obliki. Za ta postopek so na voljo razlini algoritmi komprimiranja. ihistorian lahko shranjuje podatke razlinih tipov, tudi znakovne nize oziroma tekstovne zapise. Celoten sistem je možno preprosto konfigurirati in vzdrževati. Administriranje sistema lahko poteka prek Intraneta/Interneta. asovne znake iz razlinih zbiralcev so sinhronizirane z uro na strežniku. Sistem podpira letno - zimski as. ihistorian je zelo robusten sistem, saj zbiralci omogoajo shranjevanje in naknadno posredovanje zbranih podatkov v primeru prekinjene zveze med zbiralcem in strežnikom ihistoriana. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 14 od 78

21 5.2 FIX Programski paket FIX ameriškega podjetja Intellution služi za izvedbo nadzornih sistemov. Njegova prednost je predvsem v možnosti prilagoditve za delo s katerim koli krmilnikom. Sestavljen je iz veih programskih orodij, ki se zaganjajo kot posamezne aplikacije in delujejo takrat, ko je zagnan osnovni program FIX-a. Vhodno izhodni vmesnik se konfigurira s programskim orodjem imenovanim SCU (System Configuration Utility). Osnovni namen te aplikacije je izbira in nastavitev vmesnika. Nastaviti je mogoe še komunikacijske, mrežne in varnostne parametre ter doloiti osnovne funkcije delovanja programskega paketa FIX. Naslednja pomembna aplikacija je program za urejanje baze (DataBase manager). Baza so skupine blokov v katerih so zapisani naslovi in vse lastnosti v nadzornem sistemu uporabljenih spremenljivk. Tipi blokov so doloeni glede na vrsto spremenljivke (analogni vhod, digitalni izhod, alarmni blok, raunski blok ). Za izdelavo slik programa nadzornega sistema služi aplikacija za oblikovanje prikazov (Draw). Pripravljena je tudi bogata knjižnica grafinih simbolov in objektov za lažjo in hitrejšo izdelavo nadzornih sistemov. Funkcije programa omogoajo ustrezno prilagajanje grafinih objektov na sliki (doloitev barve, velikosti, oblike). Prikazi ali drugi aktivni elementi na slikah so povezani s tokami v bazi, ki doloajo njihovo trenutno obliko ali prikaz. S programom za oblikovanje prikazov izdelani nadzorni program se zažene z aplikacijo za prikazovnje (View). Vse prikazane vrednosti spremenljivk je mogoe shraniti na trdi disk s programom za arhiviranje HTC (Historical Collect), ki ga je potrebno predhodno konfigurirati s programom za nastavitve parametrov arhiviranja HTA (Historical Assign). Zvezni potek zapisanih vrednosti spremenljivk se prikaže s programom za predstavitev zgodovine HTD (Historical Display). Intellution ima programski paket Fix zašiten s kljuem (Slika 2). Namešen mora biti na konektorju paralelnega vodila, saj je nartovan kot vmesni konektor med raunalnikom in nanj priklopljeno napravo. Ob inštalaciji program FIX samodejno zazna klju. e nadzorni raunalnik nima namešenega kljua, nadzorni sistem po dveh urah preneha delovati. Slika 2: Zašita programskega paketa FIX Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 15 od 78

22 5.3 INTELLUTION DOWNTIME Programsko orodje idowntime pomaga slediti dogodkom in identificirati problem na proizvodnem podroju preko osnovnih pripravljalnih analiz in poroil, ki so zasnovana tako v internih ali eksternih orodjih. Omogoa celo pripravo poroil preko spleta. Kot rezultat lahko identificiramo in posledino izloamo vzroke za napake v asu proizvodnje in s tem omogoamo izboljšati proizvodni proces. Koristi idowntime-a idowntime omogoa naslednje: natanno doloa vzroke neplaniranih zastojev identificira podprocese izdela poroilo kjerkoli in kadarkoli povea uporabo celotne strojne opreme a) Natanno doloa vzroke neplaniranih zastojev Z uporabo idowntime-a dobimo pregled nad celotim proizvodnim procesom nazorno pokaže kje je tisti del, ki povzoa zastoje, skozi kateri vzorec se zastoj pojavlja in nam omogoa, da predhodno odstranimo napako, preden nam zopet ogrozi proces. b) Identificira dele stroja, kjer se pojavlja napaka idowntime nam ponuja veliko ve, kot samo spremljanje dogodkov, pa pa tudi omogoa prikaz na katerem delu stroja se je napaka pojavila. S takšnim naborom podatov lahko ob racionalnem ukrepanju poveamo proizvodnji donos. c) Izdela poroilo kjerkoli in kadarkoli V današnjih visoko integriranih okoljih, kjer podatke in informacije preprosto dobimo iz produkcijskih procesov, omogoa veliko prednost za podjetja. idowntime v sebi nosi nekakšen prevajalnik, ki surove podatke že na zaslonu prikaže kot uporabne informacije, zato ni udno, e se kakšna odloitev sprejme že iz nadzorne sobe, kjer se nadzoruje proces. d) Povea uporabo celotne strojne opreme Vsi se zavedamo, da v primeru, ko stroj ne dela z optimalno uinkovitostjo temu primerno ne dosegamo proizvodnjega plana. e strnemo vse stroje pod idowntime drobnogled, lažje dosegamo vejo uinkovitost, saj imamo vse stroje pod drobnogledom. idowntime sestavljajo naslednje komponente: idowntime odjemalec Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 16 od 78

23 Odjemalec nam omogoa konfiguracijo, pregledovanje, posodabljanje in poroilni del aplikacije. idowntime strežnik idowntime strežnik odigra vlogo jedra aplikacije. Sem sodiita zaznavanje in arhiviranje dogodkov. Ecxel Add-in Opisan že pri odjemalcih ihistoriana. SQL strežnik 2000 Poznamo ve razliic: 1) Personal edition (Osebna verzija) Osebna verzija lahko dela na Windows 98, Windows NT strežnik 4.0 s servisnim popravkom 5 ali kasnejšim, Windows NT 4.0 s servisnim popravkom 5 ali kasnejšim. 2) Standard edition (Standardna verzija) Standardna verzija dela na Windows NT strežniku 4.0 s servisnim popravkom 5, Windows NT strežnik 4.0, Podjetniški verziji in na Windows 2000 strežnik /Prednostni strežnik/podatkovni center. 3) Others (Ostale verzije) Podjetniška verzija na Windows NT strežnik 4.0 s servisnim popravkom 5, Windows NT strežnik 4.0 Podjetniški verziji in na na Windows 2000 Strežnik/Prednostni strežnik/podatkovni center. Obstajajo pa še ostale verzije kot so Razvojna verzija, Namizna Engine, SQL strežnik CE. Tipi namestitev Typical (tipina), Minimum (minimalna), ter Custom (navadna). Ker se SQL 2000 strežnik skoraj vedno uporablja v povezavi z relacijsko bazo podatkov, lahko opišemo skupno uporabo naslednjih lastnosti: obvladovanje velike koliine podatkov obvladovanje velikega števila hkratnih uporabnikov zaradi zmanjšanega prometa v omrežju (prenašajo se samo tisti podatki, ki jih uporabnik potrebuje) se z veanjem števila uporabnikov hitrost bistveno ne zmanjšuje Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 17 od 78

24 dostop in manipulacija s podatki s pomojo ukazov jezika SQL (poljubne poizvedbe) povezljivost z drugimi Microsoft orodji (Excel, Word, Access) velika varnost; nadzor dostopa, vgrajeno arhiviranje in vraanje podatkov, transakcije, orodja za zagotavljanje integritete podatkov (sam podatkovni strežnik skrbi za vzdrževanje relacij med posameznimi tabelami, za pravilen vnos podatkov, za spoštovanje pravil povezav posameznih tabel, za vraanje podatkov do zadnjega veljavnega stanja v primeru okvare,...) zaradi manjšega prometa v omrežju možnost dostopa preko poasnejših povezav (klicne povezave, Internet) fleksalabilnost: od delovanja na samostojnem raunalniku do delovanja na veprocesorskih sistemih, možnost povezovanja ve podatkovnih strežnikov v federacije... pripravljen na Internet: vse rezultate poizvedb lahko MS SQL Strežnik vrne v obliki XML dokumentov, ki jih lahko enostavno (npr. s pomojo XSLT) oblikujete za prikaz na spletnih straneh Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 18 od 78

25 6 SCADA Raunalniški nadzorni sistem je del raunalniškega sistema za vodenje procesov, ki omogoa operaterju vpogled in poseganje v delovanje procesa v realnem asu. Skozi leta se je nadzorni sistem razvil iz enostavnega terminala, ki je omogoal le enostaven tabelarien pogled podatkov in sprejem omejenega nabora ukazov v sisteme, ki podpirajo široko paleto funkcij, t.j. zbiranje podatkov, spremljanje, prikaz in delovanje procesa, alarmiranje, arhiviranje podatkov in generiranje poroil. Pomembni gradniki današnjih nadzornih sistemov so grafino podani prikazi podprti z elementi animacije. Programska orodja, ki podpirajo razvoj in izvedbo aplikacij na nadzornih raunalniških sistemih se imenujejo tudi orodja SCADA (Supervisiory Control And Data Acquisition). Programska orodja tipa SCADA so se najprej pojavila na centraliziranih sistemih vodenja, na velikih raunalnikih. Uporabljali so jih v elektrarnah, dispeerskih centrih in drugih vejih sistemih. S padanjem cen raunalnikov in rastjo njihove zmogljivosti je prišlo tudi do širše uporabe orodij SCADA. Pravi razmah so dosegli z uvedbo porazdeljenih sistemov vodenja, osebnih raunalnikov ter dostopnih cen delovnih postaj in miniraunalnikov. Z razvojem lokalnih omrežij in uporabo sodobnih orodij tipa SCADA lahko onemogoimo vpogled v delovanje procesa in zbirko procesnih podatkov tudi strokovnjaku na oddaljenem delovnem mestu. Programska orodja SCADA omogoajo razvoj nadzornih sistemov z naslednjimi funkcijami: zbiranje procesnih podatkov spremljanje, prikaz in nadzor delovanja procesa alamiranje arhiviranje/shranjevanje procesnih podatkov generiranje poroil Poleg sprotnega zbiranja procesnih podatkov so sistemi SCADA tudi v funkciji podpore operaterju in omogoajo vpogled in poseganje v delovanje procesa. Interakcija z operaterjem mora biti enostavna in razumljiva. Pomemben problem uporabniških vmesnikov so prikazi, ki so podani bodisi v grafini ali tekstovni obliki, stanje procesa s pomojo animacije posameznih komponent. Sodobni SCADA sistemi vsebujejo gradnike, ki podpirajo vizualno programiranje, razvoj grafinih vmesnikov in animiranih elementov. Pomembna funkcija nadzornih sistemov je tudi obvešanje operaterja (t.j. alamiranje) v primeru odstopanj merljivih veliin iz obmoja dovoljenih vrednot. Orodja SCADA podpirajo definiranje seznama alarmov in pogoje za nastop le-teh. Glede na vrsto ali kritinost pojava alarma je mogoe alarme grupirati v posamezne skupine (npr. alarmi, opozorila, obvestila, itd.). V primeru pojava posameznih alarmov se prenese obvestilo operaterju z opisom vrste alarma. Sistemi SCADA poleg že omenjenih funkcij omogoajo tudi generiranje razlinih izpisov in poroil na osnovi tekoih procesnih podatkov. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 19 od 78

26 Lastnosti orodij SCADA lahko opišemo z dveh vidikov: Z vidika razvijalca aplikacij, katerega zahteve so povezane z lastnostnimi uinkovitega in uporabniku prijaznega razvojnega okolja. Z vidika uporabnika, t.j. operaterja, katerega zahteve se nanašajo predvsem na funkcionalnost in interakcijo z aplikacijo nadzornega sistema. Po sodobnih SCADA orodjih lahko govorimo o upoštevanju naslednjih lastnosti: uporaba objektno-orientirane paradigme modularna zgradba integriran sistem varnosti in zašite povezljivost in odprtost standardnost Paradigma objektno-orientiranih pristopov Osnovni gradniki aplikacije razvite z orodjem SCADA so objektni. Vsak objekt je razpoznaven z množico atributov in množico metod, ki operirajo nad objektovimi atributi. K definiciji objekta sodijo tudi atributi in metode, s katerimi definiramo nain animacije doloenega objekta. Objekti, ki imajo podobne lastnosti se združujejo v razrede. Razred torej predstavlja osnovni vzorec množice podobnih si objektov, kjer se podobnost izraža v enaki množici atributov in metod. Vsak objekt tako predstavlja pojavitev doloenega razreda. e orodje podpira vizualno programiranje, je vsak razred razpoznaven tudi preko pripadajoe grafine podobe. Modularna zgradba Programska orodja vrste SCADA so zasnovana modularno. Posamezne programske module lahko konfiguriramo v skladu z zahtevami aplikacije nadzornega sistema. Optimalna modularna zgradba je taka, pri kateri so okoli jedra, ki je obiajno baza podatkov, nanizani med seboj neodvisni programski modulu. Da je to zagotovljeno, posamezni programski moduli komunicirajo posredno preko jedra orodja SCADA. Integriran sistem zašite Orodja SCADA zagotavljajo razvoj aplikacij z vgrajenim sistemom zašite, ki zagotavlja kontrolo dostopa do posameznih funkcij le pooblašenim osebam. Ta lastnost omogoa definiranje razredov uporabnikov s pripadajoimi pristojnostmi. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 20 od 78

27 6.1 SCADA PRI DOGODKIH S ASOVNO ZNAKO Namen prenosa asovnih znak je v tem, da na nadzornem SCADA sistemu dobimo natanno informacijo o tem, kdaj se je dogodek zgodil, tudi v primeru, e je informacija prispela na nadzorni sistem z zamudo. Krmilniški podsistem hrani podatek opremljen s asom tako dolgo dokler ni prenesen v SCADA center. Nain prenosa podatkov je enostaven. Rešitev je primerna tudi v primeru, ko pride do izpada komunikacijske povezave, tako da vzpostavitev redundanne komunikacijske povezave ni potrebna. Pri taki rešitvi mora imeti SCADA sistem golnilnik, katerega posebnost je v tem, da zna prenašati podatkovne strukture, katerih dolžina in vsebina ni vnaprej doloena in da zna na ustrezen nain upravljati s asovnimi znakami. Modul SCADA sistema, ki podatke obdeluje, pa mora podatek in njegovo asovno znako na ustrezen nain interpretirati in ju vkljuiti v alarmne in dogodkovne liste ter histograme. Pri tem igra pomembno vlogo OPC standard, ki doloa nain, kako izmenjavati podatke med podsistemi na podroju procesnega vodenja. OPC standard v današnji izvedbi doloa t.i. vmesnik, ki definira dostop do podatkov oz. rešuje problem gonilnikov (gonilniki so OPC strežniki, SCADA sistemi so OPC odjemalci). Data Access (dostopni podatki) vmesniki v okviru OPC standarda predvideva prenos podatka, opremljenega s asovno znako od strežnika k odjemalcu. Veina sodobnih SCADA sistemov sodi med OPC odjemalce, vendar se izkaže, da to še ne pomeni, da zbirajo podatek, opremljen s asom, ki ga zajamejo kot OPC odjemalcu tudi pravilno interpretirati. SCADA sistem mora biti zasnovan tako, da v primeru, ko OPC odjemalec zazna, da se poleg podatka iz OPC strežnika prenaša tudi as, interni sistem podatkov ignorira sistemski as PC raunalnika. Konkretno: V alarmnih seznamih se pojavijo alarmi, opremljeni s asom iz krmilnika, njihova nadaljnja obdelava pa je povsem enaka kot da bi dogodek s asom opremil kar SCADA sistem sam. e SCADA sistem, ki ga uporabljamo, podpira obdelavo na nain, ki upošteva iz golnilnika prenesene asovne znake, je problem rešen uspešno. e SCADA sistem ne podpira asovnih znak, obstaja rešitev, da podatke in asovne znake loeno prenesemo v SCADA sistem, jih ne obdelamo, ampak takoj prenesemo naprej v neko podatkovno tabelo, kjer jih združimo. Kronologija dogodkov je zapisana v eksterni podatkovni tabeli in ni sinhronizirana z internim alarmnim in dogodkovnim sistemom SCADA centru. Z ozirom na dejstvo, da veliko splošnonamenskih SCADA sistemov obdelave podatkov z upoštevanjem asovnih znak ne podpira, je prav ta rešitev pri praktinih telemetrijskih sistemih zelo pogosta. Njena velika prednost je predvsem v tem, da je možno podatek in njegovo asovno znako zaradi njunega loginega združevanja zunaj SCADA sistema, prenesti v SCADA sistem loeno s pomojo obiajnega Master - Slave (Gospodar Suženj) protokola. To pomeni, da pri praktini izvedbi sistema lahko uporabimo standarden gonilnik. Slabost te rešitev je v tem, da interni alarmni in dogodkovni sistem znotraj SCADA sistema ne kaže pravih asov; le-ti so zapisani v zunanji podatkovni tabeli. Poleg OPC strežnika imamo na SCADI še naložen IFIX, ki mora biti biti vseskozi startan, saj prepisuje podatke na ihistorian strežnik. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 21 od 78

28 SCADA programska oprema: operacijski sistem (OS) proficy ifix 3.5 Proficy Historian odjemalec, ihfix zbiralec OPC strežnik Na SCADI je naložen IFIX, ki služi za nadaljnjo povezavo v procesni historian. Procesni historian zajema procesne podatke v realnem asu iz nadzornega sistema. Vsi realni procesni podatki se tako shranjujejo v procesni historian t.j. centralni arhiv procesnih podatkov. Na osnovi teh podatkov se tako posledino generirajo dogodki (zastoji na liniji, proizvedena koliina), ki se zapisujejo v relacijsko bazo. Ti dogodki se tako pred-pripravijo za prenos v proizvodni informacijski sistem. Omenjen IFIX ima verzijo 3.5, saj le ta lahko komunicira s procesnim historianom. SCADA v tem primeru opravlja funkcijo prikaza trenutnega stanja meritev in stanj v grafini obliki. SCADA je priklopljena na poslovni in industrijski Ethernet. Kot lahko vidimo iz arhitekture sistema je na SCADI naložen tudi OPC strežnik, preko katerega dobimo signale iz linije v ihistorian. 6.2 OPC Za kratico OPC se skriva ime OLE for Process Control (OLE Object Linking and Embedding) in predstavlja mednarodni industrijski standard, ki je bil razvit v sodelovanju Microsoft-a in številnih vodilnih proizvajalcev strojne in programske opreme na podroju avtomatizacije. OPC temelji na Microsoftovi OLE/COM/DCOM tehnologiji in predstavlja skupen komunikacijski vmesnik med razlinimi napravami pri kontroli in nadzoru tehnoloških procesov. Omeniti je potrebno, da je OPC zašitena znamka prostovoljne mednarodne organizacije - OPC Foundation, ki združuje ve kot 250 vodilnih podjetij, ki se ukvarjajo s podrojem kontrole in nadzora procesov, vizualizacije, e naštejemo nekaj najvejih: Honeywell, Fischer Rosemount, Siemens, Wonderware, Intellution, tudi Microsoft Razlogov zakaj je bil OPC razvit je ve. Eden glavnih je zagotovo ta, da vsak krmilnik za povezavo v SCADA sistem potrebuje svoj gonilnik (driver), povezavo z raunalnikom in programski paket za kontrolo oziroma nadzor. Problem pa se pojavi pri povezavi veih krmilnikov razlinih proizvajalcev z vsak svojimi gonilniki in s svojim programskim paketom. Tu se zano dogajati nenavadne stvari, npr. pojavijo se spori med gonilniki razlinih proizvajalcev, komunikacija med napravami je poasnejša, funkcionalnost vseh naprav ni sto odstotno izkorišena, dva programska paketa ne moreta istoasno dostopati do ene naprave, saj uporabljata vsaka svoj gonilnik, za dva krmilnika driver za isto SCADO ne obstaja, Odgovor proizvajalcev programske opreme je ta, da zaradi vedno veje konkurence razvijajo dodatne in vedno nove gonilnike. Glavni cilj OPC ja je torej prepreiti, da bi bila programska oprema za nadzor oziroma kontrolo, odvisna od strojne opreme proizvajalca. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 22 od 78

29 OPC strežnik nam je našemu podjetju zagotovil proizvajalec pakirne linije. Ta je potreben za zajemanje podatkov na OPC platformo. Veinoma so OPC strežniki univerzalni in delujejo brez problemov. Kar se tie konfiguracije OPC strežnika imamo na voljo dve možnosti. Prva je rona metoda, vendar je ta metoda dolgotrajna, zamudna ter se lako zgodi, da na koncu ne prinese uspešnih rezultatov. Potrebno je poiskati napravo (Device), katero želimo nadzorovati, brati ali pa vnašati vanjo podatke. Nato je potrebno konfigurirati kanal (Channel), po katerem bo potekala komunikacija in na koncu še želeno spremenljivko (Item). Konfiguracijo se nato shrani in poženemo OPC strežnik. Strežnik med svojim delovanjem oddaja informacije, kot so kvaliteta podatkov (data quality), Za konno delovanje naše aplikacije je»obvezno«, da je kvaliteta podatkov dobra (good) ter z im manj napakami (errors). Druga metoda je veliko prijaznejša uporabniku, vendar pa je ne podpirajo vsi OPC strežniki. Dodano imajo namre funkcijo, ki omogoa hitro in enostavno konfiguracijo saj nam strežnik sam poiše možne naprave, ki so prikljuene na raunalnik, sam doloi kanal ter prikaže vse spremenljivke, ki jih lahko nadzorujemo. Nato z miško izbiramo spremenljivke, shranimo in poženemo OPC strežnik. Veinoma tu ni problemov pri kvaliteti podatkov, še manj pa s asom, ki smo ga porabili za konfiguracijo. Nekateri OPC strežniki dopušajo tudi, da se lahko med samim delovanjem dodajajo spremenljivke in se s tem ne zmoti procesa. Nato je potrebno imeti OPC odjemalec, ki ga zagotovi proizvajalec programske opreme nadzornega oziroma SCADA sistema. Tu je potrebno konfigurirati OPC odjemalec tako, da bo dostopal do podatkov na OPC platformo, kamor jih posreduje OPC strežnik, ter jih nato tudi tja vraal. Potrebno je doloiti napravo s katero se želimo povezati, doloiti kanal in spremenljivko. Nekateri omogoajo tudi že definiranje povezav in spremenljivk. Razlini programski paketi imajo razline OPC odjemalce, kjer postopek konfiguracije enega ni popolnoma enak drugemu. Glavno je, da pravilno in smiselno povežemo skupaj OPC strežnik ter OPC odjemalec. Tudi tu je narejenih mnogo programov, ki so uporabnikom prijaznejši in ki zelo poenostavijo konfiguracijo in povezavo med strežnikom in odjemalcem. Takšen je na primer OPC Browser program, ki nam omogoi lažjo povezavo strežnika in odjemalca. Nato konfiguracijo shranimo in povezava je konana. Ostane nam le še definiranje toke v programu SCADA. Posebno mesto ima tudi KEPServerEX-ov OPC hitri odjemalec, ki se uporablja za testiranje OPC strežnikov. Dandanes nas na trgu kar zasipavajo z razlinimi programskimi paketi s katerimi lahko uinkovito nadzorujemo našo aplikacijo, to so t.i. SCADA sistemi. Dva najuspešnejša proizvajalca programskih paketov sta Intellution s programskima paketoma FIX in ifix ter Wonderware s programskim paketom InTouch. Obstajajo pa tudi drugi proizvajalci SCADA sistemov kot je Siemens, Ne glede katerega od njih izberemo moramo v naši aplikaciji nato še doloiti povezave oziroma tage. Tudi tu se lahko tega lotimo rono, vendar nudijo nekateri OPC odjemalci dodatno funkcijo, ki nam iz povezave z OPC strežnikom oziroma iz konfiguracije avtomatsko doloijo tip spremenljivke in hkrati omogoijo, da ustvarimo tag. Tako ga v SCADA sistemu nato samo izberemo in stvar naeloma deluje ter prihrani mnogo asa. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 23 od 78

30 Prednosti, ki jih prinaša OPC strežnik: enostaven za uporabo fleksibilen in kompatibilen glede na proizvajalce nudi visok nivo funkcionalnosti omogoa uinkovito delovanje Poudariti je potrebno, da se je razvoj gonilnikov prenesel na proizvajalce strojne opreme in tako ni ve problem proizvajalcev programske opreme Proizvajalec strojne opreme poleg svoje opreme razvije le en tip programske opreme ter lahko pri strankah to uporabi v njenih aplikacijah Razvijalcem programske opreme ni potrebno razvijati novih gonilnikov takoj, ko se na trgu pojavijo nove verzije strojne opreme Najve pridobijo kupci, torej mi, saj imamo na voljo ve razlinih proizvajalcev strojne in programske opreme, ki je med sabo kompatibilna ter si tako oblikujejemo svoj sistem oziroma avtomatizirajo svojo tovarno na najvišjem nivoju integracije. Aplikacija X OPC Client 1... Aplikacija Y OPC Client 2 OPC OPC Server A OPC Server B OPC Server C Slika 3: Prikaz prednosti OPC strežnika 6.3 Strežnik V našem pilotnem projektu bomo za realizacijo uporabili strežnik HP DL 380. Eden glavnih razlogov za uvedbo, poleg tega, da je HP trenutno v našem podjetju standard je ta, da je HP razširil ponudbo vkljuno z zmogljivejšimi dvojedrnimi procesorji. HP je najavil nove strežnike na platformi x86, ki delujejo na najnovejših dvojedrnih procesorjih podjetja Intel - Intel Xeon DP. Novi procesorji so dostopni na dvoprocesorskih strežnikih. Ponujajo izredno zmogljivost in odlino razmerje med ceno in zmogljivostjo ter porabo elektrike in zmogljivostjo. HP nartuje razširitev serije strežnikov ProLiant z dodatnimi dvojedrnimi procesorji Intel Xeon, ko bodo le-ti Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 24 od 78

31 širše dostopni. HP je vodilni svetovni ponudnik strežnikov x86 in strežnikov, ki temeljijo na dvojedrnih procesorjih. V povezavi z virtualizacijskimi tehnologijami strežniki HP ProLiant podjetjem omogoajo konsolidacijo kritinih aplikacij ter zmanjšanje kompleksnosti v podatkovnih centrih. Strežniki z dvojedrnimi procesorji omogoajo preprosto, a obutno poveanje zmogljivosti kljunih aplikacij, kot so podatkovni strežniki, poslovne aplikacije, rešitve za upravljanje odnosov s strankami, virtualna in terminalska okolja ter sistemi za sporoanje. V preizkusu zmogljivosti je dvoprocesorski strežnik HP ProLiant DL380 za 40 odstotkov zmogljivejši od enakega modela z enojedrnimi procesorji. HP ProLiant DL380 je najbolje prodajan strežnik na svetu, namenjen razlinim nalogam in vlogam. Novi dvojedrni procesorji bodo najprej na voljo na modelih U320 SCSI, kasneje pa tudi na modelih z drugo tehnologijo. Strežnik v našem primeru uporablja naslednjo programsko opremo: Windows 2000 strežnik aplikacija Proficy Historian SQL 2000 Standardna verzija Proficy Plant Applications (Program za definiranje signalov) vmesnik Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 25 od 78

32 7 POVEZAVA STROJA S SCADO Operacijski sistemi za vodenje industrijskih procesov v realnem asu (Real Time OS) so pred leti bili: RT, RSX, irmx, QNX, VMS Le slednja dva lahko še sreamo tu in tam, ostali so šli ve ali manj v pozabo, njihovo mesto pa so zasedli MS Windows-i. Podroje vodenja industrijskih procesov je že od nekdaj slovelo po strogih zahtevah glede hitre odzivnosti sistema in po veliki zanesljivosti delovanja. Ko gre za vodenje procesov, kot recimo vodenje jedrskega reaktorja, se bo ta strogost vsakomur zdela razumljiva. Vsekakor tudi od poslovnih sistemov priakujemo zanesljivost delovanja, vendar posledice morebitne napake v obeh procesih nikakor niso primerljive. OS-i za delo v realnem asu so morali izpolnjevati nekaj osnovnih pogojev, navedimo le najpomembnejše: hkratno izvajanje ve procesov pomembni dogodki iz procesa lahko prekinejo izvajanje in po vsaki prekinitvi, se mora procesor glede na prioritete ponovno odloati, kateri proces bo dobil prednost pri izvajanju programer lahko programom dodeljuje prioriteto izvajanja uporabniški programi ne morejo prekiniti delovanje operacijskega sistema Zaradi teh zahtev smo dobili izredno stabilne operacijske sisteme, primerne za industrijsko uporabo. Imeli pa so tudi to udovito lastnost, da je bilo vsem procesom možno izraunati as izvajana, kar je pogoj za obdelavo v realnem asu. Pojasnimo tudi pojem realni as : realni as za vodenje rakete je manjši kot tisoina sekunde, realni as za tipkanje je desetina sekunde, realni as za regulacijo temperature v sobi je nekaj minut, itd. Poenostavljeno povedano pomeni delo v realnem asu, da se mora sistem odzivati dovolj hitro glede na hitrost procesa. Razvoj vse hitrejših raunalnikov je omogoal obvladovanje tudi hitrejših procesov. Inženirji so zaeli uporabljati veliko bolj dostopne raunalnike tipa PC, na katerih so obiajno tekli Windows-i in so bili prvenstveno namenjeni nezahtevnim procesom. Ker pa je postal osebni raunalnik popularen tudi kot razvojna delovna postaja, se je vse pogosteje zael uporabljati tudi kot delovni raunalnik, tudi v procesnem vodenju. Veliko nestabilnost celotnega sistema so reševali preprosto tako, da so konnemu uporabniku omogoili delo izkljuno v okviru aplikativnega programa in mu hkrati prepreili dostop do sistemskih ukazov. Izkušnje so pokazale, da so nadzorni sistemi z omejeno uporabo OS-a dosegali še sprejemljivo stabilnost na raun zaprtosti sistema. To stanje se je popravilo šele z izidom bolj zanesljivega sistema Windows NT. Uvod zakljuimo z ugotovitvijo, da so se manjši operacijski sistemi realnega asa ohranili le še v tako imenovanih "vgrajenih sistemih" (Embeded Systems), kjer optimizirano jedro operacijskega sistema, oplemeniteno z aplikativnimi programi, obiajno naložimo v EEPROM-e industrijskih naprav, kjer se izvajajo strogo doloena procesna opravila. Za sedaj Microsoft ni prisoten na omenjenem segmentu. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 26 od 78

33 7.1 INDUSTRIJSKE KOMUNIKACIJSKE MREŽE Zelo pomembno je dejstvo, da vsi naši stroji sami po sebi na podroju Pakiranja ne omogoajo povezave preko industrijskega Etherneta, zato sem za takšne potrebe, ko se bo projekt razširil tudi na ostale linije pripravil naslednje rešitve. Kot rezulat bi omogoali enak prenos kot stroj, ki ima že vgrajeno možnost komunikacije preko industrijskega Etherneta s tem, da so v ostalih primerih strojev potrebne tudi dodelave za takšno komunikacijo. Precej dolg uvod nosilnega poglavja skuša prikazati, da tehnina popolnost ni vedno vodilo pri strateškemu odloanju. Mnogokrat zmagajo drugi na prvi pogled manj pomembni ali celo nakljuni dejavniki. Obogateni s tem spoznanjem skušajmo "pogledati v kavo" še za bodonost na podroju industrijskih komunikacij. Vsekakor je Ethernet postal standard na podroju povezovanja razlinih nadzornih centrov, SCADA sistemov, delovnih postaj, strežnikov in razlinih informacijskih vozliš znotraj podjetja. Tokrat se bomo posvetili nižjim komunikacijskim nivojem, kjer so v mrežo povezane razline inteligentne enote za vodenje procesov, kot so: krmilniki, regulatorji, upravljalni terminali, regulatorji vrtljajev, procesni števci itd. Pojavlja se vprašanje ali se Ethernet uveljavi tudi na tem komunikacijskem nivoju? Tu sreamo anarhino množico razlinih industrijskih mrež. Te morajo zadovoljevati podobnim kriterijem, ki smo jih sreali že pri operacijskih sistemih realnega asa: hiter odziv, možnost napovedi odzivnega asa, veliko zanesljivost delovanja Razlini svetovni proizvajalci tovrstne opreme ponujajo vsak svojo»najboljšo«rešitev, te pa so skoraj po pravilu neskladne med seboj. Trenutno najbolj popularne industrijske mreže so: PROFIBUS, INTERBUS-S, FIELBUS, CANBUS, DEVICENET, MODBUS in druge. Zahteva po standardizaciji krii v nebo. Poizkus poenotenja predstavlja INTERBUS-S, ki pa za zdaj še ni prevzel primata, ampak predstavlja le novo mrežo v nizu svojih predhodnic. V našem okolju verjetno prevladuje Siemensov PROFIBUS, ki tudi nima dovolj moi, da bi izrinil konkurente. Prodiranje Ethernet-a na nivo krmilnikov, se ponuja kot odrešitev trenutnega stanja na podroju industrijskih mrež. Lahko ugibamo, da bodo procesni nartovalci glede Etherneta ponovno v podobni skušnjavi, kot so bili pri uvajanju Windows-ov. Kasneje, ko se standard uveljavi, lahko pride tudi do korekcij, ki odpravijo pomanjkljivosti, tako kot se je zgodilo z NT-ji. Kljub vsemu nudi Ethernet nekaj monih razlogov za hitro uveljavitev: razširjenost - Ethernet prikljuek ima že vsak raunalnik in v zadnjem asu tudi edalje ve industrijskih naprav, krmilnikov, operaterskih terminalov, zapisovalcev procesnih veliin itd. nizka cena - Ethernet kartico dobimo že za SIT, kartica za industrijsko mrežo stane SIT dostopnost znanja in strokovnjakov - Ethernet mrežo zna zgraditi povpreen raunalniški strokovnjak v relativno kratkem asu, medtem, ko za postavitev industrijske mreže tudi bolj izkušen strokovnjak porabi bistveno ve asa dodaten strošek predstavlja nakup programa za prilagoditev industrijske mreže, ki ga Ethernet ne potrebuje Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 27 od 78

34 Navedeni argumenti so dovolj, da nas prepriajo, da bo Ethernet v bodonosti tudi v industrijskemu okolju igral zelo pomembno vlogo. Verjetno se bodo industrijske mreže ohranile v manjšem obsegu na zelo specializiranih podrojih, ki jih Ethernet v tej obliki ne rešuje optimalno. 7.2 INDUSTRIJSKA IZVEDBA OPREME ZA ETHERNET V prvem obdobju prodiranja Etherneta v industrijsko okolje so si procesni informatiki pomagali s proizvodi, ki so bili dostopni na trgu, eprav so bili namenjeni "pisarniški" rabi. Na primer: e smo skušali povezati ve krmilnikov na Ethernet, smo uporabili obiajno mrežno stikalo (Ethernet Switch). eprav to stikalo originalno ni bilo namenjeno industrijskemu okolju, smo ga najpogosteje kar uporabili, eprav izvedba v niemer ni zadovoljevala industrijskih standardov. Veji proizvajalci procesne opreme so se odzvali prvi in naredili industrijsko izvedbo. Hudomušno lahko pripomnimo, da za industrijsko izvedbo ni dovolj, da tiskano vezje vgradimo v grdo oblikovano ploevinasto škatlo, temve so bolj pomembne lastnosti: boljša zašita proti udarcem in tresljajem razširjeno temperaturno obmoje delovanja zašita proti vodi, vlagi, prahu možnost neprekinjenega delovanja skozi daljše obdobje možnost enostavne montaže v industrijskem okolju (npr: na DIN montažna vodila) dodatna možnost napajanja z enosmerno napetostjo 24V velik 'povpreni as med izpadi' (MTBF). Po pojavu prvih modelov vejih proizvajalcev, so tržno nišo zautili tudi manjši proizvajalci, ki ponujajo dovolj kvalitetno opremo za zmerno ceno. 7.3 INDUSTRIJSKA ETHERNET STIKALA Industrijska izvedba mrežnih stikal z osnovnimi lastnostmi: 5 ali 8 vhodov 10/100BaseT(X), 100BaseFX (SC konektor) za monomodno ali multimodno optino vlakno po standardu IEEE802.3, 802.3u, 802,3x razširjeno temperaturno obmoje delovanja (0 C do +60 C) podvojeno napajanje z enosmerno napetostjo 10 do 30V možnost enostavne montaže na DIN montažna vodila ali montaža z vijaki možnost neprekinjenega delovanja skozi daljše obdobje industrijsko kovinsko ohišje v zaitni izvedbi IP 30 pridobljeni certifikati UL,CUL,CE in FCC. Deluje v nevarnih obmojih (Class I, Div.2) izredno velik povpreni as med izpadi Vmesnik za prikljuitev serijskih naprav na ETHERNET (model DE 211) DE 211 je industrijska verzija pretvornika za prikljuitev RS232/RS422/RS485 naprav na Ethernet. Po obiajni izvedbi (model DE 311), ki je namenjen nezahtevnemu okolju so izdelali tudi verzijo DE 211 za zahtevno industrijsko okolje. S pomojo vmesnika lahko na Ethernet prikljuimo serijske naprave kot so: Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 28 od 78

35 industrijski krmilniki, informacijski panoji, upravljalni paneli, merilci pretoka, plinomeri, CNC obdelovalni stroji, razlini terminali, POS blagajne, italci za osebno identifikacijo itd. Vmesnik predvideva dva naina delovanja: Kot obiajni Ethernet udeleženec s svojim IP naslovom. Druga programska rešitev raunalniku doda navidezni serijski vhod (npr. COM 3), s katerim delujejo programi, kot bi raunalnik imel dodatno serijsko kartico za COM 3. Še nekaj lastnosti: vmesnik ima gonilne programe za vse pogoste operacijske sisteme vkljuno z Windows XP in Linux vsebuje 16 bitni CPU prenapetostna zašita 15kV EDS na serijski strani magnetna izolacija 1,5kV na Ethernet strani možna je montaža na DIN vodila ali pritrditev z vijaki pridobil je certificate TUV, UL, CUL, CE B in FCC B Slika 4: Primer model DE Pretvornik iz UTP na FO (ME 51 - Media Convertor) Namenjen je tako industrijskemu kot obiajnemu okolju. V industrijskem okolju, kjer bi motea elektromagnetna polja lahko povzroale motnje na komunikacijskih vodih, lahko problem rešimo z dvema pretvornikoma. Pred vstopom v elektromagnetno 'onesnaženo' okolje prikljuimo UTP/STP vodnik na pretvornik, na drugi strani pretvornika pa nadaljujemo z optinim kablom. Ko zapustimo nevarno obmoje lahko z drugim pretvornikom preidemo iz optinega kabla ponovno nazaj na kabel. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 29 od 78

36 Na opisan nain najbolj zanesljivo izvedemo Ethernet povezavo med dvema zgradbama, ki bi bila sicer podvržena udarom strel ali izenaevalnim tokovom zaradi potencialnih razlik med ozemljitvami obeh zgradb. Pretvornike lahko dobimo v dveh izvedbah: Za povezave z multimodnimi optinimi vlakni, kjer dosegamo razdalje do 2 km. Premer optinega vlakna je lahko 50/125, 62.5/125 ali 100/140µm in ima lahko konektorje ST ali SC. Za povezave z monomodnimi optinimi vlakni, kjer dosegamo razdalje do 20 km. Premer optinega vlakna je lahko 8.3/125, 8.7/125 ali 10/125µm in konektor tipa SC Na Ethernet 10/100BaseT(X) strani je prikljuek RJ45 in nanj lahko prikljuimo CAT.5 kabel dolžine do 100 m. Poleg zašite proti motnjam nam par pretvornikov lahko služi torej tudi za prikljuevanje Ethernet naprav na dolge razdalje (do 20 km). Stvari so torej stekle v prid uveljavljanja Etherneta tudi na nivoju povezovanja nižje procesne opreme. Namenoma smo potegnili vzporednice z uveljavljanjem Windowsov v procesnem vodenju in skušali namigniti, da obiajno zmaga pragmatinost navkljub množici pomislekov glede neizpolnjevanje pogojev, ki jih to podroje zahteva. Ker na trg prihaja edalje ve opreme, ki upošteva Ethernet standard in hkrati izpolnjuje pogoje za uporabo v industrijskem okolju, se uporabnikom ne bo težko odloiti. Slika 5: Primer ME 51 Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 30 od 78

37 8 KLASINI PRISTOP ZAJEMA PODATKOV Sedaj, ko smo se spoznali z orodji in strojno opremo se lahko osredotoimo kakšen je klasini pristop zajema podatkov. V veini klasinih pristopov pri zajemanju podatkov za potrebe proizvodne informatike so merilne naprave in tipala obiajno prikljuene na krmilniške sisteme (PLC-je), ki prek svojih vhodnih kartic periodino tipajo velikosti analognih meritev in stanj digitalnih signalov. Krmilniški sistemi so nato prikljueni na SCADA sistem, ki od krmilnikov periodino zajema podatke o meritvah. Veriga se zakljuuje z relacijsko podatkovno bazo (RDB), ki je sestavni del proizvodnega informacijskega sistema. Težava pri tem je, da SCADA sistem operira z meritvami (trenutnimi vrednostmi in enostavnim arhivom teh vrednosti), poslovni informacijski sistem (tudi RDB) pa potrebuje že obdelane informacije. Izkaže se, da obstaja razhajanje med SCADA sistemom in višjim informacijskim sistemom na treh podrojih: Vsebinski oziroma funkcionalni vidik: Vsebina, ki jo pokriva SCADA sistem, je trenutno stanje vseh meritev v sistemu, proizvodni informacijski sistem pa zahteva vsebino, kot je na primer poraba energenta za stroškovno mesto za dano obdobje ali celo na enoto proizvoda. asovni nivoji: Podatki v SCADA sistemu se spreminjajo na sekundnem nivoju (periodino tipanje meritev), v proizvodnem informacijskem sistemu pa se nekatere informacije spreminjajo na dnevnem ali celo mesenem nivoju. Relacijska baza podatkov znotraj poslovnega informacijskega sistema težko sprejema podatke na sekundnem nivoju. Narava podatkov: Podatki v SCADA sistemu so tipien asovni niz, kjer ima vsak podatek svojo asovno znako. Edina povezava med podatki je as. V informacijskih sistemih, kjer kot osnova nastopa relacijska podatkovna baza, so osnovna povezava med podatki relacije (na primer relacija med porabo, asovnim obdobjem in stroškovnim mestom). Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 31 od 78

38 Slika 6: Klasini koncept zajema podatkov Da bi klasien koncept zajema podatkov (stroj SCADA relacijska baza podatkov) lahko deloval v praksi, je treba podatke v SCADA sistemu ali celo na PLC-ju obdelati surovi niso primerni za uporabo v proizvodnem informacijskem sistemu. eprav je to v praksi (razmeroma uspešno) izvedeno v številnih primerih, ugotavljamo, da SCADA sistem po svoji naravi ni izrazito primeren za takšno obdelavo podatkov. To trditev lahko podkrepimo s primerom, ki se osredotoa na energetski del proizvodnega informacijskega sistema in je opisan v naslednjem odstavku. Eden od osnovnih podatkov v proizvodnem informacijskem sistemu so porabe energije za doloeno obdobje po stroškovnih mestih. Pred uvedbo odprtega trga z elektrino energijo je bilo znailno spremljano obdobje ena izmena. Izraunavanje vsote porabe po izmenah (obiajno 8 urno obdobje) je opravljal kar SCADA sistem, ali celo krmilniški sistem. Ko je prišlo do spremenjenih razmer zaradi odprtja trga z elektrino energijo, so uporabnike zaela zanimati veliko krajša asovna obdobja. eprav gre za majhno spremembo, je le-ta narekovala poseg v vse nivoje sistema (krmilnik, SCADA, RDB), kar je drago, zamudno, obenem pa prinaša spremembe v sicer že preizkušene komponente sistema. Takemu zapletu bi se lahko izognili, e bi informacijski sistem (RDB) beležil vse meritve. To je teoretino sicer mogoe, vendar koliina podatkov, hitrost zajema in asovne znake predstavljajo velike praktine ovire, tako da takšen pristop v praksi ne bi bil uporaben. Omenjene pomanjkljivosti klasine zasnove zajema podatkov pridejo še bistveno bolj do izraza v razmerah, ko je podakov veliko ali ko se med ali celo po izgradnji proizvodnega informacijskega sistema pojavljajo vedno novi. V nekaterih primerih enostavno ni mogoe na nivoju PLC ali SCADA sistema izvesti obdelavo podatkov (so del proizvodne naprave, ki je rna škatla). Dodaten moment, ki predstavlja še dodatno potencialno težavo pri klasini zasnovi zajema podatkov, pa so inteligentne merilne Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 32 od 78

39 naprave (tehtnice, ), ki podatke same prenašajo v okolje osebnega raunalnika. eprav je te podatke možno uvoziti v SCADA sistem, to obiajno ni enostavno in po nepotrebnem obremenjuje sistem v celoti. 8.1 ALTERNATIVNI PRISTOP Oitno je, da je izvor težav vrzel med SCADA sistemom (ki vsebuje vrednosti trenutnih meritev v realnem asu) in informacijskim sistemom (ki operira z obdelanimi podatki). Rešitev izhaja iz uvedbe procesnega historiana namenske procesne podatkovne baze katerega osnovna funkcija je uinkovito arhiviranje procesnih podatkov. Procesni historian je v hierarhiji pretoka podatkov umešen med SCADA sistem in poroilni sistem oziroma relacijsko podatkovno bazo. Za razliko od komponent za arhiviranje, ki teejo znotraj samih SCADA sistemov, imajo ti historiani kar nekaj prednosti: središno orientiran arhiv procesnih podatkov velika hitrost/zmogljivost arhiviranja, možnost zajema razlinih tipov podatkov, indeksirano poizvedovanje po podatkih, kar je osnova za uinkovito analizo podatkov, generiranje poroil in generiranje informacij, ki jih potrebuje informacijski sistem e zadnjo toko ilustriramo s praktinim primerom zajema ene meritve, lahko ugotovimo, da procesni historian zlahka arhivira meritve s pogostim zajemanjem, iz množice zajetih meritev zlahka izluši meritve za neko obdobje, naredi na tej podmnožici obdelavo (na primer izrauna porabljeno energijo v nekem obdobju kot razliko med stanjem števca ob koncu obdobja in stanjem števca na zaetku obdobja, deljeno s asom) in rezultat obdelave vrne informacijskemu sistemu, ki je izvedel poizvedovanje po podatkih. Pomembno je, da ta obdelava poteka zelo hitro in da procesni historian informacijskemu sistemu vrne en sam podatek rezultat obdelave. Naj podrobneje ponazorim problematiko opisano v zakljuku prejšnjega poglavja v lui uporabe procesnega historiana. Ker procesni historian arhivira vse meritve, obenem pa je sposoben informacijskemu sistemu posredovati že obdelano informacijo za poljubno obdobje, se na nobenem od nižjih nivojev (krmilniški sistem, SCADA in procesni historian) pri spremembi opazovanega asovnega obdobja ne spremeni ni, saj je obdobje obiajen parameter, ki ga procesnemu historianu v okvirju poizvedovanja posreduje informacijski sistem. Prednosti glede asa izvedbe, cene in robustnosti rešitve so oitne. Dodatna prednost procesnega historiana se kaže v primerih, ko obstaja zahteva po kompleksnejših korelacijah med podatki, oziroma ko del podatkov prihaja v relacijsko podatkovno bazo iz drugih virov. Takšen primer je na primer izraun porabljene energije na enoto proizvoda ali uinkovitosti procesa. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 33 od 78

40 Slika 7: Prikaz zajema meritev z uporabo procesnega Historiana 8.2 DEJSTVA REALNIH PROCESNIH PODATKOV Lovljenje procesnih podatkov nas najbolj prepriuje v tem, da so se zgodili v realnem asu. Vse pogosteje pa se sprašujemo tudi, kaj pomeni realen procesni podatek. Mednje štejemo: trenutno stanje stroja (deluje/ne deluje) trenutno stanje števca proizvedenih koliin trenutno stanje števca porabe energije trenutno stanje kritine temperature v procesu, ki jo je potrebno spremljati zaradi zagotavljanja sledljivosti teža izdelka oditana na tehtnici Vse zgoraj navedene toke nas pripeljejo do vprašanja zakaj sploh potrebujemo realne procesne podatke. Veliko je bilo napisanega o tem, v praksi pa nam odgovrarjajo na prej zastavljeno vprašanja naslednje lastnosti. fino planiranje na podlagi razpoložljivosti linij obvladovanje zastojev prikazovanje stopnje realizacije planov proizvodna poroila Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 34 od 78

41 Predstavljajmo si, da smo v asu, ko še ne uporabljamo procesnega ihistoriana, torej podatke, ki se pojavljajo v proizvodnih poroilih še vedno vpisujemo rono. Jasna razmejitev med avtomatskim in ronim vpisom podatkov ja prikazana na spodnjih dveh slikah. Slika 8: Prikaz zajema podatkov z uporabo Historiana Slika 9: Roni vnos podatkov v MES, brez ihistoriana Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 35 od 78

42 Roni vnos podatkov se torej zgodi po realnem dogodku na liniji oz. stroju, procesni historian pa nam te podateke posreduje v realnem asu. Prednost takšnega vnosa v realnem asu se potem zdi smiselna, saj so poroila bolj tona, hkrati razbremenimo operaterja na liniji in mu posledino omogoamo, da je njegova pozornost preusmerjena v kakovost njegovega dela. 8.3 POVEZAVA SVETOV V tem poglavju bomo govorili predvsem o tem, kako bomo med seboj povezali meritve, ki smo jih zajeli na liniji in tistimi katere dobimo v relacijsko bazo podatkov. Za razumevanje povezave si pravilno razlagajmo avtomatski zajem podatkov na liniji. Ob zastoju stroja dobimo predvsem podatke o asu zastoja in asovnem okviru kot je v našem primeru sekunda. Bolj podroben prikaz»ujemanja«obeh svetov prikazuje spodnja slika. Opisuje skupne tipe podatkov na liniji in v relacijski bazi podatkov. Slika 10: Povezava dveh svetov Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 36 od 78

43 9 ORODJA ZA OBDELAVO PODATKOV Izvedba dobrega uporabnega odjemalca za prikaz kljunih kazalcev uinkovitosti je tako vsebinski kot tehnološki problem. Takšen odjemalec mora prikazovati izbrane informacije, pripravljene v pravi obliki. e želimo, da se na podlagi informacij, ki jih generira odjemalec kdo odloa, le-teh ne sme biti ne preve in ne premalo in brskanje po njih mora biti prijazno. eprav je kriterij izbora relevantnih informacij, ki naj bi jih takšen odjemalec prikazoval v konkretnem podjetju, do neke mere subjektiven, se izkaže, da obstaja kar nekaj informacij, za katere so zainteresirani v veini podjetij. Odjemalec mora prikazovati planirane in neplanirane zastoje, urejene po pomenu in zbrane v kazalcu razpoložljivosti, kazalec zmogljivosti procesa (ki kaže, kako uspešno deluje proces takrat, ko dejansko generira proizvode v primerjavi z normativi), kazalec kakovosti in kazalec uinkovitosti procesa. Prikazovati mora odprte delovne naloge ter realizacijo proizvodnje v absolutni in relativni obliki (v primerjavi s planom). Odjemalec mora prikazovati tudi kazalce porabe energije in drugih pomembnih virov v absolutni in relativni (normirano z enoto proizvoda) obliki. S asovnega vidika je zelo pomembno, da za tiste kazalce, ki jim lahko definiramo trenutno vrednost, odjemalec to trenutno vrednost tudi prikazuje. Pri tem je potrebno poiskati kompromis med kakovostjo informacije in koliino podatkovnih obdelav, ki jih prikaz trenutnih vrednosti prinese. Izkaže se, da je s stališa funkcionalnosti sistema najugodneje, e se trenutne vrednosti osvežujejo s 15 minutno periodo. Razen vsebine, ki jo obdeluje KPI odjemalec, je zelo pomemben tudi nain, kako so podatki prikazani. Informacije morajo biti nedvoumne, ne sme jih biti ne premalo in ne preve, navigacija po aplikaciji pa mora biti preprosta. Zelo ugodno je, e je odjemalec izveden kot tanki odjemalec in sicer v tem primeru, da je do njega možno dostopati z razlinih lokacij brez predhodne instalacije. V zadnjem desetletju poskušajo inforamacijski oddelki v vejih podjetjih prenašati operativne raunalniške obdelave in podatke v strateške informacije z namenom izboljšave kvalitete in uinkovitosti odloanja. S tem namenom so podjetja investirala ogromna sredstva v orodja za uvajanje tehnologij, kot so podatkovna skladiša, OLAP orodja, sistemi SAP R3... Na žalost pa je po zakljuku tovrstnih projektov le malo uporabnikov zadovoljnih. Velika veina uporabnikov še zmeraj ne dobi ustreznih podatkov za svoje delo ali pa teh orodij ne zna uinkovito uporabljati, saj zaradi obilice drugega dela nimajo asa, da bi se nauili uinkovito uporabljati ta obiajno zahtevna orodja. Tudi tisti uporabniki, ki kljub okornemu sistemu pridejo do potrebnih podatkov, vseeno nimajo za odloanje popolnih informacij, ker preko naštetih orodij nimajo dostopa do nestrukturiranih podatkov, ki so izven strukturiranih podatkovnih skladiš. Tu gre predvsem za razline elektronske dokumente, elektronsko pošto, faks, avdio-video format... Poslovne informacije, potrebne za odloanje, torej niso vedno dostopne pravoasno ter v ustrezni obliki. Vasih jih uporabniki sploh ne dobijo, velikokrat pa sploh ne vedo, da obstajajo, ali pa še huje, vedo, da te informacije v podjetju obstajajo, vendar ne vedo, kje jih iskati, ali da do njih vodi le zelo zapletena in asovno potratna pot. V vejih podjetjih se za razline namene obiajno vzdržuje veje število medsebojno nepovezanih podatkovnih baz, vasih tudi s podvojenimi podatki. Ravno tako se uporablja ve poslovnih aplikacij, ki lahko generirajo na stotine razlinih poroil v razlinih oblikah. Tem informacijskim virom je treba dodati še razne dokumente, pripravljene v urejevalnikih besedil, preglednicah, elektronski Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 37 od 78

44 pošti... Tako imamo opraviti z veliko razlinimi viri, zato je pot do podatkov težka in dolgotrajna, kar pa je v nasprotju z vse vejo potrebo po im hitrejšem dostopu do potrebnih podatkov in informacij. V moderni, decentralizirani, krajevno raztreseni organizaciji, v kateri imajo zaposleni vejo odgovornost pri odloanju, imamo opraviti z vse vejo potrebo po hitrem in enostavnem dostopu do potrebnih podatkov in informacij. Pojavlja se zahteva po hitrem dostopu do organizacijskih pravil in postopkov, ki jih je treba poznati pri reševanju problemov. V osnovi veliko veino dela in asa porabimo pri odloanju katere podatke bomo prenašali in kasneje tudi analizirali. Pri prenosu podatkov iz razlinih virov imamo dobro priložnost poenotiti metapodatke in si izdelati podatkovni slovar oziroma repozitorij (respository). Metapodatki so podatki o podatkih, kar pomeni, da metapodatki opisujejo kaj pomenijo podatki. Potem, ko dobimo podatek v bazo podatkov ga je potrebno primerno obdelati. V ta namen imamo na voljo ve orodij s katerimi si lahko pomagamo. Poroila bodo lahko najbolj ustrezna le, e je uporabljena le najboljša tehnologija za zajem podatkov. Ustrezno poroilo in uinkovitost linije nam prikazuje tudi dejstvo, kako so postavljeni kazalci uinkovitosti posamezne linije ali celotnega podroja. Vsi ti kazalci pa imajo svojo pravo vrednost samo v primeru, da so posredovani na pravilen nain za izbrani nivo zaposlenih. Struktura prikazov podatkov je tako lahko venivojska: Slika 11: Prikaz strukture podatkov Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 38 od 78

45 9.1 MS ACCESS Je orodje znotraj zbirke orodij MS Office in je zelo primerno za hitro izdelavo poroil, ki so lahko osnova za kasnejše nadgradnje z drugimi orodji. Omogoa zajem podatkov iz razlinih virov podatkov (npr. kadrovska baza podatkov, baza podatkov poslovnega informacijskega sistema, ) in izvoz rezultatov poizvedb v bolj razširjene oblike branja oz. preraunavanja (MS Word, MS Excel). Preden se poglobimo v Access moramo jasno vedeti, kaj želimo narediti kakšen je naš cilj. Aplikacija izdelana z orodjem MS Access ima lahko samo povezavo do podatkov (npr. na Oraclu) in zato ni velika. V njej se lahko tvorijo zaasni podatki, ki se jih pri podobnih poizvedbah z druganimi vrednostmi filtrov prepiše. Na primeru lahko vidimo pregled dogodkov na liniji v eni izmeni; tu vidimo na enem poroilu dve kategoriji: dogodke in kategorije dela, v katerih je delalo osebje na liniji. Ker je bilo na liniji ve ljudi, imajo kategorije lahko v eni izmeni ve kot 8 ur. Slika 12: Primer dela poroila - dela v eni izmeni (MS Access) 9.2 INTRANET/INTERNET TEHNOLOGIJA Intranet portali predstavljajo zelo kompleksno in uinkovito orodje za podporo internim komunikacijam in dostopu do podatkov. Zaradi specifinih potreb organizacij pa obiajno uinkovitega portala ne moremo preprosto kupiti in namestiti, temve je za uinkovit intranet portal potrebno skrbno nartovanje skozi celoten življenjski cikel, ne glede na to, kako obsežen je portal. Življenjski cikel portala obiajno lahko delimo na šest faz: Priprava in planiranje, analiza in definicija potreb, nartovanje, konstrukcija, implementacija, vzdrževanje. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 39 od 78

46 Kot opcijo lahko navedemo še umik iz uporabe. To fazo lahko vkljuimo v življenjski cikel, ni pa nujno, da jo izpeljemo. e gradimo portal zgolj zase oziroma za manjši krog ljudi, lahko to pogosto naredimo brez vejih formalnosti. e pa gradimo intranet portal za podjetje s 1000 in ve zaposlenimi, potem je za uspeh neobhodna skrbna priprava in postopna izvedba vseh faz življenjskega cikla. V nadaljevanju bom zato prikazal potek nartovanja in izgradnje intranet portala skozi posamezne faze življenjskega cikla. Zanimo kar s prvo fazo: s pripravo in planiranjem portala. To je faza, ko v organizaciji zautimo, da bi pravzaprav morali nekaj narediti za izboljšanje internih komunikacij oziroma omogoiti zaposlenim lažji in sistematien dostop do potrebnih podatkov. Ob tej ugotovitvi pripravimo osnutek projekta. V osnutku nakažemo cilje, ki jih s projektom želimo dosei, in kritine elemente za dosego zastavljenih ciljev. Nato z osnutkom projekta seznanimo vodstvo in si poskušamo pridobiti njihovo naklonjenost, kajti le, e bo vodstvo naklonjeno projektu, imamo vsaj teoretine možnosti za uspeh. V zaetni pripravljalni fazi se je dobro vprašati, na kakšne probleme lahko naletimo med življenjskim ciklom projekta. Mogoe najprej pomislimo na tehnine probleme, vendar v veini organizacij internetna tehnologija ne predstavlja vejih problemov, saj je ta obiajno v veji meri že razpoložljiva. Mnogo veji problemi so obiajno politine narave, in sicer gre tu predvsem za vprašanje, kdo bo imel lastništvo in kdo skrbništvo intranet portala. Politine probleme v podjetju je zelo priporoljivo razrešiti že v tej zaetni fazi, kajti kasneje lahko ti sedaj še majhni problemi zavzamejo velike razsežnosti in lahko celo ogrozijo obstoj in nadaljevanje projekta. Ta faza je torej izrednega pomena za uspeh celotnega projekta. Že v zaetni fazi je priporoljivo, da izberemo in seznanimo kljune zaposlene, ki jih bomo potrebovali pri implementaciji intranet portala. V projektni skupini bomo potrebovali zaposlene z zelo razlinimi profili znanj, za katere pa ni neobhodno potrebno, da imajo enake poglede na projekt. Pomembno je le to, da so vsi pripravljeni odigrati svojo vlogo v projektu in da bodo s tem pripomogli pripeljati projekt v konno fazo. Obiajno je pri malce kompleksnejših intranet portalih treba v projektno skupino vkljuiti naslednje profile zaposlenih : Informatike, ki bodo skrbeli za vzdrževanje strežnikov, omrežja, programske rešitve, potrebno programsko opremo pri odjemalcih in sploh skrbeli za portal v informacijsko tehninem smislu. Oblikovalce, ki bodo poskrbeli za izgled portala in za urejanje navigacijske strukture. Imeti morajo tako oblikovalska znanja kot tudi znanja iz enostavnega pisanja razlinih krajših in enostavnih programskih kod, ki služijo za izdelavo interaktivnih in dinaminih spletnih strani. Koordinatorja, ki bo skrbel za potek celotnega projekta in bo koordiniral posamezne ljudi in skupine, ki bodo sodelovale v projektu. Skrbel bo, da bo celoten projekt potekal v okviru predvidenih rokov. Skrbeti mora za im boljše sodelovanje vseh sodelujoih in skušati izrabiti sinergijske uinke skupinskega dela. Polnilce vsebin, ki bodo skrbeli za polnjenje portala z zanimivimi in koristnimi vsebinami. Portal lahko zgradijo ljudje iz prvih treh naštetih skupin, vendar bo brez potrebnih vsebin portal zelo hitro postal Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 40 od 78

47 neuporaben. Portal bo uporaben le, e bodo njegove vsebine vzdrževane, za kar pa morajo biti zadolženi ljudje po posameznih oddelkih. Od teh ljudi je odvisna uporabnost in s tem tudi nadaljevanje razvoja intranet portala. Vzdrževalce, ki bodo priskoili na pomo, ko se bo polnilcem vsebin kaj zataknilo. Poskrbeli pa bodo tudi za tekoe delovanje intranet portala. Tako kot skoraj vsak projekt je tudi intranet portal živ projekt, ki se mora stalno spreminjati, da je sploh uporaben. Zaradi tega pa pride s asom do doloenih anomalij (pretrgane hiperpovezave, stare vsebine...), ki jih je treba poistiti. Treba pa je skrbeti tudi za arhiviranje podatkov in dodajanje uporabnikov. Uspeh projekta je mono odvisen od izbire pravih ljudi, kajti ponovno velja poudariti, da uspešni portali temeljijo na sposobnih ljudeh in ne le na najsodobnejši tehnologiji. Zgoraj sem naštel ljudi po posameznih znanjih in usmeritvah, vendar ni nujno, da ne morejo posamezni ljudje odigrati ve vlog v tem projektu. Doloene vloge so vsebinsko povezane oziroma se celo prepletajo, tako da lahko zanje uporabimo iste ljudi. Ob zaetku gradnje intranet portala se moramo zavedati dejstva, da je to komunikacijski projekt in bomo informacijsko tehniko uporabili le za orodje, zato v tej fazi informatike le izberemo, jih pa skušamo zadržati dale od projekta. Kot potrditev povedanega sem nekje na svetovnem spletu prebral naslednji citat:»na zaetku je bil Adam in ne Raunalnik, zato naj bo cilj intraneta postavitev omrežja, uporabnega za ljudi, in ne zgolj omrežja povezanih strojev!«prva faza je torej namenjena predvsem doloitvi in izbiri potrebnih ljudi, razdeljevanju zadolžitev in zastavitev smernic projekta. Po uspešni rešitvi problemov iz prve faze lahko zanemo z najzahtevnejšo drugo fazo projekta, to je, z analizo in definicijo potreb. Ta faza zahteva veliko asa in naporov, kajti od dobre izvedbe te faze je v veliki meri odvisna uspešnost celotnega projekta. V tej fazi najprej definiramo in dokumentiramo uporabniške potrebe in želje, pri emer si lahko pomagamo z raziskavo potreb po informacijah v organizaciji. Raziskava je sicer asovno izredno potratna, vendar veliko projektov propade ravno zaradi slabe priprave. Razgovorov jasno ne moremo opraviti z vsemi zaposlenimi, zato se obiajno odloimo za pogovore s kljunimi zaposlenimi po posameznih oddelkih in poslovnih enotah. Predhodno skrbno pripravimo vprašalnik, ki nam bo v pomo pri razgovorih. Pri pripravi vprašalnika in izbiri sogovornikov si pomagamo s predhodno doloitvijo procesov v organizaciji, ki jih želimo podpreti z intranet portalom, kajti intranet ne prinaša enakih koristi za vse vrste procesov. Najveje koristi ustvarimo na podrojih, kjer sodeluje veje število zaposlenih v kompleksnih procesih. Manjše koristi so na podrojih, kjer omejena skupina ljudi opravlja relativno rutinirano delo. Oglejmo si, denimo, proces fakturiranja, ki ga izvajajo tri osebe v podjetju, po možnosti vse v isti pisarni. Za to uporabljajo posebno aplikacijo, ki jo je sicer mogoe tehnološko prenesti v intranet okolje. Uporabniki bodo odslej opravljali fakturiranje skozi spletni brskalnik, vendar to samo dejstvo ne prinese nove vrednosti. Nasprotno pa lahko uvedba intranet sistema za podporo projektnega dela ali upravljanja odnosov s strankami (CRM - Customer Relationship Management) prinese mnogo koristi. Poglejmo si primer upravljanja odnosov s strankami, kjer je vpleteno mnogo ljudi v podjetju, od trgovskega potnika preko svetovalca do serviserja. Vsak od njih prispeva košek v informacijski mozaik, potreben za celovito obravnavo stranke, in vsak od njih potrebuje del teh informacij. Dostop do sistema, tudi kadar je zaposleni izven svojega podjetja, je zelo pomemben. Trgovski potnik bo morda na terenu potreboval informacije o konkretni stranki ali podobnih poslih, opravljenih v preteklosti. Morda bo svetovalec v tujini, Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 41 od 78

48 vendar vseeno preko intraneta zmožen sodelovati pri reševanju težave, ki se je pojavila pri stranki. Hiter in korekten pretok informacij med zaposlenimi je za uspešno delo kljunega pomena. Intranet je dober za vnaprej pripravljene tipe poroil, ker na raunalnikih uporabnikov ni potrebna nobena dodatna instalacija (in posledino vzdrževanje, posodabljanje). Dostopne so vsakomur, ki je avtoriziran za gledanje. Na spodnjem primeru je prikazano poroilo produktivnosti za doloeno obdobje po proizvodnih linijah. S pomojo ustreznih filtrov lahko primerjamo podatke razlinih obdobij, linij, Prednost takšne tehnologije se zrcali v dejstvu, da so podatki»on-line«. Slika 13: Primer poroila produktivnost funkcijskih blokih (intranet) 9.3 KOCKA OLAP (Cognos) Kocka se uporablja za podporo odloanju, rudarjenje podatkov, pripravo poroil iz razlinih ERP virov podatkov. To je industrijsko najbolj razširjeno OLAP (OnLine Analytical Processing) orodje, ki je že bilo nagrajeno za prikaz podatkov in je klju za standardizacijo poslovanja. Omogoa nov nivo prilagodljivosti in kontrole. Predstavitev podatkov v OLAP tehnologiji je realizirana na zelo naraven nain podobno, kot podatke pomnijo loveški možgani. Podatke si kar naprej urejamo in grupiramo v doloene skupine, ki nam pomagajo pri boljši predstavi doloenega pojava. Zelo podobno so podatki organizirani v OLAP podatkovni bazi. Podatki so grupirani v posamezne skupine, ki so razdeljena v hierarhine nivoje. Organizacijo skupin in nivojev tvorimo sami glede na vsebino podatkov. Tem podatkom pravimo tudi dimenzije. Rezultatom analize, ki nas zanimajo pa pravimo mere. Vsi ti podatki se ponavadi nahajajo v vedimenzionalni strukturi, ki ji reemo tudi OLAP kocka. Torej, podatki v OLAP tehnologiji se nahajajo v vedimenzionalni bazi ali kocki, v kateri so definirane dimenzije in mere. Dimenzije predstavljajo kategorije po katerih analiziramo podatke, mere pa predstavljajo vrednost ali velikost podatka, ki ga analiziramo. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 42 od 78

49 Struktura podatkov OLAP sistem deluje tako, da se dimenzije in mere izraunavajo iz vhodnih podatkov in zapisujejo v ustrezno strukturo. Ponavadi imajo dimenzije tudi nivoje in idealno bi bilo, da bi sistem v naprej izraunal mere za vse dimenzije na vseh nivojih. V naprej izraunane mere imenujemo tudi agregacije. Število agregacij a se izrauna po naslednji enabi: a = ld, kjer l predstavlja število nivojev dimenzije, d pa predstavlja število dimenzij. Vidimo, da se število agregacij poveuje eksponentno s številom dimenzij. e vzamemo, da ima povprena kocka dvajset dimenzij s povpreno tremi nivoji, dobimo agregacij! Za shranjevanje takšnega števila agregacij bi porabili veliko asa in veliko koliino pomnilnika. Eksponentna odvisnost števila agregacij od števila dimenzij je izredno kritina in predstavlja velik problem. Rešitev je izvedena tako, da se agregacije ne raunajo za vse nivoje dimenzije, ampak samo za spodnje nivoje. Agregacije za višje nivoje pa dobimo z vsoto spodnjih nivojev. S to omejitvijo se izjemno reducira število agregacij in asovna in prostorska komponenta ni ve kritina za shranjevanje. Za zgornji primer, kjer imamo kocko z dvajsetimi dimenzijami in povpreno tremi nivoji, dobimo tako le 60 agregacij. Režijski stroški za preraun ostalih agregacij so zanemarljivi, saj jih OLAP sistem izraunava letee in po potrebi. Raunanje agregacij poteka z seštevanjem podatkov iz vhodnih vrstic, ki se shranjujejo v OLAP podatkovno bazo. Opravka imamo z dvema tipoma podatkov. To so vhodni podatki in agregacije. Glede na to, kako shranjujemo ta dva tipa, loimo tri naine shranjevanja v OLAP podatkovno bazo: 1. MOLAP shranjuje oba tipa podatkov v vedimenzionalnih strukturah, 2. ROLAP shranjuje oba tipa podatkov v relacijski podatkovni bazi in 3. HOLAP, ki shranjuje vhodne podatke v relacijski bazi, agregacije pa v vedimenzionalni strukturi. Sistem shranjevanja MOLAP je praviloma najhitrejši nain analize podatkov, vendar zahteva tudi najvejo koliino zunanjega pomnilnika. ROLAP je vedno najpoasnejši nain analize, ker mora v vsakem primeru iskati agregacije s poseganjem v relacijsko podatkovno bazo. HOLAP deluje hitro v primerih, da se podatki agregacij nahajajo v vedimenzionalni strukturi, sicer je enako poasen kot ROLAP. Vhodni podatki Vhodni podatki se hranijo v podatkovnem skladišu, ki je realiziran kot relacijska podatkovna baza. Vsebuje podatke o vseh merah in dimenzijah, ki jih potrebuje OLAP sistem za analizo nekega poslovnega procesa. OLAP sistem zajema podatke iz podatkovnega skladiša in jih s shranjuje v OLAP podatkovno bazo. Temu postopku pravimo tudi procesiranje kocke, pri katerem se kreira kocka ter vanjo vpišejo podatki o dimenzijah in merah. Procesiranje se izvaja periodino. e uporabljamo ROLAP nain shranjevanja, potem se podatki podatkovnega skladiša lahko uporabijo kot vhodni podatki OLAP sistema in procesiranja podatkov ni potrebno izvrševati. Praktino v trenutku, ko se podatek zapiše v podatkovno skladiše, je že predstavljen v OLAP odjemalcu. Temu nainu pravimo tudi kocka v realnem asu (real-time cube). Sistem mora zagotoviti, da se agregacije osvežujejo pri vsaki spremembi vhodnih podatkov. Ostali naini shranjevanja podatkov pa Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 43 od 78

50 zahtevajo procesiranje kocke v katerem se doloi velikost strukture in izraun podatkov. Loimo tri glavne naine procesiranja kocke: 1. polno procesiranje, 2. osveževanje podatkov in 3. inkrementalno procesiranje Pri polnem procesiranju se najprej kreira struktura OLAP podatkovne baze, nato pa sledi proces raunanja podatkov ter njihovo zapisovanje v strukturo. Osveževanje podatkov poteka tako, da se ponovno opravi izraun kocke brez kreiranja strukture. Procesirati pa ni potrebno vedno celotne kocke, temve se lahko uporablja tudi inkrementalno procesiranje, kar pomeni, da se iz podatkovnega skladiša prenašajo samo na novo zapisani podatki oziroma tisti podatki, ki izpolnjujejo doloen pogoj. Pomembno je še to, da konni uporabnik OLAP aplikacije ne sme vedeti, kdaj se izvaja procesiranje. Pri inkrementalnem procesiranju se podatki enostavno samo dodajo k obstojeim, zato se delo ne prekine. V primeru polnega in osveževalnega naina pa procesiramo celotno kocko, zato konni uporabnik med procesiranjem nima dostopa do podatkov. Podatkovno skladiše polnimo s podatki razlinih OLTP (OnLine Transaction Processing) aplikacij. To so raznovrstne aplikacije ali celo ERP sistemi, ki pokrivajo osnovne transakcije poslovnega procesa. Podatki takšnih aplikacij so raznovrstni, zato jih je potrebno najprej filtrirati in pravilne prenesti v podatkovno skladiše. Praviloma se podatki v podatkovno skladiše samo dodajajo in nikoli ne brišejo, razen seveda v izjemnih okolišinah, kot je nepravilni prenos ali dvojni prenos. Podatki se periodino prenašajo s pomojo servisov za prenos podatkov, ki so sestavni del sistema za upravljanje z podatkovnimi bazami. Podatkovno skladiše nam torej uvede neko ureditev podatkov, ki so kot osnova OLAP sistema. V primeru strukturnih sprememb skladiša je potrebno izvest polno procesiranje vseh kock. Varnost podatkov Varnost podatkov v OLAP sistemu zagotovimo z štirimi nivoji varnosti: 1. Administracija kocke, 2. dostop do OLAP podatkovne baze, 3. dostop podatkov v kocki in 4. varnost dimenzij in celic. Varnost podatkov zagotavljamo z dodajanjem vlog za posamezen nivo varnosti. Pri gradnji kock je pomembno, da lahko doloimo skupino uporabnikov, ki imajo pravice za gradnjo in spreminjanje strukture kocke. Z vlogami za dostop do OLAP podatkovne baze doloamo uporabnike, ki imajo dovoljenja za dostop do OLAP podatkovne baze. Vloge v kocki doloajo pravice uporabnikov za posamezna obmoja pregledovanja podatkov OLAP kocke. V primeru, da varovanje še ni na zadovoljivi ravni, imajo OLAP sistemi vgrajen še etrti nivo varovanja. Varnost dimenzij in celic v kocki omogoa dodeljevanje vlog za posamezne celice v kocki Implamentacija OLAP tehnologije Implementacija OLAP sistema za podporo odloanju v podjetje zahteva veliko organizacijskega in informacijskega znanja. Odloitev za uporabo OLAP tehnologije Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 44 od 78

51 je upraviena povsod tam, kjer imamo veliko podatkov, ki jih lahko strnemo v vsote. Zelo pomembno je, da imamo dobro izdelan osnovni koncept izgradnje podatkovnega skladiša, vsebina OLAP kock, dimenzije in mere. Potrebno pa je tudi dobro poznavanje vsebine podatkov. Vsaka naknadna vsebinska sprememba lahko povzroi veliko strukturnih sprememb v vseh delih OLAP sistema. OLAP sistemi se veliko uporabljajo za analizo podatkov, ki se tvorijo znotraj razlinih poslovnih procesov podjetja. Danes je OLAP tehnologija že uvedena v razline tipe poslovanja. Najpogosteje se z OLAP sistemi sreujemo v banništvu, zavarovalništvu, zdravstvu, itd. Pokrivajo razline poslovne funkcije kot so prodajno in nabavno trženje, proizvodnja, planiranje itd. Tipini primer implementacije OLAP sistema je analiza podatkov maloprodajnega podjetja, ki bo tudi prikazana v nadaljevanju tega prispevka. Uporabljeno je OLAP orodje Microsoft Analysis Services. Z OLAP orodjem bomo torej zgradili sistem za uinkovito analizo podatkov v maloprodajnem podjetju. Najprej moramo opraviti analizo maloprodajnih procesov in podatkov. Podatke lahko strnemo v poslovne dogodke, ki so: nabava, prodaja, naroanje, dispozicije in reklamacije. Želimo torej analizirati podatke o koliini, prodajni in nabavni ceni za vse dogodke. Analiza naj tudi omogoa pregled po obdobjih, skladiših, poslovnih partnerjih in artiklih. Iz takšnega opisa hitro vidimo, da imamo opravka s petimi dimenzijami in tremi merami. Dimenzije so dogodek, datum, artikel, poslovni partner ter skladiše. Mere pa so podatki o koliini, prodajni in nabavni ceni. Glavni koraki pri implementaciji OLAP tehnologije lahko strnemo v naslednje korake: organizacija in transformacija podatkov, gradnja in procesiranje OLAP kocke in namestitev orodij za prikaz podatkov Organizacija in transformacija podatkov Prenos podatkov izvajamo s pomojo razlinih aktivnosti za prenos podatkov iz OLTP aplikacij v podatkovno skladiše. Ta operacija je s stališa pravilnosti podatkov najbolj kritina. Pri prenosu se velikokrat sreujemo s problemi nepravilnih ali nepopolnih podatkov. V primeru, da so podatki nepopolni, jih moramo avtomatsko dopolniti seveda, e je to mogoe. Podatkovno skladiše maloprodajnega podjetja vsebuje tabele o transakcijah, artiklih, poslovnih partnerjih, datumu, skladiših in vrsti dogodka. Ker je to relacijska podatkovna baza, moramo zgraditi ustrezne relacije med posameznimi tabelami. Celoten model temelji na modelu OLAP podatkovne baze. Najboljši podatkovni model OLAP podatkovne baze je zvezdni model (star-schema), ki vsebuje eno centralno tabelo in ve zunanjih tabel. Zvezdni model je v veini primerov kompatibilen z relacijskim modelom podatkovnega skladiša. V centralni tabeli se nahajajo podatki o merah in stinih atributih dimenzij ali kljuev dimenzij. V zunanjih tabelah pa so podatki o dimenzijah, ki vsebujejo kljue in podatke o nivojih. Centralni tabeli pravimo tudi tabela dejstev. Najvejo število vrstic vsebuje tabela dejstev v katero se vrstice samo dodajajo, zunanje tabele pa vsebujejo precej manj vrstic, ki se redkeje dodajajo. Primer zvezdnega modela je prikazan na spodnji sliki. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 45 od 78

52 9.3.3 Gradnja in procesiranje OLAP kocke Ko imamo zgrajen podatkovni model, se lahko lotimo gradnje OLAP kocke. V OLAP orodju moramo izvesti naslednje osnovne korake: 1. Povezava s podatkovnim skladišem, 2. vnos tabel podatkovnega skladiša, 3. definicija dimenzij in mer, 4. kreiranje kocke, 5. definicija shranjevanja podatkov, 6. procesiranje kocke in 7. administriranje varnosti podatkov. Ko je kocka zgrajena, jo je potrebno vzdrževati z tekoimi podatki. Vzdrževanje kocke se izvaja s procesiranjem kocke, ki mora biti izvedeno avtomatsko z izvajanjem opravil v urniku. Rono procesiranje se uporablja pri strukturnih spremembah kocke. Avtomatsko procesiranje zagotovimo s pomojo aktivnosti za prenos podatkov (Data Transformation services). Zmogljivo OLAP orodje nam omogoa še naslednje dodatne možnosti: 1. navidezne dimenzije, 2. navidezne kocke, 3. akcije, 4. izraunane mere in 5. uvoz in izvoz podatkov Navidezne dimenzije so dimenzije zgrajene iz fizinih dimenzij. Navidezno dimenzijo kreiramo takrat, ko želimo prikazati samo doloen del fizine dimenzije. V OLAP kocki je navidezna dimenzija enaka fizini dimenziji. Enako lahko gradimo tudi navidezne kocke, ki je lahko kombinacija ve fizinih kock v eno navidezno kocko ali pa predstavlja samo izsek fizine kocke. Pri gradnji navidezne kocke iz ve fizinih kock lahko izbiramo dimenzije in mere z vseh kock. Zgled za takšen primer je združitev kocke prodaja in kocke zaloga v navidezno kocko. Akcije omogoajo uporabnikom proženje poljubnih programov. Tako je možno zaganjati razne poizvedbe, odpiranje spletnih strani, itd. Izraunane mere omogoajo gradnjo lastnih mer iz že obstojeih. Izraunana mera je MDX relacija med obstojeimi merami v kocki. Podatke v kocki lahko izvažamo v posebne datoteke, ki omogoajo, da uporabnik lahko dostopa do OLAP sistema tudi z lokalnega raunalnika Namestitev orodij za prikaz podatkov Podatke pregledujemo s pomojo posebnih odjemalskih aplikacij. Odjemalec se poveže na vir podatkov OLAP sistema. Vir podatkov je lahko OLAP strežnik ali pa posebna datoteka (cub file). Ko je povezava vzpostavljena se nad OLAP podatkovno bazo izvajajo MDX poizvedbe, rezultati pa se vrnejo nazaj k odjemalcu. Aplikacije uporabljajo ve tehnologij za OLAP, ki omogoa poizvedovanje v OLAP kocki. Tehnologija OLAP je skupek vmesnikov za poseganje v vedimenzionalno strukturo in omogoa izvajanje MDX ukazov. Najbolj razširjene aplikacije so ProClarity, Cognos PowerPlay, HugryDog, IntelliBrowser, Microsoft Excel, Crystal Reports, Office Web Components, itd. Uporabimo lahko tudi razna razvojna orodja, ki omogoajo razvoj lastnih aplikacij za Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 46 od 78

53 analizo podatkov. Najve se uporabljata Microsoft Visual Basic in Borland Delphi. Mogoe je zanimiva možnost predstavitev podatkov v spletnem brskalniku. Za ta namen uporabimo gradnike Office Web Components. Glavna komponenta je vrtilna tabela, ki omogoa prikaz podatkov v spletnem odjemalcu. Predstavljajmo si, da imamo v podatkovnem skladišu vse podatke kakovostne in urejene, tako, da je naše delo le še za analiziranje. Pri tem je tehnologija OLAP kot nalaš za to delo, saj v osnovi ponuja pogled na agregirane podatke z ve dimenzij. Za primer vzemimo poslovanje naše podjetje LEK. e hoemo analizirati poslovanje podroij v doloenem obdobju, moramo najprej vedeti katero podroje bomo gledali, katero linijo, kateri dan in katero izmeno. Torej, lahko na podatke gledamo z ve dimenzij, kot so dimenzije asa, podroja itd. Temu strokovno pravimo, da gledamo podatke v podatkovnem skladišu vedimenzionalno z ve vidikov na enkrat. To še ne pomeni, da moramo vedno upoštevati za vsak podatek vse dimenzije oziroma vidike, ravno nasprotno, saj v dimenzije vkljuujemo tiste dimenzije, ki nas zanimajo in so zanimive za analiziranje. Ponavadi preko dimenzij gledamo neko že opravljeno transakcijo za vasko transakcijo pa merimo, kaj bo tu merljivo oziroma števno. Vedno moramo vnaprej doloiti glede na katero merljivo koliino bomo pregledovali podatke z ve dimenzij. Tabela v kateri shranjujemo podatke pravimo tabela dejstev (fact table). asovno dimenzijo lahko dobimo s hierarhijo, ki jo razdelimo na mesec, leto, dneve, izmene, minute, sekunde. V tem primeru, ko združimo dimenzije in tabelo dejstev dobimo t.i. kocko. OLAP je v svetu, veinoma v velikih koncernih nepogrešljivo orodje. Bistvena uporabnost tehnologije OLAP je v tem, da je možno brez vejega truda dobiti podatke pri katerih bi z uporabo strukturiranega poizvedovalnega jezika izgubili precej asa ob razmeroma lahkih in enostavnih analizah. Velikokrat je potrebno pri uporabi podatkovnega skladiša dobro razmišljati tudi o orodju, ki se bo pozneje uporabljalo pri analiziranju podatkov. V osnovi lahko povemo, da so vsa orodja OLAP enaka, razlikujejo se predvsem po prikazovanju podatkov in izrisih grafov. Pri kocki (aplikacija Cognos), katero tudi uporabljamo v našem podjetju lahko na primeru vidimo, kako lahko vrtamo v globino. Tukaj npr. vidimo podatke za prvi kvartal leta 2004 po work centrih za skupine dogodkov. Proizvodni as as malice 1998 Q1 linija x1 7,5 0,5 linija x2 3,2 0,5 linija x3 5,5 0,5 linija x4 6,2 0,5 linija x5 7,1 0,5 linija x6 5,9 0,5 linija x7 1,5 0,5 linija x8 4,3 0,5 linija x9 2,8 0,5 Tabela 1: Sumirani asi dogodkov 1. nivo Že sam zaetek bi lahko bil drugaen lahko bi izbrali npr. drugo asovno obdobje. Na tem mestu (in povsod naprej) lahko izbiramo med razlinimi nadaljevanji. Lahko Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 47 od 78

54 si npr. pogledamo bolj podrobno, kaj se je dogajalo na enakih planskih lokacijah, enakih skupinah dogodkov znotraj prvega kvartala, lahko nas zanima ena skupina dogodkov, e se odloimo za en skupek pakirnih linij, dobimo eno stopnjo niže (s pritiskom na eno tipko) podatke za samo podroje in kapacitetna mesta na njem. Proizvodni as as malice 1998 Q1 linija x1 7,5 0,5 linija x2 3,2 0,5 linija x3 5,5 0,5 linija x4 6,2 0,5 linija x5 7,1 0,5 linija x6 5,9 0,5 linija x7 1,5 0,5 linija x8 4,3 0,5 linija x9 2,8 0,5 Podroje skupaj 5.884,66 103,63 Tabela 2: Sumirani asi dogodkov 2. nivo V naslednjem koraku lahko npr. pogledamo, kako je s podatki na eni od skupin dogodkov, ki se deli naprej na druge skupine, te pa še naprej dokler ne pridemo do osnovnih dogodkov (še vedno za cel kvartal). V naslednjem koraku lahko npr. pogledamo, kako je s podatki na eni od skupin dogodkov, ki se deli naprej na druge skupine, te pa še naprej dokler ne pridemo do osnovnih dogodkov (še vedno za cel kvartal). OKVARA NEP_ZASTOJI NI_MEDIJEV 1998 Q1 linija xy linija xy2 0, linija xy3 0, linija xy5 1, Podroje skupaj 12, Tabela 3: Dogodki - vmesni nivo Naprej lahko gledamo»razbijamo«asovno obmoje, dokler ne pridemo do osnovnih podatkov za dan oz. izmeno Podatkovni jezik MDX MDX (Multdimensional Expressions) je poizvedovalni jezik, ki ga uporabljamo v OLAP podatkovnih bazah, podobno kot jezik SQL v relacijskih podatkovnih bazah. Jezika MDX in SQL sta si v osnovi precej podobna, vendar je MDX precej uinkovitejši v vedimenzionalnih strukturah. Jezik MDX potrebujemo za gradnjo Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 48 od 78

55 lastnih OLAP aplikacij. V OLAP aplikacijah prikazujemo podatke na precej specifien nain. Prikazujemo ve vrednosti (mer) po eni ali ve kategorijah (dimenzijah). Rezultat navadne SQL poizvedbe je v obliki dvodimenzionalne tabele v kateri kolone predstavljajo polja, vrstice pa posamezne zapise poizvedbe. Rezultat MDX poizvedbe je v splošnem vedimenzionalna struktura, ki jo lahko predstavimo na ve nainov. Ponavadi je predstavljena v eno dvodimenzionalnem ali v tridimenzionalnem pogledu, odvisno od tega kakšno strukturo podatkov lahko prikaže odjemalec Lastnosti jezika MDX Jezik ima vgrajenih ve kot sto internih funkcij za manipulacijo s podatki. Loimo jih lahko v ve skupin: 1. Funkcije za definiranje strukture (CROSSJOIN), 2. dimenzijske, hierarhine in nivojske funkcije za delo s lani (TOPCOUNT), 3. numerine funkcije za preraunavanje mer (SUM, COUNT, AVG), 4. logine funkcije (AND, OR, NOT), 5. funkcije za delo z nizi (FORMAT_STRING) in 6. funkcije za delo s polji. Izgradnja in uvajanje OLAP sistema v podjetje je stoodstotno pravilna odloitev. Bistvena prednost takšnega sistema je hitrost delovanja in transparentnost podatkov in s tem celotnega poslovanja podjetja. Pri gradnji sistema je pomembno že na samem zaetku izdelati celovito vsebino in definirati poslovne funkcije, ki naj jih pokriva takšen sistem. V nadaljevanju pa moramo paziti na ažurnost in pravilnost podatkov ter izdelati varnostno politiko za uporabnike, ki upravljajo s takšnim sistemom. Tehnologija OLAP ima prednost vedimenzionalne strukture podatkov, ki omogoa veliko hitrost v primerjavi z relacijskimi podatkovnimi bazami. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 49 od 78

56 10 PRAKTINA REŠITEV Sedaj, ko smo spoznali kako avtomatsko prikazovanje in spremljanje zastojev deluje in kakšne tipe proizvodnih poroil imamo na voljo se osredotoimo na realizacijo avtomatskega zajema podatkov v LEK farmacevtski družbi. Projekt avtomatskega zajemanja podatkov se bo pri nas odvijal kot pilotni projekt in ga bomo ob dobrih rezultatih nadgradili na celotno podroje. Vsekakor je pri tem potrebno imeti v mislih, da konna uvedba temelji na dejstvu, da bo tudi uporabnik s celotnim okoljem zadovljen. Ozirajo se k cliju bi lahko prihajajoi projekt v grobem razdelili v naslednje faze, ki bi bile v našem primeru potrebne za zaetek pilotnega projekta: poiskati primernega dobavitelja doloiti linijo za nadgradnjo zasnova inštalacije kvalifikacije dobavitelja podati plan testiranja za kvalifikacijo obratovanja zasnovanega v podjetju in ga uskladiti z zunanjim dobaviteljem pridobiti signale proizvajalca stroja, ter potrebna orodja za komunikacijo s SCADO pridobiti funkcijsko specifikacijo delovanja sistema detekcije zastojev, ter uporabniška navodila za administracijo sistema, pri emer upoštevamo veljavne standarde podjetja v vezi s strojno in aplikativno opremo faza testiranja analiza uporabe okolja uporabnika poroilo Še preden se lotimo projekta moramo še enkrat poudariti, da bomo poroila v produkcijskem okolju prilagali kot poroila v okviru analize ob koncu izmene. V primeru, da bo prehod na produkcijsko okolje odobren se bodo upoštevali asi zaustavitve linije, ne pa tudi štetje proizvedenih koliin. Pomembno je, kako izberemo linijo za nadgradnjo. Lahko jo izbiramo po naslednjih lastnostih: po slabih rezultatih poslovanja po enostavni nadgraditvi po starosti stroja vkljuevanje v ostale projekte Vse zgoraj naštete toke so zelo pomembne za nadaljne korake. Najbolj pravilen pristop k realizaciji je vodstvo, ki predlaga linijo za aktualno nadgradnjo, saj je najbolj obvešeno o poteku nadaljnih projektov v podjetju. Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 50 od 78

57 10.1 STANJE STROJA PRED NADGRADNJO Stroj, ki je predviden za nadgradnjo je primeren za toplo oblikovanje PVC, Aclar folije in za hladno oblikovanje aluminijaste folije. Dodajanje izdelka, tablet, dražejev in kapsul je avtomatsko, kot tudi kontrola oblike barve in prisotnosti izdelka v konnem izdelku. Ker ima izbrana pakirna linija dokaj nov stroj, v našem primeru ni potrebno dograjevati fotocelic in krmilja za zajem in podatkov. Sodobna tehnologija nam v tem primeru že omogoa izpis napake na zaslonu stroja. Za nas to pomeni, da so napake že klasificirane in da jih je potrebno le še pripeljati v informacijski sistem. Slika 14: Simbolna slika prikaza stroja na pakirni liniji Zaradi zaupnosti podatkov o stroju lahko le na grob nain predstavim funkcije na zaslonu stroja, ki jih prikazuje naslednja tabela: Uporabnik Prijava, lzbira jezika in menjava gesla Proizvodnja Sledljivost dogodkov in diagnostika Stroj Prikaz in sprememba nastavljivih vrednosti na postajah. Izvršitev nastavljenih parametrov in prikaz informacij sistema. Nastavitev stroja in funkcijsko orientiranih operacij stroja. Prikaz pomembnih vrednosti procesa Igor Koselj: Avtomatski prenos podatkov preko SCADE v poslovni informacijski sistem Stran 51 od 78