vaihtoehtojen_analyysi.tex

\chapter{Järjestelmän suunnittelu}
\label{ch:architecture-planning}
% Tuttuja asioita: hajautetun järjestelmän teoria ja sen paradigmat, IEC 61580 -standardin pääpiirteinen toiminta ja sen rajoitteet.
% Diplomityön prosessin pääpiirteinen kuvaus suunnittelusta toteutukseen.
Diplomityön suunnittelu aloitetaan ensin hajautetun järjestelmän arkkitehtuurin suunnittelusta. Tässä luvussa arkkitehtuuri suunnitellaan analysoimalla aikaisemmin läpikäytyjä hajautetun järjestelmän paradigmoja ja IEC 61850 -standardin asettamia määrityksiä. Tuloksena on arkkitehtuurisuunnitelma osaksi muuta järjestelmää, joka määrittää kommunikointiparadigmat viestien kuljettamiseen IED-laitteilta järjestelmän muille komponenteille. Tulevissa luvuissa tätä suunnitelmaa tullaan tarkentamaan toteutukseen käytettävillä tekniikoilla, joka työn lopussa toteutetaan ohjelmistoksi.


\section{Arkkitehtuurin analyysi}
\label{ch:architecture-analysis}
IEC 61850 -standardi määrittää, että viestit IED-laitteelta tulevat julkaisija-tilaaja-pa\-ra\-dig\-man mukaisesti. Viestit tilataan IED-laitteelta olevilta RCB-luokkien instansseilta. RCB-instanssi on kytketty laitteella olevaan datajoukkoon, jonka tiedoista ollaan kiinnostuneita. Rajoituksena standardi asetti, että tilaajan täytyy varata RCB-instanssi ja yksi RCB-instanssi voi palvella vain yhtä tilaajaa kerrallaan. RCB-instansseja IED-laitteissa on rajallinen määrä yhtä datajoukkoa kohti ja näitä voidaan myös käyttää aseman sisäiseen toimintaan. Tässä työssä käsitellyssä IED-laitteessa yhteen datajoukkoon oli esimerkiksi määritetty viisi eri RCB-instanssia. Seurauksena on, että kyseisen datajoukon voi tilata vain viisi saman aikaista tilaajaa. Lisäksi tässä työssä testattu IED-laite rajoitti avoimet yhteydet viiteen. Tästä ylimeneviä yhteyksiä ei avattu, ja IED-laite palautti standardin mukaisen negatiivisen vastauksen.

Vaatimus V2 määritti, että IED-laitteen tilatut viestit täytyy saada jaettua järjestelmän muiden komponenttien kanssa. Työn tekohetkellä komponentteja järjestelmässä oli kaksi: mittaustiedon näyttämiseen ja tilatiedon tarkkailuun. Vaatimus V3 määritti, että komponenttien määrän pitää pystyä muuttumaan järjestelmän tarpeiden mukaan. Tämä vaatimus asetettiin tulevaisuuden varalle, jolloin komponentteja on mahdollisesti enemmän kuin kaksi.

Edelle mainituista IED-laitteen rajoituksista ja työlle asetetuista vaatimuksista voidaan tehdä johtopäätöksiä hajautuksen arkkitehtuurin suhteen. Samalle IED-laitteelle avattujen yhteyksien määrä halutaan pitää pienenä. Tämän lisäksi varattujen RCB-instanssien määrä jokaista datajoukkoa kohti halutaan myös pitää pienenä. Edellä mainittujen perusteella aseman resursseja halutaan varata mahdollisimman vähän ja vapauttaa niitä aseman muuhun toimintaa. Lisäksi vaaditut resurssit pitää pystyä määrittämään ennalta. Tämä helpottaa aseman insinöörin suunnittelutyötä, koska hän voi ottaa luvut huomioon IED-laitteiden konfiguroinnissa.

Edellä mainittuun tilanteeseen ratkaisuna olisi ollut, että järjestelmän yksittäiset komponentit tilaisivat niiden tarvitsemat tiedot suoraan IED-laitteelta. Tämä on esitetty kuvan \ref{fig:architecture-analysis} yläosassa. Ongelmana tässä kuitenkin on aikaisemmin mainittu yhteyksien määrän rajoitus IED-laitteelle ja se, että niiden määrä haluttiin minimoida ja pitää vakiona. Lisäksi viestit tilataan ja palautetaan komponentille MMS-protokollamäärityksien mukaisesti. Seurauksena on, että jokainen komponentti joutuu käsittelemään MMS-protokollan binääridataa itse tai kirjaston avulla. Viestin muoto olisi parempi olla ymmärrettävämpi. Näin viestin lukeminen eri tekniikoilla olisi helpompaa. Tämän asetti vaatimus V8 ja oli myös T3 tutkimuskysymyksen aihe.

\begin{figure}[ht!]
	\includegraphics[width=0.7\textwidth]{pictures/architecture-analysis.png}
	\caption{IED-laitteelta viestien tilaus suoraan ja väliohjelmiston avulla.}
	\label{fig:architecture-analysis}
\end{figure}

Ratkaisuna edellä mainittuun tilanteeseen on kommunikoinnin epäsuoruuden lisääminen. Epäsuoruutta saadaan aikaan toteuttamalla erillinen ohjelmistokomponentti IED-laitteen ja muiden järjestelmän komponenttien väliin. Tätä komponenttia voisi kutsua myös nimellä \emph{väliohjelmisto} (\emph{middleware}) ja on esitetty kuvan \ref{fig:architecture-analysis} alaosassa. Väliohjelmisto tilaisi viestit IED-laitteelta ja halutuilta RCB-instansseilta. Samalla komponentti muokkaisi saapuvat viestit parempaan muotoon, joka olisi helpompi muiden järjestelmän komponenttien lukea. Väliohjelmiston avulla yhteyksien määrä IED-laitetta kohti saadaan yhteen. Tämän avulla myös saadaan minimoitua varattujen RCB-instanssien määrä datajoukkoa kohti yhteen. Tuloksena on vakiomäärät yhteyksiä ja RCB-instansseja datajoukkoa kohti, jotka ovat helpompi ennustaa ja konfiguroida etukäteen tarpeiden mukaan.

Vaatimuksessa V4 mainittiin myös, että muu järjestelmä ohjaa viestien tilauksen aloittamista ja lopettamista. Väliohjelmistoa on mahdollista muun järjestelmän ohjata tilauksien mukaan. Väliohjelmisto ja epäsuoruus myös helpottavat viestien puskuroinnin toteuttamista komponenteille, joka oli vaatimus V6. Ilman epäsuoruutta, jokaisen komponentin tulee toteuttaa oma sisäinen puskuri viestien vastaanottamiseen.

Tässä kappaleessa analysoitiin IEC 61850 -standardin asettamia rajoja ja ohjelmistolle asetettuja vaatimuksia. Näistä analysoitiin mikä olisi toimiva ratkaisu tässä tilanteessa järjestelmän hajauttamiseen korkealla tasolla. Tuloksena järjestelmään päätettiin lisätä epäsuoruutta toteuttamalla väliohjelmisto IED-laitteen ja järjestelmän muiden komponenttien väliin. Jäljelle jää vielä miettiä vastaukset seuraaviin kysymyksiin:
\begin{itemize}
	\item Mitkä kommunikointiparadigmat toteuttavat väliohjelmiston ja komponenttien vaatimukset?
	\item Mihin muotoon matalan tason MMS-viesti väliohjelmistossa tulee muuntaa jakoa varten?
	\item Mitkä ovat väliohjelmiston ja muiden komponenttien välisten liitoksien vahvuudet?
	\item Kuinka viestien puskurointi väliohjelmiston avulla toteutetaan?
\end{itemize}


\section{Osapuolten liitoksien analyysi}
Aikaisemmin kappaleessa \ref{ch:liitokset} käsiteltiin hajautetun järjestelmän osapuolten välisiä liitoksia. Erilaisten liitoksien luokittelut esiteltiin taulukossa \ref{tab:communication-models}. Lisäksi hajautetussa järjestelmässä kommunikointi osapuolten välillä voi olla suoraa tai epäsuoraa. Aikaisemmin kohdassa \ref{ch:architecture-analysis} päädyttiin lisäämään epäsuoruutta IED-laitteen ja järjestelmän muiden komponenttien väliin.

IED-laitteen ja viestien tilaajan välinen kommunikointi on suoraa ja se ei tapahdu välittäjän kautta. Lisäksi osapuolten välillä on vahva väli- ja aikaliitos. Kommunikoinnissa osapuolet tietävät toistensa identiteetin (IP-osoitteen), jonka seurauksena niiden välillä on vahva väliliitos. Kommunikoinnissa on myös vahva aikaliitos, koska osapuolien täytyy olla olemassa samaan aikaan. Tilaajan täytyy olla ottamassa viesti vastaan, kun IED-laite sen lähettää ja IED-laitteen pitää olla olemassa, kun tilaus tehdään. Kaikki edellä mainitut tulevat IEC 61850 -standardin määrityksien seurauksena ja näihin ei työssä voida vaikuttaa.

Työn aloitushetkellä järjestelmässä oli kaksi tietoa tarvitsevaa komponenttia. Lisäksi vaatimus V3 asetti, että näiden komponenttien määrä voi muuttua tarpeiden mukaan. Näistä seurauksena väliohjelmiston ja muiden järjestelmän komponenttien välinen suhde on yksi-moneen. Toteuttamalla suora kommunikointi väliohjelmiston ja järjestelmän muiden komponenttien väliin, väliohjelmiston täytyy tietää muiden komponenttien olemassaolosta ja kenelle viestit ohjataan. Tämä lisäisi osapuolten välistä riippuvuutta ja vähentäisi toteutuksen joustavuutta. Ratkaisuna on lisätä epäsuoruutta väliohjelmiston ja muiden komponenttien väliin välittäjällä. Tämä on esitetty kuvassa \ref{fig:coupling-analysis}. Välittäjä vähentää osapuolten välistä riippuvuutta ja lisää toteutuksen joustavuutta. Se myös auttaa toteuttamaan asetettuja vaatimuksia, kuten viestien puskurointia (V6) ja uuden viestin ilmoitusta (V5). Vaatimus V7 asetti, että komponenttien pitää pystyä suodattamaan tietoa sen lähteen perusteella. Välittäjän tuoma epäsuoruus auttaa myös tämän vaatimuksen toteuttamisessa. Tällä vastuu väliohjelmistolta viestien jakamisesta saadaan siirrettyä välittäjän vastuulle.

\begin{figure}[ht!]
	\includegraphics[width=1\textwidth]{pictures/coupling-analysis.png}
	\caption{Välittäjä väliohjelmiston ja komponenttien välissä lisäämään epäsuoruutta ja joustavuutta.}
	\label{fig:coupling-analysis}
\end{figure}

Väliohjelmiston ja muiden komponenttien välille edellä mainitun perusteella halutaan heikko väliliitos. Väliohjelmiston ei tarvitse tietää järjestelmän muiden komponenttien identiteettiä ja tämä parantaa toteutuksen joustavuutta. Aikaliitos asetettujen vaatimuksien perusteella pystyisi olemaan vahva tai heikko. Kuitenkin muu järjestelmä ohjaa tilauksen aloittamista ja lopettamista (vaatimus V4). Seurauksena on, että väliohjelmisto ja muut komponentit ovat olemassa samaan aikaan. Tämä poistaa tarpeen heikolle aikaliitokselle.

Tässä kappaleessa analysoitiin hajautetussa järjestelmässä olevien osapuolien liitoksien vahvuutta. IEC 61850 -standardi asettaa rajoitteet IED-laitteen ja väliohjelmiston välille, joihin ei voida vaikuttaa. Väliohjelmiston ja muiden komponenttien väliin päädyttiin toteuttamaan epäsuora kommunikointi joustavuuden ja vaatimusten takia. Samojen osapuolten väliin halutiin toteuttaa heikko väliliitos ja vahva aikaliitos. Kysymyksenä jää miettiä millä hajautuksen paradigmoilla välittäjä tulee toteuttaa, jotta saadaan halutut ominaisuudet?


\section{Paradigmojen analyysi}
Aikaisemmissa kappaleissa analyysien ja vaatimusten pohjalta päädyttiin kuvan \ref{fig:coupling-analysis} hajautetun järjestelmän arkkitehtuuriin. Tässä kappaleessa vertaillaan ja analysoidaan eri hajautuksen paradigmoja. Tarkoituksena on selvittää mitä paradigmoja tarvitaan, jotta asetetut vaatimukset voidaan toteuttaa. Näitä olivat viestien puskurointi (V6), ilmoitukset komponenteille uuden viestin saapuessa (V5) ja viestien suodattamisen mahdollisuus IED-laitteen mukaan (V7). Tässä kappaleessa käsitellyt paradigmat koskevat kuvan \ref{fig:coupling-analysis} välittäjää väliohjelmiston ja järjestelmän komponenttien välissä. Hajautetun järjestelmän eri paradigmat oli esitetty taulukossa \ref{tab:communication-paradigms}.

Järjestelmään haluttiin epäsuoruutta välittäjällä. Tätä parhaiten tarjoavat epäsuorat kommunikointiparadigmat. Vaatimus V6 määritti, että viestejä pitää pystyä puskuroimaan myöhempään ajan hetkeen, jos komponentti ei niitä ehdi käsitellä. Tämän ominaisuuden parhaiten tarjoaa viestijonoparadigma. Viestejä haluttiin erotella IED-laitteen mukaan (V7), ja komponentit voisivat päättää itse mistä ovat kiinnostuneita. Tätä ominaisuutta epäsuorista paradigmoista tarjoavat joukkokommunikointi ja julkaisija-tilaaja. Joukkokommunikoinnissa komponentti pystyisi olemaan osa haluttuja ryhmiä. Julkaisija-tilaaja-paradigmassa komponentti pystyisi tilaamaan halutut viestit. Kummatkin edellä mainituista tarjoavat myös halutut ilmoitukset (V5). Joukkokommunikointi- ja julkaisija-tilaaja-systeemissä vastaanottajat saavat ilmoituksen uuden viestin saapuessa. Jotta joukkokommunikoinnilla saadaan haluttu toiminnallisuus, tulee ryhmän olla avoin ja sen pitää mahdollistaa osapuolten liittyminen ja poistuminen ryhmästä. Lisäksi ryhmien pitää sallia olevan päällekkäisiä. Tämä sen takia, että komponentin on mahdollisesti saada viestejä useammasta lähteestä samaan aikaan.

Järjestelmään halutun epäsuoruuden takia suorat kommunikointiparadigmat eivät sovellu kovin hyvin hajautuksen toteuttamiseen. Näitä olivat prosessien välinen kommunikointi ja etäkutsut. Hajautuksessa osapuolien välillä haluttiin olevan heikko väliliitos ja vahva aikaliitos. Kummassakin edellä mainitussa paradigmassa liitokset ovat vahvoja. Suoralla kommunikoinnilla vastaanottavan osapuolen pitää toteuttaa viestipuskuri itse, verrattuna jos käytettävä epäsuora systeemi tarjoaisi puskurin sen sijaan. Tämä hankaloittaa uusien komponenttien kehitystyötä. Muu järjestelmä on toteutettu web-sovelluksena, josta seurasi vaatimus V10, että kommunikoinnin pitää toimia TCP/IP-protokollaperheen päällä. Prosessien välinen kommunikointi tapahtuu mm. pistokkeilla ja näin ollen on vaatimukseen nähden liian matalaa. Etäkutsut tarjoavat tähän paremman vaihtoehdon, mutta vaatimuksissa ei ollut tarvetta pyyntö-vastaus-kommunikoinnille. Viestien suunta on tässä tapauksessa yhden suuntaista IED-laitteelta järjestelmän komponentille.

Asetettuihin vaatimuksiin nähden epäsuorat paradigmat sopivat toteutukseen parhaiten. Näistä tarvitaan viestijonoparadigmaa viestien puskurointiin ja joukkokommunikointi tai julkaisija-tilaaja niiden lähettämiseen komponenteille. Joukkokommunikointi ja julkaisija-tilaaja paradigmat ovat kummatkin tilanteeseen sopivia vaihtoehtoja. Vielä pitää miettiä millä tekniikalla halutut paradigmat toteutetaan. Valitun tekniikan tulee yhdistää kaksi eri paradigmaa niin, että viestien oikea reitittäminen ja puskurointi ovat mahdollisia.

% TODO: Miettiä onko muita syitä hylätä joukkokommunikointi vaihtoehtona kuin tekniikan valinta.


\section{Toteutustekniikoiden vertailu}
Hajautetun järjestelmän toteuttamiseen löytyy erilaisia avoimia standardeja kuten \emph{AMQP} (\emph{Advanced Message Queuing Protocol}) \cite{amqp-homepage} ja \emph{MQTT} (\emph{Message Queuing Telemetry Transport}) \cite{mqtt-homepage}. Standardien tarkoitus on määrittää yhteiset säännöt osapuolten kommunikointiin hajautetussa järjestelmässä. Standardien pohjalta on toteutettu erilaisia viestien välitysohjelmistoja, joihin muut osapuolet voivat ottaa yhteyttä standardin mukaisesti tekniikasta riippumatta. Kummatkin edellä mainitut standardit ovat määritetty toimivaksi TCP/IP-protokollaperheen päällä \cite[s.~1]{mqtt-specification} \cite[s.~22]{AMQP-specification}.

MQTT on julkaisija-tilaaja-paradigmaan pohjautuva kommunikointistandardi. MQTT""-""mää\-ri\-tyk\-si\-en mukainen välittäjäpalvelin tarjoaa myös viestien puskuroinnin mahdollisuuden \cite{mqtt-specification}. MQTT on pääasiassa tarkoitettu kommunikointiin, missä kaista on rajallista ja kommunikoinnista huolehtivan koodin jalanjälki pitää olla pientä. Tästä syystä se on paljon käytetty standardi IoT-laitteissa (Internet of Things) ja kotiautomaatiossa \cite[s.~9--11]{mqtt-for-iot}.

AMQP-standardi on tarkoitettu \emph{MOM}:in toteuttamiseen (\emph{Message-Oriented Middleware}) ja näin ollen mahdollistaa monen eri kommunikointiparadigman toteuttamisen \cite[s.~6]{AMQP-specification}. MOM tarkoittaa hajautetussa järjestelmässä \emph{väliohjelmistoa} (\emph{middleware}), jota käytetään lähettämään ja vastaanottamaan viestejä. MOM:in tarkoitus on tarjota heterogeeninen alusta viestien vaihtoon tekniikasta ja verkkoprotokollasta riippumatta \cite{mom}. AMQP-standardi mahdollistaa esimerkiksi viestijonot, etäkutsut ja erilaiset reititykset kuten pisteestä pisteeseen ja julkaisija-tilaaja. AMQP tarjoaa toteutukseen enemmän paradigma vaihtoehtoja kuin MQTT.

Tässä työssä toteutuksen tekniikaksi valittiin AMQP. AMQP tarjoaa kaikki vaaditut ominaisuudet välittäjän toteuttamiseen. AMQP ei mahdollista joukkokommunikoinnin toteuttamista, mutta mahdollistaa julkaisija-tilaaja-paradigman. Aikaisemmin julkaisija-ti\-laa\-ja-paradigma todettiin toteutukseen sopivaksi vaihtoehdoksi joukkokommunikoinnin kanssa. AMQP tarjoaa viestien puskuroinnin jokaista tilaajaa kohden ja komponenttien on mahdollista myös suodattaa viestejä kiinnostuksen mukaan. MQTT olisi myös todennäköisesti sopinut toteutukseen, koska se tarjosi kaikki vaaditut ominaisuudet. Työssä kuitenkin päädyttiin AMQP:n valintaan tekijän aikaisemman kokemuksen ja muiden työntekijöiden kanssa käydyn keskustelun tuloksena. Viestien lähetykselle järjestelmässä ei vaadittu takuita, mutta nämä olisi hyvä olla olemassa tulevaisuuden takia (V11). AMQP tarjoaa takuumekanismit viestien lähettämiseen transaktioina ja vastaanottamiseen niiden kuittaamisella \cite[s.~14,21]{AMQP-specification}. Kuinka AMQP tarkalleen toimii, on tämän diplomityön ulkopuolella ja siitä kerrotaan vain lyhyesti kohdissa missä tietoa tarvitaan. AMQP:sta voi lukea enemmän sen dokumentaatiosta \cite{AMQP-specification} ja verkkosivulta \cite{amqp-homepage}.


\section{Viestin formaatti}
IED-laitteelle kommunikointi ja siltä tulevat viestit lähetetään MMS-protokollan binäärimäärityksien mukaan. Jotta tilaavien komponenttien olisi helppo lukea viestin sisältö, täytyy se muuntaa toiseen muotoon. Hajautetussa järjestelmässä viestejä voidaan lähettää lähettäjän formaatin tai yhteisen hyväksytyn formaatin mukaan. Jos viestin lähettäjä päättää formaatin, täytyy viestissä olla tieto sen muodosta, jotta vastaanottajan on mahdollista se lukea. Järjestelmän yhteisessä formaatissa tätä tietoa ei tarvita, koska kaikki osapuolet käyttävät samaa formaattia ilman poikkeuksia. Viestejä voidaan lähettää binääri- tai tekstimuodossa. Binäärimuodossa datarakenteet esitetään binääreinä ja tekstimuodossa ne esitetään tekstimuodossa. Tekstimuoto on yleensä pidempi esitysmuoto kuin binäärimuoto.

Aikaisempien kappaleiden pohjalta päädyttiin kuvan \ref{fig:coupling-analysis} mukaiseen arkkitehtuuriin. Arkkitehtuurissa väliohjelmiston tehtävä on tilata viestejä IED-laitteelta, muuntaa ne ymmärrettävään muotoon ja julkaista AMQP-välittäjäpalvelimelle. Järjestelmän komponentit tilaavat viestejä AMQP-palvelimelta tarpeidensa mukaan.

Vaatimuksen V8 mukaan järjestelmän komponenteille viestien lukeminen haluttiin pitää helppona ja viestin koolla ei ollut teknisiä rajoitteita. Tämän takia viestit päätetiin esittää mieluummin tekstiformaatissa. Tekstimuoto on helpompi ihmisen lukea esimerkiksi vikatilanteissa. Binääritiedon lukeminen yleensä tarvitsee erillisen ohjelman. Nykypäivänä web-teknologioissa on käytössä kaksi tunnettua tekstimuotoista esitystapaa, joita ovat \emph{XML} (\emph{Extensible Markup Language)}) \cite{xml-specification} ja \emph{JSON} (\emph{JavaScript Object Notation}) \cite{json-standard}.

Työssä viestien välityksen tekniikaksi valittiin JSON. Viestin muutoksen JSON-muotoon tekee väliohjelmisto, joka tilaa viestit IED-laitteelta. JSON on nopeampi ja kevyempi tiedonsiirtoformaatti kuin XML \cite{json-xml-comparison}. Lisäksi JSON on nykypäivänä paljon käytetty tiedonsiirron muoto web-rajapinnoissa kuten REST (Representational State Transfer). JSON:in lukeminen ihmiselle on helppoa ja sille on olemassa tuki valmiina monelle eri ohjelmointikielelle ilman erillistä kirjastoa. JSON on myös kasvattanut suosiotaan ajan saatossa XML:ään verrattuna \cite{google-trends-xml-json}. Ja asiasta on kirjoitettu erilaisia blogiposteja kuten \cite{the-rise-and-rise-of-json, why-json-is-better-than-xml, Patrizio2016}.


\section{Yhteenveto}
Tässä luvussa eri analyysien ja vaatimuksien pohjalta päädyttiin lopulta kuvassa \ref{fig:high-level-system-architecture} olevaan järjestelmän arkkitehtuuriin. Kuvassa on esitetty viestin kulku järjestelmän läpi ja sen muoto. Lisäksi osapuolten väliin on merkitty niiden käyttämät kommunikointiprotokollat.

\begin{figure}[ht!]
	\includegraphics[width=1\textwidth]{pictures/high-level-system-architecture.png}
	\caption{Suunniteltu korkean tason järjestelmän hajautus ja kommunikointiprotokollat osapuolten välillä.}
	\label{fig:high-level-system-architecture}
\end{figure}

Arkkitehtuurissa väliohjelmisto tilaa viestejä IED-laitteelta IEC 61850 -standardin mukaisesti MMS-protokollan avulla. Viesti päädyttiin muuttamaan JSON-formaattiin helpomman luettavuuden saamiseksi ja sen muuntamisen hoitaa väliohjelmisto. Välittäjän kommunikointiprotokollaksi valittiin AMQP-standardi ja kommunikointiparadigmaksi jul\-kai\-si\-ja-ti\-laa\-ja ja viestijono. Väliohjelmisto tilaa viestejä IED-laitteelta ja uudelleenjulkaisee ne JSON-muodossa välittäjälle. Järjestelmän muut komponentit tilaavat viestejä välittäjältä AMQP-standardin mukaisesti. Suunniteltua mallia tullaan tarkentamaan teknisesti ennen toteutusta luvussa \ref{ch:suunnittelu}.