3 WEB-TEKNOLOGIAT JA NIIDEN SOVELLUKSET
4.2 Tavoitteet ja lähtökohdat
Tässä työssä käsiteltävien järjestelmien osalta voidaan katsoa IEC 61850 standardin mukaisten laitteiden mahdollistavan kehittyneet Web-pohj aiset toiminnot toteutettavaksi suoraan laitteisiin. Näissä uuden sukupolven IEC 61850 yhteensopivissa laitteissa on käytettävissä Ethernet-liitäntä sekä aikaisempaa enemmän muistia ja suorituskapasiteettia.
Kasvaneet laiteresurssit mahdollistavat järjestelmien ja varsinkin suojareleiden karmalta uudentyyppisten toimintojen tarjoamisen laitteesta. Tämän lisäksi laitteet tulee mallintaa rakenteisen mallin mukaisesti.
Seuraavan sukupolven IEC 61850 standardiin pohjautuvissa laitteissa Web-sovellukset tulevat olemaan merkittävä toiminnallinen kokonaisuus. Erilaisia tuotekonfiguraatioita tehdään saman tuoteperheen sisälle aikaisempaa enemmän ja kasvaneen toiminnallisuuden vuoksi näiden tuotehallintaan vaadittava työmäärä kasvaa merkittävästi, kts kuva 4.1.
Tuotekonfiguraatioihin tehtävät muutokset pitää pyrkiä tekemään keskitetysti ja niin, että muutokset siirtyvät automaattisesti tuotteessa olevien sovelluksien käytettäväksi.
Erilaisista sähköverkon suojaustoiminnoista tyypillisesti yhdistetään tietyille sovellusalueille sopivia kokonaisuuksia. Kaikkien suojaustoimintojen suorittaminen yhdellä laitteella ei yleensä ole mahdollista riittämättömien laiteresurssien puolesta.
Toisaalta käyttäjät eivät yleensä ole valmiita maksamaan toiminnoista, joita he eivät tarvitse.
Samaan tuoteperheeseen kuuluvissa laitteissa on Web-sovellusten kannalta tietty perustoiminnallisuus. Näitä toimintoja ovat esimerkiksi tapahtumalistojen ja mittaustietojen esittäminen. Tähän voidaan varautua ohjelmiston suunnitteluvaiheessa, sisällyttämällä tarvittava toiminnallisuus kiinteästi sovellukseen.
Tuote 1:
Konesuoja Tuote 2:
Johtosuoja Tuote 3:
Muuntajasuoja Toiminnallisuus:
suojaukset, ohjaus, ...
Perustuote:
mittaukset, tiedonsiirto, Web-
sovellus, ...
Tuotteistaminen
Kuva 4.1 Suojareleiden konfiguraatio! ja tuotteistaminen.
Tyypillisesti samaan suojareleperheeseen kuuluu johto-, kone- ja muuntajasuojalaitteita.
Kaikilla näillä on omat erityisvaatimuksensa suojaustoiminnoille, vaikka itse peruslaite pysyy samana. Suurimmat vaikutukset tällä on suojaustoimintojen määrään. Tietyn suojaustoiminnon puuttuessa pitää Web-sovelluksesta poistaa viittaukset tähän toimintoon.
Viittausten poistamiseen liittyvään toiminnon toteutukseen vaikuttaa myös suojareleen konfiguroitavuustaso. Tämän osalta suojareleet voidaan jakaa kahteen ryhmään: kiinteisiin ja ohjelmoitaviin laitteisiin, kts. kuva 4.2.
Asettelut Asettelut
Kiinteästi konfiguroitu
suojarele
Sovelluskohtainen toiminnallisuus
Ohjelmoitava suojarele
SCL/CID SCL/CID
Kuva 4.2 Periaatekuva kiinteästä ja ohjelmoitavasta suojareleestä.
Kiinteästi konfiguroidun suojareleen toiminnallisuuteen käyttäjä ei voi vaikuttaa, mutta voi muuttaa sen toimintaan vaikuttavia asetteluja. Varsinainen konfiguraatio määräytyy tuotteistusprosessin yhteydessä. Ohjelmoitavan laitteen käyttäjä voi itse valita, mitä toimintoja laitteeseen sisällytetään ja muuttaa valittuihin toimintoihin vaikuttavia asetteluja. Näissä tapauksissa käytössä on jokin korkean tason ohjelmointikieli, esimerkiksi aikaisemmin mainittu IEC 1131-3, jonka avulla valinta sekä mahdollinen lisälogiikka toteutetaan.
Laitteen kannalta IEC 61850 mallinnuksen tuloksena saadaan ICD-ja CID-määrittelyt. ICD on jo itsessään täydellinen kuvaus laitteen toiminnoista ja asetteluista, mutta asetteluarvot vastaavat tehdasasetteluja. Kiinteisiin suojareleisiin ICD-määrittelyt voidaan siirtää jo valmistuslinjalla. Dynaamisten laitteiden tapauksessa käyttäjä muokkaa laitteen toiminnallisuuden haluamakseen sen mukana toimitetuilla konfigurointityökaluilla.
4.3 Asettelujen hallinta
Edellisen perusteella IEC 61850 mallinnuksen soveltamiseen valitaan kaksi lähestymistapaa. Toinen on tarkoitettu kiinteille suojareleille, joissa on käytössä vähemmän laiteresursseja ja toinen ohjelmoitaville suojareleille. Tässä esimerkissä IEC 61850 mallinnuksesta hyödynnetään suojaustoimintojen asettelujen määrittelyjä. Kiinteissä laitteissa asetteluja on suppeimmillaan joitakin kymmeniä, mutta ohjelmoitavissa laitteissa niitä on tyypillisesti jopa tuhansia
Laite ja sen sisältämät toiminnot esitetään laitteen paikallisnäytöllä tyypillisesti puumaisena rakenteena. Tällä tavoin voidaan tiettyjä toimintoja ryhmitellä loogisesti.
Käyttäjät ovat tottuneita paikallisnäytöllä käytettyyn ryhmittelyyn, joten vastaavan rakenteen käyttäminen Web-sovelluksessa helpottaa siirtymistä niiden käyttämiseen.
Kuvassa 4.3 on esitetty yksinkertainen esimerkki toimintojen ryhmittelystä.
- Tapahtumat Päävalikko
- Mittaukset
Suojaustoiminnot Ylivirtasuojaus Jännitesuojaus L Energia
Ohjaus asettelut - Ohjaukset
L Asettelut Teho
Yleiset asettelut
Kuva 4.3 Esimerkki suojareleen toimintojen ryhmittelystä laitteen paikallisnäytöllä.
Edellä esitettyä ryhmittelyä hyödyntävien komponenttien kannalta on edullisinta, että ryhmittely pystytään mallintamaan yhtenäisellä tavalla. IEC 61850 standardi tarjoaa tähän kolme erilaista mahdollisuutta:
1. Ryhmittely loogisten laitteiden avulla. Erityyppiset loogisesti yhteenkuuluvat toiminnot voidaan ryhmitellä loogisiksi laitteiksi.
2. Ryhmittely dataryhmien (DataSet) avulla.
3. Valmistajakohtaisten osien käyttäminen SCL-määrittelyissä.
Kahden ensimmäisen tavan etuna on, että ne ovat täysin standardin mukaisia tapoja ja yhteensopivia eri laitevalmistajien kesken. Loogisten laitteiden ja dataryhmien kohdalla ongelmaksi muodostuu puumaisten hierarkioiden luominen, koska tämän tyyppiseen rakenteeseen näissä määrittelyissä ei ole valmiuksia. Loogiset laitteet ja dataryhmät on ensisijaisesti tarkoitettu siirrettävän tiedon ryhmittelyyn eikä niinkään esitystavan määrittelyyn.
Valmistajakohtaisten määrittelyjen käyttäminen on sinällään standardin mukainen menettely, mutta luonnollisesti niiden sisältöön standardissa ei oteta kantaa. Näiden määrittelyjen hyödyntäminen eri valmistajien kesken ei käytännössä ole mahdollista, mutta kaikki laitteen toiminnallisuuteen liittyvä informaatio on saatavilla myös standardin mukaisesti, vaikka esitystapaan liittyvät määrittelyt eivät olisikaan käytössä
Tässä tapauksessa toteutustavaksi valittiin valmistajakohtaisten määrittelyjen hyödyntäminen. SCL-muotoisten tiedostojen käyttäminen läpi koko järjestelmän mahdollistaa tehokkaasti tiedon yhtenäisyyden. Tällä tavoin on helppo varmistua siitä, että riippumatta käytetäänkö laitetta Web-sovelluksen, PC-pohjaisen konfigurointityökalun tai oman paikallisnäytön kautta, käyttöliittymät sisältävät saman loogisen rakenteen. Mikäli esitystapa on määritelty valmistajakohtaisissa osissa niin eri valmistajien konfigurointityökalut saattavat esittää rakenteen eri tavoin, mutta varsinainen informaatio pysyy samana. Valmistajakohtaisia määrittelyjä käyttämällä vältytään ylimääräisten loogisten laitteiden ja dataryhmien määrittelyiltä, jotka tietyissä tapauksissa saattavat monimutkaistaa kokonaisten järjestelmien tiedonsiirron määrittelyä.
Kuvassa 4.4 on esitetty kiinteästi konfiguroidun suojareleen SCL-määrittelyjen käsittely.
Tästä voidaan nähdä suunnittelun perusperiaate eli kiinteässä laitteessa suurin osa konfiguraation tekemiseen liittyvistä toiminnoista suoritetaan erillään laitteen omasta ohjelmistosta. Tiedot voidaan siirtää suoraan esimerkiksi C-lähdekooditiedostoihin, jotka voidaan kääntää suojareleen järjestelmäohjelmiston osaksi.
IEC 61850 SCL/XML ICD
+valmistajakohtaiset osat
Asettelutyökalu
IEC 61850 SCLVXML CID
IEC 61850 SCL/XML ICD
Asettelujen looginen rakenne
Kuva 4.4 SCL-käsittely kiinteästi konfiguroitavassa laitteessa.
Kuvassa 4.5 on esitetty ohjelmoitavan suojareleen SCL-määrittelyjen käsittely.
Ohjelmoitavan laitteen konfiguraatio voi muuttua loppukäyttäjän vaatimusten mukaan.
Toiminnallisuutta ei tyypillisesti voida muuttaa mielivaltaisesti vaan tietyn maksimi- toiminnallisuuden rajoissa.
Tarvittavat toimenpiteet ovat periaatteessa samat kuin kiinteän suojareleen yhteydessä, mutta tässä tapauksessa loogisen rakenteen prosessointi suoritetaan suojareleen järjestelmäohjelmiston toimesta. Loogisen rakenteen prosessointiin käytettävä komponentti voidaan suunnitella ja toteuttaa siten, että sitä voidaan käyttää sekä osana suojareleen ohjelmistoa, että laitteen ulkopuolella.
IEC 61850 SCL/XML ICD
+valmistajakohtaiset osat
Asettelutyökalu
IEC 61850 SCL/XML CID
+valmlstajakohtalset osat Laitteen maksimi
konfiguraation määrittely
Asettelujen loogisen rakenteen määrittely valmistajakohtaisiin osiin
Asettelujen loogisen rakenteen prosessointi
Suojareleen sovellusohjelmat T uotteistusprosessi
IEC 61850 SCL/XML ICD
Suojarele
Asettelujen looginen rakenne
Kuva 4.5 SCL-käsittely ohjelmoitavassa suojareleessä.
Ohjelmoitavan suojareleen yhteydessä tulee loogisen rakenteen prosessoinnin yhteydessä tutkia, mitkä osat konfiguraatiosta ovat todellisuudessa käytössä. Kiinteästi konfiguroitavassa suojareleessä tämä ei ole ongelma, koska toiminnallisuus ei voi käytön aikana muuttua.
4.4 Muita soveltamismahdollisuuksia
Parametrien hallinnan lisäksi toinen mahdollinen IEC 61850 standardin soveltamismahdollisuus Web-sovellusten yhteydessä on asemakaavioiden hyödyntäminen.
Asemakaavioita on sähkönjakeluverkon automaatiojärjestelmissä totuttu käyttämään johtolähtötason rakenteen ja laitteiden visualisointiin. Usein isoilla graafisilla näytöillä varustetuissa suojareleissä nämä kuvat voidaan esittää suoraan laitteen paikallisnäytöltä.
Toisaalta SCADA-järjestelmien ohjaus- ja järjestelmäkuvat perustuvat asemakaavioiden käyttöön. Nämä molemmat käytännössä kuvaavat samaa kohdetta, muuta ne on toteutettu toisistaan riippumatta. Web-sovellus lisää potentiaalisesti tätä työtä.
IEC 61850 standardin mukaisella SCL-tiedostolla voidaan kuvata myös asemakaavioita.
Tämä tarjoaa saman edun kuin edellä esitetty parametrointihierarkian hyödyntäminen eli kerran suunniteltu ja toteutettu asemakaavio voidaan siirtää sellaisenaan työkaluihin, laitteeseen ja laitteen Web-sovellukseen.
5 WEB-SOVELLUKSEN KEHITTÄMINEN 5.1 Nykytilanne
ABB Oy:n keskijänniteverkon suojareletuotteista REF542+ tuoteperhe sisältää Web- palvelimen ja joitakin laitteen toimintoja voidaan valvoa Web-selaimen avulla. REF542+
tuotteet eivät pohjaudu IEC 61850 standardiin, eikä sisällön tuottamiseen ei ole näissä tuotteissa sovellettu automaattisia menetelmiä.
5.2 Lähtökohdat ja toteutusmallin valinta
Palvelinsovellus suunnitellaan erityisesti sulautettuja järjestelmiä varten, joissa on käytössä tiettyyn tarkoitukseen suunniteltu laiteratkaisu. Tämä tarkoittaa, että laiteresursseja on käytössä rajallisesti ja niiden käyttö pitää suunnitella siten, että laitteen muu toiminta ei missään tilanteessa häiriinny. Sovelluksen rakenne tulee suunnitella sellaiseksi, että toiminnallisuuden lisääminen onnistuu helposti. Rajapinnat ympäröivään järjestelmään eristetään omaan ohjelmistokerrokseen, joka rajaa ympäristön muuttamisen vaikutukset Web-sovellukseen.
Varsinaisen Web-palvelinohjelmiston suunnittelu ja toteutus on rajattu tämän työn ulkopuolelle. Tuoteprojektin yhteydessä päätetään käytettävästä Web-palvelimesta ja silloin voidaan päätyä kaupalliseen ratkaisuun. Kaupallisen toteutuksen valintaan voi johtaa mm. seuraavat syyt:
• Palvelimen toteutukseen ei liity sellaista eritysosaamista, joka katsottaisiin tuoteprojektissa tarpeelliseksi.
• Voidaan keskittyä sovellusosan suunnitteluun, toteutukseen ja testaukseen.
• Projektin aikataululliset ja taloudelliset rajat.
Valmiiden palvelinohjelmistojen osalta tutustuttiin muutamiin saatavilla oleviin ratkaisuihin. Nämä olivat NicheStack HTTPServer (WebPort), Allegro Software RomPager, RTXC Quadnet TCP/IP networking software HTTP server, GoAhead Webserver ja Mbedthis AppWeb. Yhteenveto näiden tärkeimmistä teknisistä ominaisuuksista on esitetty liitteessä 2 taulukkomuodossa. Tämä taulukko antaa kuvan siitä millaisia ominaisuuksia sulautettuihin järjestelmiin tarkoitetut Web-palvelinohjelmistot tarjoavat.
Taulukossa 5.1 on esitetty tämän työn tutkimusvaiheen aikana esille tulleet vähimmäis
vaatimukset, joita tulee seurata valittaessa tai toteutettaessa Web-palvelinta suojareleeseen.
Taulukko 5.1 Web-palvelimelle asetetut vaatimukset.
Vaatimus: Perustelu:
HTTP 1.1 (RFC 2616) HTTP 1.0 puutteellinen nykyaikaisten sovellusten tehokkaaseen toteutukseen.
C-kielinen toteutus Kohdejärjestelmät toteutettu poikkeuksetta C-kielellä. Ohjelmistokomponentit
hankitaan tyypillisesti lähdekoodijakeluna.
Digest todentaminen Tarvitaan turvallinen tunnistusmenetelmä.
Istuntojen hallinta Järjestelmään voi olla kytkeytyneenä monta samanaikaista käyttäjää.
Staattisen sisällön käyttäminen ilman Kaikissa laitteissa ei ole
tiedostojärjestelmää tiedostojärjestelmän palveluja saatavilla.
Käyttöj ärj estelmäriippumaton toteutus Eri laitteissa voi olla erilaiset
käyttöjärjestelmät. Testaaminen Windows-ympäristössä.
HTTP-liikenteen salaus Tietoturvaan liittyvien vaatimusten kasvaminen.
Nykyaikaiset Web-sovellukset pyritään suunnittelemaan siten, että esitystapa ei ole sidottu esitettävään informaatioon. Tätä periaatetta noudatetaan myös tässä tapauksessa, joten luonnollinen lähtökohta on selainpohjainen toteutus. Toiminnallisuus selain- ja palvelinsovelluksien pyritään jakamaan siten, että palvelinsovellukseen voitaisiin liittyä helposti myös muilla kuin selaimeen perustuvilla asiakassovelluksilla, vaikka se tällä hetkellä ei vaikuta merkittävältä vaatimukselta.
Suurin osa toimintalogiikasta pyritään keskittämään selainsovellukseen, palvelin
sovelluksen keskittyessä informaation tarjoamiseen. Selainsovellukset on perinteisesti suunniteltu toimimaan mahdollisimman monissa eri selaimissa ja niiden eri versioissa.
Tässä sovelluksessa mahdollisimman laajaa yhteensopivuutta ei kuitenkaan asetettu tärkeimmäksi tavoitteeksi. Pelkästään tietoturvariskeistä johtuen suojareleen Web- sovellusta ei ole tarkoitettu yleiseen verkkoon kytkettäväksi. Käyttäjät ovat tyypillisesti suojareleen käyttöön koulutettuja henkilöitä, jolloin käytettävät selainvaihtoehdot voidaan helpommin rajata. Tavoitteena on testata ja varmistaa valmiin sovelluksen toimivuus Microsoft Internet Explorer ja Mozilla Firefox-selainten viimeisimmillä versioilla.
Eräs tärkeimmistä tavoitteista selainsovelluksen suunnittelussa on, että käyttäjä pystyy nopeasti sisäistämään siinä olevat toiminnot. Käytännössä tämä tarkoittaa sitä, että käyttöliittymää suunniteltaessa huomioidaan tällä hetkellä käytössä olevia ABB Oy PC- pohjaisia suojareleiden asettelu- ja konfigurointityökaluja. Mukaan otetaan myös suojareleen omalla näytöllä esitettyjä rakenteita. Erityisesti asettelurakenteet pyritään pitämään yhtenäisinä.
в @ is
Kuva 5.1 Web-sovelluksen rakenne ja rajapinnat.
Selainpohjaisella toteutuksella pyritään vähentämään varsinaiselle sulautetulle järjestelmälle aiheutuvaa kuormitusta. Tällaisella toteutuksella pyritään varmistamaan
sovelluksen siirrettävyys. Sulautetut järjestelmät on hyvin usein suunniteltu tiettyä tarkoitusta tai käyttökohdetta varten. Laitetason eroavaisuudet piilotetaan käyttöjärjestelmätason rajapintojen taakse ja riippuvuudet tuoteperhekohtaisiin toteutuksiin syntyvät siitä kuinka varsinaiseen prosessidataan liitytään.
Selainsovelluksen toiminnallisuus voidaan suunnitella kokonaan laiteriippumattomaksi ja siinä haasteet liittyvät toiminnallisuuden varmistamiseen erilaisissa selainympäristöissä.
Selainsovelluksen kannalta ei ole merkitystä miten sen tarvitsema informaatio tuotetaan.
Tämä antaa erittäin suuret vapaudet palvelinsovelluksen suunnitteluun. Palvelin
sovelluksen toteutustapa voidaan valita aina sen mukaan, mikä käytettävän laiteympäristön kannalta on sopivin.
Palvelinsovelluksen uudelleen toteutukseen ei pitäisi olla tarvetta, vaan sovellus siirretään sovittamalla pelkästään rajapinnat. Modulaarinen rakenne mahdollistaa muutosten vaikutusten tehokkaan rajaamisen. Kuvassa 5.1 on esitetty Web-sovelluksen rakenne ja rajapinnat.
5.3 Laitteistoarkkitehtuurien huomioiminen
Laiteympäristöt, joihin nyt suunniteltava sovellus tulisi olla sovitettavissa, edustavat aitoja prosessoriympäristöjä. Suunnittelussa lähtökohtana on usein jokin nykyaikainen tehokas prosessoriperhe. Nämä prosessorit sisältävät joitakin oheislaitteita, tyypillisesti erilaisia sarja- ja rinnakkaismuotoisia I/O väyliä sekä ajastimia, mutta käyttö- ja haihtumaton muisti on toteutettu ulkoisilla komponenteilla. Käyttömuistina on usein SDRAM-tyyppi.
Haihtumattoman muistina käytetään lähes poikkeuksetta Flash-tyyppisiä muisteja.
EEPROM-muistia käytetään yleensä laitteen tunnistetietojen tai asetteluarvojen tallentamiseen. Ohjelma ladataan käynnistyksen yhteydessä käyttömuistiin suoritettavaksi.
Kuvassa 5.2/A on esitetty yhdellä prosessorilla toteutetun suojareleen periaatteellinen rakenne. Tällainen toteutus valitaan yleensä kustannustehokkaisiin ratkaisuihin.
Tiedonsiirto laitteessa suoritettavien sovellusten kesken on helppoa, koska siihen voidaan käyttää suoraan käyttöjärjestelmän palveluja.
Vaativissa sovelluksissa voidaan lisääntyneen toiminnallisuuden tai monimutkaisten suojausalgoritmien vuoksi päätyä useammalla prosessorilla toteutettuun ratkaisuun.
Toiminnallisuus voidaan jakaa esimerkiksi siten, että kriittiset suojaussovellukset suoritetaan omalla prosessorilla ja tiedonsiirto sähköasema-automaatiojärjestelmään on toteutettu prosessori-pohjaisella liitäntäkortilla, kts. kuva 5.2/B. Tässä tapauksessa tiedonsiirto laitteessa suoritettavien sovellusten kesken ei voi kaikissa tapauksissa perustua käyttöjärjestelmän tarjoamiin palveluihin.
Joissakin tapauksissa halutaan vanhempiin tuotesukupolviin sisällyttää uudemmissa tuotteissa esiteltyä toiminnallisuutta. Esimerkiksi IEC 61850 standardin mukaisen protokollan lisääminen voidaan toteuttaa erillisellä yhdyskäytävä-laitteella, kts. kuva 5.2/C.
Yhdyskäytävä voi hakea tiedot laitteesta esimerkiksi yksinkertaisella sarjaliikenneväyIällä perinteisiä sähkönjakeluverkon automaatiossa käytettyjä protokollia hyödyntäen ja tarjota ne IEC 61850 standardin mukaisesti uudempiin järjestelmiin. Tämä ratkaisu on oleellisesti samantyyppinen kuin edellinen, mutta laitetason tiedonsiirto on tyypillisesti huomattavasti hitaampaa.
Kuva 5.2 Erilaisten laitteistoarkkitehtuurien periaatekuvat.
Työn tavoitteena on luoda erilaisiin laitetoteutuksiin sovitettavissa oleva ympäristö, joten yhden prosessorin järjestelmä asettaa rajat käytettävissä oleville laiteresursseille ja muut vaihtoehdot rajoittavat sisäistä tiedonsiirtoa ja sen toteuttavaa rajapintaa.
5.4 Käynnistysajan minimointi
Käynnistysajalla tarkoitetaan tässä sitä aikaa, joka kuluu suojareleen katkaisijaa ohjaavan digitaalilähdön aktivoitumiseen siitä hetkestä, kun suojareleen apujännitteet on kytkettyjä mitattavassa sähköverkossa on vikatilanne. Tilanteessa, jossa suoritettava ohjelma ladataan haihtumattomasta muistista, siirto voi aiheuttaa merkittäviä viiveitä käynnistykseen. Tästä syystä käynnistyksen yhteydessä siirrettävä datamäärä eli suojausalgoritmit sisältävä
järjestelmäohjelmisto tulisi pitää mahdollisimman pienenä. Vähemmän aikakriittiset ohj elmistokomponentit voidaan ladata suoritusta varten muistiin sitten, kun suoj ausalgoritmien suoritus on alkanut.
Nykyisin suojareleiden järjestelmäohjelmistoissa on usein mahdollisuus tiedosto
järjestelmän käyttöön. Web-sovellusten toteuttamisen kannalta tämä on hyvä asia, koska staattiset osat, kuten kuvat ja tyylimäärittelyt, voidaan sijoittaa tiedostojärjestelmään. Tällä voidaan välttää niiden sisällyttämistä järjestelmäohjelmistoon, joka taas puolestaan kasvattaisi käynnistysaikaa. Ongelmalliseksi tilanteen tekee se, että fyysisesti tiedostojärjestelmä sijaitsee kohtuullisen hitaalla Flash-muistilla, jota järjestelmä- ohjelmiston muut komponentit käyttävät. Tiedostojärjestelmä on näin ollen kriittinen jaettu resurssi. Web-palvelin ja siihen liittyvät moduulit suoritetaan käytännössä aina hyvin matalan prioriteetin tehtävinä, joten Web-sovellus saa hyvin vähän aikaa tiedostojärjestelmän käyttöön.
Tästä syystä voidaan harkita staattisten osien siirtämistä välimuistiin. Tällöin niiden lataaminen ensimmäisen latauskerran jälkeen tehostuu huomattavasti, koska tiedosto
järjestelmää ei välimuistiin lataamiseen jälkeen enää tarvita. Välimuisti voidaan toteuttaa läpikirjoittavana, jolloin vain lukupyynnöt käsitellään välimuistin kautta.
Kirjoitusoperaatiot käyttävät edelleen tiedostojärjestelmän palveluja suoraan. Kuvassa 5.3 on esitetty tiedostojärjestelmän käyttäminen välimuistin avulla. Välimuistin toteuttamista yksinkertaistaa, että staattiset osat sovelluksesta eivät muutu, poistu tai lisäänny laitteen käyttöaikana. Välimuistiin ladatun tiedoston osalta voidaan luottaa ajantasaisuuteen ilman erikseen tehtäviä tarkistuksia.
Flash-ajuri Tiedostonkäsittely
API
Läpikirjoittava välimuisti
Fyysinen Flash-muisti Web-palvelin
Tiedostojärjestelmä Käyttöjärjestelmä
Kuva 5.3 Välimuistin käyttö palvelimessa.
5.5 Palvelinsovellus
Sulautettuihin järjestelmiin liitettyjen Web-sovellusten pääasiallinen tarkoitus on esittää laitteen- tai prosessin tilaa, mihin laite on liitetty. Tämä tarkoittaa, että pelkkien staattisten Web-sivujen avulla ei voida tuottaa tarkoituksen mukaista sovellusta. Tästä johtuen Web- sivut täytyy tuottaa joko kokonaan tai osittain dynaamisesti. Sulautettuihin järjestelmiin tarkoitetut Web-palvelimet sisältävät usein tekniikoita, joilla dynaaminen sisältö voidaan sisällyttää staattisiin Web-sivuihin. Osa näistä on tuttuja yleiskäyttöisten Web-palvelimien kautta, mutta osa on selkeästi tarkoitettu laiteläheisten ratkaisujen tarpeisiin.
Skripti-kielien käyttäminen ja suorittaminen Web-palvelimessa on hyvin tavallinen lähestymistapa yleiskäyttöisten Web-palvelimien yhteydessä ja sen suurimpia etuja ovat dynaamisesti tuotettujen dokumenttien rakenteen ja sisällön helppo muokkaaminen.
Sulautetuissa järjestelmissä palvelimella suoritettavien skriptien käyttö ei kuitenkaan ole ongelmatonta. Skriptien tulkkaaminen on hidasta ja tulkit itsessään kuluttavat laiteresursseja. Usein sulautettujen Web-palvelimien käyttämät skripti-kielet ovat merkittävästi suppeampia kuin yleiskäyttöisten palvelimien yhteydessä käytetyt.
SSI-tekniikan käyttämiseen liittyy skripti-kielten ongelma eli pyydetty Web-sivu täytyy aina parsia SSI-kutsujen varalta. Tämä kuluttaa laiteresursseja. Tehokkaampi ratkaisu on prosessoida sivut siten, että sisällöstä muodostetaan merkkijonoja ja funktio-kutsuja sisältävä taulukko, kts. kuva 5.4. Taulukko on tyypillisesti tuotettu C-kieliseen lähdekooditiedostoon, jolloin se voidaan kääntäjän avulla sisällyttää suoritettavaan ohjelmaan. Sivua pyydettäessä palvelin tarkistaa, löytyykö pyydettyyn sivuun taulukko- osoitin. Taulukon sisältö puretaan vastaukseksi ja SSI-kutsut voidaan suorittaa ilman tulkkaamista. Sivujen esiprosessointi on yleistä sulautettujen Web-palvelimien yhteydessä.
Tämän tavan etuja ovat vähäinen laiteresurssien tarve, koska sivujen käsittely tapahtuu etukäteen. Toisaalta sivujen sisällön muuttaminen vaatii aina uuden käännöksen sovelluksesta ja siirrettävyys Web-palvelimien välillä on huono.
C-kääntäjä
Kuva 5.4 Periaatekuva SSI-esiprosessoinnista.
CGI-pohjaisessa ratkaisussa voidaan omassa sovelluksessa tuottaa suoraan dokumentti, joka palautetaan asiakassovellukselle. Sulautettujen järjestelmien yhteydessä tämä käytännössä tarkoittaa usein sitä, että sivun rakenne sisällytetään käännettävään ohjelmaan mukaan. Haluttaessa muutoksia dokumentin rakenteeseen joudutaan tekemään uusi käännös sovelluksesta. CGI-pohjaista ratkaisua käytettäessä paras vaihtoehto olisi pyrkiä tuottamaan informaatio sellaisessa muodossa, joka pystytään helposti muokkaamaan asiakassovelluksen toimesta. Tämä mahdollistaa esitystapaan liittyvän informaation tallentamisen staattisesti ja mahdollisesti siten, että se voidaan helposti muuttaa.
5.5.1 Ratkaisuvaihtoehto
CGI-tyyppisen ratkaisun käyttäminen dynaamisen sisällön tuottamiseen saattaa tavallisten palvelimien yhteydessä olla huono, koska CGI-ohjelman ajaminen tarkoittaa käytännössä uuden prosessin luomista. Prosessien luominen saattaa muodostaa merkittävän kuorman palvelimelle, jos pyyntöjä tulee paljon. Sulautetuissa Web-palvelimissa CGI-tyyppinen toiminta on yleensä toteutettu tavallisena funktio-rajapintana ja CGI käytännössä suoritetaan samassa prosessissa kuin Web-palvelin. Tällöin prosessien luominen ei aiheuta ongelmaa.
Teknologia on pitkään käytettyjä siihen pohjautuvat sovellukset ovat kohtuullisen pienellä vaivalla siirrettävissä erilaisiin ympäristöihin. Toteutuksessa noudatetaan yleisesti käytettyä ns. Moúfe/2-rakennetta, jossa yksi CGI- tai muu vastaava aktiivinen ohjaussivu suorittaa pyyntöjen käsittelyn ja siirtämisen muille moduleille. Kuvassa 5.5 on esitetty Model2- rakenteen periaate [24, s. 166].
Selain-sovellus
Toiminnon käsittelijä
Prosessirajapinta VVeb-palvelln
Toiminnon ohjaus
Näkymä/
sivu
Kuva 5.5 Model2-rakenteen periaate.
Sallitut pyynnöt määritellään yksinkertaisuuden vuoksi tavallisien HTTP GET- ja POST- metodien avulla. SOAP-tyyppisten viestien käyttäminen vaatii käytännössä XML-parserin toteuttamista suojareleen järjestelmäohjelmistoon. Sovelluksessa käytettävät viestirakenteet ovat pysyviä ja tavallisten HTTP-viestien käsittelyyn on Web-palvelimissa usein valmis funktio-rajapinta. HTTP 1.1 -määrittelyn mukaisesti GET-metodia käytetään sellaisiin pyyntöihin, jotka eivät muuta laitteen tilaa. POST-metodia käytetään silloin, kun tilanmuutokset ovat mahdollisia.
Kaikkiin pyyntöihin vastataan XML-muotoisella dokumentilla. Sanomien rakenteet voidaan pitää kohtuullisen yksinkertaisina, jolloin niiden käsittely selainsovelluksessa tai mahdollisesti muussa asiakassovelluksessa saadaan mahdollisimman tehokkaaksi.
CGI-ohjelmien ja yleensä C-kielellä kirjoitettujen Web-sovellusten tietoturvariskeihin varaudutaan huolellisella suunnittelulla. Tarkastelemalla valmiita Web-palvelintoteutuksia voidaan määritellä, kuinka paljon omassa sovelluksessa tulee varautua erilaisiin ongelmiin.
Karkeasti voidaan sanoa, että protokollatasolla tehtävät hyökkäykset on yleensä estetty jo palvelintoteutuksissa, mutta sovellustasoon ne eivät voi puuttua. Näin ollen toimintojen ohjauksesta vastaava moduuli toteutetaan siten, että palvelupyynnöt hylätään aina jos:
• Se sisältää tunnistamattomia parametreja
• Parametrien arvot eivät ole sallituissa rajoissa tai arvoa ei ole liitetty parametriin
• Parametrien määrä ylittää asetetun rajan
• Polkumäärittelyt sisältävät kiellettyjä merkkijonoja, kuten ”V.\”
• Pyynnön muotoa ei tunnisteta
• HTTP GET-metodia käytetään muissa kuin turvallisissa operaatioissa
Kuvassa 5.6 on esitetty palvelinsovelluksen moduulien jakautuminen valitun toteutustavan mukaisesti. Kuvassa on esitetty mittausten ja tapahtumien käsittelyyn käytetyt moduulit, mutta sama rakenne ja jako toteutetaan myös muiden toimintojen kohdalla.
Web-palvelin
Kuva 5.6 Model2-rakenteen käytännön toteutus.
5.6 Selainsovellus
Selainsovellukseen sisällytettävä toiminnallisuus on pääpiirteittäin esitetty kuvassa 5.7 esitetyssä käyttötapauskaaviossa. Selainsovelluksen käyttäjiksi on määritelty neljä käyttäjäryhmää: operaattorit, pääkäyttäjät, vierailijat ja huoltohenkilökunta.
Selainsovellus
«precondition»
{sisäänkiijautuminen suoritettu}
Huolto ja ylläpito
.aitteen tilan tarkastelu , Laitteen asettelu
huolto
Laitteen ohjaaminen )/
pääkäyttäjät vierailijat
äiriötallenteiden käsittely
'apahtumierT siirtäminen _
Tapahtumien' .kuiltaaminen
operaattorit
'allennuksen' liipaisu
Kuva 5.7 Selainsovelluksen käyttötapaukset.
Käyttöliittymän yleisen ulkoasun ja asettelujen määrittely on teknisesti helpoiten ratkaistavissa. Toisaalta visuaalisen ilmeen ja käytettävyyden osalta työtä voi olla hyvin
Käyttöliittymän yleisen ulkoasun ja asettelujen määrittely on teknisesti helpoiten ratkaistavissa. Toisaalta visuaalisen ilmeen ja käytettävyyden osalta työtä voi olla hyvin