arvio.tex

\chapter{Tulosten arviointi ja pohdinta}
\label{ch:arviointi}
Diplomityössä toteutettu ohjelma ei ole ollut tuotannossa osana muuta järjestelmää vielä kovin kauan. Kuitenkin tähän mennessä se on toiminut ongelmitta. Varmasti ei voida arvioida, että ohjelmassa ei tulisi ongelmia tulevaisuudessa, mutta ainakin alun perusteella tulokset näyttävät toimivilta. Tältä osin voidaan arvioida, että diplomityö pääsi asetettuihin tavoitteisiin onnistuneesti ja halutut vaatimukset saatiin täytettyä. Kuitenkin toimivuudesta huolimatta toteutuksessa on kohtia mitä voitaisiin parantaa, tehdä toisin ja jatkokehittää. Nämä ovat kuitenkin tulevaisuudessa yrityksen sisällä tehtäviä työtehtäviä tai mahdollisesti toisen diplomityön aiheita.

Työn aikana järjestelmän hajautukseen pohdittiin eri paradigmojen sopivuutta ja huomattiin, että siihen sopisivat julkaisija-tilaaja-, joukkokommunikointi- ja viestijono-pa\-ra\-dig\-mat. Toteutukseen valittiin AMQP-standardi, joka mahdollisti julkaisija-tilaaja- ja viestijono-pa\-ra\-dig\-mat, mutta ei suoraan ollut tarkoitettu joukkokommunikointiin. Tämän takia joukkokommunikointi jätettiin pois ja korvattiin julkaisija-tilaaja-paradigmalla. Kuinka hyvin joukkokommunikointi olisi sopinut toteutukseen ei ole tarkkaa tietoa. Kuitenkin julkaisija-tilaajan-paradigma jatkaa IEC 61850 -standardin määrittämää julkaisija-tilaaja-kom\-mu\-ni\-koin\-ti\-a IED-laitteen kanssa ja näin ollen sopii toteutukseen. Toteutukseen myös harkittiin MQTT-standardia AMQP:n sijaan, joka on pelkästään julkaisija-tilaaja-kom\-mu\-ni\-koin\-tiin tarkoitettu protokolla. AMQP kuitenkin valittiin tekijän aikaisemman kokemuksen ja muiden yrityksessä olevien henkilöiden keskustelun pohjalta. Koska joukkokommunikointi jätettiin pois toteutuksesta, olisi MQTT voinut sopia toteutukseen paremmin kuin AMQP sen keveyden takia.

IED-laitteelta tuleva viesti päätettiin muuntaa JSON-muotoon XML:än sijaan. Vertailua kahden välillä tehtiin ja päätös oli aikaisemmin tutkimuksen perusteella selvä. JSON-muoto on kevyempi kuin XML ja sopii viestin muotona hajautettuun järjestelmään. Suunniteltu JSON-rakenne on toiminut käytön ajan tarpeiden mukaan. Kuitenkin siinä oli kohtia mitä pystyisi toteuttamaan toisin. Esimerkiksi \emph{bit-string} tyypin bittijärjestys (endian) voi vaihdella muuttujien välillä ja tämän takia siitä JSON-viestiin julkaistiin kaksi eri arvoa \emph{valueLittleEndian} ja \emph{valueBigEndian} (liite \ref{ch:report-json-format} rivit 23--24). Tällä vastuu muuttujan oikein lukemisesta siirretään tilaajalle. Standardissa kuitenkin on määritetty, kuinka päin muuttuja esitetään, jos se on tyyppiä bit-string. Tämän vastuun voisi siis siirtää rcb\_sub-ohjelman puolelle ja tarjota JSON-viestissä pelkkä \emph{value}-kenttä, niin kuin kaikille muillekin muuttujille. Tämä lisäisi JSON-rakenteen yhtäläisyyttä ja helpottaisi sen lukua. Lisäksi aikatyypit \emph{utc-time} JSON-viestissä päätettiin antaa siinä muodossa missä ne tulevat IED-laitteelta, eli millisekunteja UNIX-ajanlaskusta (epoch). JSON ei määritä käytettävää aikaformaattia, mutta JSON-rajapintoihin suositellaan käytettäväksi ISO 8601 -standardin aikaformaattia \cite{json-api-specification}.

Ennen tuotantoversion toteutusta demon ongelmia analysoitiin. Saatujen tuloksien pohjalta toteutuksen ohjelmointikieleksi valittiin C-kieli sen suorituskyvyn takia. Suurin syy demon huonoon suorituskykyyn oli Ruby-oletustulkin GIL, joka rajoittaa yhden säikeen suorituksen kerrallaan ja estää rinnakkaisuuden. Tämän lisäksi pienempi syy oli Ruby-kielen hitaampi suorituskyky verrattuna C-kieleen. C-kielen valinta oli hyvä ratkaisu. Ohjelman aika kaikkien RCB-instanssien tilaamiseen saatiin alas noin 30 sekunnista alle 15 sekuntiin. Nyt suurin osa ajasta tulee IED-laitteelle tehtävien kutsujen määrästä ja niiden odottamisesta. Demon muistinkäyttö Ruby on Rails -ympäristössä oli noin 150 Mt. Rcb\_sub:in muistin käyttö saatiin noin 4 kt, joka on todella iso muutos aikaisempaan nähden. Tekniikan valinnan suhteen päätökset onnistuivat hyvin.

Ohjelman kehityksen aikana noudatettiin C-ohjelmoinnin ohjeistoa. Tarkoituksena välttää sen yleisimpiä virheitä, esimerkiksi tekstin formatointihyökkäys \cite{format-string-attack} ja muistin ylivuoto \cite{buffer-overflow-attack}. Tähän käytettiin apuna GCC-kääntäjän vipuja esimerkiksi \texttt{-Wall} ja \texttt{-Wextra} \cite{gcc-manual-warnings}. Huolellisesta ohjelmoinnista huolimatta järjestelmään tulee tietoa ulkopuoliselta IED-laitteelta, joka voi sisältää vahingollista tietoa. Tämä osuus jätettiin pois, koska se ei kuulunut tämän diplomityön aiheen piiriin. Ohjelman tietoturva kuitenkin täytyy tarkistaa läpi tulevaisuudessa.

Järjestelmä aloittaa tilauksen käynnistämällä yhden rcb\_sub-prosessin per IED-laite. Tieto prosessille annettaan komentoriviparametreilla. Tilauksen muuttuessa, prosessi täytyy käynnistää uudelleen. Työn tekohetkellä ratkaisu sopi tarkoituksiin hyvin. Ratkaisuna olisi myös voinut toteuttaa yhden rcb\_sub-prosessin, joka pystyisi tilaamaan monta eri IED-laitetta rinnakkain, tai yhden IED-laitteen tilausta voisi muuttaa ilman, että prosessia täytyy käynnistää uudelleen. Tähän toteutustapaan tiedonsiirto komentoriviparametreilla ei enää onnistuisi vaan tarvittaisiin jokin muu kommunikointitapa. Tähän sopisi aikaisemmin käsitellyt prosessien väliset kommunikointiparadigmat, esimerkiksi pistokkeet. Toteutuksessa monen eri rcb\_sub-prosessin tilaamat viestit ohjataan saman RabbitMQ-palvelimen kautta eri reititysavaimilla. Järjestelmän skaalautuessa isommaksi joutuu RabbitMQ isomman kuorman alle, joka todennäköisesti muodostuu pullonkaulaksi. Tarkkoja rajoja tähän ei vielä tiedetä ja nykyinen keskitetty RabbitMQ-palvelin todettiin riittäväksi tarkoituksiin tällä hetkellä. Kuitenkin tulevaisuudessa tämä on asia mikä täytyy ottaa huomioon.

Ohjelma jätettiin työssä pisteeseen, missä se saavutti kaikki sille asetetut vaatimukset. Kuitenkin tulevaisuudessa ohjelmaa voidaan lisätä ominaisuuksia tarpeen vaatiessa. Isoin puute ohjelmassa oli testiympäristö ja sen yksikkötestit. C:ssä ei ole suoraan tukea yksikkötestien kirjoittamiseen. Ympäristön pystytys vaatii erillisen kirjaston projektin yhteyteen, jolla yksikkötestit kirjoitetaan. Yksikkötestit ovat tärkeä osa ohjelman ylläpitoa ja toiminnan varmistamista muutosten jälkeen. Testiympäristön ja testien toteuttaminen jäi tulevaisuuden kehitystyöksi.

Tässä diplomityössä suunniteltu arkkitehtuuri ja ohjelmistoratkaisut voivat toimia muissakin saman tyylisissä järjestelmissä, missä kommunikoidaan IEC 61850 -standardin mukaisesti ja tietoa julkaistaan eteenpäin. Periaatteessa suunnitelmasta olisi mahdollista toteuttaa oma kokonaisuutensa, jota olisi mahdollistaa käyttää muunkin järjestelmän kanssa. Tämä kuitenkin vaatisi tarkempaa suunnittelua ja edellä pohdittujen vaihtoehtojen käsittelyä.