• Rezultati Niso Bili Najdeni

Sistemzazbiranje,prikazinanalizopodatkovoproizvodnemprocesu AmbroˇzJanc

N/A
N/A
Protected

Academic year: 2022

Share "Sistemzazbiranje,prikazinanalizopodatkovoproizvodnemprocesu AmbroˇzJanc"

Copied!
65
0
0

Celotno besedilo

(1)

Univerza v Ljubljani

Fakulteta za raˇ cunalniˇ stvo in informatiko

Ambroˇz Janc

Sistem za zbiranje, prikaz in analizo podatkov o proizvodnem procesu

DIPLOMSKO DELO

UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE

RA ˇCUNALNIˇSTVO IN INFORMATIKA

Mentor : izr. prof. dr. Uroˇs Lotriˇ c

Ljubljana, 2021

(2)

besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.

Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/

licenses/.

Besedilo je oblikovano z urejevalnikom besedil LATEX.

(3)

Kandidat: Ambroˇz Janc

Naslov: Sistem za zbiranje, prikaz in analizo podatkov o proizvodnem pro- cesu

Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika

Mentor: izr. prof. dr. Uroˇs Lotriˇc

Opis:

Razvijte sistem za zbiranje in prikaz podatkov o industrijskem procesu, ki uporabnikom pomaga pri upravljanju z energijo po priporoˇcilih standarda ISO 50001. Sistem zasnujte kot aplikacijo odjemalec – streˇznik, ki preko protokola OPC UA bere ˇzelene podatke iz industrijskega krmilnika in jih v obliki ustreznih diagramov prikazuje uporabniku.

Title: Production process data acquisition, visualization, and analysis sy- stem

Description:

Develop a production process data acquisition, visualization, and analysis sy- stem, that follows energy management according to the guidelines presented in the ISO 50001 standard. Design the system in a client-server architecture that collects data from an industrial controller, using the OPC UA protocol, and displays collected data in the form of appropriate diagrams.

(4)
(5)

Kazalo

Povzetek Abstract

1 Uvod 1

2 Standard ISO 50001: Upravljanje z energijo 5

3 Opis proizvodnega procesa 9

4 Uporabljene tehnologije 13

4.1 Python . . . 13

4.2 OPC UA . . . 13

4.3 React . . . 14

4.4 Django . . . 14

4.5 SQLite . . . 15

5 Predstavitev izdelanega sistema 17 5.1 Sistem kot reˇsitev za standard ISO 50001 . . . 17

5.2 Struktura sistema . . . 21

5.3 Branje podatkov iz industrijskega krmilnika . . . 22

5.4 Zaledni del . . . 24 5.5 Celni del . . . .ˇ 32

6 Zakljuˇcek 51

(6)
(7)

Povzetek

Naslov: Sistem za zbiranje, prikaz in analizo podatkov o proizvodnem pro- cesu

Avtor: Ambroˇz Janc

V danaˇsnjem ˇcasu je vedno veˇcja potreba po sistemih, s katerimi se lahko shrani, nadzoruje in analizira podatke v proizvodnem procesu. Naraˇsˇca ˇzelja po ˇcim veˇcji energetski uˇcinkovitosti, naj bo to zaradi okoljevarstvenih ali ekonomskih razlogov. V nalogi razvijemo sistem, ki zbira in prikazuje po- datke uporabniku tako, da si uporabnik z njimi pomaga razbrati najveˇcje po- rabe energentov. Zato sistem razvijemo po priporoˇcilih standarda ISO 50001.

Standard ISO 50001 je mednarodno priznan standard, ki je namenjen izdelavi upravljalnega ogrodja, ki organizacijam pomaga doseˇci energijske cilje.

Sistema ima strukturo odjemalec-streˇznik, kjer streˇzniˇski del aplikacije bere podatke iz senzorjev industrijskih krmilnikov v podatkovno bazo. Od- jemalski del sistema te podatke s klici na streˇzniˇski del sistema pridobi iz podatkovne baze in jih prikazuje na uporabniku prijazen naˇcin.

Kljuˇcne besede: ISO 50001, proizvodni proces, zbiranje in analiza podat- kov, programiranje spletnih aplikacij.

(8)
(9)

Abstract

Title: System for acquisition, visualization, and analysis of production pro- cess data

Author: Ambroˇz Janc

Nowadays, the demand for systems that can store, control, and analyze pro- duction process data increases. Moreover, lately, the need for energy effi- ciency is rising, may that be for environmental or economic reasons. This thesis aims to develop a system that collects and displays data to a user and helps him focus on the largest energy consumers. That is why we design the system according to the ISO 50001 standard. ISO 50001 is an internationally recognized standard and provides guidelines to organizations for constructing a management framework for achieving energy goals.

The system is a client-server application, where the server-side reads data from sensors connected to industrial controllers and store it in a database.

Then, using calls to the server-side, the client-side reads data from the database and displays it user-friendly.

Keywords: ISO 50001, production process, data acquisition and analysis, web development.

(10)
(11)

Poglavje 1 Uvod

Nadzorni sistemi so v pomoˇc operaterjem, da laˇzje in bolj uˇcinkovito sledijo delovanju strojev in ukrepajo ob potencialnih nevarnostih. Z nadzornimi sistemi lahko sledimo produktivnosti delavcev in strojev in tako hitro ugo- tovimo kako ukrepati, da optimiziramo poslovanje. Danes pa ozaveˇsˇcenost o onesnaˇzenju okolja raste in takˇsni sistemi so lahko zelo uporabni pri sledenju okoljskega odtisa podjetja ali tovarne.

Tovarne so eden najveˇcjih onesnaˇzevalcev okolja, saj je pribliˇzno tretjina vse porabe energije in emisij CO2 na svetu pripisana industriji [28]. Ravno zaradi tega je leta 2011 ISO razvil standard ISO 50001 - Upravljanje z energijo [12], ki organizacijam pomaga zmanjˇsati porabo energije. Ta standard temelji na ISO 9001 - Sistem vodenja kakovosti [13] in ISO 14001 - Sistem ravnanja z okoljem [11]. Zaradi kombinacije uvajanja veˇcje kakovosti in bolj ekoloˇsko usmerjene proizvodnje standard ISO 50001 uporablja vse veˇc organizacij.

V tej diplomski nalogi se ukvarjamo z zbiranjem in prikazom podatkov o zraˇcnem pretoku in porabi elektriˇcne energije industrijskega sistema. S temi podatki bomo lahko razumeli, kdaj ima sistem veˇcjo porabo in kdaj manjˇso.

Potencialno se bo iz teh podatkov dalo tudi videti, kdaj je nekaj na stroju pokvarjeno ali narobe deluje.

Podoben ˇze obstojeˇc sistemSiemens Mindsphere [19], je sicer deloma za- stonjska aplikacija. Siemens Mindsphere je orodje, ki uporabnikom omogoˇca,

1

(12)

da preko oblaˇcnih storitev poveˇzejo svoj obstojeˇc sistem za zbiranje podatkov in spletno aplikacijo za vizualizacijo zbranih podatkov. Te spletne aplikacije lahko uporabnik razvije sam v poljubnem programskem jeziku ali pa jih raz- vija kar na vmesniku Siemens Mindsphere. Slabost Siemens Mindsphere je ravno v tem, da priˇcakuje, da ima uporabnik ˇze izdelan sistem za zbiranje in shranjevanje podatkov, preko katerega lahko dostopa do podatkov svojega proizvodnega procesa. To teˇzavo bomo z naˇsim sistemom reˇsili, saj bo sistem celosten in enostavno prenosljiv. Organizacije si velikokrat ˇzelijo sistem, ki je povsem lokalen in ne potrebuje komunikacije z zunanjim svetom za svoje delovanje. Tak sistem bomo v razvili v okviru naloge. Vendar vseeno ˇzelimo omogoˇciti komunikacijo podatkov izven sistema, zato bomo zaledni del sis- tema razvili tako, da bodo podatki dostopni tudi za odjemalce, ki niso del sistema.

Enostavnejˇsi sistem so implementirali v [15], kjer pa so imeli dovolj velik zaslon, da so lahko vse vizualizacije in analize prikazali na enem prikazu, kjer je lahko teˇzavno izluˇsˇciti pomembne informacije. Avtorji so izdelali tudi zaledni del sistema, ki komunicira z strankinim streˇznikom in ˇcelnim delom sistema. Glede naˇcina naˇsih prikazov si bomo malo pomagali z njihovim iz- delkom, vendar ˇzelimo v naˇsem sistemu prikaz podatkov ˇse izboljˇsati. ˇZelimo se osredotoˇciti bolj na to, da so glavni podatki, ki jih mora uporabnik videti, zlahka vidni in na prikazu izstopajo.

V doktorskem delu [5], avtorica navede nekaj primerov aplikacij za vizu- alizacijo podatkov, ki jih je izdelala med svojimi raziskavami. Te aplikacije so podobne naˇsim, saj se veˇcinom ukvarjajo s sledenjem porabe energije v upanju na izboljˇsave. Pri teh aplikacijah je spet ista teˇzava, kot pri Siemens Mindsphere in to je, da te aplikacije priˇcakujejo ˇze obstojeˇc sistem za zbiranje podatkov.

V delu najprej opiˇsemo standard ISO 50001, njegov namen in uˇcinek na industrijo ter okolje. Potem opiˇsemo proizvodni proces, za katerega smo izdelali sistem. V poglavju 4 opiˇsemo tehnologije, ki smo jih uporabili za izvedbo sistema. Poglavje 5 pa je namenjeno opisu celotnega sistema, kako

(13)

Diplomska naloga 3 zadostuje standardu ISO 50001, njegovo delovanje in struktura.

(14)
(15)

Poglavje 2

Standard ISO 50001:

Upravljanje z energijo

Namen standarda je omogoˇciti organizacijam, da vzpostavijo sisteme in pro- cese, potrebne za nenehno izboljˇsevanje energetske uˇcinkovitosti, vkljuˇcno z energijsko uˇcinkovitostjo ter rabo in porabo energije [31]. Standard oprede- ljuje zahteve za sistem upravljanja organizacije z energijo in doloˇca zahteve za sistematiˇcen, na podatkih in dejstvih temeljeˇc proces, osredinjen na nenehno izboljˇsevanje energetske uˇcinkovitosti. Standard je namenjen izboljˇsevanju energetske uˇcinkovitosti celotnih organizacij, kar pomeni da zaobjame celo- tno organizacijo in njeno delovanje, ne le nekega industrijskega obrata.

Standard pravi, da mora organizacija izbrati osebo ali skupino oseb, ki so odgovorni za delovanje in izboljˇsevanje sistema za upravljanje z energijo. Od- govorne osebe skupaj z vodstvom organizacije in ekipo energetskih strokov- njakov ustvarijo energetsko politiko, ki zaobjema najboljˇsi pristop za identifi- kacijo, zajem in sledenje energijske porabe. Energetska politika je dinamiˇcen dokument, ki ga je treba redno pregledovati in po potrebi prilagoditi spre- minjanju organizacije. Vkljuˇcevati mora: definicijo obsega in mej sistema za upravljanje z energijo, zavezo sprotnim izboljˇsavam, identifikacijo energijskih indikatorjev in definicijo energetskih ciljev.

Organizacija mora redno izvajati energetski pregled kjer mora odgovorna 5

(16)

oseba preveriti zbrane podatke zadnjega meseca/leta in iz teh podatkov doloˇciti veˇcje porabnike energije v organizaciji. Med pregledom se mora tudi identificirati potencialne nove ukrepe za varˇcevanje z energijo, napake v sistemu in prevelike porabe energije zaradi napak v sistemu.

Organizacija mora identificirati najbolj pomembne energijske indikatorje, s katerimi lahko odgovorne osebe potem doloˇcijo anomalije v sistemu in poiˇsˇcejo veˇcje porabnike energije. Primeri energijskih indikatorjev so: poraba energije na izdelek, poraba energije na uro, poraba energije na kvadratni me- ter. Ko so energijski indikatorji doloˇceni, morajo biti podatki o njih dostopni po celotni organizaciji, dostop je lahko omogoˇcen preko e-poˇste, aplikacije ali spletnega portala (odvisno od strukture organizacije).

Standard doloˇca tudi nam najbolj pomemben del, nadzor, merjenje in analizo energijskih indikatorjev v sistemu za upravljanje z energijo. Po standardu mora organizacija definirati in periodiˇcno pregledati meritvene potrebe. Kljuˇcne karakteristike njenega delovanja, ki doloˇcajo energijsko uˇcinkovitost, morajo biti nadzorovane, merjene in analizirane v naˇcrtovanih intervalih. Takˇsne karakteristike so: veˇcji porabniki energije in ostali rezul- tati energijskega pregleda, pomembne spremenljivke, ki so lahko povezane s porabniki energije, energijski indikatorji, primerjava priˇcakovane energijske porabe z dejansko in efektivnost naˇcrta. Za ta namen mora organizacija na lokaciji namestiti merilnike porabe energije in informacijski sistem za upra- vljanje z energijo (angl. Energy Management Information System EMIS).

EMIS je med drugim portal, na katerem morajo biti prikazani podatki za porabo energije, energijsko uˇcinkovitost in potencialni prihranki. Podatki morajo biti posodobljeni v 15 minutnih intervalih, da lahko operaterji vi- dijo trenutno stanjje sistema, ti podatki morajo biti dostopni ves ˇcas. Iz teh podatkov mora EMIS generirati poroˇcila, ki jih odgovorne osebe potem pregledajo in uporabijo pri energijskem pregledu. Iz teh poroˇcil se morajo videti priloˇznosti za izboljˇsave energijske uˇcinkovitosti.

Sistem upravljanja z energijo, opisan v standardu, temelji na metodo- logiji nenehnega izboljˇsevanja imenovani planiraj-izvedi-preveri-ukrepaj, ki

(17)

Diplomska naloga 7 upravljanje z energijo vkljuˇcuje v obstojeˇco prakso organizacije.

Prvi korak cikla, imenovan planiraj, je namenjen razumevanju konte- ksta organizacije, vzpostavljanju energetske politike in ustanovitvi skupine za upravljanje z energijo. Organizacija mora razmisliti o ukrepih za obrav- navanje tveganj in priloˇznosti, izvesti energetske preglede in identificirati pomembne rabe energije (energijske indikatorje, angl. energy performance indicator, EnPI) [6]. Poleg tega je potrebno doloˇciti sploˇsne in energetske cilje ter akcijske plane, potrebne za doseganje rezultatov, ki bodo izboljˇsali energetsko uˇcinkovitost v skladu z energetsko politiko organizacije.

V koraku izvedi mora organizacija izvajati akcijske plane, ukrepe za de- lovanje in vzdrˇzevanje ter komuniciranje. Zagotoviti mora kompetentnost in razmisliti o energetski uˇcinkovitosti pri snovanju in naroˇcanju.

V koraku preveri mora organizacija nadzorovati, meriti, analizirati, vre- dnotiti in izvesti vodstveni pregled energetske uˇcinkovitosti in sistema za upravljanje z energijo (angl. energy management system, EnMS).

V koraku ukrepaj mora organizacija ukrepati za odpravo neskladnosti ter za nenehno izboljˇsevanje energetske uˇcinkovitosti in sistema za upravljanje z energijo.

(18)
(19)

Poglavje 3

Opis proizvodnega procesa

Namen proizvodnega procesa je pravilno razvrstiti in ˇcasovno optimalno zloˇziti izdelke na palete na izhodnih mestih. Proizvodni proces je prilagojen za dva razliˇcna izdelka, ki jih mora loˇciti in zloˇziti na palete, tako da so na paleti le izdelki istega tipa.

V proizvodnem procesu sta dve vstopni (oznaka ’A’ na sliki 3.1) in tri izstopne toˇcke, ena od izstopnih toˇck (oznaka ’C’ na sliki 3.1) uporablja drug tip palet, kot ostali dve (oznaka ’B’ na sliki 3.1). Celoten proizvodni proces je iz varnostnih razlogov omejen z varnostno ograjo in se ob vstopu ˇcloveka v nevarno obmoˇcjo ustavi.

9

(20)

Slika 3.1: Proizvodni proces

Zlaganje opravlja robotska roka (oznaka ’D’ na sliki 3.1), ki poleg pre- laganja izdelkov skrbi tudi za zalogo palet na dveh izstopnih toˇckah. Pred vstopnimi toˇckami se z uporabo fotocelic doloˇci vrsta paketa. Stroj se nato glede na trenutno stanje odloˇci, na katero od vstopnih toˇck bo paket poslal.

Ko se ena od vstopnih toˇck dovolj napolni, robot iz nje pobere izdelke in jih odloˇzi na pravilno mesto. Ko je na neki izstopni toˇcki paleta polna, se ta odpelje ven iz obmoˇcja delovanja na mesto, kjer jo delavec z viliˇcarjem odpelje v skladiˇsˇce.

V elektro omari, ki cel proces oskrbuje z elektriˇcno energijo, je nameˇsˇcen merilec elektriˇcne energije, ki iz meritev toka in napetosti na vseh treh fazah [7] izraˇcuna porabo elektriˇcne energije. Iz tega merilca bomo sledili vsem vrednostim, ki nam jih ponuja. Ker ima proces veliko pnevmatskih elemen-

(21)

Diplomska naloga 11 tov, na primer robotska glava, letve za uravnavanje palet na valjˇcnicah in ustavljalec paketov, smo med glavni dovod zraka in stroj montirali merilec zraˇcnega pretoka.

Celoten proizvodni proces je krmiljen z industrijskim krmilnikom [1], do katerega je neposredna povezava do obeh merilnikov. To velja za vse dele procesa razen za robota, ki ima svoj krmilnik, ki mu industrijski krmilnik poˇsilja signale o stanju proizvodnega procesa. Robot se glede na vsebino signalov odloˇci o svojem naslednjem dejanju. Na industrijskem krmilniku shranimo prebrane podatke in jih pretvorimo v obliko, primerno za branje.

(22)
(23)

Poglavje 4

Uporabljene tehnologije

V tem poglavju opiˇsemo tehnologije, ki smo jih uporabili v tej diplomski nalogi. Za razvoj takih sistemov obstaja veliko razliˇcnih tehnologij in orodij, ki bi jih lahko uporabili. Zato smo pred zaˇcetkom dela pregledali veliko moˇznosti in se odloˇcili za tiste, ki so najbolj primerne za naˇs sistem in s katerimi ˇze imamo izkuˇsnje.

4.1 Python

Python [24] je interpretni visokoravni veˇcnamenski programski jezik, ki ga je ustvaril Guido van Rossum leta 1990. Nastal je v okviru odprtokodnega projekta, ki ga upravlja neprofitna organizacija Python Software Foundation.

Ravno zaradi svojega naˇcina dela s podatkovnimi tipi in odprtokodne narave, ima Python veliko podporo knjiˇznic za delo z razliˇcnimi tehnologijami, zaradi ˇcesar je zadnje ˇcase zelo popularen.

Python smo uporabili za programiranje zalednega dela sistema.

4.2 OPC UA

OPC UA [21] je ogrodje neodvisno od platforme, ki je namenjeno za varno komunikacijo med streˇznikom in odjemalcem. Pri razvoju OPC UA so se

13

(24)

zgledovali po OPC Classic [22], ki zdruˇzuje veˇc razliˇcnih protokolov za ko- munikacijo med streˇznikom in odjemalcem. OPC UA funkcionalnosti vseh protokolov zdruˇzi v en sam protokol. OPC Classic je bil zelo popularen, ravno zaradi zahtev industrije po nadzornih sistemih, saj je poenostavil ko- munikacijo z njimi. Z razvojem ostale tehnologije se je pojavila potreba po izboljˇsanju protokola komunikacije. Zato so razvili OPC UA, ki podpira vse funkcionalnosti OPC Classic. Poleg vsega kar so zmoˇzni protokoli OPC Clas- sic, je pri OPC UA izboljˇsana varnost komunikacije, dodana moˇznost iskanja streˇznikov OPC v omreˇzju in moˇznost izvajanja programov na streˇzniku.

Protokol OPC UA smo uporabili za komunikacijo med naˇsim sistemom in industrijskim krmilnikom proizvodnega procesa.

4.3 React

React [26] je knjiˇznica Javascript [14] namenjena gradnji uporabniˇskih vme- snikov. React uporablja komponentni sistem, kjer lahko programer doloˇci svoje komponente (kot razrede v Javi), ki jim potem dinamiˇcno spremi- nja stanje in prikaz v brskalniku. React ima, tako kot Javascript, na voljo mnoˇzico knjiˇznic. To je eden od razlogov, da smo ga izbrali.

Celni del sistema smo naˇˇ crtovali kot spletno aplikacijo, zato smo za pro- gramiranje ˇcelnega dela izbrali React.

4.4 Django

Django [3] je ogrodje napisano v jeziku Python, ki je sicer namenjeno izdelavi spletnih strani in temelji na arhitekturi MVC [20]. Obstaja tudi knjiˇznica django-rest-framework [4] za izdelavo vmesnikov Rest API (angl. Application Programming Interface) [27] z ogrodjem Django, ki jo bomo uporabili mi.

Knjiˇznica omogoˇca poenostavljeno delo s podatkovnimi bazami, definicijo modelov in definicijo dostopnih toˇck streˇznika Rest API.

Django smo uporabili za programiranje zalednega dela sistema in z upo-

(25)

Diplomska naloga 15 rabo knjiˇznice django-rest-framework izdelali strukturo zalednega dela in po- datkovne baze.

4.5 SQLite

SQLite [29] je ena najbolj uporabljenih podatkovnih baz, uporabljena je v mobilnih napravah in veˇcini raˇcunalniˇskih sistemov. Je stabilna in medplat- formna tehnologija. SQLite svojo bazo in vse podatke o njej shrani v eno samo datoteko, tako je baza izjemno prenosljiva. V teoriji podpira velikosti podatkovne baze do 281 TB [18].

Podatkovno bazo SQLite bomo uporabili za naˇs sistem, saj je povezava med SQLite in Djangom zelo enostavna, poleg tega ˇzelimo, da je v sistemu uporabljena podatkovna baza, ki za opravljanje svoje naloge ne potrebuje dodatnih procesov.

(26)
(27)

Poglavje 5

Predstavitev izdelanega sistema

5.1 Sistem kot reˇ sitev za standard ISO 50001

Za proizvodni proces, opisan v poglavju 3, smo po standardu ISO 50001 doloˇcili energijske indikatorje, s katerimi lahko doloˇcimo energijsko uˇcinkovitost celotnega procesa. Doloˇcili smo dva glavna energijska indikatorja: porabo elektriˇcne energije v kWh in porabo zraka v litrih na minuto. Ker pa merilne naprave ponujajo veliko podatkov, ki jih je ˇskoda zavreˇci, smo se odloˇcili doloˇciti ˇse dodatne, manj pomembne indikatorje, s katerimi bomo ˇse doda- tno lahko doloˇcili uˇcinkovitost delovanja procesa. Zraˇcni merilec nam ponuja indikatorje o porabi zraka v litrih na sekundo, litrih na uro in kubiˇcnih metrih (m3). Za boljˇse razumevanje porabe elektriˇcne energije uporabimo ˇse meritve napetosti v voltih (tu se na posamezni fazi priˇcakuje napetost okoli 230 V) in toka v amperih na vseh fazah elektriˇcnega napajanja. Poleg tega se meri tudi napetost med fazami, kjer se na posamezni povezavi priˇcakuje napetost okoli 400 V. V sistem smo dodali tudi moˇznost doloˇcanja poljubnih indikatorjev, kar pomeni, da lahko uporabnik vnese ime indikatorja, katerega podatke ˇzeli brati iz industrijskega krmilnika, na primer hitrost motorja, pozicijo robotske roke, trenutno ˇstevilo izdelkov na paleti.

S takˇsnimi indikatorji lahko odgovorna oseba hitro doloˇci anomalije v sistemu, ko ugotovi da je vrednost na nekem indikatorju veˇcja ali manjˇsa

17

(28)

kot bi morala biti. Za ˇse hitrejˇso identifikacijo napak smo v sistem dodali tudi moˇznost doloˇcanja zgornjih in spodnjih mej za posamezni indikator. Da sistem zadostuje standardu ISO 50001 (veˇc o ostalih zahtevah standarda in o tem, kako smo jim zadovoljili, v poglavju 5.5) smo v sistem dodali tudi poˇsiljanje dnevnih poroˇcil. Poroˇcila se generirajo vsak dan in se poˇsljejo na elektronske naslove, ki jih definira uporabnik. V poroˇcila za posame- zni indikator zapiˇsemo zadnjo prebrano vrednost, povpreˇcje zadnjega dneva, najveˇcjo prebrano vrednost zadnjega dneva in najmanjˇso prebrano vrednost zadnjega dneva (sliki 5.1 in 5.2).

Slika 5.1: Primer dnevnega poroˇcila

(29)

Diplomska naloga 19

Slika 5.2: Primer dnevnega poroˇcila v datoteki json

V poroˇcila vkljuˇcimo tudi indikatorje, ki jih uporabniki v aplikaciji defini- rajo sami. Uporabnik na definirane elektronske naslove v dnevnem poroˇcilu dobi elektronsko poˇsto, ki vsebuje zadnjo prebrano vrednost, povpreˇcje za indikator za zadnjih 24 ur ter najveˇcjo in najmanjˇso prebrano vrednost v za- dnjih 24 urah. Te podatke zapiˇsemo v elektronsko sporoˇcilo kot besedilo in jih posebej zapiˇsemo tudi v datoteko json. ˇCe je prebrana vrednost kdaj izven definiranih meja, bo sistem poslal poroˇcilo (slika 5.3) o preseˇzenih mejah na elektronske naslove, ki jih doloˇci uporabnik v aplikaciji.

(30)

Slika 5.3: Primer poroˇcila o preseˇzenih mejah

Ugotovili smo tudi, da lahko anomalija porabe energije nastane, kadar industrijski krmilnik pade v napako, kar lahko ovira delovanje proizvodnega procesa. Zato smo doloˇcili tudi zbiranje podatkov o trenutnih napakah na industrijskem krmilniku. Tako lahko vidimo, ˇce je bila anomalija v porabi energije povzroˇcena zaradi napake v delovanju sistema.

Na industrijskem krmilniku smo vkljuˇcili streˇznik OPC UA, ki ima ves ˇcas odprta vrata (angl. port), na katera se lahko z odjemalcem OPC UA poveˇzemo in preberemo podatke o indikatorjih. V sistemu deluje proces, ki vsakih 10 sekund poˇslje zahtevo industrijskemu krmilniku po podatkih, pridobljene podatke pa potem shrani v podatkovno bazo, iz katere jih lahko z zalednim delom sistema beremo in streˇzemo odjemalcem v omreˇzju. ˇCelni del sistema v 10 sekundnih intervalih poˇsilja zahteve po podatkih na zaledni del sistema, ki zahtevane podatke posreduje ˇcelnemu delu sistema. Na ˇcelnem delu sistema moramo pred prikazom podatkov v brskalniku te podatke ˇse procesirati na razliˇcne naˇcine, saj se isti podatki uporabijo na veˇc razliˇcnih prikazih, z razliˇcnimi nameni. Veˇc in bolj natanˇcno o delovanju sistema v naslednjih poglavjih.

(31)

Diplomska naloga 21

5.2 Struktura sistema

Izdelani sistem ima pet pomembnih gradnikov: spletno aplikacijo, streˇznik REST API, branje podatkov iz industrijskega krmilnika, industrijski krmilnik s streˇznikom OPC UA in podatkovno bazo SQLite (prikazano na sliki 5.4).

Slika 5.4: Struktura izdelanega sistema

Spletna aplikacija (ˇcelni del izdelanega sistema) prikazuje tenutno shra- njene podatke v podatkovni bazi, te podatke pridobi z zahtevami na streˇznik REST API. V spletni aplikaciji pridobljene podatke procesiramo in jih pri- pravimo v obliko primerno za prikaz. Streˇznik REST API (zaledni del izdela- nega sistema) je namenjen komunikaciji med ostalimi procesi in podatkovno bazo. Na streˇznik iz ostalih procesov poˇsiljamo zahteve po podatkih ali pa poˇsljemo podatke, ki jih ˇzelimo shraniti v podatkovno bazo. Te zahteve

(32)

streˇznik procesira in posreduje podatkovni bazi. Ob konˇcani operaciji od- jemalcu sporoˇci stanje (uspeh, napaka) zahteve in zraven po potrebi poˇslje podatke. Industrijski krmilnik ima definiran streˇznik OPC UA, preko kate- rega lahko odjemalci OPC UA dostopajo do podatkov o spremenljivkah in stanju industrijskega krmilnika. Tako tudi beremo podatke iz industrijskega krmilnika. Na lokalni raˇcunalniˇski sistem smo namestili proces, ki ustvari odjemalca OPC UA, preko katerega poˇsilja zahteve na streˇznik OPC UA na industrijskem krmilniku. Podatke prebrane iz industrijskega krmilnika nato posreduje streˇzniku REST API, ki jih shrani v podatkovno bazo. Podatkovna baza SQLite je namenjena hranjenju podatkov, ki jih pridobimo iz industrij- skega krmilnika. Podatkovna baza direktno komunicira le s streˇznikom REST API, ko streˇznik od drugje dobi zahtevo po podatkih ali po hrambi podatkov.

5.3 Branje podatkov iz industrijskega krmil- nika

Na raˇcunalniˇski sistem, ki streˇze naˇs sistem, smo namestili dodaten proces, s katerim preko protokola OPC UA beremo podatke iz industrijskega kr- milnika. Ta proces je sestavljen iz dveh delov. Prvi del je tudi glavni del njegovega toka in je namenjen branju osnovnih podatkov o energijskih indika- torjih, omenjenih v prejˇsnem poglavju. Proces se vsakih 10 sekund s pomoˇcjo protokola OPC UA poveˇze na industrijski krmilnik, prebere zahtevane po- datke in jih poˇslje zalednemu delu aplikacije, da se shranijo v podatkovno bazo.

Drugi del procesa je namenjen branju podatkov o napakah na industrij- skem krmilniku. Ker pa se napake dogajajo bolj redko, bi bilo preveˇc po- troˇsno, da bi vsakih 10 sekund brali podatke o njih, saj se veˇcino ˇcasa ne bi niˇc spremenilo. Zato smo ta del izvedli tako, da proces najprej ustvari dve niti (angl. thread): eno za opozorila (angl. warning) in eno za napake (angl.

error). Te niti izvajajo kodo, ki ustvari odjemalca OPC UA, se poveˇze na industrijski krmilnik in ustvari naroˇcnino (angl. subscription) na spremembe

(33)

Diplomska naloga 23 o napakah ali opozorilih. Ko je takˇsna naroˇcnina ustvarjena, streˇznik OPC UA, nameˇsˇcen na industrijskem krmilniku, poˇslje na odjemalca obvestilo o spremembi spremenljivke, na katero se je odjemalec naroˇcil. V tem obve- stilu poˇslje podatke o imenu spremenljivke, njeni vrednosti in pa dodatno strukturo, z mogoˇcimi pomembnimi podatki. Za lovljenje takˇsnih obvestil smo na odjemalcu definirali posebno funkcijo, ki obvestilo ujame in izluˇsˇci podatke, ki so nam pomembni. Ker nas v tem primeru ne zanima le kdaj se je neka napaka sproˇzila, ampak tudi koliko ˇcasa je trajala (le tako bomo lahko toˇcno doloˇcili, da je bila napaka kriva za anomalijo v sistemu), smo definirali ˇse seznam, v katerem sledimo trenutno aktivnim napakam. Tako napako ob prvi pojavitvi shranimo v seznam skupaj s ˇcasom pojavitve. Ko je bila odpravljena, jo poiˇsˇcemo v seznamu ter poˇsljemo podatke o napaki in intervalu trajanja napake na zaledni del aplikacije. Zaledni del podatke potem shrani v podatkovno bazo.

Niti teˇceta v ozadju. Za takˇsno izvedbo smo se odloˇcili, ker proces, na katerem teˇce odjemalec OPC UA in je naroˇcen na spremembe na streˇzniku OPC UA, zgolj ˇcaka na obvestila o spremembah streˇznika in ne more opra- vljati ostalih operacij. Poleg tega je takˇsna izvedba raˇcunsko bolj efektivna.

Obstaja pa tudi nevarnost, da se zgodi plaz napak. To se zgodi, ko se sproˇzi neka napaka, ki povrzoˇci veliko drugih napak. To bi lahko naˇs proces preo- bremenilo z obvestili in ustavilo njegov glavni tok. Kar pa ne smemo dovoliti, ˇce ˇzelimo, da sistem deluje pravilno. Tu se potem pojavi tudi vpraˇsanje ana- lize napak, ko ˇzelimo doloˇciti, katera napaka je povzroˇcila plaz in zakaj. Pri takˇsni analizi lahko naˇs sistem pomaga, saj se iz intervalov proˇzenja napak lahko vidi, katera napaka je zaˇcela plaz. Takˇsna analiza se imenuje analiza temeljnih vzrokov delovanja (angl. root cause analysis) [23]. Analiza je izven obsega diplomskega dela.

(34)

5.4 Zaledni del

Zaledni del sistema obsega podatkovno bazo, v kateri shranjujemo vse po- datke in pa streˇznik REST API, namenjen komunikaciji med podatkovno bazo in ˇcelnim delom sistema ali ostalimi potencialnimi odjemalci.

5.4.1 Podatkovna baza

Struktura podatkovne baze je dokaj enostavna, saj so vsi energijski indika- torji zgolj ˇstevila, kar pomeni, da v podatkovno bazo shranjujemo ˇstevila in ˇcasovne oznake branja podatkov. V podatkovni bazi imamo osem entitet.

Entiteta electricmeterdata (slika 5.5) vsebuje podatke o drugem od dveh glavnih energijskih indikatorjev: porabi elektriˇcne energije v kilovatnih urah (kWh), poleg tega pa vsebuje ˇse podatke o ostalih manj pomembnih ener- gijskih indikatorjih, ki pomagajo bolje razumeti porabo elektriˇcne energije:

napetost na vsaki izmed treh faz, napetost med vsemi kombinacijami treh faz in tok na vsaki fazi. Vsak zapis v tej tabeli ima tudi ˇcasovno oznako trenutka branja podatkov iz industrijskega krmilnika.

Slika 5.5: Entiteta electricmeterdata

(35)

Diplomska naloga 25 Entiteta airflowdata (slika 5.6) vsebuje podatke o enem od dveh glavnih energijskih indikatorjev: porabi zraka v litrih na minuto in pa ostalih manj pomembnih energijskih indikatorjih, ki se tiˇcejo porabe zraka: poraba zraka v litrih na sekundo, litrih na uro in kubiˇcnih metrih (m3). Vsak zapis v tej tabeli ima tudi ˇcasovno oznako trenutka branja podatkov iz industrijskega krmilnika.

Slika 5.6: Entiteta airflowdata

Entiteta alarm (slika 5.7) vsebuje podatke o napakah proizvodnega pro- cesa: ime napake, ˇcas proˇzenja napake, ˇcas odpravljanja napake in tip na- pake, kjer je tip napake lahko opozorilo (angl. warning) ali napaka (angl.

error).

Slika 5.7: Entiteta alarm

Entitetaemails (slika 5.8) je namenjana shranjevanju elektronskih naslo- vov, na katere iz sistema poˇsiljamo dnevna poroˇcila in morebitna poroˇcila

(36)

o napakah, ta entiteta hrani elektronske naslove in vrednost, ki pove ali je elektronski naslov aktiven ali ne. Sistem bo poroˇcila poˇsiljal le na aktivne elektronske naslove.

Entiteta limit (slika 5.8) je namenjena shranjevanju podatkov o mejah indikatorjev. Uporabnik aplikacije lahko katerikoli indikator omeji z zgornjo in spodnjo mejo, ˇce vrednosti tega indikatorja preseˇzejo to mejo, bo sistem uporabnika na to opozoril z obvestili na uporabniˇskem vmesniku in na elek- tronske naslove v ’emails’ entiteti poslal poroˇcilo o preseganju mej.

Entiteta packages (slika 5.8) vsebuje podatke o trenutnem ˇstevilo prede- lanih izdelkov, te podatke uporabimo, za analizo porabe na enoto uspeˇsno izdelanega izdelka.

Slika 5.8: Entiteteemails, limit in packages

Uporabnik lahko v aplikaciji doloˇci ˇse druge indikatorje, ki jih ˇzeli brati iz industrijskega krmilnika (na primer hitrost motorja, vrednost fotocelice, pozicija robota), zato je smo uvedli entiteto tagstoget (slika 5.9), ki hrani podatke o posameznih indikatorjih. Zapisi v tej entiteti vsebujejo ime indi- katorja v industrijskem krmilniku, aktivnost branja tega indikatorja (ali naj sistem prebere vrednost ali ne), prikazno ime, ki ga uporabnik sam doloˇci in pa enoto, s katero naj bo indikator prikazan v aplikaciji. Poleg tega smo de- finirali ˇse entitetotagsdata (slika 5.9) v kateri so zapisi, ki vsebujejo dejanske prebrane podatke uporabniˇsko definiranih indikatorjev. Zapisi v tej enti- teti vsebujejo ime indikatorja, na katerega se podatki navezujejo, prebrane podatke in ˇcasovno oznako.

(37)

Diplomska naloga 27

Slika 5.9: Entitetitagstoget intagsdata

Entitete v podatkovni bazi med seboj nimajo nobenih relacij, saj njihovi zapisi niso odvisni med sabo. Tako je tudi celotna struktura podatkovne baze poenostavljena.

5.4.2 Streˇ znik REST API

Streˇznik REST API je proces, ki teˇce neodvisno od ostalih delov sistema in mora biti ves ˇcas aktiven. Proces uporablja vrata (angl. port) 8000 na lokal- nem raˇcunalniˇskem sistemu in je tako dostopen iz drugih raˇcunalniˇskih siste- mov v omreˇzju preko naslova IP. S pomoˇcjo knjiˇznice django-rest-framework je streˇznik izdelan po zahtevah in priporoˇcilih izdelave streˇznikov REST API.

Na streˇzniku smo definirali entitetne razrede, ki se uporabljajo v podat- kovni bazi. Tako lahko enostavno spremenimo strukturo podatkovne baze v kodi streˇznika in jo z migracijami posodobimo. Na streˇzniku smo definirali poglede (angl. views), ki so namenjeni komunikaciji streˇznika z zunanjimi odjemalci. Ko odjemalec poˇslje zahtevo po podatkih iz streˇznika, se izvede koda enega izmed teh pogledov in v primeru pravilne zahteve streˇznik poˇslje odgovor s podatki. Za potrebe testiranja smo v poglede, za ustvarjanje novih zapisov v podatkovni bazi, dodali posebno funkcijo, ki preveri ali je v podat- kovni bazi za to entiteto ˇze preveˇc zapisov. V tem primeru bo streˇznik na podatkovno bazo poslal zahtevo o brisanju najstarejˇsega zapisa in ˇsele nato shranil nov zapis v podatkovno bazo.

Podatke na streˇzniku serializiramo (angl. serialization) [17] zato, da se

(38)

potem laˇzje prenesejo do odjemalca, ki je te podatke zahteval. Tu smo se odloˇcili, da serializiramo vse podatke o posameznem modelu (entiteti), ki jih shranjujemo. Lahko bi na primer izvedli serializacijo tako, da bi se serializirali le doloˇceni podatki. Vendar smo podatke shranili v podatkovno bazo zato, da jih lahko beremo iz drugih lokacij. Zato takˇsna delna serializacija ne bi bila logiˇcna. Lahko bi tudi omejili podatke, do katerih lahko dostopa nekdo, ki trenutno ni v naˇsi mreˇzi, in tako dodali dodaten element varnosti podatkov na streˇznik. Vendar je to izven obsega tega diplomskega dela in pa, kot ˇze reˇceno, smo podatke zbrali zato, da se delijo in se da iz njih razbrati uporabne informacije o sistemu.

Vmesnik streˇznika je definiran tako, da ima vsaka entiteta svoj naslov URL, na katerem je dostopna. Ta naslov mora biti oblike:

’{naslov IP streˇznika}:8000/{entiteta}/’. Na ta naslov lahko poˇsljemo le operaciji GET in POST, za branje vseh zapisov in ustvarjanje novega zapisa. Vsaka entiteta pa ima tudi definiran ˇse dodaten naslov URL, za operacije nad posameznimi zapisi v entiteti. Ta naslov mora biti oblike:

’{naslov IP streˇznika}:8000/{entiteta}/{id zapisa}/’. Na posameznih zapisih entitet lahko uporabnik poleg metode GET izvaja tudi metodi DELETE in PUT, za brisanje in posodabljanje zapisa. Za laˇzje razumevanje smo ustvarili grafiˇcne prikaze za posamezne dostopne toˇcke: elektriˇcna energija na sliki 5.10, poraba zraka na sliki 5.11, napake na sliki 5.12, uporabniˇsko definirane meje na sliki 5.13, uporabniˇsko doloˇceni indikatorji na sliki 5.14, podatki uporabniˇsko doloˇcenih indikatorjev na sliki 5.15.

(39)

Diplomska naloga 29

Slika 5.10: REST API dostopna toˇcka za podatke o elektriˇcni energiji

Slika 5.11: REST API dostopna toˇcka za podatke o porabi zraka

(40)

Slika 5.12: REST API dostopna toˇcka za podatke o napakah stroja

Slika 5.13: REST API dostopna toˇcka za podatke o doloˇcenih mejah

(41)

Diplomska naloga 31

Slika 5.14: REST API dostopna toˇcka za podatke o uporabniˇsko doloˇcenih indikatorjih

Slika 5.15: REST API dostopna toˇcka za podatke o podatkih uporabniˇsko doloˇcenih indikatorjev

(42)

Poleg tega smo definirali ˇse posebno dostopno toˇcko za poˇsiljanje poroˇcil na elektronske naslove (slika 5.16), ki je namenjena zgolj za operacije POST, saj ne vraˇca nobenih posebnih podatkov. Ta dostopna toˇcka je dostopna na naslovu URL ’{naslov IP streˇznika}:8000/sendEmail/’ in kot telo zahteve sprejme vsebino poroˇcila, ki ga mora poslati na elektronske naslove.

Slika 5.16: REST API dostopna toˇcka za podatke o elektronskih naslovih

5.5 Celni del ˇ

Celni del sistema bodo najveˇˇ c uporabljali uporabniki sistema in zato mora biti ˇcimbolj enostaven in intuitiven za uporabo. Ker smo ˇzeleli, da je ˇcelni del enostavno dostopen vsem v omreˇzju sistema, smo ga izdelali kot spletno apli- kacijo. Uporabniki lahko dostopajo do aplikacije z uporabo svojega brskal- nika, preko naslova URL ’http://{naslov IP naprave na kateri je nameˇsˇcen sistem}/:3000’.

Ker je ˇcelni del sistema zelo obseˇzen in mora prikazovati veliko podatkov, smo se ga odloˇcili loˇciti na veˇc delov in za vsak del naredili svoj prikaz. V

(43)

Diplomska naloga 33 skladu s standardom ISO 50001 smo glavna energijska indikatorja in njune trenutne podatke prikazali na prvem in glavnem prikazu z imenom Main EnPIs. Podoben prikaz smo naredili tudi za manj pomembne energijske in- dikatorje in ga poimenovaliSecondary EnPIs. Preko prikazovMain EnPIs in Secondary EnPIs lahko uporabnik tudi dostopa do prikaza Details, ki je na- menjen bolj podrobni analizi posameznega indikatorja. Za prikaz podatkov o alarmih smo doloˇcili prikazAlarms, za primerjavo razliˇcnih indikatorjev med sabo prikaz Data comparison, za pregled in dodajanje uporabniˇsko definira- nih indikatorjev prikazTags, za zgodovinsko analizo podatkov o posameznem indikatorju smo izdelali prikaz Historic analysis in za doloˇcanje in pregled omejitev za indikatorje smo dodali prikaz Indicator limits. V tem poglavju bomo vsak prikaz bolj podrobno opisali in utemeljili, zakaj smo se ga odloˇcili izdelati tako, kot smo ga izdelali.

Slika 5.17: ˇCelni del sistema z odprtim prikazom Main EnPIs

(44)

5.5.1 Prikaz Main EnPIs

Ta prikaz smo naˇcrtovali tako, da lahko uporabnik takoj vidi najpomemb- nejˇse podatke glavnih indikatorjev sistema; poraba zraka v litrih na minuto in poraba elektriˇcne energije v kWh. Kot prikazuje slika 5.17, smo izdelali ˇstiri vizualizacije. Dve od teh vizualizacij prikazujeta trenutno vrednost in- dikatorjev in sta barvno kodirani, glede na trenutno vrednost indikatorja. ˇCe je trenutna vrednost zelo majhna, se bo vizualizacija prikazala z rumeno, ˇce je v primernem intervalu zeleno in ˇce je prevelika rdeˇce. Tako lahko uporab- nik hitro razbere interval trenutne vrednosti indikatorja, ne da bi pogledal dejanske ˇstevilke ali pa od daleˇc vidi, da je v sistemu nekaj narobe, saj veli- kokrat uporabnik ne bo dovolj blizu zaslona, da bi videl ˇstevila na zaslonu.

Ostali dve vizualizaciji sta namenjeni podrobnejˇsi analizi podatkov za za- dnjih 7 dni. Iz teh grafov lahko uporabnik hitro razbere, ˇce so se v zadnjem ˇcasu v sistemu pojavile kakˇsne anomalije. Iz slike 5.17 se na primer hitro vidi, da je poraba zraka nekajkrat skoˇcila v nevarne vrednosti, kar se splaˇca raziskati. Poleg tega lahko iz grafa za porabo elektriˇcne energije vidimo, da so bili v merjenju skoki porabe, kar lahko pomeni veliko poveˇcanje porabe energije ali pa napako v merilnem sistemu (v naˇsem primeru v tistih ˇcasih naˇs sistem ni bil priˇzgan in iz proizvodnega procesa ni bral podatkov o porabi).

Poleg tega smo na ta prikaz dodali ˇse kratek povzetek za vsak indikator v zadnjih 7 dneh, kjer vkljuˇcimo povpreˇcno porabo zadnjih 7 dni, trenutne meritve, prejˇsnjo meritev, poveˇcavo v izmerjeni vrednosti, najveˇcjo meritev zadnjega tedna, najmanjˇso meritev zadnjega tedna in pa porabo indikatorja v primerjavi z ˇstevilom obdelanih izdelkov.

Za tak naˇcin prikaza smo se odloˇcili, ker standard pravi, da mora biti glavni prikaz ˇcelnega dela sistema narejen tako, da lahko uporabnik hitro razloˇci trenutne meritve indikatorjev. Ravno tako standard zahteva, da se mora iz prikaza hitro videti nedavne trende, v naˇsem primeru smo to na- redili tako, da smo izdelali dva grafa, ki prikazujeta vrednosti za zadnjih 7 dni. Poleg tega v skladu s standardom naredimo kratko analizo podatkov, da uporabnik lahko vidi kakˇsne so bile povpreˇcna, najveˇcja in najmanjˇsa vre-

(45)

Diplomska naloga 35 dnost indikatorjev. Standard pravi, da mora sistem prikazovati tudi porabo na enoto izdelka, kar smo tudi dodali v povzetek.

5.5.2 Prikaz Details

Ta prikaz je namenjen bolj podrobni analizi posameznega indikatorja, do njega uporabnik dostopa tako, da klikne na prikaz trenutne vrednosti indi- katorja. Ta prikaz uporabniku ponuja veˇc podatkov, zato je loˇcen na zgornji in spodnji del. V zgornjem delu prikaza (slika 5.18) uporabnik lahko vidi podatke za izbrani indikator skozi zadnji mesec delovanja, te podatke lahko potem tudi filtrira glede na datum, tako da izbere poljubni datum in pritisne na gumb ’Filter graph data by date’. Poleg tega grafa je ˇse graf porazde- litve podatkov indikatorja. Iz slike 5.18, na primer vidimo, da smo lahko z meritvami relativno zadovoljni, saj je poraba zraka veˇcinoma majhna, se je pa spet pojavilo nekaj anomalij. Porazdelitev izraˇcunamo tako, da vse po- datke razdelimo na intervale in za vsak interval izraˇcunamo ˇstevilo meritev, ki spada v ta interval. Nad grafa smo dodali ˇse povzetek za izbrani indikator, ki prikazuje trenutno meritev, prejˇsno meritev in poveˇcanje porabe v odstot- kih ter povpreˇcno, najveˇcjo in najmanjˇso meritev v ˇcasovnem intervalu, ki ga uporabnik izbere. Poleg tega povzetka smo vkljuˇcili ˇse povpreˇcno, najveˇcjo in najmanjˇso meritev tega in prejˇsnega tedna merjenja.

(46)

Slika 5.18: Zgornji del prikaza Details za indikator porabe zraka v litrih na minuto

Spodnji del tega prikaza (slika 5.19) je namenjen analizi vsakega dne posebej. Za ta del prikaza razdelimo podatke na dnevne intervale in za vsak dan v zadnjem tednu prikaˇzemo poseben graf. Tako lahko uporabnik ˇse bolj podrobno analizira podatke za posamezne dni, ker je lahko podatkov za en graf preveˇc. Poleg tega je na tak naˇcin primerjava posameznih dni med seboj dosti laˇzja. Tu smo ˇzal morali narediti prikaz tako, da se ne vidijo vsi dnevi naenkrat, saj na zaslonu ni dovolj prostora za vse grafe. Druga moˇznost je bila, da bi grafe naredili manjˇse, vendar bi bili potem zelo nepregledni in poslediˇcno neuporabni.

(47)

Diplomska naloga 37

Slika 5.19: Spodnji del prikazaDetails za indikator porabe zraka v litrih na minuto

Po standardu mora sistem omogoˇcati hitro podrobnejˇso analizo vseh in- dikatorjev, ki jih ponuja. Tu smo imeli moˇznost uporabiti razliˇcne grafe, na primer za prikaz porazdelitve obstaja veliko naˇcinov prikazov (violinski dia- grami [30], ˇskatliˇcni diagrami [2]), vendar smo se odloˇcili za navadni stolpiˇcni diagram, ki ga nekateri sicer ne priporoˇcajo za prikaz porazdelitev, je pa ve- liko bolj uporabljen in ga uporabniki znajo bolje brati, kot ostale. Dnevno analizo indikatorja smo prikazali na ta naˇcin, ker je tako laˇzje primerjati vre- dnosti indikatorja za posamezne dneve, kot pa, ˇce je vse na enem grafu. Tako nastane naslednji vzorec: uporabnik na grafu v zgornjem delu prikaza vidi, da se je zgodila anomalija in jo gre na spodnji del bolj podrobno analizirati.

5.5.3 Prikaz Secondary EnPIs

Ta prikaz (slika 5.20) je podoben prikazu Main EnPIs v tem, da prikazuje trenutne meritve za vse ostale sekundarne indikatorje. Tu povzetkov ne pri- kazujemo v zaˇcetnem stanju prikaza, ampak samo v prikazu Details, ki je

(48)

tako kot pri prikazuMain EnPIs dostopen s klikom na graf trenutne vredno- sti indikatorja. Prikaz Details ima isto strukturo kot tisti na prikazu Main EnPIs, zato ga ne bomo ˇse enkrat opisovali. Dodatna posebnost tega pri- kaza je spodnji del prikaza, kjer so narisani trije tortni grafi. Ti tortni grafi so namenjeni prikazu porabe elektriˇcnega toka na posameznih fazah. Tako lahko uporabnik iz teh grafov hitro razvidi ali se je na kaki fazi kaj zalomilo.

Na sliki 5.20 se na primer vidi, da je sistem na fazi dva porabil veˇc toka, kot na ostalih.

Slika 5.20: Prikaz Secondary EnPIs

Standard pravi, da mora aplikacija zagotavljati hitro identifikacijo napak v sistemu in ravno zato smo tu naredili tortne grafe, iz katerih lahko uporab- nik hitro vidi, da je nekaj narobe. Odloˇcitev za izdelavo ostalih delov tega prikaza smo utemeljili ˇze v poglavjih 5.5.1 in 5.5.2.

5.5.4 Prikaz Alarms

Ta prikaz je razdeljen na dva dela: primerjava ˇstevila napak s ˇstevilom opozo- ril ter analiza napak in opozoril. Primerjava ˇstevila napak s ˇstevilom opozoril

(49)

Diplomska naloga 39 je stolpiˇcni diagram (slika 5.21), na katerem sta prikazana ˇstevilo opozoril in ˇstevilo napak. Tako lahko uporabnik hitro doloˇci, katerih je v sistemu veˇc.

Opozorila so sistemu veˇcinoma neˇskodljiva, medtem ko napake lahko pome- nijo ustavitev sistema, zato taka primerjava uporabniku pride zelo prav.

Slika 5.21: Prikaz Alarms primerjava ˇstevila napak s ˇstevilom opozoril Analiza napak in opozoril je sestavljena iz dveh delov. Prvi del je tabela, v kateri so zapisane vse napake in opozorila, njihov tip, ime in ˇcasovne oznake.

Drugi del pa je malo prirejen Ganttov diagram [9], ki prikazuje zabeleˇzene napake in opozorila na grafu, njihov zaˇcetek in trajanje. S takˇsnim prikazom lahko uporabnik hitro razbere, kdaj je bil sistem upoˇcasnjen ali celo ustavljen zaradi napak. Na sliki 5.22 se na primer vidi, da je neko opozorilo trajalo kar 30 minut. Ko smo kasneje to analizirali, smo ugotovili, da smo ravno takrat testirali drug del proizvodnega procesa in zato pozabili reˇsiti opozorilo. Z uporabo Ganttovega diagrama lahko uporabnik, kadar se zgodi plaz napak, hitro doloˇci katera napaka ali opozorilo se je pojavilo prvo in analizira zakaj je priˇslo do plazu ter naslednjiˇc to prepreˇci.

Za tak prikaz alarmov smo se odloˇcili, ker so Ganttovi diagrami najbolj razˇsirjeni in najboljˇsi naˇcin prikaza ˇcasovnih podatkov. Iz njih se zlahka razbere kdaj in koliko ˇcasa je bila aktivna napaka ali opozorilo. Poleg tega standard priporoˇca uporabo takih ˇcasovnih diagramov za analizo napak proi- zvodnega procesa. Podobno vizualizacijo napak in opozoril so uporabili tudi v [25] vendar mislimo, da smo v naˇsem sistemu prikaz napak in opozoril izboljˇsali. Teme prikaza in analize napak in opozoril se dotakne tudi [10],

(50)

Slika 5.22: Prikaz Alarms analiza napak in opozoril

kjer avtorji tudi prikaˇzejo veˇc naˇcinov vizualizacije napak in opozoril, ki pa jih nismo uporabili, ker analiza napak in opozoril ni glavni del te diplomske naloge. Podajo pa zanimiv naˇcin prikaza napak in opozoril v obliki spirale, kjer se za vsak ˇcasovni interval izraˇcuna ˇstevilo prisotnih napak in opozoril in se tisti interval obarva glede na to ˇstevilo. S takim naˇcinom prikaza se po- tem lahko prikaˇze podatke tudi za cel mesec naenkrat, vendar pa tak prikaz uporabniku ne omogoˇca bolj podrobne analize napak in opozoril, ki smo jo hoteli mi omogoˇciti uporabnikom naˇsega sistema.

5.5.5 Prikaz Data comparison

Ta prikaz je namenjen za primerjavo podatkov med indikatorji, razdeljen je na ˇstiri dele. Prvi del je namenjen primerjavi le dveh indikatorjev med seboj, v tem delu se opravi kratka korelacijska analiza [16], kjer izraˇcunamo korelacijski koeficient R in pa razdaljno korelacijo [8]. V drugem delu smo naredili graf, ki v zaˇcetku prikazuje vse indikatorje, ki se trenutno merijo v sistemu (tudi tiste, ki jih je definiral uporabnik sam), lahko pa uporabnik

(51)

Diplomska naloga 41 izbere, katere ˇzeli prikazati. V zadnjem delu prikaza si uporabnik lahko izbere do ˇsest indikatorjev in se mu za vsakega od njih nariˇse poseben graf.

V prvem delu (slika 5.23) tega prikaza smo podali uporabniku moˇznost izbrati dva indikatorja, za katera ˇzeli opraviti primerjalno analizo. Ko upo- rabnik izbere ta indikatorja, se nariˇse graf na katerem s toˇckami nariˇsemo izbrana indikatorja, kjer je x koordinata toˇcke vrednost meritve prvega in- dikatorja in y koordinata toˇcke vrednost meritve drugega indikatorja. Tako lahko ˇze iz grafa uporabnik hitro razbere ali sta indikatorja med sabo odvi- sna ali ne. Poleg grafiˇcnega prikaza odvisnosti med indikatorjema, pa smo naredili tudi izraˇcun korelacijskega koeficienta R, s katerim se doloˇci linearna korelacija med indikatorjema. Vrednost tega koeficienta je na intervalu [-1, 1], kjer vrednost -1 pomeni negativna korelacija, 0 pomeni da ni korelacije in 1 pomeni pozitivno korelacijo med indikatorjema. Ker pa je lahko ta ko- eficient nenatanˇcen, saj meri le linearno korelacijo, smo zraven izraˇcunali ˇse korelacijo razdalje (angl. distance correlation), ki smo jo izraˇcunali po for- mulah v [8]. Formula za korelacijo razdalje vrne vrednost na intervalu [0, 1], kjer 0 pomeni, da med indikatorjema ni povezave in 1 pomeni, da sta indikatorja med sabo moˇcno odvisna. S tako analizo zadostimo standardu, ki pravi, da mora sistem uporabniku omogoˇcati analizo odvisnosti med indi- katorji, saj uporabniku omogoˇcamo vizualno in numeriˇcno analizo odvisnosti med indikatorji.

Slika 5.23: Prvi del prikaza Data comparison, primerjava napetosti na fazi L1 in med fazama L1 in L2

(52)

Dela dva in tri sta namenjena soˇcasni analizi veˇcih indikatorjev, v teh delih ne raˇcunamo korelacijskih koeficinetov, vendar samo prikaˇzemo indika- torje, ki jih uporabnik izbere. V drugem delu (slika 5.24) uporabnik izbira indikatorje za prikaz na enem grafu, kjer se vsi izbrani indikatorji nariˇsejo naenkrat. Na takem grafu se lahko vrednost informacija podatkov hitro iz- gubi, vendar smo mnenja, da je lahko vseeno uporaben, kadar ˇzeli uporabnik videti meritve veˇcih indikatorjev na enem grafu. V ˇcetrtem delu prikaza smo uporabniku omogoˇcili, da s pritiskom na gumb ’Generate report’ aplikacija ustvari datoteko json, v katero se shranijo podatki za izbrane indikatorje v zadnjem tednu. Tako lahko uporabnik izbere poljubne indikatorje, prikaˇze njihove vrednosti na grafu in potem te vrednosti zapiˇse v datoteko, ki jo shrani preko brskalnika.

Slika 5.24: Drugi del prikazaData comparison, primerjava vseh indikatorjev, razen tistih povezanih s porabo zraka

Tretji del (slika 5.25) tega prikaza ima podobno funkcijo kot drugi, s tem da se v tem delu za vsak indikator, ki ga uporabnik izbere, nariˇse nov graf.

Zaradi moˇznih teˇzav z raˇcunsko moˇcjo, smo se tu odloˇcili uporabnika omejiti na najveˇc 6 izbranih indikatorjev naenkrat. Tako se uporabniku na zaslonu ne bo prikazovalo preveˇc podatkov in ti podatki se bodo lahko posodobili, ne da bi aplikacija zamrznila.

Z drugim in tretjim delom v aplikaciji spet (tako kot v prvem) zadostu- jemo zahtevi standarda o primerjavi meritev indikatorjev med sabo, le da

(53)

Diplomska naloga 43

Slika 5.25: Tretji del prikaza Data comparison, uporabnik je izbral 3 indika- torje za prikaz

tu uporabniku omogoˇcamo primerjavo veˇcih indikatorjev naenkrat. Drugi in tretji del tega prikaza naˇceloma opravljata isto funkcionalnost, vendar smo se jih odloˇcili loˇciti v dva razliˇcna dela, ker smo mnenja, da se na grafu, ki je v drugem delu, vˇcasih lahko izgubi informacija, ki jo lahko najdemo na grafih v tretjem delu in obratno.

5.5.6 Prikaz Tags

Tu lahko uporabniki doloˇcijo svoje indikatorje iz spremenljivk, ki so na indu- strijskem krmilniku. Uporabnik vnese ime spremenljivke na industrijskem kr- milniku, prikazno ime in enoto, v kateri ˇzeli prikazati to spremenljivko (slika 5.26). ˇCe si uporabnik zbere spremenljivko, ki na industrijskem krmilniku pomeni hitrost motorja, bo v prvo vnosno polje vnesel ime spremenljivke, v drugo vnosno polje poljubno prikazno ime, na primer ’Hitrost motorja 1’ in v tretje vnosno polje enoto, v tem primeru ’rpm’ (angl. rotations per minute, obrati na minuto). Tako lahko uporabnik definira svoje poljubne indikatorje, ki jih lahko potem primerja z ostalimi indikatorji na prikazuData comparison in sledi njihovim zgodovinskim vrednostim na prikazu Historic analysis.

Na tem prikazu se uporabniku izpiˇsejo vsi indikatorji, ki jih je do sedaj doloˇcil (slika 5.26). Izpiˇse se mu: ime spremenljivke, prikazno ime ter trenu- tna meritev indikatorja z enoto, ki jo je vnesel. Uporabnik lahko tudi pritisne

(54)

na posamezen indikator, kar bo ta indikator oznaˇcilo kot neaktiven (ˇce je tre- nutno aktiven) ali aktiven (ˇce je trenutno neaktiven). ˇCe je nek uporabniˇsko definiran indikator aktiven, bo sistem iz industrijskega krmilnika prebral nje- govo vrednost. V nasprotnem primeru, ˇce je neaktiven, pa je ne bo. Na tem prikazu smo dodali ˇse izbirno polje, kjer lahko uporabnik izbere enega izmed definiranih indikatorjev in se mu prikaˇze graf trenutno prebranih podatkov za ta indikator (slika 5.27).

Slika 5.26: PrikazTags, prikaz vseh indikatorjev in vnosna polja za dodajanje indikatorjev

S tem prikazom pomagamo v sistemu zadostiti zahtevi standarda, ki pravi, da mora uporabnik sistem za branje in analizo podatkov ves ˇcas po- sodabljati in po potrebi dodati nove indikatorje.

(55)

Diplomska naloga 45

Slika 5.27: Prikaz Tags, prikaz grafa za indikator Speed of conveyor motor TC1

5.5.7 Prikaz Historic analysis

Ta prikaz je namenjen zgodovinski analizi posameznega indikatorja. Za laˇzjo razlago razdelimo prikaz na tri dele. V prvem delu (slika 5.28) uporabnik izbere indikator in pa dva intervala, kjer ima na voljo izbire: ta teden, prejˇsni teden, ta mesec, prejˇsni mesec, zadnjih 6 mesecev, to leto in lansko leto.

Ko uporabnik izbere ta intervala se mu nariˇseta dva grafa, vsak za svoj interval, na katerih so prikazani podatki za izbrani interval. Poleg teh grafov se uporabniku prikaˇzeta tudi povzetka za vsak interval, tako kot na prikazu Details, le da tu uporabniku izraˇcunamo le povpreˇcno, najveˇcjo in najmanjˇso vrednost za izbrani indikator, na vsakem izmed izbranih intervalov.

Slika 5.28: Prvi del prikaza Historic analysis, uporabnik je izbral indikator porabe zraka, z intervali ta teden in prejˇsni teden

(56)

Drugi del prikaza (slika 5.29) je namenjen tedenski analizi povpreˇcja meri- tev za vsako uro. To pomeni, da smo za vsako uro v zadnjih 7 dneh izraˇcunali povpreˇcje vseh meritev v tej uri in te vrednosti narisali z vroˇcinskim diagra- mom (angl. heatmap). Tako lahko uporabnik aplikacije hitro vidi, kateri dan in uro v tem dnevu je imel stroj najveˇcjo povpreˇcno porabo. Za tak prikaz smo se odloˇcili, ker se iz njega hitro vidi, katera ura v dnevu izstopa, saj ima drugaˇcno barvo, kot ostale. Na primer iz slike 5.29 lahko uporabnik hitro ugotovi, da ima proizvodni proces okoli 13-te ure najveˇcjo povpreˇcno porabo v dnevu, tako lahko dodatno analizira zakaj in kje pride do takˇsne porabe, naj bo to zaradi slabega dela operaterjev ali prevelikega navala zahtev za izdelke.

Slika 5.29: Drugi in tretji del prikaza Historic analysis za indikator porabe zraka, interval v tretjem delu je tedenski

V tretjem delu (slika 5.29) prikaza uporabniku aplikacija prikaˇze povzetke podatkov razdeljenih glede na izbran interval. Tu lahko uporabnik izbira med intervali: dnevni, tedenski, meseˇcni in letni. Aplikacija glede na izbrani interval razdeli podatke v skupine in za vsako skupino izraˇcuna povzetek, tako kot v prvem delu tega prikaza. Tako uporabniku omogoˇcimo dodatno analizo posameznega intervala, kar mu lahko pomaga doloˇciti teˇzavo, zaradi katere ima proizvodni proces veˇcjo porabo kot ˇzeljeno.

Ta prikaz smo izdelali, ker standard zahteva, da sistem za energijsko upravljanje dovoljuje zgodovinsko analizo podatkov. Za zadostitev tej zah-

(57)

Diplomska naloga 47 tevi standard priporoˇca, da sistem omogoˇca primerjave porabe po dnevih, tednih, mesecih in letih. Ta prikaz smo naˇcrtovali s tem v mislih. Zato smo prikaz naredili tako, da ga lahko uporabnik uporabi za zgodovinsko analizo po vseh priporoˇcenih intervalih. Ker se nam je poleg teh intervalov zdela pomembna tudi analiza urnih intervalov, smo dodali tudi drugi del prikaza z vroˇcinskim diagramom, ker se na takˇsnem diagramu lahko hitro vidi od- stopanje od normalnih vrednosti, ki ga na navadnih grafih uporabnik teˇzko opazi. Tako smo s tem prikazom zadovoljiji standardovi zahtevi in dodali ˇse dodatno moˇzno zgodovinsko analizo.

5.5.8 Prikaz Indicator limits

Kot zadnji prikaz ˇcelnega dela sistema smo izdelali vmesnik, kjer lahko upo- rabnik omeji indikatorje, ki jih sistem bere iz industrijskega krmilnika (slika 5.30). Uporabnik v vnosno polje vnese prikazno ime indikatorja, novo zgor- njo mejo in novo spodnjo mejo ter pritisne na gumb ’Add/Edit limits!’ in v bazi se posodobijo podatki za omejitev indikatorja.

Slika 5.30: Prikaz Indicator limits

V primeru, da omejitev za indikator ˇze obstaja, se bo ta prikazala v spo- dnjem oknu z vsemi pomembnimi podatki, ki vkljuˇcujejo: trenutno prebrano vrednost, zgornjo mejo, spodnjo mejo, povpreˇcno porabo, prejˇsno prebrano vrednost, najveˇcjo prebrano vrednost in najmanjˇso prebrano vrednost. Upo-

(58)

rabnik lahko v tem oknu klikne na katerikoli indikator in podatki za ta in- dikator (prikazno ime, spodnja in zgornja meja), se bodo samodejno vpisali v vnosna polja. Ta prikaz tudi ponuja vnos elektronskih naslovov, na katere naj sistem poˇsilja dnevna poroˇcila in poroˇcila o preseganju doloˇcenih mej.

Tu lahko uporabnik vnese nov elektronski naslov in z obkljukanjem ’Send reports to this email?’ dovoli poˇsiljanje poroˇcil na vneˇsen elektronski naslov.

Ce ˇˇ zeli uporabnik prekiniti poˇsiljanje poroˇcil na doloˇcen elektronski naslov, v vnosno polje vnese ˇzeljen elektronski naslov in odkljuka ’Send reports to this email?’, tako bo sistem oznaˇcil vneˇsen elektronski naslov kot neaktiven in nanj nehal poˇsiljati poroˇcila.

V primeru da nek indikator preseˇze vneˇseno mejo, bo prikaz uporabnika na to opozoril, tako da bo zaˇcela rdeˇce utripati zgornja orodna vrstica, kar uporabnik vidi tudi na drugih prikazih (slika 5.31). Poleg tega bo tisti in- dikator, ki je presegel mejo, zaˇcel na prikazu Indicator limits utripati rdeˇce (slika 5.32). Poleg tega bo sistem sestavil poroˇcilo (slika 5.3) o preseˇzenih mejah za vse indikatorje, ki so katerokoli mejo presegli, in to poroˇcilo poslal na vse aktivne elektronske naslove v podatkovni bazi.

Slika 5.31: Uporabnik je na prikazu Data comparison in zadnja meritev ne- kega indikatorja je presegla spodnjo ali zgornjo mejo

Standard sicer zahteva, da se take meje indikatorjev doloˇcijo ˇze ob izdelavi energijske politike, tako da bi v resniˇcni situaciji bile te meje doloˇcene ˇze prej in ˇze shranjene v podatkovni bazi. Ker pa standard doloˇca tudi to, da se mora energijska politika ves ˇcas posodabljati glede na razmere mislimo, da je tak vmesnik za definiranje omejitev indikatorjev nekaj, kar mora ˇcelni del takega sistema imeti. Poleg tega standard doloˇca, da mora sistem ob preseganju

(59)

Diplomska naloga 49

Slika 5.32: Zadnja meritev indikatorja porabe zraka v litrih na minuto je presegla zgornjo mejo

katerekoli omejitve indikatorja uporabnika na to opozoriti, zato smo to tudi dodali v prikaz.

(60)
(61)

Poglavje 6 Zakljuˇ cek

V diplomskem delu smo razvili sistem za zbiranje, prikaz in analizo podat- kov o proizvodnem procesu. Sistem omogoˇca beleˇzenje podatkov o doloˇcenih indikatorjih v proizvodnem procesu. Podatki so enostavno prenosljivi tudi izven sistema, saj je streˇznik, ki podatke streˇze na voljo vsem odjemalcem v sistemu. V ˇcelnem delu sistema smo izdelali veˇc prikazov, s katerimi lahko uporabnik podrobno analizira vrednosti indikatorjev. Poleg analize indika- torjev smo dodali tudi analizo napak v sistemu, ki uporabniku pomaga ˇse dodatno analizirati delovanje proizvodnega procesa. Sistem generira tudi dnevna poroˇcila in poroˇcila o preseˇzeniuh mejah vrednosti indikatorjev.

Celoten sistem smo razvili tako, da zadostuje tistim delom standarda ISO 50001, ki se tiˇcejo zbiranja, prikaza in analize podatkov. Tako je sistem uporaben za organizacije, ki ˇzelijo zadostiti zahtevam standarda ISO 50001.

Sistem se lahko v prihodnosti izboljˇsa tako, da se posvetuje z uporab- niki sistema, ki bodo povedali, ˇce jim kakˇsni prikazi na ˇcelnem delu sistema manjkajo ali so odveˇc. Poleg tega lahko povedo, kako se lahko ˇze obstojeˇci prikazi spremenijo in tako izboljˇsajo uporabniˇsko izkuˇsnjo. Kar se lahko ˇse izboljˇsa je bolj podrobna analiza napak v proizvodnem procesu, trenutno sis- tem zbira le podatke ali se je napaka zgodila. Lahko bi zbirali tudi podatke o tem toˇcno katera napaka se je zgodila in njen opis (to bi lahko imeli drugje shranjeno in bi le prikazali). Uporabnikom bi to omogoˇcalo dodatno analizo

51

(62)

napak v procesu in poslediˇcno boljˇse razumevanje delovanja.

(63)

Literatura

[1] Ifran A in sod. “Programmable Logic Controller Forensics”. V: (2017), str. 18–24. doi:10.1109/MSP.2017.4251102.

[2] Skatliˇˇ cni diagrami.url:https://towardsdatascience.com/understanding- boxplots-5e2df7bcbd51(pridobljeno 13. 8. 2021).

[3] Django.url:https://www.djangoproject.com/(pridobljeno 29. 7. 2021).

[4] django-rest-framework. url: https://www.django-rest-framework.

org/(pridobljeno 29. 7. 2021).

[5] Veronika Domova. “Designing visualization and interaction for indu- strial control rooms of the future”. Doktorska naloga. Link¨oping Stu- dies in Science in Technology, 2020.

[6] EnPI. url: https://www.iso.org/obp/ui/#iso:std:iso:50006:

ed-1:v1:en(pridobljeno 25. 6. 2021).

[7] Elektriˇcne faze. url: https://www.fluke.com/en-us/learn/blog/

power-quality/single-phase-vs-three-phase-power(pridobljeno 29. 7. 2021).

[8] Szekely Gabor in Rizzo Maria. “PARTIAL DISTANCE CORRELA- TION WITH METHODS FOR DISSIMILARITIES”. V: (2014). doi: 10.1214/14-AOS1255.

[9] Ganttovi diagrami. url: https://www.projectmanager.com/gantt- chart (pridobljeno 13. 8. 2021).

53

(64)

[10] Wenkai Hu in sod. “Design of visualization plots of industrial alarm and event data for enhanced alarm management”. V: (2018). doi: https:

//doi.org/10.1016/j.conengprac.2018.07.0053.

[11] ISO 14001 - Sistem ravnanja z okoljem. url: https : / / www . iso - standard.si/iso-14001/(pridobljeno 29. 7. 2021).

[12] ISO 50001 - Upravljanje z energijo.url: https://www.iso.org/iso- 50001-energy-management.html (pridobljeno 29. 7. 2021).

[13] ISO 9001 - Sistem vodenja kakovosti.url:https://www.iso-standard.

si/iso-9001/ (pridobljeno 29. 7. 2021).

[14] Javascript.url:https://www.javascript.com/(pridobljeno 29. 7. 2021).

[15] Jwo Jung-Sing, Lin Ching-Sheng in Lee Cheng-Hsiung. “An Interactive Dashboard Using a Virtual Assistant for Visualizing Smart Manufac- turing”. V: (2021). doi:10.1155/2021/5578239.

[16] Korelacijska analiza.url: https://sphweb.bumc.bu.edu/otlt/mph- modules / bs / bs704 _ multivariable / bs704 _ multivariable5 . html (pridobljeno 13. 8. 2021).

[17] Valentin Kragelj. “Pregled in analiza tehnologij za serializacijo objek- tov”. Diplomska naloga. FRI - Fakulteta za raˇcunalniˇstvo in informa- tiko, 2014.

[18] SQLite limits. url: https://www.sqlite.org/limits.html (prido- bljeno 29. 7. 2021).

[19] Siemens Mindsphere. url: https : / / siemens . mindsphere . io / en (pridobljeno 12. 8. 2021).

[20] MVC. url: https : / / dotnet . microsoft . com / apps / aspnet / mvc (pridobljeno 29. 7. 2021).

[21] OPC Unified Architecture. url: https : / / opcfoundation . org / wp - content/uploads/2020/11/OPCF- FLC- Technical- Paper- C2C.pdf (pridobljeno 25. 6. 2021).

(65)

Diplomska naloga 55 [22] OPC Classic.url:https://opcfoundation.org/faq/what-is-opc-

classic/(pridobljeno 29. 7. 2021).

[23] Williams P. “Techniques for Root Cause Analysis”. V: (2001). doi: 10.1080/08998280.2001.11927753.

[24] Python.url: https://www.python.org/ (pridobljeno 25. 6. 2021).

[25] Sandeep R. “Graphical Representation of Industrial Alarm Data”. V:

(2010).doi: 10.3182/20100831-4-FR-2021.00033.

[26] React.js. url: https://reactjs.org/(pridobljeno 29. 7. 2021).

[27] Rest API. url: https : / / www . ibm . com / cloud / learn / rest - apis (pridobljeno 29. 7. 2021).

[28] Karnouskos S in sod. “Towards the Energy Efficient Future Factory”.

V: (2009).doi: 10.1109/INDIN.2009.5195832.

[29] SQLite. url: https : / / www . sqlite . org / index . html (pridobljeno 29. 7. 2021).

[30] Violinski diagrami.url:https://towardsdatascience.com/violin- plots-explained-fb1d115e023d(pridobljeno 13. 8. 2021).

[31] ISO 50001 whitelist. url: https://www.se.com/ww/en/download/

document/WP1425EN/ (pridobljeno 1. 9. 2021).

Reference

POVEZANI DOKUMENTI

Ker pa tak naˇ cin razvoja prinaˇ sa kar nekaj prednosti tako za naroˇ cnika kot izvajalca, smo se odloˇ cili, da v tem diplomskem delu predstavimo testno voden razvoj v kombinaciji

Odloˇ citev, da se bo uporabnik med stranmi pomikal z uporabo stranskega menija sem sprejel zato, ker je takˇsen naˇ cin postavitve uporabljen v veliki veˇ cini spletnih

Dodatno, lahko po- nudnike iˇsˇ cemo v bliˇ zini trenutne lokacije, ki se privzeto doloˇ ci sama, dodana pa je tudi moˇ znost, da jo doloˇ ci uporabnik sam. Morebitni ponudniki, ki

Uspeˇsnost sistema definirata hitrost izvedbe poljubnega ukaza in koliko dela ima uporabnik, da ukaz posreduje sistemu. Bolj ko smo veˇsˇ ci komunikacije, s katero upravljamo

Da vozliˇsˇ ce ustvari legitimen nov blok, kateri se lahko prikljuˇ ci verigi, mora generirati zgoˇsˇ ceno vrednost bloka, tako da ta ustreza teˇ zavnosti. Te- ˇ zavnost doloˇ

poroˇ cilo kefalometriˇ cne analize mora biti strukturirano na takˇ sen naˇ cin, da je skla- dno z definicijami podanimi v prejˇ snjem poglavju; tako lahko sistem osnovan na

ˇ Clani skupine se odloˇ cijo, da se splaˇ ca porabiti veˇ c ˇ casa za pisanje zahtev, zato mora biti predloga za primere uporabe podrobnejˇsa, napisana v enakem stilu, da ne bi

V sodobnem svetu se opravljajo meritve tudi pri nogometnih tekmah, zato smo se odloˇ cili, da to podroˇ cje podrobneje raziˇsˇ cemo in analiziramo s pomoˇ cjo analize omreˇ zij