Antti Heinonen
Häiriöhavaintojärjestelmän Integraatio Liikenteenhallintajärjestelmään
Tietotekniikan pro gradu -tutkielma 13. maaliskuuta 2019
Tekijä:Antti Heinonen
Yhteystiedot:Antti Heinonen
Ohjaaja:Ville Isomöttönen
Työn nimi:Häiriöhavaintojärjestelmän Integraatio Liikenteenhallintajärjestelmään
Title in English:Integration of Disturbance Detection System Into Traffic Control Systems Työ:Pro gradu -tutkielma
Suuntautumisvaihtoehto:Ohjelmistotekniikka Sivumäärä:87+0
Tiivistelmä: Tämä pro gradu keskittyy eritason komponenttien välisen kommunikaation suunnittelemiseen ja toteutukseen. Tutkielma esittelee pääasialliset olevassaolemat toteutuk- set Suomen liikennejärjestelmissä, niiden yhteisen arkkitehtuurin pääpiirteet sekä käsittelee uuden laitetyypin integraatiota olemassaoleviin järjestelmiin.
Tutkielman lopputuloksena on uusi rajapinta liikenneviraston ohjelmistoihin, jonka avulla pystytään välittämään ja vastaanottamaan viestejä koneoppimista hyödyntävälle kamerapoh- jaiselle häiriöhavaintojärjestelmälle.
Avainsanat: gradu3, pro gradu -tutkielmat, Software Architecture, Software Design, C#, WinCC OA, PLC
Abstract:This graduate thesis is focused on integration of components from different levels of complexity and transmission of messages between these different systems. Thesis presents the main architecture and existing solutions in Finnish traffic systems and focuses on creation of a new integration layer of software and plc in order to effectively communicate between REST-application and traffic cameras that detect disturbances using machine learning.
Keywords: gradu3, pro gradu -tutkielmat, Software Architecture, Software Design, C#, WinCC OA, PLC
Esipuhe
Tämä Pro gradu tutkielma on toteutettu työsuhteen aikana YSP Oy -yrityksellä.
YSP Oy toimii konsulttina sekä liikenneteknisten järjestelmien toteuttajana Suomen Liiken- nevirastolle. Pääasiallisena tuotteena toimii kokonaisratkaisujen tarjoaminen Liikenneviras- tolle alkaen yksittäisten laitteiden tilaamisesta, asentamisesta ja logiikkaohjelmoinnista, jat- kuen valvomo-ohjelmiston kautta REST-rajapintaan asti, johon Liikenneviraston Tieliiken- teen ohjauksen integroitu käyttöliittymä (T-LOIK) ottaa yhteyden.
Jyväskylä, 13. maaliskuuta 2019
Antti Heinonen
Termiluettelo
HTTP (lyhenne sanoista Hypertext Transfer Protocol) on protokolla, jota selaimet ja palvelimet käyttävät viestiensä välitykseen.
TCP (lyhenne sanoista Transmission Control Protocol) on matalan tason tietoliikenneprotokolla, jonka avulla tietokoneet viestivät toisilleen.
REST (lyhenne sanoista Representational State Transfer) on HTTP- protokollaan perustuva arkkitehtuurimalli ohjelmointirajapin- tojen toteuttamiseen.
XML (engl. Extensible Markup Language) on XML-tyyppisten mer- kintäkielien standardi, johon muunmuassa verkkosivujen HTML kuuluu.
JSON (lyhenne sanoista JavaScript Object Notation) on avoimen stan- dardin mukainen tiedostomuoto tiedonvälitykseen.
.NET Framework on Microsoftin kehittämä ohjelmistokomponenttikirjasto.
C# on Microsoftin kehittämä olio-ohjelmointikieli, joka pohjautuu .Net-kirjastoon.
ASP.NET on avoimen lähdekoodin ohjelmistokehys modernien web-sovellusten rakentamiseen.
AKKA.Net on työkalupaketti ajonaikaisten tapahtumapohjaisten ohjelmis- tojen kehitykseen, joka pohjautuu .Net -kirjastoon.
NUnit on avoimen lähdekoodin kirjasto .NET-sovelluksien yksikkö- testaamiseen.
SCADA (engl. Supervisory Control and Data Acquisition) on tietoko- neohjelma, joka tarjoaa pohja-arkkitehtuurin erilaisiin automaa- tiojärjestelmiin ja niiden hallintaan.
WinCC OA (engl. WinCC Open Architecture) on Siemensin kehittämä SCADA- ohjelmistotuote.
PLC (engl. Programmable logic controller) on riisuttu tietokone, jo-
T-LOIK (lyhenne sanoista Tieliikenteen ohjauksen integroitu käyttöliit- tymä) on järjestelmä, jonka tarkoituksena on vastaanottaa da- taa ja hallita eri osia Suomen liikenteenhallintajärjestelmistä.
T-LOIK-Ohjaussovitin on järjestelmä, jonka tarkoituksena on toimia viestinvälittäjä- nä SCADA-ohjelmiston ja/tai PLC-laitteiden sekä T-LOIK:n välillä.
DriverManager on C# :lla toteutettu ajurialusta, joka pohjautuu microftin MEF- applikaatioihin (Managed Extensible Framework).
Kuviot
Kuvio 1. Järjestelmän yleisarkkitehtuuri . . . 3
Kuvio 2. Esimerkki LD:n syntaksista, lähde “Ladder Logic Examples” 2018-10-16. . . 7
Kuvio 3. Modbus TCP esimerkki, lähde: “How do you program and parameterize Modbus/TCP communication between S7-1500 CPUs and S7-1200 CPUs?” (2018- 10-16). . . 12
Kuvio 4. T-LOIK-ohjaussovittimen tietovuo-kaavio . . . 22
Kuvio 5. DriverManager WinCC OA:n projektimanagerin aliprosessina . . . 25
Kuvio 6. XaidDriverin arkkitehtuuri. . . 37
Kuvio 7. XaidDriverin sisäinen rakenne . . . 52
Taulukot
Taulukko 1. Modbus TCP:n rakenne . . . 12Sisältö
1 JOHDANTO . . . 1
2 ARKKITEHTUURIN YLEISKUVA . . . 3
3 PLC . . . 6
3.1 Structured Text . . . 8
3.2 Modbus Protokolla . . . 11
3.3 PLC käyttötapauksia . . . 13
4 SCADA . . . 14
4.1 WinCC Open Architecture . . . 15
4.2 Datan vastaanottaminen ja välitys WinCC OA:ssa . . . 16
5 REST-ARKKITEHTUURI & T-LOIK-OHJAUSSOVITIN . . . 17
5.1 REST-arkkitehtuuri . . . 18
5.2 T-LOIK-Ohjaussovitin ja Akka.NET . . . 20
6 MANAGED EXTENSIBILITY FRAMEWORK & DRIVERMANAGER . . . 24
7 X-AID HÄIRIÖNHAVAINTOJÄRJESTELMÄ JA TESTIVETOINEN KEHITYS . 28 7.1 Kuvaus X-AID häiriönhavaintojärjestelmästä . . . 29
7.2 X-AID-simulaattori . . . 30
7.3 Testivetoinen kehitys . . . 31
8 XAIDDRIVER . . . 32
8.1 Oliosuunnittelu ja XaidDriver . . . 36
8.2 XaidDriverin kehityksessä sovelletut suunnittelumallit . . . 45
8.3 Datan representaatiot WinCC OA:ssa . . . 54
8.4 XaidDriverin datan käsittely WinCC OA:ssa . . . 61
9 X-AID INTEGRAATION TESTAAMINEN . . . 64
9.1 XaidDriverin yksikkötestaus . . . 65
9.2 Integraatiotestaus XaidDriverin ja WinCC OA:n välillä . . . 66
9.3 Kenttätestien huomioita ja tuloksia . . . 70
10 YHTEENVETO JA JATKOTOIMENPITEET . . . 72
LÄHTEET . . . 76
1 Johdanto
Liikennevirasto aloitti vuonna 2013 hankkeen, jonka tarkoituksena oli yhtenäistää useita erilaisia Suomessa olevia liikenteenohjausjärjestelmiä (“Uusi tieliikenteen ohjausjärjestel- mä (T-LOIK) nopeuttaa tiedonkulkua tienkäyttäjille ja helpottaa liikennepäivystäjien työtä”
2016-03-04). Tämän seurauksena syntyi yksi yhteistävä järjestelmä: T-LOIK (Tieliikenteen ohjauksen integroitu käyttöliittymä). Koska Suomessa on melko paljon liikenteenohjaus- järjestelmiä, on kaikkien pääasiallisten järjestelmien yhdistäminen T-LOIK-järjestelmään usean vuoden prosessi.
Tämän pro gradun keskipisteenä on Etelä-Suomeen suunnitteilla oleva tunnelijärjestelmä.
Tunnelin läpi kulkee moottoritie ja tunnelin alue sisältää lukuisia erilaisia PLC-laitteita (Pro- grammable Logic Controller), joita ohjataan SCADA-järjestelmien (Supervisory Control and Data Acquisition) ja T-LOIK:n kautta. Tätä yleisarkkitehtuuria havainnoillistava kuvio 1 esi- tellään tarkemmin seuraavassa kappaleessa. Tämän tunnelin SCADA-järjestelmä on toteutet- tu Siemensin WinCC OA -järjestelmän pohjalta.
Tunnelin teknisesti kiinnostavimpia kohteita ohjelmistokehityksen näkökulmasta on tunne- liin tuleva häiriöhavaintojärjestelmä (HHJ, X-AID). Tämä järjestelmä prosessoi videoku- vaa koneoppimista hyödyntäen, tunnistaen liikennehäiriöitä ja välittää niistä tietoa SCADA- järjestelmälle ja takaisin. Näiden viestien sisältönä on esimerkiksi pysähtynyt ajoneuvo, hi- das ajoneuvo ja väärään suuntaan ajava ajoneuvo. Häiriötilanteita varten tunnelin ohjaus- järjestelmään on rakennettu erilaisia reaktioita liikennekäyttäjän varoittamiseen ja kaistojen sulkemiseen. Käytännössä erilaiset hälytykset laukaisevat sekvenssejä PLC-laitteissa, jotka sitten reagoivat tilanteesta riippuen korrektilla tavalla, kuten sulkemalla jonkin kaistan ja oh- jaamalla liikenteen toiseen suuntaan.
Tämän pro gradun lopputuloksena on X-AID-palvelimen TCP-yhteyden (Transmission Cont- rol Protocol) sisäistä protokollaa tulkkaava ajuri, joka kommunikoi X-AID kameroiden ko- neoppimis-palvelimen kanssa ja välittää hälytyksiä WinCC OA -pohjaiseen tunnelijärjestel- mään.
tä tämän ajurin nimeksi tuli XaidDriver. DriverManager on C#-ohjelmointikielellä toteutettu geneerinen ajurialusta, joka käyttää WinCC OA:n C# rajapintaa. Tämän ajurialustan tarkoi- tuksena on helpottaa WinCC OA:n sisäisen CTRL-skriptikielen jatkamista C#-ohjelmointi- kielellä, sillä C# taipuu helpommin kompleksisempiin operaatioihin kuin CTRL. Ajurialusta nopeuttaa ja yksinkertaistaa ulkoisten rajapintojen toteutusta WinCC OA-järjestelmään.
Tämän pro gradun aikana havainnoillistetaan miten olemassaolevia järjestelmiä integroidaan toimivaksi kokonaisuudeksi sekä osoitetaan kuinka useita eri kokonaisuuksia yksittäinen mo- derni automaatiojärjestelmä sisältää. Tarkoituksena on kaventaa kuilua ohjelmistotekniikan ja automaatiosuunnittelun välillä sekä tarjota tietoa tavoista integroida automaatiojärjestelmä korkean tason ohjelmointikielten ohjelmiin. Tutkielma esittää erilaisia kehitystapoja ja suun- nittelumalleja luotettavan ohjelmiston kehitykseen ja havainnoillistaa käytännön esimerkeil- le kuinka näitä malleja voi hyödyntää.
Tutkielmassa käydään läpi ensin olemassaoleva arkkitehtuuri ja avataan miten tutkielman eri luvut liittyvät olemassaolevaan arkkitehtuuriin. Tarkoituksena on vastata seuraaviin ky- symyksiin: mikä on PLC, mitä tarkoittaa SCADA-järjestelmä ja kuinka se kommunikoi kor- keamman tason ohjelmointikielten ohjelmien kanssa, miten nämä järjestelmät kommunikoi- vat keskenään ja miten näistä osista muodostuu valvomo-ohjelmisto (luvut 2 - 4). Ohessa avataan miten tällainen tunnelivalvomojärjestelmä yhdistetään TLOIK-järjestelmään (luku 5). Tämän jälkeen siirrytään käsittelemään XaidDriverin kehitystä: minkälaisten teknolo- gioiden päälle tämä ajuri on rakennettu (luku 6), millaisia ohjelmistokehityksen menetelmiä voidaan soveltaa kehityksen yhteydessä, kuinka järjestelmän toimivuutta testataan, millaisia suunnittelumalleja toteutuksessa hyödynnetään, millaista ohjelmistoarkkitehtuuria HHJ:n in- tegraatiossa käytetään ja lopulta miten tämä järjestelmä testataan laadullisesti (luvut 7 - 9).
Lopuksi arvioidaan protokollatulkin toimivuutta, mitä puutteita löytyi alustavan testaamisen ohessa, mitä mahdollisia jatkotoimenpiteitä järjestelmän kokonaistestaamisessa voi ilmetä ja miten niihin voi reagoida kyseisen järjestelmän loppuun hiomiseksi sekä pohditaan yleisesti pro gradun onnistumista (luku 10).
2 Arkkitehtuurin yleiskuva
Häiriöhavaintojärjestelmän integroimisen näkökulmasta on olennaista esitellä kehitykses- sä hyödynnettävät teknologiat: olennaisimmat ovat T-LOIK, T-LOIK-ohjaussovitin, WinCC OA-järjestelmä, PLC logiikka, DriverManager ja X-AID-palvelin.
Kuvio 1. Järjestelmän yleisarkkitehtuuri
Kuvio 1 havainnollistaa komponenttien rooleja ja niiden välisiä tiedonvälitystapoja. Jokai- sella komponentilla tässä kuvassa on oma roolinsa. Kamerat välittävät videokuvaa koneoppi- mispalvelimelle ja koneoppimispalvelin tunnistaa liikennehäiriöitä kuvavirrasta. XaidDriver, joka on toteutettu ajuriksi DriverManagerin sisälle, tulkkaa näitä viestejä. DriverManager re- kisteröityy WinCC OA:n aliprosessiksi. WinCC OA on SCADA-järjestelmä, eli se kommu- nikoi PLC-laitteiston kanssa ja tarjoaa graafisen käyttöliittymän liikenteen hallitsemiseksi sekä valvomiseksi tunnelissa.
PLC-laitteisto ohjaa alimman tason laitteistoa, eli esimerkiksi liikennepuomeja tai liiken- nevaloja. T-LOIK-ohjaussovitin kommunikoi SCADA-järjestelmän kanssa sekä toteuttaa T- LOIK-järjestelmän rajapinnan. T-LOIK ohjaa useita eri SCADA-järjestelmiä ja PLC-laitteistoja, toimien keskistettynä graafisena käyttöliittymänä liikennekeskuksen päivystäjälle.
XaidDriverin toteutus on siis suunnittelututkimuksen näkökulmasta Hevnerin ja Chatterjeen (2010) määrittelemä "wicked problem", eli kansankielisesti häijy ongelma. Tämänkaltaiset ongelmat Hevner ja Chatterjee määrittelevät seuraavilla tavoilla:
1 . Epätasaiset vaatimukset ja rajoitteet
2 . Kompleksiset interaktiot ongelman eri osakomponenttien välillä
3 . Luontainen joustavuus, joka vaikuttaa sekä suunnitteluprosessin että tuotoksien muutoksiin.
4 . Kriittinen riippuvuus ihmisten kognitiivisiin kykyihin luoda tehokkaita ratkaisuja 5 . Kriittinen riippuvuus ihmisten sosiaalisiin kykyihin, johtuen tiimityön tarpeesta
Lienee selvää, että tämän kokoisessa integraatioprojektissa jokainen näistä osioista täyt- tyy: pelkästään YSP Oy:lla on useita eri ihmisiä toteuttamassa ratkaisuja ongelman eri osa- alueisiin: ihmisiä suunnittelemassa IP-verkot sekä laitteiston välistä kommunikaatiota, ihmi- siä tuottamassa logiikkakoodia ja asentamassa PLC-laitteistoa, CTRL-skriptikieltä ja valvo- moa koodaavia ihmisiä, korkean tason ohjelmointikielten ratkaisuja tuottavia ihmisiä sekä projektipääliköitä. Kun tähän lisää yhteistyövaatimukset muiden yritysten sekä asiakkaan kanssa, on häijy ongelma syntynyt. Tässä suunnittelututkimuksessa pyritäänkin katsomaan tämän ongelman ratkaisua kokonaisuuden kannalta ja selittämään, kuinka tämänkaltaisen ongelman voi ratkaista.
Pro Gradun ymmärtämisen helpottamiseksi aloitetaan kokonaisuuden osien läpikäynti ma- talimmalta tasolta siirtyen koko ajan korkeammalle abstraktiotasolle. Tämä tarkoittaa, että ensin käsitellään PLC-laitteiston osuutta kokonaisuudessa, mistä siirrytään korkeammalle abstraktiotasolle SCADA-järjestelmiin. SCADA-järjestelmien läpikäymisen jälkeen keski- tytään REST-arkkitehtuuriin ja TLOIK-ohjaussovittimeen, sillä näiden kautta integroidaan tämä SCADA-järjestelmä T-LOIK:n järjestelmään. Komponenttien käsittelyn lopuksi käy-
dään läpi Microsoftin MEF-applikaatiot ja DriverManager, sillä näiden pohjalta toteutetaan XaidDriver. Lopulta siirrytään paneutumaan itse XaidDriverin suunnitteluun, toteutukseen ja testaukseen.
3 PLC
PLC (engl. Programmable Logic Controller) on pieni ohjelmoitava tietokone. Ohjelmoita- vat logiikat ovat alunperin kehittyneet korvaamaan traditionaaliset releet (Erickson 1996).
PLC:n kehitti General Motorsin automaattivaihteisto-osasto vuonna 1968 (Erickson 1996), Nykyään PLC-laitteisto toimii sekä CERN-tutkimuslaitoksessa (Fernandez Adiego, Prieto Barreiro ja Blanco Vinuela 2011) että liikennevaloissa. Näitä pieniä tietokoneita löytää kaik- kialta, sillä ne ovat yleiskäyttöisiä, nopeita ja niihin voi ohjelmoida oman logiikkansa. Kuten Erickson (1996) toteaa: "Ohjelmoitavat logiikat ovat automatisaation eturintamalla."
Vuosien aikana PLC:n käyttötapaukset ja erilaiset tarpeenmukaiset muunnokset ovat muut- taneet maailmaa. PLC-ohjelmoinnin perustana käytetään logiikkalohkoja. Ohjelmoitavat lo- giikkalohkot kehittivät David W. Page ja LuVerne R. Peterson vuonna 1985 (Page ja Peterson 1985).
Logiikkalohkojen tarkoituksena on toteuttaa boolean logiiikkaa ja ne toimivat logiikkaohjel- moinnin ohjelmointiparadigman mukaisesti. Alunperin PLC-ohjelmoinnin tärkein osa olivat LD:t (Ladder Diagram). Näiden diagrammien oli tarkoitus havainnoillistaa ohjelman raken- netta sähkökaaviota muistuttavalla tavalla.
Kuviossa 2 esitetty esimerkki on varsin yksinkertainen, mutta oikean elämän sovelluksissa vastaavia toiminnallisuuksia voi olla tuhansia. Myös ohjelmointi on työlästä: käytännössä LD:a käyttäessä ohjelmoija joutuu kehitysympäristössään valitsemaan jonkin komponentin, siirtämään sen haluamaansa paikkaan, valitsemaan toisen komponentin ja piirtämään näiden välille kytkennän.
Kuvio 2. Esimerkki LD:n syntaksista, lähde “Ladder Logic Examples” 2018-10-16.
Jo tämän esimerkin perusteella voinee ymmärtää, että vastaavanlaiset ohjelmat paisuivat no- peasti hyvin pitkiksi ja vaikealukuisiksi, mikä puolestaan teki PLC-ohjelmoinnista työläs- tä. Ratkaisuna on kehittynyt useita eri kieliä, joita sovelletaan useimmiten tarpeen mukaan:
kieli on usein valmistajakohtainen. Esimerkiksi Schneider Electricsin laitteisto - jota YSP pääasiassa käyttää - tukee Structured Text:iä.
Tässä pro gradussa keskitytään lähennä ST:iin, joka on määritelty PLCOpen IEC 61131-3 standardissa (Tiegelkamp ja John 1995). Nykyään tätä standardia seuraavia kieliä on viisi:
aiemmin mainittu LD ja ST, FBD (Function Block Diagram), IL (Instruction List, nykyään deprekoitunut) sekä SFC (Sequential Function Chart). Näistä kielistä erityistä huomiota tässä tutkielmassa saa ST, sillä tämän projektin PLC-laitteisto toimii sillä.
3.1 Structured Text
ST on tekstipohjainen verrattuna LD:n graafisuuteen. Sen ulkonäkö muistuttaa korkeamman tason ohjelmointikieliä ja sen syntaksi on varsin helppolukuista. Tarkemmalla tarkastelulla kuitenkin huomaa näiden ohjelmointikielten suuren eron, mistä syystä seuraavassa esimer- kissä havainnoillistetaan liikennevalon keltaisen valon käyttäytymistä (YSP Oy, 2019).
(∗ Y e l l o w f l a s h ∗)
i f s e q S t e p =1 o r s e q S t e p =6 o r s e q S t e p =8 o r s e q S t e p =10 t h e n d e v i c e O u t . c o n t r o l R e d L i g h t : = 0 ;
d e v i c e O u t . c o n t r o l G r e e n L i g h t : = 0 ;
i f s e q S t e p =1 t h e n
y e l l o w F l a s h C T U (CU: = y e l l o w F l a s h T O N 2 . Q , PV : = 0 , R : = 0 ) ; e n d _ i f ;
i f s c a d a S t a t u s . a l e r t C o m m u n i c a t i o n E r r o r =0 t h e n s c a d a S t a t u s . y e l l o w L i g h t F l a s h : = 1 ;
e l s e
s c a d a S t a t u s . y e l l o w L i g h t F l a s h : = 0 ; e n d _ i f ;
ELSE
s c a d a S t a t u s . y e l l o w L i g h t F l a s h : = 0 ; e n d _ i f ;
(∗ Y e l l o w f l a s h t i m e r s∗)
y e l l o w F l a s h T O N 1 ( IN : = ( s c a d a S t a t u s . y e l l o w L i g h t F l a s h = 1 ) and n o t ( y e l l o w F l a s h T O N 2 . Q) , PT : = T# 500 ms , Q =>
d e v i c e O u t . c o n t r o l Y e l l o w L i g h t ) ;
y e l l o w F l a s h T O N 2 ( IN : = ( s c a d a S t a t u s . y e l l o w L i g h t F l a s h = 1 ) and y e l l o w F l a s h T O N 1 . Q , PT : = T# 500 ms ) ;
(∗ Y e l l o w s o l i d ∗) i f s e q S t e p =2 t h e n
d e v i c e O u t . c o n t r o l R e d L i g h t : = 0 ; d e v i c e O u t . c o n t r o l Y e l l o w L i g h t : = 1 ; d e v i c e O u t . c o n t r o l G r e e n L i g h t : = 0 ; e n d _ i f ;
(∗ Red and y e l l o w ∗) i f s e q S t e p =4 t h e n
d e v i c e O u t . c o n t r o l R e d L i g h t : = 1 ; d e v i c e O u t . c o n t r o l Y e l l o w L i g h t : = 1 ; d e v i c e O u t . c o n t r o l G r e e n L i g h t : = 0 ; e n d _ i f ;
Jokaista eri valon väriä edustaa jokin numeerinen arvo, joka asetetaan status-arvoksi rekiste- riin. Lienee myös syytä huomauttaa, että automaatiomaailmassa tilavaihtumien toteutuksessa on aina sekä kontrolliarvo että statusarvo. Tämä johtuu siitä, että mahdollisten yhteysongel- mien tai muiden käyttämiseen vaikuttavien tekijöiden yhteydessä näin pystyy vertaamaan viimeksi annettua kontrolliarvoa ja varsinaista statusarvoa, varmistuen näin ohjauksen on- nistumisesta. Kuten SCADA-luvussakin tullaan huomauttamaan, automaatiojärjestelmissä luotettavuus on aina ensimmäinen prioriteetti.
Kieli sisältää mm. switch-case-lauseita, silmukoita, if-then-else -lauseita ja primitiivisiä funk- tioita (sqrt(), sin()). Myös perustietotyypit ovat mukana: bitit, kokonaisluvut, reaaliluvut, ajankesto, päivämäärä, ajankohta, päivämäärä ja ajankohta sekä tekstinpätkä. Myös muut- tujat voivat olla paikallisia tai globaaleja, eli samankaltaisuuksia olio-ohjelmointiin löytyy.
PLC-ohjelmat toimivat ikuisessa silmukassa, jossa toteutetaan erilaisia sekvenssejä.
ST:n operaattorit sekä lausekkeet voi karkeasti jakaa neljään eri luokkaan (“Structured Text Tutorial to Expand Your PLC Programming Skills” 2018-09-20):
1 . A r i t m e e t t i s e t o p e r a a t i o t 2 . R e l a a t i o n a a l i s e t o p e r a a t i o t 3 . L o o g i s e t o p e r a a t i o t
4 . B i t t i o p e r a a t i o t
Aritmeettiset operaatiot sisältävät summalaskut, negaatiot ja vähennyslaskut, moninkerrat, eksponentit, jakamisen sekä modulon. Relaationaaliset operaatiot puolestaan sisältävät yh- täkuin, pienempi kuin, pienempi tai yhtä iso kuin, suurempi kuin, suurempi tai yhtä iso kuin ja ei samankokoiset vertailut. Loogiset operaatiot ja bittioperaatiot puolestaan sisäl- tävät AND:in, OR:in, XOR:in ja NOT:in. Erona näiden käytössä bittioperaatioissa verrattu- na loogisiin operaatioihin on, että samat toiminnot suoritetaan bittitasolla, eli boolean logii- kan totuustaulujen mukaisesti (“Structured Text Tutorial to Expand Your PLC Programming Skills” 2018-09-20).
ST:n suurin hyöty on koodin kierrätettävyys (“Structured Text Tutorial to Expand Your PLC Programming Skills” 2018-09-20). LD:n graafisuuden sijasta tekstipohjainen ohjelmointi- kieli on suuri etu, sillä samaa koodia pystyy tällä tavalla helposti uudellenkäyttämään. Tii- vistettynä ST on siis tekstipohjainen vastaus LD:n graafiselle lähtökohdalle, minkä tuomat edut ovat merkittäviä verrattuna graafiseen kieleen. PLC-laitteiden tarvitsee kuitenkin usein kommunikoida toisten laitteiden kanssa. Tätä varten on kehitelty erilaisia tiedonsiirtoproto- kollia, joista yksi on Modbus.
3.2 Modbus Protokolla
Yksinkertaisissa laitteissa ja käyttötapauksissa, esimerkiksi yksinkertaisessa palohälyttimes- sä, riittää, että kolvaa kuparilangan kiinni virtapiiriin, jotta saa signaalin milloin kyseinen laite hälyttää. Kompleksisemmissa tapauksissa sovelletaan jotakin tiedonvälitys-protokollaa.
Yksi käytettävistä protokollista on Modbus. Modbus on myös tämän tutkielman kannalta olennainen, sillä projektin laitteisto käyttää Modbus-protokollaa.
Modbus on Modiconin (nykyään Schneider Electric) vuonna 1979 julkaisema sarjaliikenne- protokolla. Nykyään se toimii teollisuuden de facto -standardina, eli suurin osa maailman automaatiojärjestelmistä toimii Modbus-protokollalla (Phan 2012). Suuri osa nykyajan au- tomaatioista itseasiassa käyttää jonkinlaista muunnelmaa virallisesta Modbus-protokollasta.
Yksittäinen laite käyttää Modbus-protokollaa, jonka avulla se saa ohjeistuksensa logiikkaoh- jelmalta. Tämän jälkeen laite välittää viestinsä samalla protokollalla eteenpäin.
Jokainen modbus-yhteys koostuu ohjaaja-ohjattava (master-slave) -tyyppisestä kommuni- kaatiosta. Tämä tarkoittaa että master-laite lähettää viestejä, joita slave-laite kuuntelee ja to- teuttaa annetut käskyt. Modbus on sarjaliikenne protokolla, joka toimii parikaapelilla. Moni- mutkaisemmissa tapauksissa laitteeseen liitetään Ethernet-portti tai sarjakytkentä, mitkä kon- figuroidaan kommunikoimaan Modbus-protokollan kanssa, jolloin kyseiseen laitteeseen on mahdollista päästä käsiksi TCP/IP-protokollilla (Modbus 2004). Tällöin puhutaan Modbus- protokollan variaatiosta: Modbus TCP/IP - tai Modbus TCP -protokollasta. Muunneltu Mod- bus TCP siis vie Modbus protokollan TCP:n sovelluskerrokseen. Lukuisista Modbus-variaatioista huolimatta tässä tutkielmassa keskitytään lähinnä aiemmin mainittuun TCP/IP -variaatioon Modbus-protokollasta, sillä se on tämän projektin laitetoiminnan ymmärtämisen kannalta olennaisin variaatio kyseisestä protokollasta. Viestien välitys tapahtuu kirjoittamalla laittei- den rekistereihin erilaisia arvoja, joita lukemalla tämä laitteisto saa käskynsä.
Kuvio 3. Modbus TCP esimerkki, lähde: “How do you program and parameterize Mod- bus/TCP communication between S7-1500 CPUs and S7-1200 CPUs?” (2018-10-16).
Modbus TCP/IP -protokolla toimii hyvin samankaltaisella tavalla kuin perinteinen asiakas- palvelin -arkkitehtuuri, jota enemmistö internetistä käyttää. Modbus-protokollan käyttämä portti on 502. Modbus-viestin kehys koostuu sovelluksen data yksiköstä (ADU, Applica- tion Data Unit), joka kapseloi sisällensä protokolla data yksikön (PDU, Protocol Data Unit).
ADU koostuu osoitteesta, PDU:sta ja virheentarkistuksesta. PDU puolestaan kostuu funk- tion koodista ja datasta (Modbus 2004). Vaihtoehtoja protokollan viestintämuotoon on usei- ta, mutta Ethernet-verkoissa käytetään Modbus TCP kehystä, jonka Modbus 2004 määritte- lee seuraavan taulukon mukaisesti. Tässä taulukossa asiakas muodostaa kaikki nämä neljä kohtaa. Palvelin puolestaan kopioi tunnisteet ja käyttää niitä, muodostaen oman vastausvies- tinsä pituuskentän. Tämän kehyksen bittijärjestys on MSB (Most significant bit, merkittävin bitti ensimmäisenä).
Nimi Pituus Kuvaus
Transaktion tunniste 2 tavua Synkronisaatio palvelimen ja asiakkaan välillä Protokolla tunniste 2 tavua 0 = Modbus protokolla
Viestin pituus 2 tavua Viestin pituus kahdessa tavussa
Yksikön tunniste 1 tavu Slave-laitteen tunniste (255 jos ei käytössä) Taulukko 1. Modbus TCP:n rakenne
3.3 PLC käyttötapauksia
Koska PLC:n sisäisen logiikan pystyy itse ohjelmoimaan, ovat sen käyttötapaukset erit- täin vaihtelevia, mutta usein koordinaatiota vaativissa tehtävissä PLC-laitteisto yhdistetään SCADA-ohjelmistoon (Fernandez Adiego, Prieto Barreiro ja Blanco Vinuela 2011). Useim- mat automaatiojärjestelmät toimivat jonkinlaisella yhdistelmällä SCADA:a (Goldenberg ja Wool 2013) sekä PLC:tä (Erickson 1996). PLC:n levinneisyys on sellainen asia, mitä harva ihminen tulee edes ajatelleeksi. Näitä pieniä tietokoneita käytetään kaikkialla missä tarvitaan automaatiota: tehtaissa, ydinvoimaloissa, metrojärjestelmissä ja niin edelleen.
Tämän projektin liikenteenhallinta sekä LVIS-laitteisto toimivat PLC:llä. Tämä tarkoittaa esimerkiksi useita liikennevaloja, liikennepuomeja, kameroita, ilmanpuhaltimia, varoitus- merkkejä, tieopasteita sekä kaikkea muuta mitä tämänkaltaiseen suureen tunnelijärjestel- mään kuuluu. Kokonaisuuden hallitsemiseen tarvitaan SCADA:a (Supervisory Control and Data Acquisition), eli tuttavallisemmin valvomo-ohjelmistoa.
4 SCADA
SCADA (engl. Supervisory Control And Data Acquisition) on tietokoneohjelmisto- tai arkki- tehtuurityyppi, jolla yleisesti tarkoitetaan valvomo-ohjelmistoa. Kuten Boyer (2009) toteaa:
"SCADA teknologia on kehittynyt viimeisen 30 vuoden aikana suurien prosessien monito- riontiin ja kontrolloimiseen."
Useimmiten SCADA:a käytetään PLC-laitteiston monitorointiin ja käskyttämiseen (Daneels ja Salter 1999). Ajatus SCADA-ohjelmiston takana on saada hallitusti kerättyä tietoa useasta lähteestä ja pystyä reagoimaan erilaisissa tilanteissa valvomon käyttöliittymän kautta, kuten tulipalon syttyessä tai sähkövian ilmentyessä. SCADA-järjestelmät on usein myös mahdol- lista kahdentaa: sama sovellus voi omata URI:n sekä aktiivisesta että passiivisesta palveli- mesta, jolloin esimerkiksi yhteysvian sattuessa passiivisesta palvelimesta tulee sovelluksen aktiivinen palvelin ja toisinpäin. SCADA-järjestelmän on tarkoitus olla ennen kaikkea luo- tettava.
Usein nykyaikaiset valvomojärjestelmät kommunikoivat myös muiden järjestelmien kans- sa, joko internetin tai kirjoittamansa tietokannan kautta. Tämä tosin on tuonut esiin huo- mioita ja puutteita SCADA-järjestelmien tietoturvasta (Choi ym. 2010; Igure, Laughter ja Williams 2006; Ten, Liu ja Manimaran 2008). Esimerkiksi Suomessa on neljä tieliikenne- keskusta (Tampere, Helsinki, Turku, Oulu), joissa päivystetään tieliikennettä. Näiden kes- kuksien valvomoissa on useita SCADA-ohjelmistoja joilla ohjataan liikenneympäristöä, ku- ten tämän projektin tapauksessa. T-LOIK-hankkeen myötä liikennevirasto pyrkii yhtenäistä- mään liikennekeskuksen päivystäjän työn yhden käyttöliittymän taakse, joka välittää viestit eri SCADA ohjelmistoille. YSP Oy:n käyttämänä SCADA-ohjelmisto on WinCC Open Arc- hitecture.
4.1 WinCC Open Architecture
WinCC OA on Siemens kehittämä SCADA-järjestelmä, jonka tarkoituksena on visualisoi- da ja operoida erilaisia prosesseja, tuotantovirtoja, laitteita ja tehtaita kaikilla eri liiketoi- minnan osa-alueilla. Ohjelmiston hajautettu rakenne mahdollistaa jopa 2048 ohjausjärjes- telmän liittämisen toisiinsa saumattomasti (“The SCADA system without limits” 2018-08- 15). Lienee syytä mainita, että tässä puhutaan 2048:sta erillisestä järjestelmästä, eikä pel- kästään yksittäisistä laitteista. Jokainen näistä järjestelmistä voi omata lukuisia eri yhteyksiä eri PLC-laitteille. WinCC OA:n vahvuuksiin kuuluu sen tarjoama tehokkuus sekä skaalau- tuvuus (Spangenberg, Cerff ja Kaiser 2011). WinCC OA:ta pystyy kustomisoimaan usealla eri tavalla sekä se on alustariippumaton, eli siitä on myös saatavilla valmis jakelu Windows-, Linux-, iOS- ja Android -käyttöjärjestelmille (“SIMATIC WinCC Open Architecture - Ba- sic system” 2018-08-15). WinCC OA:n päälle on myös mahdollista suunnitella graafinen käyttöliittymä.
Pähkinänkuoressa WinCC OA:n tarkoitus on siis kerätä ja välittää dataa useaan eri lähtee- seen. Sen muokattavuuden yhdistäminen PLC-laitteistoon tarjoaakin erittäin paljon erilaisia käyttötapauksia, mistä syystä WinCC OA:n käyttötarkoitukset sisältävät useanlaisia erilaisia järjestelmiä. Näihin sisältyy esimerkiksi Norjan tieliikennekeskuksen liikenteenhallintajär- jestelmä, ohjaus- ja virheenraportointi järjestelmä Sveitsin rautateille, Ranskan Besançonin kaupungin katuvalaistuksen hallintajärjestelmä ja CERN-tutkimuskeskuksen hiukkasfysii- kan laboratorion hallintajärjestelmä (“SIMANTIC WinCC Open Architecture - HMI Softwa- re - Siemens” 2019-03-07).
WinCC OA:n ohjelmointikielenä toimii CTRL (control script language). CTRL:n syntaksi perustuu ANSI-C:n standardiin (“Control script language” 2018-08-15), eli se on C:n va- riantti, mikä tekee syntaksin opettelusta varsin triviaalia kokeneemmalle ohjelmoijalle. Ny- kyään WinCC OA tarjoaa myös rajapinnan C#-ohjelmointikielelle, minkä kautta voi lukea ja kirjoittaa prosessiarvoja, hälytyksiä ja historiadataa. WinCC OA tarjoaa myös rajapinnan erilaisille tietokannoille kuten Access, Oracle ja Microsoft SQL (“Control script language”
2018-08-15). Tämä mahdollistaa esimerkiksi erillisen web-sovelluksen luomisen, mikä tark- kailee WinCC OA:n käyttämän tietokannan dataa (Varela ym. 2018; Qiu ja Gooi 2000).
WinCC OA:lla on myös mahdollista luoda paneelitiedostoilla ja CTRL-skripteillä erilaisia komponentteja sekä yhdistellä näitä graafisen käyttöjärjestelmän luomiseksi. Tämän ohjel- miston suurin vahvuus on sen huomionarvoinen hajautettu arkkitehtuuri: järjestelmän eri osat on luotu yksittäisiksi erilaisiksi komponenteiksi, joita WinCC OA:n prosessimanageri tarkkailee ja käskyttää. Tällä periaatteella myös DriverManager rekisteröidään WinCC OA:n prosessimanagerin prosessiksi. WinCC OA on siis ennen kaikkea hajautettu järjestelmä, jo- ka rakentuu useista erilaisista komponenteista. Kun tähän käyttöliittymään yhdistää datan vastaanottamisen ja välittämisen, on valvomo-ohjelmisto valmis.
4.2 Datan vastaanottaminen ja välitys WinCC OA:ssa
Datan kulkemisketju tapahtuu datapointeilla. WinCC OA:ssa asetetaan jokin tietty tunnis- te datapointille. Tämä datapoint-rakenne voidaan myös konfiguroida kuuntelemaan Modbus TCP-yhteyttä jostakin tietystä osoitteesta. Tämä ei tietenkään ole pakollista, eli datapoint- teja voi myös käyttää väliaikaisena arvon säilytyspaikkana, johon C# API:n avulla voidaan syöttää jotain dataa, jota myöhemmin sitten käsitellään WinCC OA:n sisäisissä operaatiois- sa, kuten luvussa 8.4 esitetään. Jos datapoint sidotaan johonkin Modbus TCP -osoitteeseen, osoitetta koskevaa liikennettä pystyy käsittelemään WinCC OA:ssa ja C#-rajapinnassa viit- taamalla sen datapointtiin. Juuri tällä tavalla yksittäiset liikenteenhallinta laitteistot liitetään valvomojärjestelmään, joka sitten antaa niille käskyjä kuten valon vaihtaminen tai liikenne- puomin nostaminen.
Koska WinCC OA:n prosessiarvoja on mahdollista käsitellä eri ohjelmointikielillä ja se tarjo- aa C#-rajapinnan, C# on erittäin looginen valinta kun WinCC OA:n tuottamaa dataa ruvetaan tulkitsemaan ja välittämään muille sovelluksille.
5 REST-arkkitehtuuri & T-LOIK-Ohjaussovitin
REST (Representational State Transfer) on moderni arkkitehtuurimalli web-kehitykseen. Al- lapiilevät ominaisuudet ovat hyvin ohjelmistokohtaisia, mutta REST-arkkitehtuurin ohjelmat käyttävät aina HTTP-protokollan ominaisuuksia toteuttaakseen erilaisia operaatioita.
T-LOIK-Ohjaussovitin on REST-sovellus, jonka tarkoituksena on välittää T-LOIK:n viestejä PLC-laitteistolle ja SCADA-järjestelmille. Se toimii liitoksena liikennejärjestelmiin, joita T- LOIK ohjaa ja valvoo. Myös T-LOIK on REST-sovellus, joten kyseisen arkkitehtuurimallin ymmärtäminen on olennaista kokonaiskuvan hahmoittamisen kannalta. Tässä luvussa pyri- tään avaamaan REST-arkkitehtuuria sekä sen roolia moderneissa Suomen liikennejärjestel- missä.
5.1 REST-arkkitehtuuri
REST-arkkitehtuurin tarkoituksena on jakaa web-sovelluksen eri toiminnallisuudet selkeästi eroteltaviin kokonaisuuksiin. Arkkitehtuuri tarjoaa HTTP-protokollan yli erilaisia operaa- tioita, jotka ovat mahdollisimman itsenäisiä, eivätkä omaa riippuvuuksia toisiin sovelluksen operaatioihin. Kun sovellus toteuttaa REST-arkkitehtuurin, kutsutaan sovellusta RESTful- sovellukseksi. Kuten Feng, Shen ja Fan (2009) toteavat: "REST-arkkitehtuuri ei ainoastaan pysty hyödyntämään kaikkia HTTP-protokollan tarjoamia ominaisuuksia, vaan omaa myös yksinkertaisuuden tarjoaman edun."
Kuusi suunnitelmallista periaatetta ohjaavat RESTful-kehitystä (Erl ym. 2012):
1 . Asiakas-palvelin -arkkitehtuuri 2 . Tilattomuus
3 . Välimuistiin tallentamisen mahdollisuus 4 . Kerroksittainen järjestelmätoteutus
5 . Koodin välitystä tarvittaessa ("Code on demand") 6 . Yhtenäinen rajapinta
Ensimmäinen periaate on hyvin yleinen web-sovelluksien kannalta: jokin järjestelmä toimii palvelimena ja jokin asiakkaana, joka käyttää tämän palvelimen tarjoamia palveluja. Toinen on puolestaan yleisimpiä REST-kehityksen periaatteita: REST-arkkitehtuurin mukaan teh- dyn sovelluksen täytyy olla tilaton, eli jokainen operaatio on atominen eikä omaa jonkin toisen operaation suorittamista esivaatimuksena. Kuten Rodriguez (2008) toteavat: "Tässä yhteydessä tilattomuus parantaa web-palvelun suorituskykyä ja yksinkertaistaa palvelinpuo- len komponenttien suunnittelua ja toteutusta, sillä tilan puuttuminen poistaa tarpeen synkro- nisoida sessioiden dataa ulkoisten sovellusten kanssa."
Kolmas puolestaan on lähinnä sovelluksen suoritusnopeuden kannalta olennainen tekijä: vä- limuistissa olennaisen tiedon säilyttäminen nopeuttaa ohjelman käyttöä ja vähentää latenssia (Erenkrantz 2009). Välimuisti voi tässä tapauksessa olla palvelimen tai web-selaimen väli- muisti.
Neljännen periaatteen mukaan REST-arkkitehtuuria seuraavassa sovelluksessa tarkoittaa kom- ponenttien jakamista järkeviin kokonaisuuksiin, joissa matalamman tason resurssit tarjoavat toiminallisuuksiaan ylemmille tasoille. Tällä toteutuksella järjestelmän komponentit eivät tiedä mitään muista komponenteista, ainoastaan niistä joiden kanssa ne itse suoranaisesti kommunikoivat (Chou ja Li 2016). Kyseessä on siis kapselointia vastaava periaate.
Viides kohta - eli koodin välitys tarvittaessa - on vapaaehtoinen, mutta toteutuu esimerkiksi kun REST-sovellus tarjoaa web-selaimella Javascript-tiedostoja, joilla manipuloidaan web- sivun sisältöä ja välitetään viestejä palvelimelle (Masse 2011).
Kuudes kohta on olennainen REST-sovelluksen kehitykseen ja jakautuu erinäisiin alakoh- tiin, joiden tarkoituksena on tarkemmin määritellä kyseinen yhteinen rajapinta. Nämä koh- dat ovat: pyydettyjen resurssien identifiointi palvelupyynnöissä, kuten tietyn URI:n kutsu- minen tietyllä HTTP:n metodilla, resurssien manipulaatio representaatioiden kautta, atomi- set viestit, eli jokainen viesti omaa kaiken operaatioon vaadittavan tiedon sekä HATEOAS (Hypermedia as the engine of application state), eli hypermedia applikaation tilan mootto- rina (Thijssen 2012). Palvelinpuoli vain suorittaa näitä atomisia operaatioita, ja sovelluksen
"tila"päätellään siitä mitä operaatiota kutsutaan.
T-LOIK-ohjaussovittimen tapauksessa kaikki kohdat paitsi viides toteutuvat - kyseinen so- vellus ei omaa front endiä tai varsinaista käyttöliittymää, pelkästään RESTful operaatioita.
Esimerkiksi yksittäisen liikennevalon tilan hakemiseksi suoritetaan HTTP:n GET-operaatio tiettyyn URL-osoitteeseen, kuten esimerkiksi https://www.server.org/liikennevalo/id/status.
Jos taas laitteen tilaa halutaan muokata, suoritetaan erilainen HTTP-operaatio, kuten POST tai PUT eri URL-osoitteeseen. Jokainen aloituspiste ohjelmakoodin suoritukselle on sidottu johonkin HTTP-metodiin (GET, POST, PUT, DELETE) sekä osoitteeseen. REST-arkkitehtuuri seuraa CRUD-mallia (Create, Read, Update, Delete). Tämä malli asettaa raamit joiden mu- kaisesti kyseinen sovellus toimii.
5.2 T-LOIK-Ohjaussovitin ja Akka.NET
Akka.NET on .NET versio Javan Akka-ohjelmistokirjastosta. Akka.NET perustuu Aktori- suunnittelumalliin, jonka kehitti Carl Hewitt vuonna 1973 (Hewitt, Bishop ja Steiger 1973).
Akka.NET:in kehittäjien mukaan tämän kirjaston päämääränä on tarjota seuraavanlaisia toi- mintoja (“What is Akka.NET?” 2018-08-15):
1 . Monisäikeistä käytöstä ilman matalan tason konstruktioita, kuten lukkoja ja atomisuutta 2 . Läpinäkyvää etäkommunikaatiota eri järjestelmien ja komponenttien välillä
3 . Klusteroitua ja skaalautuvaa arkkitehtuuria
Aktori-suunnittelumallissa pyritään tarjoamaan abstraktiota, joissa komponenteista tai jär- jestelmistä tehdään omia aktoreitaan, jotka kommunikoivat keskenään asynkronisilla vies- teillä metodikutsujen sijasta. Aktorit ylläpitävät ja hoitavat omaa tilaansa sekä reagoivat aina vastaanottaessaan muutosviestin. Tämä reaktio voi olla esimerkiksi lapsi-aktorin luominen, itsensä pysäyttäminen, lapsensa pysäyttäminen tai viestin välitys toisille aktoreille (“What is Akka.NET?” 2018-08-15).
T-LOIK-Ohjaussovitin on adapteri-sovellus, joka välittää viestejä T-LOIK:n ja SCADA:n tai PLC-laitteiden välillä. Sovelluksen tarkoituksena on integroida useita eri SCADA-järjestelmiä ja PLC-laitteistoja T-LOIK:n käyttöliittymään, eli tulkita T-LOIK:n laittamien REST-kutsujen sisällä kulkevasta XML:stä varsinainen komento ja muuttaa se joko SCADA:n tai PLC- laitteen ymmärtämään muotoon.
T-LOIK-Ohjaussovittimen tapauksessa jokaista yksittäistä laitetta - kuten kamera, liikenne- valo, tiedotusopaste, puomi ja niin edelleen - edustaa yksittäinen aktori, joka toteuttaa ky- seisen laitteen vaatiman protokollan. Näitä protokolla-luokkia on tietenkin vain yksi, mutta ohjelmiston ollessa ajossa jokaisesta laitteesta luodaan oma erillinen aktori-instanssinsa. Tä- mä aktori on käytännössä C#-luokka, joka Akka.NET:iä hyödyntäen kuuntelee ja välittää viestejä laitteen ja T-LOIK:n välillä. Yksittäiset laitteet määritellään rekursiivisessa XML- tiedostossa. Esimerkiksi yksittäisen liikennevalon asetus voisi näyttää XML-muodossa tältä:
< a s e t u s n i m i = " l i i k e n n e v a l o 1 " k u v a u s = " l i i k e n n e v a l o n 1 a s e t u k s e t " >
< a s e t u k s e t >
< a s e t u s n i m i = " i d " k u v a u s = " l i i k e n n e v a l o n I d " a r v o = " 1 " / >
< a s e t u s n i m i = " o s o i t e " k u v a u s = " v a l o n i p−o s o i t e "
a r v o = " 1 2 7 . 0 . 0 . 1 " / >
< a s e t u s n i m i = " p r o t o k o l l a " k u v a u s = "AKKA. NET a k t o r i l u o k k a "
a r v o = " v a l o P r o t o k o l l a " / >
</ a s e t u k s e t >
</ a s e t u s >
Tämä aktori parsii T-LOIK:n REST-kutsulla lähettämän XML-tiedoston sisällöstä oleellisen ohjauksen, muuttaa sen PLC-laitteen tai SCADA:n hyväksymään muotoon, suorittaa ohjauk- sen, vastaanottaa kuittausviestin laitteelta ja parsii kuittausviestistä oleellisen tiedon ja kon- vertoi sen takaisin T-LOIK:n hyväksymään XML-muotoon. Akka.NET siis toimii työkaluna, jonka avulla PLC-laitteita saadaan käsiteltyä C#:n kaltaisen korkean tason ohjelmointikielen vaatimalla abstraktiotasolla.
Esimerkiksi liikennevalojen suoraohjauksessa - eli ilman SCADA-järjestelmää - ohjaussovit- timen liikennevalojen protokolla-aktori lukee tiedon kyseistä aktoria vastaavan laitteen IP- osoitteesta ja eri funktiokäskyjen sijainnit PLC-laitteen muistirekisterissä sekä omaa tarvit- tavat metodit tämän XML-käskyn konvertoimiseen muotoon, jonka PLC ymmärtää. Sinän- sä ohjausmetodi on samanlainen myös WinCC OA-järjestelmien kanssa: erona on lähinnä se, että muistiavaruuden osoitteiden ja hexalukujen sijasta käskyjä välitetään datapointteihin WinCC OA:n tukemassa muodossa. T-LOIK-ohjaussovittimen toimintaa kuvaa kuviossa 4 oleva tietovuokaavio:
Kuvio 4. T-LOIK-ohjaussovittimen tietovuo-kaavio
T-LOIK:in ohjatessa liikennevaloa T-LOIK laittaa verkon yli ohjaussovittimelle REST-kutsun, joka sisältää XML-datana esitetyn ohjauskäskyn. Ohjaussovitin lukee tämän käskyn, etsii sa- maa laitetyyppiä ja saman tunnisteen omaavan protokolla-aktorin ja lukee protokolla-aktorin luokan tiedoista sen IP-osoitteen sekä muut relevantit tiedot, minkä jälkeen ohjaussovitin suorittaa funktion, joka muokkaa tästä XML-käskyn datasta aktori-luokan määrittelemän ta- vutaulukon tai SCADA:n tapauksessa jonkin muun tietotyypin, jonka ohjaussovitin välittää PLC-laitteelle tai SCADA-järjestelmään. Samalla logiikalla välitetään tietoja PLC-laitteista ja SCADA-järjestelmistä T-LOIK:iin, nämä operaatiot vain suoritetaan päinvastaisessa jär- jestyksessä.
T-LOIK-Ohjaussovitin toteuttaa usean eri suunnittelumallin ominaisuuksia:
1 . AKKA.NET-kirjaston tarjoaminen aktoreiden avulla kyseinen applikaatio toteuttaa Aktori-suunnittelumallin (Actor Model).
2 . T-LOIK sekä T-LOIK-Ohjaussovitin voivat kummatkin toimia sekä palvelimena että asiakkaana, kommunikoiden keskenään REST-kutsuilla ja XML-tiedostoilla, joten se toteuttaa myös kahdensuuntaisen palvelin-asiakas-suunnittelumallin.
3 . Viestinvälittäjä-suunnittelumalli (Broker pattern) toteutuu, sillä T-LOIK:illa voi olla monta instanssia eri palvelimilla, mitkä kommunikoivat saman ohjaussovittimen kautta PLC-laitteistolle ja SCADA-järjestelmille.
4 . Modbus TCP:n toteuttamisen seurauksesta myös master-slave -arkkitehtuuria hyödynnetään paljon.
5 . SCADA-järjestelmien tavoin ohjaussovitin on mahdollista kahdentaa kahden eri palvelimen toimintaan, jotka tarvittaessa vaihtavat aktiivisen ja passiivisen palvelimen välillä. (Hot Standby)
Tämän ohjelmiston avulla SCADA-järjestelmä ja sen aliprosessiksi rekisteröity XaidDriver yhdistyvät T-LOIK:n järjestelmään.
6 Managed Extensibility Framework & DriverManager
MEF (Managed extensibility framework) on .NET 4.0 versiossa ensijulkaisunsa kokenut Microsoftin ohjelmistokirjasto (“Managed Extensibility Framework (MEF)” 2018-09-24).
MEF:in päätarkoitus on helpottaa ohjelmiston laajentamista, sillä se sallii laajennusten koo- din helpon kapseloinnin erillisiksi komponenteiksi, joita uudelleenkäytetään eri sovelluksien välillä ilman kovakoodattujen riippuvuuksien muodostamista (“Managed Extensibility Fra- mework (MEF)” 2018-09-24). DriverManager on C#-ohjelmointikiellä rakennettu ajurialus- ta WinCC OA -ohjelmille, joka on toteutettu .NET-kirjaston MEF-kirjastolla.
MEF-komponentit rekisteröidään isäntä-sovellukseen pelkällä konfiguraatio-tiedostolla, jon- ka jälkeen sovellus pystyy käyttämään näitä komponentteja. MEF tarjoaa tavan löytää uudet komponentit implisiittisesti: MEF-komponentti ilmaisee konfiguraatio-tiedostossa sekä riip- puvuutensa että tarjoamansa ominaisuudet. Kun yksittäinen MEF-komponentti (kutsutaan nimellä part) liitetään ohjelmistoon, MEF-kehyksen koostaja-moottori (MEF composition engine) liittää sen tarjoamat toiminnallisuudet muihin MEF-komponetteihin (“Managed Ex- tensibility Framework (MEF)” 2018-09-24).
Tässä käyttötapauksessa DriverManager on MEF-applikaatio, joka kuuntelee WinCC OA:n Datapointtien muutoksia ja toteuttaa niiden perusteella jotain operaatioita. DriverManagerin sekä ajurien mahdolliset riippuvuudet sijoitetaan WinCC OA:n kansiorakenteen sisälle, jol- loin Win CC OA:n projektimanageri löytää DriverManagerin .exe-tiedoston. Tämän jälkeen DriverManager rekisteröidään SCADA-järjestelmän projektimanageriin. Rekisteröinnin jäl- keen projektimanageri hoitaa DriverManagerin käynnistämisen, sulkemisen, uudelleenkäyn- nistämisen ja yleisen monitoroinnin. DriverManagerin konfiguraatiotiedostoon määritetään ajurien kansiosijainti. XaidDriverin koodin kääntämisestä syntynyt .dll-tiedosto sijoitetaan tietokoneella tähän määriteltyyn kansioon, jonka jälkeen DriverManager löytää ja käynnis- tää tämän ajurin.
Kuvio 5. DriverManager WinCC OA:n projektimanagerin aliprosessina
Kuviossa näkyy esimerkkikonfiguraatio WinCC OA:n projektinhallinta konsolista, jossa lis- tataan ohjelmaan ladatut erilliset komponentit, joita projektimanageri monitoroi. Viimeisenä prosessina näkyy WCCOADriverManager. DriverManager toimii MEF-sovelluksen liitos- kohtana WinCC OA-ohjelmistolle: konfiguraatiot toteutetaan JSON-muodossa. Esimerkik- si XaidDriverin konfiguraatio, joka sijoitetaan WinCC OA-järjestelmän tietorakenteeseen, näyttää simulaatiotilanteessa seuraavalta:
{
" i n p u t " : {
" x a i d " : {
" managerNumber " : 1 ,
" a c t i v e " : 1 ,
" c o n n e c t i o n N a m e " : " x a i d−1" ,
" a d d r e s s " : " h t t p : / / l o c a l h o s t : 1 1 1 8 0 / x a i d / " ,
" r e d u n d a n c y A d d r e s s " : " h t t p : / / l o c a l h o s t : 1 1 1 8 1 / x a i d / " ,
" o l d N e w C o m p a r i s o n " : t r u e ,
" p o r t " : " 9991 " ,
" r e d u n d a n c y P o r t " : " 9992 " ,
" i p " : " 1 2 7 . 0 . 0 . 1 " ,
" r e d u n d a n c y I p " : " 1 2 7 . 0 . 0 . 1 " ,
" c r e a t e X a i d D a t a p o i n t s " : f a l s e }
} }
DriverManager kyselee ja lukee nämä tiedot SCADA-järjestelmän tietorakenteesta. Käyn- nistyessään se kyselee jokaisen datapointin yleiset konfiguraatiot ja etsii ennaltamääritel- lystä paikasta tämänkaltaisia konfiguraatiotietoja. Output- ja input-kenttien sisällä olevan olion nimi määrittelee etsittävän ajurin. Esimerkiksi XaidInputDriver-luokassa on luokan nimeksi määritelty "xaid", joten DriverManager osaa yhdistää tämän konfiguraatiotiedos- ton ja löytyneen ajurin .dll-tiedoston. Tämä mahdollistaa ohjelman vaatimien peruspara- metrien välityksen: tämän JSON-tekstin lukeminen string-muuttujasta tarjoaa XaidDrive- rille HTTP-rajapinnan osoitteen sekä TCP-yhteyden IP-osoitteen ja portin. Näillä tiedoilla MEF-applikaatio käynnistää ajurin ja aloittaa välittämään dataa SCADA-järjestelmän ja X- AID-järjestelmän välillä.
Osasta datapointeista halutaan myös ajonaikaisesti lukea dataa JSON-muodossa. Tällaisten
{
" o u t p u t " : {
" x a i d " : {
" managerNumber " : 1 ,
" a c t i v e " : 1 ,
" t y p e " : " c a m e r a " ,
" i d " : 9 0 1 0 ,
" s e r v e r I d " : 1 ,
" c o n n e c t i o n N a m e " : " XaidCam−HKA10" ,
" c o n n e c t i o n S t r i n g " : " h t t p : / / l o c a l h o s t : 1 1 1 8 0 / x a i d / s i m u l a t o r / "
} } }
Tämä JSON kertoo DriverManagerille, että tämän datapointin arvojen muutosta halutaan kuunnella. Output-avaimen alla oleva xaid-avain puolestaan kertoo ajurin nimen. Tämä sallii tämän datapointin kenttien arvojen lähettämisen XaidOutputDriver-luokan funktiolle Out- putChangedAsync, joka sitten tulkitsee arvoja ja suorittaa parametrisoituja toimintoja.
7 X-AID häiriönhavaintojärjestelmä ja testivetoinen kehitys
X-AID häiriönhavaintojärjetelmä on keinoälyä ja koneoppimista hyödyntävä liikenteen mo- nitorointijärjestelmä. X-AID on AVID (Automatic Video Incident Detection) järjestelmä, eli koneoppimista hyödyntävä X-AID-palvelin analysoi jatkuvalla syötöllä sille saapuvaa video- kuvaa liikenteestä. Tämän projektin tapauksessa X-AID-järjestelmä valvoo tunnelin liiken- nettä mahdollisissa ongelmakohdissa ja välittää viestejä valvomoon. Hälytyksien lauetessa PLC-laitteisto laukaisee erilaisia liikenteenohjaus-sekvenssejä. Nämä sekvenssit esimerkiksi sulkevat kaistoja, vaihtavat liikennevaloja punaisiksi, sulkevat liikennepuomeja ja vaihtavat tieopasteiden tekstejä. Tämän tarkoituksena on lisätä liikenteen turvallisuutta ja sujuvuutta, vähentäen vaaratilanteita.
X-AID häiriönhavaintojärjestelmän kanssa kommunikoidaan pääasiallisesti TCP-yhteydellä.
Järjestelmä omaa myös yksinkertaisen HTTP-rajapinnan, jonka kautta pystyy esimerkiksi lataamaan johonkin tiettyyn hälytykseen sidotun videotiedoston. X-AID-palvelimen lähettä- mästä tavutaulukosta tulkitaan varsinainen viestisisältö käsittelemällä tavutaulukkoa X-AID- protokollan määritelmien mukaisesti. Tavutaulukko sisältää erilaisia muuttujatyyppejä, ku- ten char, UInt32, UInt16 ja niin edelleen, joita parsitaan protokollan määritelmien mukaises- ti. Varsinainen X-AID protokollan tekninen toteutus ja viestisisältö on määritelty järjestel- män toimittajan tarjoamassa dokumentissa 2017-098-T004-V1r5 - External TCP Interface - Technical Specification.pdf.
Onnistunut integraatio valvomojärjestelmiin ja tieliikenteen ohjausjärjestelmiin vaatii TCP- datan reaaliaikaista lukemista, protokollan tulkkaamista ja viestien välittämistä SCADA:n kautta PLC:lle ja takaisin. Jotta viestien välitys SCADA:n ja PLC:n suuntaan toimisi mahdol- lisimman esteettömästi, toteutettiin kyseinen tulkkiohjelma TCP-kuuntelijana DriverMana- gerin ajuriksi. Ajuri muodostaa myös aiemmin mainittuja HTTP-rajapinnan URL-osoitteita, jotka välitetään SCADA:n kautta T-LOIK:iin. Tätä kautta T-LOIK ja SCADA pystyvät la- taamaan hälytystapahtumista videotiedoston sekä kuvan HTTP:n kautta, ilman tarvetta TCP- virran tulkkaamiselle.
7.1 Kuvaus X-AID häiriönhavaintojärjestelmästä
Järjestelmän toimittajan mukaan (“Traffic Video Analysis / Automatic Video Incident De- tection - XAIDTM” 2018-09-27) osa-alueet joilla X-AID:ia voi hyödyntää ovat:
1 . Liikennevideoiden analysointi
2 . AVID-monitorointi tie-, tunneli- ja siltaosuuksilla
3 . Liikennerikkomusten ja epäsäännöllisyyksien havainnointi 4 . Liikenteen sujuvuuden monitorointi
Käytännössä X-AID vastaanottaa jatkuvaa videokuvaa tarkkailemastaan alueesta ja hälyt- tää TCP:n kautta ajuria, jos epäsäännöllisyyksiä ilmenee. X-AID-järjestelmään ohjelmoidut hälytykset ovat (“Traffic Video Analysis / Automatic Video Incident Detection - XAIDTM” 2018-09-27):
1 . Väärään suuntaan ajava ajoneuvo 2 . Pysähtynyt ajoneuvo
3 . Liikenneruuhka 4 . Hidas ajoneuvo 5 . Kävelijä
6 . Alentenut havainnointitaso (sumua, savua jne.) 7 . Esteitä tiellä
8 . Ajoradan ulkopuolella ajaminen
9 . Rekka-auto/Hidas ajoneuvo ohituskaistalla 1 0 . Keltaisen linjan ylitykset
1 1 . Ansalanka tiellä
Tästä listauksesta olennaisia tämän pro gradun kannalta ovat kohdat 1, 2 ja 4, sillä nämä hälytykset ovat ainoat tässä projektissa huomioon otettavat hälytykset. Juuri hälytykset 1,2 ja 4 toimivat laukaisimina PLC-laitteiston suorittamille liikenteehallinta-sekvensseille.
7.2 X-AID-simulaattori
X-AID-järjestelmän (Automatic Video Incident Detection (AVID)) protokollatulkin kehitys- tä varten järjestelmän toimittanut yritys tarjosi YSP Oy:lle käyttöön X-AID-simulaattorin.
Tämä simulaattori on toimitettu komentorivillä ajettavana .exe-tiedostona, joka pystyttää pai- kallisen palvelimen ja ajaa simulaattoria.
X-AID-simulaattori tarjoaa sekä TCP-rajapinnan, jonka kautta pääasiallinen kommunikaa- tio tapahtuu, sekä HTTP-rajapinnan, jolla pystyy aktivoimaan ja deaktivoimaan simuloituja hälytyksiä. Tämä mahdollistaa TCP-yhteyden ottamisen ja hälytyksien simuloinnin HTTP:n yli, jolloin TCP-yhteyden kautta saapuu informaatiota kyseisestä hälytyksestä.
Tarkemmat protokolla-määritelmät on myös tarjottu .pdf-tiedostoina. Näissä dokumenteissa määritellään tavutaulukkojen sisältö, protokollan rakenne ja sopivat C#-ohjelmointikielen tietotyypit sekä HTTP-kutsut joilla saa laukaistuja simuloituja hälytyksiä. Jokaisella viestillä on 16 tavun otsikko, jonka jälkeen seuraa varsinainen tietosisältö, jota tulkitaan järjestelmän toimittajan tarjoaman TCP-rajapinnan dokumentaation mukaisesti.
X-AID-simulaattori toimii varsinaisen kehitystyön selkärankana, sillä ottamalla TCP-yhteyden simulaattoriin ja laukaisemalla hälytyksiä HTTP-kutsuilla pystyy palvelimelta vastaanotta- maan simuloituja hälytyksiä, jotka vastaavat oikean elämän tilanteiden laukaisemia hälytyk- siä. Näiden simuloitujen tilanteiden käsittely tapahtuu siis aivan samalla tavalla kuin oikeas- sakin tilanteessa, mikä mahdollistaa itse protokollatulkin kehityksen.
Protokollamääritelmä tarjoaa myös selkeää osviittaa luokkasuunnitteluun, sillä on vähem- män työlästä käyttää luokkasuunnittelun pohjana jo valmiiksi tässä dokumentissa määritel- tyjä luokkarakenteita. Joka tapauksessa kyseisen simulaattorin tarjoama etu on huomattava verrattuna esimerkiksi tilanteeseen, jossa olisi tarjolla vain .pdf-tiedosto protokollamääritel- mistä. Tällöin järkevintä olisi kehittää simulaattori varsinaisen protokollatulkin kehityksen ohessa. Lähtökohdat huomioon ottaen viisain tapa kehittää kyseinen ajuri on siis testivetoi- nen kehitys (Test Driven Development).
7.3 Testivetoinen kehitys
Testivetoinen kehitys (Test Driven Development, TDD) on tapa suunnitella ohjelmistoja.
Aluksi vaatimuksista eritellään selkeät käyttötapaukset, joiden perusteella rakennetaan yksikkö- ja integraatiotestit. Tämän jälkeen testejä vasten kehitetään itse ohjelmistoa, eli testit kirjoi- tetaan ennen varsinaista ohjelman sisältöä. Testivetoisen kehityksen prosessin pystyy jaotte- lemaan viiteen osaan (Beck 2003):
1 . Luo testi
2 . Aja testit ja katso epäonnistuuko kyseinen uusi testi 3 . Kirjoita koodi
4 . Aja testit
5 . Refaktoroi koodi
Tämän kehitystavan päämääränä on tuottaa helposti luettavaa ja siistiä koodia (Beck 2003).
Tarkoituksena on siis luoda epäonnistuvia testejä, luoda koodia joka toteuttaa testin läpäi- semiseen vaadittavat operaatiot ja testien läpäisemisen jälkeen suorittaa tarvittavaa refakto- rointia.
Testivetoisen kehityksen etuja ja haittoja on tarkasteltu useassa eri tutkimuksessa: esimer- kiksi George ja Williams 2004 suorittivat kokeen, jonka tuloksista huomattiin, että testi- vetoista kehitystä toteuttaneiden ohjelmoijien koodi oli parempilaatuisempaa, sillä heidän koodinsa läpäisi 18% enemmän black-box testeistä kontrolliryhmään verrattuna. Tosin hait- tana huomattiin, että testivetoista kehitystä toteuttavilla ohjelmoijilla kesti keskimäärin noin 16% enemmän aikaa. Myös IBM:n suorittamassa kokeessa (Maximilien ja Williams 2003) huomattiin, että testivetoisen kehityksen avulla defektien määrä laski noin 50%. Automaa- tiojärjestelmissä luotettavuus on luonnollisesti hyvin tärkeää, joten testivetoisen kehityksen vahvuudet kannattaa hyödyntää tämän järjestelmäintegraation toteutuksessa.
8 XaidDriver
XaidDriver on X-AID-palvelimen rajapinta SCADA-järjestelmään. XaidDriver sijaitsee Dri- verManagerin ajurina, joka toimii myös X-AID-järjestelmän välittämän TCP-protokollan tulkkina sekä tämän suunnittelututkimuksen varsinaisena kohteena.
Hevner ja Chatterjee (2010) määrittelevät suunnittelututkimukselle kahdeksan eri kohtaa, joihin tutkimuksen pitäisi pystyä vastaamaan:
1 . Mikä on tutkimuskysymys? Mitkä ovat vaatimukset?
2 . Mikä on suunnittelututkimuksen artifakti? Miten artefaktin toiminnot ilmenevät?
3 . Mitä suunnitteluprosesseja tai heurestiikkoja käytetään artefaktin rakennuksessa?
4 . Miten artefakti on sidonnainen todellisuuteen? Mitkä teoriat tukevat artefaktin suunnittelua ja suunnitteluprosessia?
5 . Mitä evaluaatioita suoritetaan suunnittelusyklien aikana?
6 . Kuinka artefakti liitetään sovellusten ympäristöön ja kuinka sitä kenttätestataan?
7 . Mitä uutta tietoutta tämän artefaktin suunnittelusta syntyy?
8 . Onko suunnittelukysymykseen vastattu?
Tässä tapauksessa tutkimuskysymys on kuinka tämänkaltainen häiriöhavaintojärjestelmä in- tegroidaan liikenteenhallintajärjestelmään. Tähän kysymykseen sisällöllisesti vastaa koko tutkielma. Vaatimukset myös määritellään erikseen myöhemmin luvussa 8. Suunnittelututki- muksen artefakti puolestaan on X-AID-järjestelmän valvomo-ohjelmiston ajuri, eli XaidDri- ver. Suunnittelussa käytettyjä suunnittelumalleja ja heurestiikkoja käydään läpi luvussa 8.2 sekä luvussa 8.1. Evaluaatioina puolestaan toimivat yksikkötestit, integraatiotestit sekä kent- tätestit, joita käydään läpi luvussa 9. Ajurin integraatiota olemassaolevaan ympäristöön puo- lestaan avataan luvussa 8.3. Tutkimuskysymykseen vastaaminen ja uuden tiedon syntymistä puolestaan pohditaan luvussa 10.
Aiemmin mainitun mukaisesti XaidDriver toteutettiin DriverManagerin ajuriksi, jotta kom- munikointi WinCC OA:n suuntaan on helpompaa. Tämän lisäksi kehityksessä hyödynne-
jaston tarkoitus on yksinkertaistaa TCP- tai UDP-yhteyksien luomista, sillä se on geneeri- nen protokollatulkki-ohjelmistokirjasto. ProtoLib tarjoaa muutaman pakollisen toteutettavan rajapinnan: IEncoder, IDecoder ja IMessageHandler. Näihin rajapintoihin kirjoitetaan sovel- luskohtaiset koodit, mutta muuten itse kirjaston alustaminen on varsin yksinkertaista, kuten luvun 8 koodista havaitsee.
ProtoLib-protokollakirjasto perustuu DotNetty-kirjastoon, joka on käännös Javan Netty-kirjas- tosta. Hyödyntämällä näitä olemassaolevia kirjastoja ja komponentteja itse kehitystyössä säästetään paljon aikaa. Muun muuassa SCADA-järjestelmän datanvälityksen kahdennuksen ja TCP-protokollatulkin perustoimintojen toteutuksen pystyy näin hyvin pitkälti ohittamaan.
Suurin osa työstä menee siis protokollakohtaisten enkoodereiden ja dekoodereiden rakenta- miseen, datan mallintamiseen C#-luokiksi ja useiden eri komponenttien integraatioon.
Ajuri on TCP-asiakas. Se pyörii DriverManagerin päällä ikuisessa silmukassa ja ottaa ti- lattomasti DotNettyä hyödyntävän ProtoLibin avulla vastaan X-AID-palvelimen lähettämiä viestejä ja parsii niistä C#-representaatiot sekä välittää vastaanottamaansa tietoa SCADA:n kautta PLC:lle ja takaisin PLC:ltä SCADA:n kautta palvelimelle. Pääasialliset toiminnalliset vaatimukset ovat seuraavat:
1 . Ajuri tulkkaa ja muodostaa X-AID protokollan määritelmän mukaisia viestejä
2 . Ajuri lähettää ja vastaanottaa dataa X-AID-järjestelmän ja SCADA-järjestelmän välillä 3 . Ajuri koostaa X-AID -järjestelmän lähettämän datan perusteella luokkarakenteet ja
välittää sen tiedot SCADA:an.
4 . Ajuri ylläpitää omissa malli-luokissaan järjestelmän tämän hetkistä tilaa.
5 . Järjestelmä koittaa uudelleenyhdistää X-AID -järjestelmään yhteysvian sattuessa.
6 . Järjestelmä osaa uudelleenkäynnistyä tietokoneen kaatuessa.
7 . Järjestelmä osaa tunnistaa kumpi palvelimista on tällä hetkellä aktiivinen ja kumpi passiivinen
8 . Järjestelmä on luotettava, sillä se tulee pyörimään kellon ympäri SCADA:n aliprosessina.
9 . Järjestelmä osaa alustaa itsensä asennuksen ja käynnistyksen tapahtuessa
yksittäisten kameroiden aiheuttamat hälytykset
1 1 . Järjestelmä kykenee vaihtamaan aktiivisen ja passiivisen X-AID palvelimen välillä mahdollisen yhteysvian sattuessa
Kuudennen kohdan hoitaa aiemmin mainittu WinCC OA:n prosessimanageri Pmon, jon- ka aliprosessiksi DriverManager rekisteröityy. Seitsemäs kohta puolestaan on jo toteutet- tu DriverManager-ohjelmistossa, jonka ajuriksi XaidDriver rekisteröityy. Toinen kohta vaa- timuksista on toteutettu ProtoLib-kirjaston avulla, joka alustetaan DriverManagerin Input- rajapinnan toteuttavassa XaidInputDriver-luokassa. ProtoLib-kirjaston alustuksen toteuttava funktio näyttää seuraavanlaiselta:
/ / / <summary >
/ / / I n i t i a l i z e s t h e p r o t o l i b i n s t a n c e / / / </ summary >
/ / / < param name= " p o r t " > </ param >
/ / / < param name= " i p " > </ param >
p u b l i c P r o t o L i b C l i e n t I n i t i a l i z e P r o t o l i b ( s t r i n g p o r t , s t r i n g i p ) {
L o g g e r . I n f o ( " I n i t i a l i z i n g p r o t o l i b " ) ; S o c k e t C h a n n e l C o n f i g _ s o c k e t C h a n n e l = new
S o c k e t C h a n n e l C o n f i g . S o c k e t C h a n n e l C o n f i g B u i l d e r ( ) . S e t K e e p A l i v e (t r u e)
. B u i l d ( ) ;
_ c l i e n t C o n f i g = new C l i e n t C o n f i g B u i l d e r ( ) . S e t C h a n n e l C o n f i g ( _ s o c k e t C h a n n e l )
. S e t S e r v e r I p A d d r e s s ( I P A d d r e s s . P a r s e ( i p ) ) . S e t S e r v e r P o r t ( i n t . P a r s e ( p o r t ) )
. B u i l d ( ) ;
_ f r a m e D e c o d e r C o n f i g = new
L e n g t h F i e l d B a s e d F r a m e D e c o d e r C o n f i g B u i l d e r ( ) . S e t B y t e O r d e r ( B y t e O r d e r . L i t t l e E n d i a n ) . S e t L e n g t h F i e l d O f f s e t ( 4 )
. S e t L e n g t h F i e l d L e n g t h ( 4 ) . S e t L e n g t h A d j u s t m e n t (−8)
. S e t M a x F r a m e L e n g t h ( I n t 3 2 . MaxValue ) . S e t F a i l F a s t (t r u e)
. B u i l d ( ) ;
_ d e c o d e r B u i l d e r = new
R e s p o n s e D e c o d e r S e r v i c e . R e s p o n s e D e c o d e r B u i l d e r ( ) . S e t O b s e r v e r ( t h i s ) ;
_ e n c o d e r B u i l d e r = new
R e q u e s t E n c o d e r S e r v i c e . R e q u e s t E n c o d e r B u i l d e r ( ) ;
_ m e s s a g e H a n d l e r = new M e s s a g e H a n d l e r ( new TimeSpan ( 0 , 0 , 6 0 ) , new TimeSpan ( 0 , 0 , 6 0 ) ) ;
_ c l i e n t B u i l d e r = new C l i e n t B u i l d e r ( ) . S e t C l i e n t C o n f i g ( _ c l i e n t C o n f i g )
. S e t F r a m e D e c o d e r C o n f i g ( _ f r a m e D e c o d e r C o n f i g ) . S e t D e c o d e r B u i l d e r ( _ d e c o d e r B u i l d e r )
. S e t E n c o d e r B u i l d e r ( _ e n c o d e r B u i l d e r )
. S e t I n b o u n d M e s s a g e H a n d l e r ( _ m e s s a g e H a n d l e r ) ;
r e t u r n _ c l i e n t B u i l d e r . B u i l d ( ) ; }
Loput listauksessa esille tulleet kohdat on toteutettu ajuriin, jonka rakenne ja sovelletut suun- nittelumallit sekä vaatimusten täyttyminen käydään läpi tarkemmin seuraavissa luvuissa.
8.1 Oliosuunnittelu ja XaidDriver
Koska kyseessä on integraatioprojekti ja kyseisessä projektissa on tarjottu avuksi järjestel- män tarjoajan kehittämä simulaattori sekä kyseisen simulaattorin dokumentaatio, on hel- pointa aloittaa oliosuunnittelu sekä testien suunnittelu seuraamalla kyseisen dokumentaation datarakenteita.
Palvelimelta vastaanotetuista viesteistä mallinnettiin C#-luokkia ja luokkien sisältöjen pe- rusteella niistä muodostettiin hierarkia. Hierarkian perusteella nämä luokat voi luokitella kolmeen eri pääkategoriaan:
1. Koko järjestelmän laajuista informaatiota tai asetuksia. Näiden kantaluokkana toimii Xaid- SystemParameters.
2. Analysaattori-palvelimet ja niihin liittyvät luokat. Kantaluokkana toimii Server.
3. Yksittäiset kamerat. Jokaisella kameralla on tila, asetukset, isäntäpalvelin, kaistakohtaisia tilastoja ja erilaisia hälytyksiä. Kantaluokkana toimii Camera.
Toiminnallisuuksien perusteella eritelty arkkitehtuurikuvaus tiedonkulusta ja ohjelmiston tehtävistä on seuraavanlainen:
37
Tässä kuvataan SCADA:n aliprosessina toimivan DriverManagerin suhde XaidDriveriin se- kä XaidDriverin suhde sen hyödyntämään ProtoLib-kirjastoon. WinCC OA:n C#-Manager on C#-rajapinta WinCC OA:lle, jota DriverManager käyttää. XaidDriver hoitaa arvojen päi- vittämisen DriverManagerin kautta, mutta ohjelman alustuessa ensi kertaa se käyttää itsel- leen injektoitua referenssiä C#-Manageriin ja luo sen avulla ajurin vaatimat datarakenteet WinCC OA -järjestelmään. DatapointModifer-luokka siis toteuttaa luvun 8 vaatimusten koh- dan numero 9.
XaidInputDriver ja XaidOutputDriver toteuttavat DriverManagerin määrittelemät rajapinta- vaatimukset ja rekisteröityvät DriverManageriin. Molemmat näistä omaavat funktiot, jotka käynnistyvät kun WinCC OA:n datapoint arvot muuttuvat. Lienee silti tärkeää huomata, että DriverManager tarkkailee vain datapoint-rakenteita joissa on erikseen määritelty konfiguraa- tioissa DriverManagerin vaatima asetus JSON-tiedosto, kuten kappaleessa 6 esitettiin. Kum- matkin näistä luokista omaavat XaidSingleton-luokan avulla referenssin samaan staattiseen ajuriin. Tämän ajurin pääasiallinen luokka on XaidDriver.
XaidDriver on ajurin kantaluokka. Tämä luokka omaa ajantasalla olevat tiedot X-AID-järjestel- män tämänhetkisestä tilasta. Kommunikaation X-AID-järjestelmään XaidDriver toteuttaa hyödyntämällä ProtoLib-ohjelmistokirjastoa, toteuttamalla sen vaatimat rajapinnat: IClient- MessageHandler, IDecoder ja IEncoder. IClientMessageHandlerin rajapinnan toteuttaa Mes- sageHandler-luokka, joka omaa viestien lukemisen ja lähettämisen lisäksi muun muassa toi- minnallisuudet viestijonojen luomiseen sekä virheenkäsittelyyn. XaidDecoder ja XaidEnco- der puolestaan toteuttavat rajapinnat IDecoder ja IEncoder. Koska XaidDriver säilyttää tul- kattavien olioiden tilan ja rakenteen, se toteuttaa luvun 8 vaatimusten kohdan numero 4.
XaidDriver omaa myös ajastimen, jonka perusteella lähetetään protokollamäärityksen mu- kaista ping-viestiä viiden sekunnin välein. Tämä johtuu siitä, että X-AID-järjestelmä sulkee yhteyden mikäli asiakas ei lähetä yhteyden ylläpitoviestiä 10 sekunnin välein. Tämä funktio näyttää seuraavanlaiselta:
/ / / <summary >
/ / / S e n d s p i n g m e s s a g e t o X−AID s e r v e r .
/ / / </ summary >
p u b l i c a s y n c v o i d S e n d P i n g M e s s a g e ( ) {
i f ( ! _hostName . E q u a l s ( E n v i r o n m e n t . MachineName ) ) {
i f ( _ c l i e n t . A c t i v e ) a w a i t _ c l i e n t . C l o s e A s y n c ( ) ; i f ( _ r e d u C l i e n t ! = n u l l && _ r e d u C l i e n t . A c t i v e ) a w a i t
_ r e d u C l i e n t . C l o s e A s y n c ( ) ; r e t u r n;
}
i f ( _ c l i e n t . A c t i v e ) {
t r y {
a w a i t S e n d R e q u e s t ( Command . K e e p A l i v e , ( u l o n g ) 1 2 3 4 5 6 1 7 8 9 1 0 , M e s s a g e I d , 2 4 ) ; }
c a t c h {
L o g g e r . E r r o r ( $ " E x c e p t i o n o c c u r r e d w h i l e s e n d i n g a r e q u e s t t o X−AID s e r v e r . " ) ;
a w a i t C h e c k F o r R e d u n d a n c y ( ) ; }
} e l s e
{
t r y {
a w a i t C o n n e c t ( ) ; }
c a t c h
L o g g e r . E r r o r ( $ " Couldn ’ t r e c o n n e c t t o Xaid−S e r v e r ! " ) ; a w a i t C h e c k F o r R e d u n d a n c y ( ) ;
} } }
Tämä funktio siis yrittää myös uudelleenyhdistää ajurin X-AID-palvelimelle, mikäli yhteys on katkennut. Funktion alussa myös tarkistetaan, että tämä instanssi ajurista on aktiivisella SCADA-palvelimella sijaitseva instanssi. Mikäli näin ei ole, suljetaan yhteys eikä yhteyt- tä enää oteta, ellei aktiivisen palvelimen nimi vaihdu kyseisen tietokoneen nimeksi. Tämän avulla siis toteutetaan luvun 8 vaatimusten kohta numero 5 ja varmistetaan kohdan numero 7 toteutuminen. Samalla mahdollisten yhteysongelmien sattuessa tämä funktio koittaa vaihtaa aktiivisesta palvelimesta passiiviseen palvelimeen ja takaisin yhteyden luomiseksi, kunnes jompi kumpi näistä palvelimista vastaa. Tällä tavalla saadaan myös toteutettua luvun 8 vaa- timusten kohta numero 11. Ajuri toteuttaa vaihdoksen aktiivisen ja passiivisen palvelimen väliä funktion CheckRedundancy avulla, mikä näyttää tältä:
/// <summary>
/// If the client can’t be reached in the ping message (default: 5 seconds),
/// the driver will attempt to switch to using the alternative client.
/// </summary>
private async Task CheckForRedundancy() {
if ( _reduClient != null) {
Logger.Warn("Attempting redundancy switch!");
ProtoLibClient switchClient = null;
await _client.CloseAsync();
switchClient = _client;
_client = _reduClient;
_reduClient = switchClient;
string url = _baseUrl;
_baseUrl = _reduBaseUrl;
_reduBaseUrl = url;
try {
await _client.ConnectAsync();
await DefaultDataPointQueries();
SubscribeToEvents();
} catch {
Logger.Error("Couldn’t connect to redundant server!
Attempting again in 5 seconds.");
} } }
Tällä funktiolla siis vaihdetaan aktiivista ja passiivista palvelinta virhetilanteessa. Tämän li- säksi tarkkaillaan SCADA:n aktiivisen ja passiivisen palvelimen tilatietoja välittävää datapoint- arvoa, jonka perusteella päätellään ottaako tämä kyseinen instanssi ajurista yhteyttä X-AID -palvelimeen. Tämä funktio puolestaan näyttää tältä:
/ / / <summary >
/ / / S u b s c r i b e s t o r e d u n d a n c y d a t a p o i n t i n SCADA and d i s c o n n e c t s o r c o n n e c t s upon h o s t name c h a n g e
/ / / </ summary >
p r i v a t e a s y n c T a s k S u b s c r i b e T o R e d u n d a n c y ( ) {
O a V a r i a n t s u b s c r i p t i o n V a l u e = n u l l ;
O a D p V a l u e S u b s c r i p t i o n V a l u e S u b s c r i p t i o n = n u l l ;
