-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathyhteenveto.tex
65 lines (58 loc) · 8 KB
/
yhteenveto.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
\chapter{Yhteenveto}
\label{ch:yhteenveto}
% Diplomityön tuloksena saatiin ohjelmistokomponentti osaksi muuta sähköasemiin liittyvää järjestelmää.
Diplomityön tuloksena saatiin ohjelmistokomponentti osaksi isompaa sähköasemiin liittyvää järjestelmää. Komponentti kykeni tilaamaan viestejä IED-laitteelta IEC 61850 -stan\-dar\-din mukaisesti, muuntamaan viestit JSON-muotoon ja jakamaan sen muun järjestelmän kanssa. Viestien jako järjestelmässä toteutettiin AMQP-standardiin pohjautuvalla välittäjäpalvelimella, joka käyttää julkaisija-tilaaja- ja viestijono-kom\-mu\-ni\-koin\-ti\-pa\-ra\-dig\-mo\-ja. Toteutetun systeemin arkkitehtuuri esitettiin kuvassa \ref{fig:planned-system-architecture}. Arkkitehtuurissa muu järjestelmä on vastuussa tilauksien orkestroinnissa ja rcb\_sub-prosessien suorituksesta.
% Yhteenveto asetetuista vaatimuksista ja kuinka ne saavutettiin.
Diplomityön alussa asetettiin vaatimuksia, jotka toteutuksen pitäisi pystyä täyttämään. Taulukossa \ref{tab:requirements-met} on esitetty yhteenveto asetetuista vaatimuksista ja kuinka ne tuontantoversiossa on täytetty. Taulukossa vaatimukset on esitetty niiden tunnuksilla, jotka asetettiin aikaisemmin kappaleessa \ref{ch:vaatimukset}.
\begin{table}[ht!]
\caption{Yhteenveto asetetuista vaatimuksiin ja kuinka ne täytettiin.}
\label{tab:requirements-met}
\begin{tabular}{p{0.11\linewidth} | p{0.82\linewidth}}
\hline
\textbf{Vaatimus\-tunnus} & \textbf{Kuinka vaatimus täytettiin} \\
\hline
% viestien tilaus sähköasemalta IEC 61850 -standardin mukaisesti
V1 & Viestit tilattiin käyttämällä libIEC61850-kirjastoa, joka hoitaa standardin mukaisen matalan tason kommunikoinnin. \\
\hline
% tilattujen viestien jakaminen järjestelmässä siitä kiinnostuvien komponenttien kanssa
V2 & Viestien jakamiseen käytettiin viestijono- ja julkaisija-tilaaja-kommunikointiparadigmoja, jotka toteutettiin AMQP-standardin mukaisella RabbitMQ-välittäjäohjelmistolla. \\
\hline
% tilattuja viestejä haluavien komponenttien määrä pitää pystyä muuttumaan järjestelmän tarpeiden mukaan
V3 & Komponentit pystyvät tilaamaan viestejä RabbitMQ-välittäjältä julkaisija-tilaaja-paradigman mukaan. Tilaajien määrää ei ole rajoitettu. \\
\hline
% muu järjestelmä ohjaa milloin viestien tilaus sähköasemilta aloitetaan ja lopetetaan
V4 & Järjestelmä ajaa rcb\_sub-ohjelmaa taustaprosessina ja antaa tilauksen tarvittavat tiedot sille komentoriviparametreillä. \\
\hline
% komponenttien täytyy saada ilmoitus uudesta viestistä ilman erillistä kyselyä
V5 & RabbitMQ-välittäjä tarjoaa ilmoituksen tilaajalle, kun uusi viesti julkaistaan. \\
\hline
% viestit puskuroidaan myöhempää käsittelyä varten jos komponentti ei ehdi niitä heti käsitellä
V6 & RabbitMQ-välittäjä tarjoaa viestijonoparadigman mukaisen jonon, jos tilaaja ei ehdi viestiä käsitellä. \\
\hline
% komponentin pitää pystyä suodattamaan viestit sen lähteen identiteetin perusteella
V7 & Rcb\_sub julkaisee viestit RabbitMQ-välittäjälle IED-laitteen tunnisteella, jolloin tilaaja voi tilata haluamansa viestit. \\
\hline
% viestien jakamisen muoto pitää olla helposti ymmärrettävä järjestelmän osapuolien kesken
V8 & IEC 61850 -standardin mukainen binääritason viesti muutettiin JSON-muotoon, joka on helpommin luettavissa ohjelmistolle ja ihmiselle. \\
\hline
% sähköasemalta tilattavien viestien määrä pitää pystyä muuttumaan tilauksien välillä
V9 & Rcb\_sub-ohjelmaa ajetaan taustaprosessina ja järjestelmä voi muuttaa tilauksen tietoja (RCB-instanssien määrä) syöttämällä eri komentoriviparametrit käynnistyksen yhteydessä. \\
\hline
% viestien välitystekniikka järjestelmässä täytyy tukea verkkopalvelun tapauksessa TCP/IP-protokollamäärityksiä
V10 & MMS-protokolla ja valittu AMQP-standardi toimivat TCP/IP-protokollaperheen päällä. \\
\hline
% tiedonsiirrossa lähetystakuu ei ole välttämättömyys
V11 & AMQP tarjoaa lähetystakuumekanismit julkaisijoiden ja tilaajien välille. \\
\hline
\end{tabular}
\end{table}
% Lähtökohtien avulla huomattiin että järjestelmän kommunikointiin tarvittiin viestijonoparadigma ja joukkokommunikointi tai julkaisija-tilaaja.
Työssä ratkaisua lähdettiin etsimään tarkastelemalla ensin hajautetun järjestelmän teoriaa, sen kommunikointiparadigmoja ja IEC 61850 -standardin määrityksiä. Saatuja tietoja apuna käyttäen suunniteltiin arkkitehtuuri osaksi muuta järjestelmää. Huomattiin, että viestijonoparadigma tarvittiin viestien puskurointiin ja kommunikointiin sopi jouk\-ko\-kom\-mu\-ni\-koin\-ti- tai julkaisija-tilaaja-paradigma.
% Toteutuksen tekniikaksi valittiin AMQP-standardi ja viesti päädyttiin muuntamaan JSON-muotoon.
Järjestelmän kommunikointiin valittiin AMQP-standardi, jonka myötä julkaisija-tilaaja-paradigma päätyi toteutukseen joukkokommunikoinnin sijaan. AMQP ei suoraan ollut tarkoitettu joukkokommunikoinnin toteuttamiseen. IEC 61850 -standardi määritti, että viestit IED-laitteelta tilataan julkaisija-tilaaja-paradigman mukaan. Toteutetun ohjelmiston ja valittujen paradigmojen voidaan sanoa jatkavan IED-laitteen tilausmekanismia ja näin ollen sopivat toteutukseen. Toteutus sallii monen tilaajan tilata sama viesti, mitä IEC 61850 -standardi ei ilman erillistä RCB-instanssia mahdollistanut. Viestin sisältö päädyttiin muuttamaan JSON-muotoon helpomman luettavuuden takia verrattuna MMS-protokollan binääriseen esitysmuotoon. Ohjelman tekemä JSON-muoto on nähtävissä liitteessä \ref{ch:report-json-format}. Edellä mainittujen pohjalta näiden osalta asetettuihin vaatimuksiin päästiin hyvin ja ne saatiin täytettyä. Nämä myös antavat vastaukset tutkimuskysymyksiin T1, T2 ja T3.
% Demon ongelmat ja niiden syyt.
Ennen diplomityön aloitusta tekijä oli yrityksessä toteuttanut demon ohjelmiston toimivuudesta. Demo oli tie oppia IEC 61850 -standardin toimintaa ja perehtyä aiheeseen tarkemmin ennen oikeaa toteutusta. Demossa oli kuitenkin ongelmia, mitkä haittasivat sen jatkokehitystä. Diplomityössä analysoitiin demon ongelmia, joita olivat huono suorituskyky, muistivuoto ja toiminnan epävarmuus. Toiminnan epävarmuuteen ja huonoon suorituskykyyn oli syynä Ruby-kielen oletustulkissa oleva globaali tulkkilukitus (GIL/GVL). Ja muistivuoto aiheutui huonosti toteutetusta Ruby- ja C-kielen välisestä liitoksesta.
% Kuinka tekniset ongelmat ratkottiin toteutetussa ohjelmistossa.
Toteutetun ohjelman suorituskykyä saatiin paremmaksi valitsemalla matalamman tason C-ohjelmointikieli. C on käännettävä kieli verrattuna Ruby:n tulkattavaan kieleen. Lisäksi C voi hyödyntää käyttöjärjestelmän säikeitä ilman rajoituksia verrattuna Ruby-tulkin globaaliin lukitukseen. Muistivuoto saatiin korjattua huolellisella ohjelmoinnilla ja varmistamalla, että muisti vapautettiin, kun sitä ei enää tarvittu. Kielen valinnalla ohjelman muistinkäyttö saatiin entiseen nähden pienemmäksi. Ruby:llä toteutettu demo käytti muistia noin 150 Mt ja rcb\_sub käytti noin 4 kt. Toteutetussa ohjelmassa ei ollut demossa havaittavia ongelmia ja on osoittautunut tuotannossa toimivaksi muun järjestelmän kanssa. Edellä mainittujen perusteella demon analyysi onnistui ja sen pohjalta toteutukseen tehtiin oikeita teknisiä valintoja. Tämä myös vastaa tutkimuskysymykseen T4.
% Toteutettu ohjelma on toiminut hyvin ja päästiin asetettuihin tavoitteisiin.
Toteutettu ohjelmisto on tuotannossa osana muuta järjestelmä ja diplomityön kirjoittamisen valmiiksi saamiseen asti on toiminut ongelmitta. Kappaleessa \ref{ch:arviointi} arvioitiin ja pohdittiin saatuja tuloksia. Näiden pohjalta voidaan sanoa, että diplomityössä suunniteltu toteutus pääsi asetettuihin tavoitteisiin ja tutkimuskysymyksiin löydettiin vastaus. Toteutus ei kuitenkaan ole täydellinen ja siinä on parannettavaa. Näihin kohtiin tullaan yrityksessä palaamaan tulevaisuudessa ja muuttamaan niitä, mikäli tarve vaatii. Tämän diplomityön tulokset tarjoavat myös apua samankaltaisten järjestelmien suunnitteluun ja toteutukseen.