Timo Ahola
WEB-SOVELLUKSEN KEHITTÄMINEN
SÄHKÖNJAKELUVERKON SUOJARELEISIIN
Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 26.5.2006
Työn valvoja Markku Syrjänen
Työn ohjaaja Janne Starck
Tekijä
Timo Ahola
Päiväys
26.5.2006
Sivumäärä
85 + Niteet 6 s.
Työn nimi
Web-sovelluksen kehittäminen sähkönjakeluverkon suojareleisiin
Professuuri
T ietämvstekniikka
Koodi
T-93
Työn valvoja
Professori Markku Syrjänen
Työn ohjaaja
Diplomi-insinööri Janne Starck
Sähkönjakeluverkon automaatiojärjestelmien standardoinnin myötä eri laitevalmistajien suojareleet tulevat yhtenäistymään ja toisaalta uudet laitesukupolvet tarjoavat entistä enemmän mahdollisuuksia uusien ominaisuuksien toteuttamiseen.
Tässä opinnäytetyössä on tutkittu erilaisten Web-teknologioiden ja toteutusmallien soveltuvuutta sulautettuihin suojareleympäristöihin sekä standardoitujen mallinnus- menetelmien hyödyntämistä kehittämisessä ja tuotteistuksessa. Perustutkimukseen liittyen suoritettiin ABB Oy myyntiorganisaatiolle kyselytutkimus, jonka avulla kartoitettiin käyttäjien käsityksiä ja toiveita liittyen suojareleisiin toteutettaviin Web-sovelluksiin. Web- teknologiat sekä standardin mukaiset mallinnusmenetelmät ovat verrattain uusia asioita sähkönjakeluverkon automaatiojärjestelmien kanssa työskenteleville tuotekehittäjille.
Tämän opinnäytetyön eräs tarkoitus on tarjota katsaus näihin molempiin. Toteutukseen valituissa teknologioissa ja toteutusmalleissa on pyritty huomioimaan suojareletuotteiden rajalliset laiteresurssit, pitkät elinkaaret, erilaisten tuotevariaatioiden ylläpito sekä toteutuksen siirrettävyys erilaisten laitetoteutusten välillä.
Avainsanat
suoj arele, Web, WWW, sähkönjakeluverkon automaatio
Author
Timo Ahola
Date
26.5.2006
Pages
85 + app. 6 p.
Title of thesis
The development of Web-application for protection relays for distribution networks
Professorship
Knowledge Engineering
Professorship Code
T-93
Supervisor
Professor Markku Syrjänen
Instructor
M.Sc. Janne Starck
As a result of the standardization work that has been done for the distribution automation systems, the protection relays from different manufacturers become like each other, but on other hand, the new generations of devices will have more potential for new features.
This thesis investigates how the different Web-technologies and design patters fit into embedded protection relays. As a part of the research, a marketing survey was conducted, which was used to find out the requirements for the Web-applications that are provided by the protection relay. It has also been investigated how the standardized way of modeling the devices can be used in the development of the Web-applications. Different Web- technologies and standardized ways to model the protection relays are quite new things for the developers that are working in the area of distribution automation systems. One of the aims of this thesis is to provide information from both of these areas. The technologies and design patterns that are implemented were chosen according to the limited hardware resources and long life cycles of the devices; number of product variants and transferability were also considered when the technologies were chosen.
Keywords
protection relay, Web, WWW, distribution automation
Tämä diplomityö on tehty ABB Oy Sähkönj akeluautomaatio -yksikössä Vaasassa opinnäytetyöksi TKK:n tietotekniikan osastolle. Työn valvojana on toiminut professori Markku Syrjänen ja ohjaajana diplomi-insinööri Janne Starck, joille haluan esittää kiitokset.
Lisäksi haluan kiittää kaikkia työ- ja opiskelukavereita, jotka ovat tavalla tai toisella myötävaikuttaneet tämän työn valmistumiseen. Erityisesti haluan kiittää vaimoani Anua saamastani tuesta ja kannustuksesta sekä lapsiani, joiden ansiosta sain välillä muutakin ajateltavaa kuin tämä työ.
Laihialla 26.5.2006
Timo Ahola
Rajakankaantie 5 66400 Laihia
TIIVISTELMÄ ABSTRACT ESIPUHE
SISÄLLYLUETTELO
KUVAT 1
TAULUKOT 3
MERKINNÄT JA LYHENTEET 4
1 JOHDANTO...8
2 PERUSTEET...10
2.1 Suojarele...10
2.2 Suojareleiden ohjelmistoympäristöt...13
2.3 Suojareleiden laiteympäristöt...14
2.4 Tiedonsiirtojärjestelmät...16
2.5 IEC 61850 standardi...19
2.5.1 Datamalli... 20
2.5.2 Tiedonsiirto... 24
2.5.3 SCL-kuvauskieli... 26
3 WEB-TEKNOLOGIAT JA NIIDEN SOVELLUKSET... 29
3.1 Web-teknologiat... 29
3.2 Tietoturva... 35
3.2.1 Salaaminen ja asiakassovelluksen todentaminen... 37
3.3 Kirjallisuuskatsaus... 39
3.4 Kyselytutkimus...42
3.4.1 Tulokset... 45
3.4.2 Kyselytutkimuksen yhteenveto. 49
4.2 Tavoitteet ja lähtökohdat... 50
4.3 Asettelu] en hai linta... 53
4.4 Muita soveltamismahdollisuuksia... 58
5 WEB-SOVELLUKSEN KEHITTÄMINEN... 59
5.1 Nykytilanne... 59
5.2 Lähtökohdat ja toteutusmallin valinta... 59
5.3 Laitteistoarkkitehtuurien huomioiminen... 63
5.4 Käynnisty sajan minimointi... 64
5.5 Palvelinsovellus... 66
5.5.1 Ratkaisuvaihtoehto... 68
5.6 Selainsovellus... 71
5.7 Web-sovelluksen resurssit... 74
5.8 Tietoturva ja tiedon yhtenäisyys... 76
6 YHTEENVETO JA JOHTOPÄÄTÖKSET... 77
LIITTEET Kyselytutkimuslomake
Web-palvelimien vertailutaulukko IEC 61850 standardin osat
KUVAT
Kuva 2.1 Konesuojareleen kytkentäesimerkki... 11
Kuva 2.2 ABB:n prosessoripohjaisia suojareleitä (REF54_, REX521, REM610)...11
Kuva 2.3 Esimerkki IEC 1131-3 mukaisista toimilohkoista ja niiden käytöstä...12
Kuva 2.4 Sulautetuissa järjestelmissä esiintyviä muistikonfiguraatioita... 15
Kuva 2.5 Sähköaseman paikallisautomaatiojärjestelmän periaatekuva... 17
Kuva 2.6 IEC 61850 datamalli luokkakaaviona...20
Kuva 2.7 IEC 61850 palvelimen mallinnus... 21
Kuva 2.8 Esimerkki loogisten solmujen, toimintojen ja fyysisten laitteiden suhteesta... 22
Kuva 2.9 Loogisen solmun rakenne puu-rakenteena...23
Kuva 2.10 Periaatekuva loogisten solmujen hajautuksesta... 24
Kuva 2.11 IEC 61850 tiedonsiirtorajapinnat...25
Kuva 2.12 Periaatekuva IEC 61850-8-1 SCSM määrittelystä... 25
Kuva 2.13 SCL-kielen ja erityyppisten konfigurointitiedostojen käyttö... 28
Kuva 3.1 Web- ja Intemet-teknologioiden suhde protokollamalliin...29
Kuva 3.2 Perinteisen Web-sovelluksen ja Ajax-pohjaisen sovelluksen ero... 33
Kuva 3.3 Salaus- ja todentamismenetelmien suhde siirtokerroksiin...38
Kuva 3.4 HTTP Basic-todentaminen... 38
Kuva 3.5 HTTP Digest-todentaminen... 39
Kuva 3.6 Kyselyn tulokset liittyen Web-sovelluksen tarpeeseen...45
Kuva 3.7 Kyselyn tulokset liittyen toiminnallisuuteen... 46
Kuva 3.8 Kyselyn tulokset kysyttäessä Web-sovelluksen käyttötavasta... 47
Kuva 3.9 Kyselyn tulokset liittyen käyttäjätasoihin...47
Kuva 4.1 Suojareleiden konfiguraatiot ja tuotteistaminen... 51
Kuva 4.2 Periaatekuva kiinteästä ja ohjelmoitavasta suojareleestä... 52
Kuva 4.3 Esimerkki suojareleen toimintojen ryhmittelystä laitteen paikallisnäytöllä...53
Kuva 4.4 SCL-käsittely kiinteästi konfiguroitavassa laitteessa... 56
Kuva 4.5 SCL-käsittely ohjelmoitavassa suojareleessä... 57
Kuva 5.1 Web-sovelluksen rakenne ja rajapinnat... 62
Kuva 5.2 Erilaisten laitteistoarkkitehtuurien periaatekuvat... 64
Kuva 5.3 Välimuistin käyttö palvelimessa... 66
Kuva 5.4 Periaatekuva S SI-esiprosessoinnista... 67
Kuva 5.5 Model2-rakenteen periaate...69
Kuva 5.6 Model2-rakenteen käytännön toteutus... 71
Kuva 5.7 Selainsovelluksen käyttötapaukset...72
Kuva 5.8 Ajax-sovelluksen rakenne...73
Kuva 5.9 Resurssien jakaminen sovellusten kesken... 75
TAULUKOT
Taulukko 2.1 IEC 61850 viestityypit ja vastaavat protokollat...26 Taulukko 5.1 Web-palvelimelle asetetut vaatimukset...60
MERKINNÄT JA LYHENTEET ACSI
Ajax ANSI ARP
ASP BEEP CDC CGI CHAP
CID CPOW CPU CSS DA DNP 3.0 DOM DPC DSP EEPROM GOOSE GSE GSSE HMI
HTML
Abstract Communication Service Interface, tiedonsiirtoon käytetyt palvelut IEC 61850 järjestelmässä
Asynchronous JavaScript And XML, Web-teknologia
The American National Standards Institute, standardisointijärjestö Address Resolution Protocol, IP ja laiteosoitteen välillä tehtäviin muunnoksiin käytettävä protokolla
Active Server Pages, Web-palvelimella suoritettava skripti-kieli Blocks Extensible Exchange Protocol, sovellustason protokolla Common Data Class, IEC 61850 yhteiset dataluokkamäärittelyt Common Gateway Interface, Web-sovellusrajapinta palvelimella
Challenge Handshake Authentication Protocol, todentamiseen käytettävä menetelmä
Configured IED Description, SCL-muotoinen tiedosto IEC 61850 looginen solmu: synkronoitu erotin
Central Processing Unit, ohjelmaa suorittava yksikkö
Cascading Style Sheets, tekniikka tyylien lisäämiseksi dokumentteihin Distribution Automation, sähkönjakeluverkon automaatio
Sähkönjakeluverkon automaatiojärjestelmissä käytetty protokolla Document Object Model, dokumenttimalli ja ohjelmointirajapinta IEC 61850 CDC tyyppi: kahdennettu tilatieto
Digital Signal Processor, signaalinkäsittelyprosessori Haihtumattoman muistin tyyppi
Generic Object Oriented Substation Event Generic Substation Event
Generic Substation Status Event
Human Machine Interface, teollisuudessa käytetty nimitys laitteen paikallisnäytöstä
HyperText Markup Language, tapa esittää tietoa WWW-ympäristössä
HTTP
I/O ICD ICMP
IEC
IEC 60870 IEC 60870- IEC 61850 IED IEEE IHMI IMAP
IP IPSEC L2TP TON
MAP
MD 5 MMS Modbus OWL PAP POIS PGP
HyperText Transfer Protocol, tapa siirtää informaatiota WWW- ympäristössä
Input/Output, yleisnimitys laitetason tuloista ja lähdöistä IED Capability Description, SCL-muotoinen tiedosto
Internet Control Message Protocol, ohjaus ja virheviestien lähetykseen käytetty protokolla
International Electrotechnical Commission, sähköalan kansainvälinen standardisointi ärj esto
101 Sähkönjakeluverkon automaatiojärjestelmissä käytetty protokolla 103 Sähkönjakeluverkon automaatiojärjestelmissä käytetty protokolla Kansainvälinen standardi sähkönjakeluautomaatio järjestelmille Intelligent Electronic Device, prosessoripohj ainen laite
Institute of Electrical and Electronics Engineers, Inc.
IEC 61850 looginen solmu: vastaava kuin HMI
Internet Message Access Protocol, sähköpostin käsittelyyn käytettävä protokolla
Internet Protocol, osoitteistamiseen ja reitittämiseen käytettävä protokolla IP Security Protocol, IP-kerroksen tietoturva-arkkitehtuuri
Layer 2 Tunnel Protocol, tunnelointiprotokolla
Local Operating Network, mm. sähkönjakeluverkon automaatio
järjestelmissä käytetty protokolla
Manufacturing Automation Protocol, MMS protkollaan liittyvä määrittely
Turvallinen hash-funktio
Manufacturing Message Specification (ISO 9506), protokollamäärittely Modiconin kehittämä sarjaliikenneprotokolla
Web Ontology Language, määrittely informaation prosessointia varten Password Authentication Protocol, todentamistekniikka
IEC 61850 looginen solmu: distanssisuoja
Pretty Good Privacy, julkisen avaimen salaustekniikka
PHP POP POSIX РРТР Profibus РТОС RAM RDF
RED500 RS-232 RS-485 SCADA
SCD SCL
SCSM
SDRAM SGML
SMTP SOA SOAP SPA SPI SPS SRAM SSD
Web-palvelinympäristöihin kehitetty skriptikieli
Post Office Protocol, sähköpostin käsittelyyn käytettävä protokolla Portable Operating System Interface for uniX, käyttö] ärjestelmärajapinta Point-to-Point Tunnel Protocol, turvallinen tunnelointiprotokolla
Profibus organisaation kehittämä nopea sar]aliikenneprotokolla IEC 61850 looginen solmu: ylivirtasuoja, aikapohjainen
Random Access Memory, käyttömuisti
Resource Description Framework, WWW resurssien kuvaukseen käytettävä määrittely
ABB:n suo]arele tuoteperhe
Sarjaliikenteessä käytetty signaalitasomäärittely
Sarjaliikenteessä käytetty differentiaalinen signaalitasomäärittely Supervisory Control And Data Acquisition, sähköasemien kaukokäyttö-j ärj estelmä
Substation Configuration Description, SCL-muotoinen tiedosto
Substation Configuration description Language, IEC 61850 standardin määrittelemä kuvauskieli
Specific Communication Service Mapping, IEC 61850 ristiviittaus-määrittely
Haihtuvan muistin tyyppi
Standard Generalized Markup Language, standardoitu dokumentointi kieli
Simple Mail Transfer Protocol, sähköpostin siirtoon käytettävä protokolla Service-Oriented Architecture, palvelupohjainen arkkitehtuuri
XML-pohjainen tapa välittää viestejä HTTP-protokollan avulla ABB:n kehittämä sarjaliikenneprotokolla
Serial Peripheral Interface, yksinkertainen oheislaitesarjaliitäntä IEC 61850 CDC tyyppi: tavallinen tilatieto
Haihtuvan muistin tyyppi
System Specification Description, SCL-muotoinen tiedosto
SSH Secure Shell, mm. WWW-ympäristöissä käytetty tiedonsiirron suoj austekniikka
SSI Server Side Includes, tapa sisällyttää dynaamisia elementtejä Web-sivuun SSL Secure Socket Layer, salausprotokolla
SV Sampled Values, näytteistettyjen arvojen siirtoon käytetty protokolla SVG Scalable Vector Graphics, vektorigrafiikan esitystapa
TCP Transmission Control Protocol, luotettava tiedonsiirtoprotokolla TLS Transport Layer Security, sama kuin SSL
UCA Utility Communications Architecture
UDP User Datagram Protocol, IP protokollan yhteydessä käytettävä protokolla W3C Worl Wide Web Consortium, Web teknologioita kehittävä organisaatio VML Vector Markup Language, vektorigrafiikan esitystapa
WSDL Web Services Description Language, kieli Web-palvelujen määrittelyyn
WWW World Wide Web, myös W3, Web
XCBR IEC 61850 looginen solmu: katkaisija
XHTML extensible HyperText Markup Language, XML-muotoinen HTML XML extensible Markup Language, rakenteinen dokumenttimuoto XPath XSL-kieliperheen jäsen
XSL Extensible Stylesheet Language, XMUdokumenttien käsittelyyn käytettävä kieliperhe
XSL-FO XSL-kieliperheen jäsen XSLT XSL-kieliperheen jäsen
1 JOHDANTO
IEC 61850 standardin ensimmäinen versio on ollut nyt jonkin aikaa saatavilla ja suoj arelevalmistaj at ympäri maailmaa tuovat markkinoille uusia standardin mukaisia laitteita. Ensimmäistä kertaa ollaan tilanteessa, jossa eri valmistajien tuotteet tarjoavat standardoitujen ominaisuuksien lisäksi mahdollisuuden liittää niitä samoihin automaatiojärjestelmiin. Tämä voidaan toteuttaa yleiskäyttöisten ohjelmistotyökalujen avulla niin, että laitteet pystyvät siirtämään tietoa keskenään Ethernet-verkossa. Tämä lisää entisestään alalla vallitsevaa kovaa kilpailua ja asiakkaille pitää pystyä tuottamaan laitteita, jotka erottuvat ominaisuuksiltaan muista valmistajista. Yksi tällainen lisäominaisuus voisi
olla suojareleeseen liitetyt Web-sovellukset.
Web-sovellusten liittäminen laitteisiin tai järjestelmiin on esimerkiksi viihde-elektroniikan, teollisuusautomaatioj ärj estelmien sekä kunnonvalvontasovelluksien yhteydessä jo arkipäivää. Sähkönjakeluun liittyvissä järjestelmissä ne ovat kuitenkin vielä suhteellisen harvinaisia ja eikä niitä yleensä ole toteutettu suoraan suojareleeseen.
Tämän työn puitteissa kerätyn tiedon pohjalta on tarkoitus pystyä kehittämään sulautettuihin järjestelmiin sopiva Web-sovellus, joka pystytään siirtämään erilaisten laite- ja ohjelmistoarkkitehtuurien välillä mahdollisimman pienellä sovitustyöllä. Web- sovelluksen tarjoamilla toiminnoilla tulisi olla mahdollista valvoa ja ohjata laitteen toimintaa tavallisen internet-selaimen avulla. Näin voitaisiin korvata kokonaan tai osittain perinteiset suojareleen asetteluun ja ohjelmointiin käytettävät PC-sovellukset.
Edellä esitetyt tavoitteet saattavat tuntua nykyisen teknologisen kehityksen vuoksi helpoilta, mutta työn edetessä havaitaan kuinka yksinkertaiselta kuulostavat tuotekehitysvaatimukset jakautuvat lukuisiksi tehtäviksi, joita ilman aiheeseen perehtymistä on hyvin hankala nähdä. Web-teknologioiden hyödyntäminen kriittisissä suojarelesovelluksissa tarjoaa monia haasteita. Tässäkin tapauksessa kehitettävää löytyi laiteresurssien käytön optimoinnista käyttöliittymäsuunnitteluun.
Työssä pyritään vastaamaan seuraaviin kysymyksiin, jotka ovat varsinaisen päätavoitteen onnistumisen kannalta oleellisia:
• Mitkä Web-teknologiat ja toteutusmallit sopivat parhaiten käytettäväksi suojareleessä?
• Minkälaisia odotuksia käyttäjillä on suojareleisiin liitetyille Web-sovelluksille?
• Tuotehallinnollisesti Web-sovellusten ylläpitäminen sulautetuissa laitteissa voi vaatia yllättävän paljon työtä. Voidaanko IEC 61850 standardia soveltaa sisällön tuottamisessa ja onko tätä prosessia mahdollista automatisoida?
Työ etenee seuraavasti: luvussa 2 tutustutaan sähkönjakeluverkon automaatiojärjestelmiin sekä niissä käytettäviin suojareleisiin ja niiden tekniikkaan. Tällä teollisuudenalueella on omat erityisvaatimuksensa, joiden voidaan olettaa heijastuvan Web-sovellusten kehitystyöhön. Lisäksi tarkastellaan sähkönjakeluverkon automaatiojärjestelmiin liittyviä tiedonsiirtoratkaisuja ja työn kannalta tärkeää IEC 61850 standardia. Luvussa 3 luodaan katsaus erilaisiin Web-teknologioihin sekä niihin liittyviin riskeihin ja tietoturvaan, koska näistä ei sähkötekniikkaan tai teollisuuden sulautettuihin järjestelmiin suuntautuneilla henkilöillä välttämättä ole kovin kattavaa tuntemusta. Tässä osiossa esitetään työn yhteydessä suoritetun kyselytutkimuksen tuloksia. Erilaisten toteutusmallien käsittelyyn on haettu laajempaa näkemystä tutustumalla aiheesta kirjoitettuihin artikkeleihin muiltakin kuin sähkönjakeluverkon automaatiojärjestelmien alueelta. Luvuissa 4 ja 5 esitetään oman sovelluksen suunnittelua ja IEC 61850 standardin soveltamista. Valittu lähestymistapa on käytännönläheisempi kuin varsinaisesti suunnitteluprosessia kuvaava. Viimeinen luku on varattu yhteenvedolle ja aiheeseen liittyvälle pohdinnalle.
2 PERUSTEET 2.1 Suoj arele
Suojareleellä, tai lyhyemmin releellä, tarkoitetaan tässä yhteydessä laitetta, joka pystyy havaitsemaan sähkönjakeluverkossa olevan vian ja tekemään toimenpiteitä, joilla voidaan minimoida viasta aiheutuvat vahingot [1, s. 9-30].
Suojareleiden kehityksessä on nähtävissä selkeitä askeleita, jotka johtavat nykyisin käytettyihin prosessoripohjaisiin releisiin. Kehitys alkoi sähkömekaanisista releistä, joissa mittaus tyypillisesti tapahtuu vertaamalla mittasuureen aiheuttamaa sähkömagneettista voimaa mekaaniseen jousen aiheuttamaan voimaan. Sähkömekaanisissa releissä pystyttiin jo tekemään toimintapisteasetteluja, mutta asettelut tyypillisesti ryömivät ympäristöolosuhteista ja ajasta riippuen. Asettelulla tarkoitetaan suojareleen toimintaan vaikuttavien parametrien arvojen muuttamista. Sähkömekaanisten releiden jälkeen siirryttiin staattisiin releisiin, joissa ei enää ollut ohjauskoskettimien lisäksi muita liikkuvia osia. Mittausten käsittelyjä vertailu on näissä toteutettu analogiaelektroniikalla. Staattisilla releillä saavutetaan suuri toimintanopeus sekä asettelujen pysyvyys. [2, s. 299]
Tämän jälkeen siirryttiin numeerisiin releisiin eli älykkäisiin prosessoripohjaisiin releisiin (IED), joissa mittaukset käsitellään analogia-digitaalimuunnoksen kautta ja laskenta tapahtuu digitaalisesti [2, s. 299]. Ensimmäiset ajatukset prosessoripohjaisista releistä on esitetty jo 1960-luvulla, mutta kaupallisia toteutuksia saatiin vasta 1970-luvun lopussa [1, s. 9-2; 3, s. 8]. Prosessoripohjaiset toteutukset mahdollistivat entistä monipuolisempien toimintojen toteutuksen yhdellä laitteella sekä erilaisten kenttäväylien ja protokollien käyttöönoton sähköasemilla [2, s. 411]. Aikaisemmin signaalit oli johdotettava yksitellen laitteiden ja järjestelmien välillä. Prosessoripohjaisten releiden yksi tärkeimmistä ominaisuuksista on itsevalvonta, jonka avulla voidaan ratkaisevasti vähentää laitteen sisäisten toimintahäiriöiden vaikutuksia sähkönjakeluverkon automaatiojärjestelmän toimintaan [3, s. 34]. Kuvassa 2.1 on esitetty yksinkertaistettu konesuojareleen kytkentä ja kuvassa 2.2 on muutamia AB В Oy valmistamia prosessoripohj aisia suojareleitä.
v—V V
►Tiedonsiirto Suojarele
Kuva 2.1 Konesuojareleen kytkentäesimerkki.
Kuva 2.2 ABB:n prosessoripohjaisia suojareleitä (REF54_, REX521, REM610).
Prosessoriteknologian ja laiteresurssien kasvaessa suojareleiden ominaisuudet monipuolistuvat jatkuvasti. Nykyaikaiset suojareleet pystyvät suojaustoimintojen ohella suorittamaan esimerkiksi erilaisia ohjaus- ja valvontatoimintoja, joita varten aikaisemmin tarvittiin omat laitteet. Ohjauksilla tarkoitetaan tyypillisesti katkaisijoiden, erottimien sekä muuntajien jännitteensäätäjien ohjaamista [4, s. 113].
Numeeristen releiden asettelu- ja ohjelmointimahdollisuudet ovat usein erittäin monipuoliset. Ohjelmointiin käytetään tyypillisesti graafiseen käyttöliittymään perustuvia korkeantason ohjelmointikieliä. Suojareleen ohjelmointia kutsutaan usein myös konfiguroinniksi. Korkeantason ohjelmointikielenä voidaan käyttää esimerkiksi IEC 1131- 3-standardiin pohjautuvaa toimilohkoesitystä, kts. kuva 2.3. Erilaisiin sähkönjakeluverkon topologian muutoksiin ja kuormitustilanteiden vaihteluihin voidaan varautua asetteluryhmien avulla [4, s. 116]. Asetteluryhmiä on tyypillisesti kahdesta kahdeksaan kappaletta, joista yksi on aktiivinen eli käytössä. Asetteluryhmä sisältää suojaustoimintoihin liittyviä asetteluja ja yksi asetteluryhmä vastaa yhtä sähkönjakeluverkon tilaa. Asetteluryhmä mahdollistaa asetteluarvojen samanaikaisen käyttöönoton [4, s. 116]. Hyvin usein erilaisten suojausalgoritmien parametrit ovat toisistaan riippuvaisia ja niiden asettelu yksi kerrallaan ilman asetteluryhmiä olisi käytännössä mahdotonta.
AND AND MUX
LOAD CTD 1
Kuva 2.3 Esimerkki IEC 1131-3 mukaisista toimilohkoista ja niiden käytöstä.
Sähkömekaanisia ja -staattisia suojareleitä valmistetaan edelleen ja niitä on runsaasti käytössä, vaikka ne vähitellen korvautuvat uudemman sukupolven laitteilla. Myöhemmin tässä työssä suojareleellä tarkoitetaan aina prosessoripohjaista toteutusta.
2.2 Suojareleiden ohjelmistoympäristöt
Tässä työssä suojareleiden ohjelmistoympäristöllä tarkoitetaan laitteeseen sisältyvää sulautettua järjestelmää. Suojareleiden ohjelmistot ovat lisääntyneiden toimintojen johdosta monimutkaistuneet niin, että käytännössä laitteen sisäinen tehtävien- ja resurssien}ako hoidetaan käyttöjärjestelmän avulla. Suojareleissä, kuten teollisuussovelluksissa yleisestikin, käyttöjärjestelmät ovat erityisesti sulautettuihin järjestelmiin tarkoitettuja reaaliaikaisia käyttöjärjestelmiä. Reaaliaikakäyttöj ärj estelmien ominaisuuksia ovat deterministisyys, hyvä vasteaika, muunneltavuus, luotettavuus ja hallittu alasajo.
Reaaliaikaisen järjestelmän oikea toiminta ei riipu pelkästään loogisesti oikeasta tuloksesta vaan myös ajasta, jolloin tulos saatiin. Suoritettavien tehtävien reaaliaikavaatimukset ovat joko kovia tai pehmeitä. Kova reaaliaikavaatimus tarkoittaa sitä, että tehtävän suorittaminen on epäonnistunut, jos asetettuja aikakriteereitä ei saavuteta ja ohjattava järjestelmä saattaa muuttua epävakaaksi. Pehmeä reaaliaikavaatimus voidaan edelleen
suorittaa onnistuneesti vaikka aikakriteeri ei täyty. [5, s. 450]
Laiteresurssien rajallisuudesta johtuen sulautettuihin järjestelmiin on tarjolla eritasoisia reaaliaikaisia käyttöjärjestelmiä. Tästä johtuen saman yrityksen eri tuotteissa voi olla käytössä eri käyttöjärjestelmä, joista osa voi olla jopa omaa suunnittelua.
Käyttöjärjestelmien tarjoamat palvelut ovat luonnollisesti samankaltaisia, mutta ne eivät välttämättä toteuta esimerkiksi POSIX-standardirajapintaa. Käytössä olevat käyttöjärjestelmät tarjoavat suppeimmillaan vain välttämättömimmät prosessien luomiseen ja niiden välisen tiedonsiirron toteuttamiseen tarvittavat kutsut. Tyypillisesti kaikki muut osat kuten tiedostojärjestelmä, laiteajurit ja protokollapinot liitetään erillisinä moduuleina käyttöjärjestelmään. Aikakriittiset suojausalgoritmit suoritetaan jaksollisesti keskeytys- käsittelyssä ja muut toiminnot normaalisti käyttöjärjestelmän vuorontajan ohjaamina.
2.3 Suojareleiden laiteympäristöt
Hyvin yleisesti sulautetuissa järjestelmissä ohjelma suoritetaan suoraan haihtumattomasta muistista, jolloin haihtumattoman muistin kohdalla puhutaan ohjelmamuistista.
Muistipiirien kapasiteetin kasvaessa ja tekniikan kehittyessä ollaan kuitenkin siirtymässä enemmän järjestelmiin, joissa ajettava ohjelma ladataan haihtumattomasta muistista käyttömuistiin suoritusta varten.
Suojareleissä on usein käytössä tiettyyn tarkoitukseen optimoitu prosessori ja muistikonfiguraatio. Yksinkertaisimmissa laitteissa käytetään mikrokontrollereita, joissa samalla piirille on prosessoriytimen lisäksi sisällytetty tarvittavat oheislaitteet sekä rajattu määrä käyttö- ja ohjelmamuistia. Usein mikrokontrollerit eivät edes kykene osoittamaan ulkoisia muisteja.
Tavallisesti suojareleissä käytetään tunnettujen valmistajien pitkän elinkaaren omaavia prosessoriperheitä. Prosessoreita voi olla yhdessä laitteessa useampia ja tietyissä tapauksissa käytetään signaalinkäsittelyyn tarkoitettuja DSP-prosessoreita. DSP-prosessorit soveltuvat esimerkiksi monimutkaisten suoj ausalgoritmien laskentaan. Tavalliset prosessorit edustavat yleensä von Neumann-arkkitehtuuria, jossa ohjelma- ja käyttömuisti käyttävät yhteisiä osoite-, ohjaus- ja dataväyliä. DSP-prosessoreissa käytetyssä Harvard- arkkitehtuurissa ohjelma- ja käyttömuistille on omat osoite-, ohjaus- ja dataväylät, mikä tehostaa ohjelman suoritusta. Tyypillisiä nykyaikaisissa sulautetuissa järjestelmissä käytettyjä haihtuvan muistin tyyppejä ovat SRAM ja SDRAM. Haihtumattomista tavallisimpia ovat EEPROM ja Flash-tyypit. Kuvassa 2.4 on esitetty muutamia esimerkkejä erilaisista muistikonfiguraatioista.
EEPROM
Flash
prosessori (von Neumann)
SRI
osoite data ohjaus
prosessori (von Neumann)
SRI
osoite data ohjaus
ohjelmamuisti
Flash
käyttömuisti
SRAM
SDRAM
Í EEPROM
prosessori (von Neumann)
SRI
osoite data ohjaus
Flash
ohjaus- ja virkistyslogiikka
SDRAM
Kuva 2.4 Sulautetuissa järjestelmissä esiintyviä muistikonfiguraatioita.
SRAM on nopea staattinen luku-kirjoitusmuisti. SRAM-muistia käytetään sovelluksissa, joissa käyttömuistin koko on satoja kilotavuja tai vähemmän ja muistin nopeus sekä liitännän yksinkertaisuus ovat tärkeitä. SRAM säilyttää tiedon niin kauan kuin käyttöjännite on kytketty eikä se tarvitse virkistämistä. [6, s. 40]
SDRAM on synkroninen DRAM-vcmisXi. DRAM-muisti on yksinkertainen valmistaa ja verrattuna SRAM-muistiin se tarvitsee huomattavasti vähemmän pinta-alaa. Tämä taas mahdollistaa kapasiteetiltaan suurempien muistien taloudellisen valmistamisen. DRAM on SRAM-muistia hitaampaa ja vaatii erityisen ohjainlogiikan, jolla huolehditaan muistin tarvitsemista virkistys- ja kellosignaaleista. Nykyaikaisiin prosessoreihin tämä logiikka on jo sisällytetty, joten erillisiä ohjainpiirejä ei tarvita. [6, s. 86]
Aikaisemmin prosessoreissa ei välttämättä ollut SDRAM-muistien vaatimaa ohjauslogiikkaa eikä SDRAM-muisteja pidetty riittävän luotettavana vaativiin sulautettuihin järjestelmiin, joten RAM-muisti täytyi olla luotettavana pidettyä nopeaa SRAM-tyyppiä. Toisaalta yhä edelleen tietyissä erityistä nopeutta vaativissa sovelluksissa SRAM-muistien käyttö on välttämätöntä.
EEPROM-muistissa tallennettu tieto säilyy ilman käyttöjännitettä eikä piiriä tarvitse irrottaa ohjelmoinnin ajaksi. EEPROM-muistia voidaan ohjelmoida tavu kerrallaan, mutta kirjoitusaika on suhteellisen pitkä, usein muutamia millisekunteja [6, s. 56]. Nykyisin EEPROM-muistit on usein varustettu sarjaliitännällä ja niitä käytetään esimerkiksi tunnistetietojen tallentamiseen. EEPROM-muistien kapasiteetit ovat yleensä joitakin kymmeniä kilotavuja.
FYas/z-muisti on nykyisin käytetyin haihtumaton muistityyppi sulautetuissa järjestelmissä.
Sen tärkeimmät ominaisuudet ovat samat kuin EEPROM-muistilla. Suurimmat erot tulevat piirin toteutustekniikassa, tiedon kirjoitustekniikassa, nopeudessa sekä kapasiteetissa.
Flash-muistissa ohjelmoitavan muistipaikan tulee olla tyhjä ja yhden tavun kirjoittaminen kestää noin 10 ps. Muisti pitää tyhjentää sektoreittain [6, s. 62]. Nykyisten Flash-muistien kapasiteetit ovat hyvin suuria, usein kymmeniä tai satoja megatavuja. Ohjelma voidaan suorittaa suoraan Flash-muistista tai sitten se ladataan RAM-muistiin suoritusta varten.
2.4 Tiedonsiirtojärjestelmät
Sähköaseman paikallisautomaatiojärjestelmä jakaantuu kolmeen kerrokseen: valvomotaso, asemataso ja lähtötaso kts. kuva 2.5 [2, s. 412]. Eri kerroksissa käytetään tyypillisesti erilaisia väyläratkaisuja ja protokollia tiedon välittämiseen. Valvomotasolla tiedonsiirto tapahtuu usein TCP/IP protokollan avulla Ethernet-verkossa. Asematasolla käytetään asemaväyliä kuten LON ja lähtötasolla jokainen signaali on johdotettu erikseen suojareleen digitaali- ja analogiatuloihin sekä lähtöihin. Myöhemmin esiteltävä IEC 61850 standardi määrittelee eri tasoille sopivat yhtenäiset tiedonsiirtotavat.
VALVOMOTASO
ASEMATASO
tiedonvälitys- yksikkö paikalliskäyttöjärjestelmä
asemaväylä
"lähtötaso
suojareleet ja ohjausyksiköt
johdotus
kojeisto
Kuva 2.5 Sähköaseman paikallisautomaatiojärjestelmän periaatekuva.
Prosessiautomaatiojärjestelmiin verrattuna sähkönjakeluverkon automaatiojärjestelmissä käytetään hyvin eri tyyppisiä protokollia. Vain muutamat protokollat, kuten Profibus ja Modbus, ovat saavuttaneet suosiota molemmissa järjestelmissä. Tarve erilaisille protokollille on syntynyt mm. seuraavista syistä [7]:
• Informaatio on eri tasolla. Prosessiautomaatiossa siirretään tyypillisesti suoraan anturilta saatavaa mittausinformaatiota, kun taas suojareleeltä saatava data on mittausinformaation perusteella tehty johtopäätös tai toiminto.
• Sähköasemat on hajautettu maastoon ja tiedonsiirto voi tapahtua hitaan tiedonsiirtoväylän kautta, esimerkiksi analogisella modeemilla. Hitaan väylän takia pyritään siirtämään mahdollisimman vähän informaatiota ja käytännössä tämä tarkoittaa tapahtumapohjaista tiedonsiirtoa.
Tulevaisuudessa nämä kaksi teollisuudenalaa tulevat todennäköisesti lähentymään Ethemet-pohjaisten ratkaisujen tullessa markkinoille. Nykyisin sähkönjakeluverkon automaatiojärjestelmiin on vakiintunut useita erilaisia protokollia. Osa näistä perustuu kansainvälisten standardisointijärjestöjen määrittelyihin, kuten esimerkiksi IEC 60870-101, IEC 60870-103 sekä myöhemmin esiteltävä IEC 61850. Näiden lisäksi on useita laitevalmistajakohtaisia protokollia, joista esimerkkinä SPA.
Monet laitevalmistajakohtaiset protokollamäärittelyt ovat yleisesti saatavilla, mutta eri valmistajat tulkitsevat määrittelyjä hieman toisistaan poikkeavalla tavalla. Sen vuoksi toteutukset eivät ole keskenään täysin yhteensopivia. Tämä hankaloittaa eri valmistajien laitteiden liittämistä samaan järjestelmään ja lisää merkittävästi järjestelmän rakentamiseen ja suunnitteluun tarvittavaa työmäärää. Tyypillistä perinteisesti käytetyille protokollille on, että ne ovat signaalipohjaisia, eli siirrettävä tieto ei sisällä merkitystä vaan se täytyy määritellä jokaiselle tiedolle erikseen.
Perinteisesti sähkönjakeluverkon automaatiojärjestelmissä käytetyt protokollat perustuvat kysely-vastaus periaatteeseen, jossa samaan verkkoon liitetyistä laitteista tai järjestelmistä vain yksi voi suorittaa kyselyjä. Näiden protokollien toteutus onnistuu vähäisillä laiteresursseilla, koska esimerkiksi viestien törmäyksen tunnistusta ei tarvita. Jotkin protokollat mahdollistavat tietojen lähettämisen spontaanisti ja jopa useille eri vastaanottajille, esimerkkinä mainittakoon DNP 3.0. Fyysisten verkkojen topologia on yleensä tähti tai rengas. Aikaisemmista RS-232 ja RS-485 -tyyppisistä väyläratkaisuista ollaan mm. IEC 61850 standardin sekä teollisuuden Profmet- ja Modbus TCP-ratkaisujen myötä siirtymässä Ethernet-pohjaisiin verkkoihin.
Protokollien avulla siirrettäviä tietoja ovat tapahtumat, asettelut, mittaukset, häiriötallenteet, vikaraportit ja vikatiedot. Näiden lisäksi siirretään erilaisia ohjauskomentoja. Ohjauskomennot voidaan antaa paikallisesti suoraan laitteen ohjauspaneelista tai ohjauskeskuksesta, jolloin ne välitetään laitteelle kulloinkin käytettävän protokollan avulla. Turvallisuussyistä laite asetetaan käsin paikallis- tai etäkäyttötilaan, jolloin ei virheellisesti yritetä ohjata laitetta kahdesta eri lähteestä.
Ohjauksissa tyypillinen periaate on valinta ennen ohjausta. Tämä tarkoittaa, että ohjattava kohde ensin valitaan ja varataan. Tässä yhteydessä tarkistetaan, että suoritettava ohjauskomento on mahdollinen ja että oikea kohde on valittu. Varsinaisen ohjaus- komennon yhteydessä tarkistetaan lukuisia erilaisia ehtoja. Mikäli nämä ehdot eivät täyty niin varaus puretaan. Tarkistettavia ehtoja ovat ohjattavan kohteen lukitukset, synkronointi- ehdot, estotilat, operaattorin käyttöoikeudet sekä ohjattavan laitteen tila. [4, s. 113-114]
2.5 IEC 61850 standardi
IEC 61850 standardin päätavoite on yhtenäistää ja mallintaa eri valmistajien järjestelmät ja laitteet siten, että ne pystyvät käsittelemään ja siirtämään tietoa keskenään [4, s. 302-303].
Aikaisemmista standardeista ja käytännöistä poiketen IEC 61850 määrittelee tiedonsiirtoon käytettävän protokollan lisäksi suositukset järjestelmien ja systeemien hallintaan, datamallin määrittelyn, järjestelmien kuvauskielen, testauksen, mahdollisen toiminnal
lisuuden sekä palvelut. [4, s. 302-303]. Standardi ei kuitenkaan ota kantaa laitteiden konfiguraatioihin, koska se riippuu käytettävissä olevista laiteresursseista [8, s. 12]. IEC 61850 standardi jakaantuu kymmeneen eri osa-alueeseen ja neljääntoista dokumenttiin.
Standardin osat on esitetty liitteessä 3 olevassa taulukossa.
Standardissa on alun perin keskitytty sähkönjakeluverkon automaatiojärjestelmiin ja erityisesti suojaustoimintoihin. Standardi kuitenkin kehittyy jatkuvasti ja esimerkiksi datamalliin on lisätty laajennuksia, joiden avulla voidaan mallintaa esimerkiksi vesi- ja tuulivoimaloita sekä muita energiantuotantojärjestelmiä. [9, s. 24]
2.5.1 Datamalli
IEC 61850 standardin sisäistämisen kannalta keskeisessä osassa on siihen liittyvä datamallin ymmärtäminen. Datamallin keskeinen tarkoitus on säilyttää tiedon viitekehys ja esittää tieto rakenteisessa muodossa. IEC 61850 mallinnetussa järjestelmässä jokainen yksittäinen informaatio, esimerkiksi mitattava suure, on yksiselitteisesti tunnistettavissa ja sen yhteys todelliseen prosessiin on koko ajan tiedossa. Aikaisemmissa järjestelmissä tämä yhteys ei ole itsestään selvää vaan tyypillisesti se toteutetaan erilaisten ristiviittaus- taulukoiden avulla. Keskeisimpiä IEC 61850 mallinnuksen käsitteistä ovat loogiset solmut (Logical Node) }a yhteiset dataluokat (Common Data Classes). Kuvassa 2.6 on esitetty IEC 61850 datamalli yksinkertaistetun UML-luokkakaavion muodossa [10, s. 73].
XCBR Looginen laite
Palvelin
Data- attribuutti Looginen
solmu
IEC 61850-7-3:
yhteiset dataluokat IEC 61850-7-4:
loogisen solmun attribuutit IEC 61850-7-4:
loogiset solmut
Kuva 2.6 IEC 61850 datamalli luokkakaaviona.
Palvelin sisältää kaiken informaation ja toiminnallisuuden, joita voidaan käyttää tiedonsiirtoverkossa. Yhdessä fyysisessä laitteessa (IED) voi olla useita palvelimia.
Kuvassa 2.7 on esitetty palvelimen periaatteellinen malli. [10, s. 54]
Palvelin
Looginen laite
Tunnistetiedot, tila Looginen solmu
Tieto
Hakemisto
Ï
Kooste Raportointi ja
lokit Raportti
GOOSE/GSSE
Näytteistetyt arvot
GOOSE GSSE SV >
Aktivointi j> Asetteluryhmä
Assosiointi Aikasynkronointl Tiedostonsiirto
Kuva 2.7 IEC 61850 palvelimen mallinnus.
Looginen solmu liittyy tiettyyn fyysisen laitteen toimintoon, jonka yksi tai useampi looginen solmu tuottaa. Yhden toiminnon vaatimat loogiset solmut voivat sijaita yhdessä tai useammassa fyysisessä laitteessa, kuten kuvassa 2.8 on esitetty [11, s. 23]. Loogiseen solmuun kuuluu tietyt toiminnot ja data. Looginen solmu on pienin mahdollinen rakenne, joka voi siirtää dataa. Lyysiset laitteet voidaan yhdistää fyysisillä yhteyksillä ja loogiset
solmut loogisilla yhteyksillä. [11, s. 20-21]
r
—Toiminnot—Loogiset solmut
Synkronoitu katkaisijan
kytkentä
Distanssisuoja Ylivirtasuoja
Q)
SГО
IHMI X X X Aseman tietokone
CPOW X Synkronoitu katkaisija
POIS X
X
Yhdistetty distanssi- ja ylivirtasuoja
a>
</>
'<n
PTOC U-
XCBR X X X Ohjausyksikkö
J
Kuva 2.8 Esimerkki loogisten solmujen, toimintojen ja fyysisten laitteiden suhteesta.
Looginen solmu koostuu yhteisten dataluokkien tyyppimäärittelyjen mukaisista attribuuteista. Kuvassa 2.6 esitetyistä attribuuteista Loc on SPS-tyyppinen ja Pos on DPC- tyyppinen. Käytettävissä olevat yhteiset dataluokat on esitetty standardin osassa IEC 61850-7-3. Dataluokat koostuvat data-attribuuteista, joiden kuvaukset löytyvät standardin osasta IEC 61850-7-2 ja -7-3. Data-attribuutit ovat joko primitiivi- tai kooste-tyyppisiä, jotka on koostettu perustyypeistä [12, s. 20]. Kuvassa 2.9 on esitetty erään loogisen solmun
rakenne [10, s. 28]. Kuvasta on nähtävissä myös viitteisiin perustuva esitystapa.
XCBR1
Data-attribuutti Looginen solmu
Viite data-attribuuttiin Viite Dataan
Viite loogiseen solmuun Mode
- ctIVal - operTime - origin - ctINum - stVal
XCBR1 XCBRlPos XCBRlPos.ctlVal XCBRlPos.operTime XCBRlPos.origin XCBRlPos.ctINum XCBRlPos.stVal XCBRlPos.q XCBRlPos.t
Kuva 2.9 Loogisen solmun rakenne puu-rakenteena.
Jokainen fyysinen laite (IED) sisältää vähintään yhden loogisen laitteen, jolla on vähintään yksi looginen solmu, joka kuvaa laitteen ominaisuuksia. Käytettävissä olevat 92 loogista solmua on määritelty standardin osassa IEC 61850-7-4. Jokaisella loogisella solmulla on lyhennetty nimi, joka muodostuu sen suorittamasta toiminnosta ja toimintaryhmästä, esimerkiksi PTOC, Protection Time Over Current. Muita esimerkeissä esiintyviä loogisia solmuja ovat POIS, PTRC, XCBR, IHMIja CPOW.
Kuvassa 2.10 on esitetty esimerkki, kuinka loogisten solmujen jakaminen voidaan suorittaa [13, s. 99]. Vaihtoehdossa A suojarele sisältää kaikki tarvittavat loogiset solmut ja ohjaussignaalit on johdotettu suoraan katkaisijalle. Vaihtoehdossa В myös katkaisija sisältää IEC 61850 toteutuksen ja ohjauskomento välitetään laukaisuthan varmistavalta solmulta (PTRC) GSE viestinä katkaisijalle.
А. В.
Johdotettu laukaisu
PTOC
PTRC PTOC
XCBR PTRC
XCBR
Katkaisija Katkaisija
Kuva 2.10 Periaatekuva loogisten solmujen hajautuksesta.
2.5.2 Tiedonsiirto
IEC 61850 standardin tiedonsiirtomäärittely perustuu IEEE:n raporttiin UCA 2.0 järjestelmästä, jossa esitellään uusi tapa mallintaa ja siirtää tietoa sähköaseman paikallisautomaatiojärjestelmissä [14]. UCA 2.0 on käytetty muutamissa järjestelmissä koeluonteisesti. IEC 61850 standardissa ei yritetä määritellä kiinteästi varsinaista tiedonsiirrossa käytettävää tekniikkaa. Sen sijaan oleellinen osa on abstrakti tiedonsiirtopa!velurajapinta (ACSI), joka voidaan liittää ristiviittauksilla (SCSM) siihen tiedonsiirtotapaan, mikä kulloinkin on tehokkain [4, s. 306; 12]. Tällä hetkellä käyttöön on valittu MMS/TCP/IP/Ethemet ja fyysisenä yhteytenä voidaan käyttää joko optisia kuituja tai 10Base-T/l00Base-T kaapelointia [15, s. 24]. Kuvassa 2.11 on esitetty periaatteelliset tiedonsiirtorajapinnat [8, s. 19]. Ristiviittaukset MMS viesteihin on määritelty standardin osassa IEC 61850-8-1 [15], kts. kuva 2.12 [10, s. 22].
Sovellus
SCSM 1
SCSM 2
SCSM n Sovelluskerros 1
(OSI 7) Sovelluskerros 2
(OSI 7) Sovelluskerros n (OSI 7)
Kuva 2.11 IEC 61850 tiedonsiirtorajapinnat.
OSI Sovellus Esitystapa
Istunto Kuljetus
Verkko Siirtoyhteys
Fyysinen
Datamallit
IEC 61850-7-3, IEC 61850-7-4
Informaation vaihto (ACSI)
IEC 61850-7-2
en MMS (ISO 9506)
m
CO ASN.1
oCO Istunto
— TCP
IP Ethernet
Optinen kuitu, 10Base-T/100Base-T
V IEC 61850-8-1
J
Kuva 2.12 Periaatekuva IEC 61850-8-1 SCSM määrittelystä.
Tiedonsiirron kannalta IEC 61850 standardi sisältää useita eri protokollia. Näitä on määritelty mm. erityyppisten viestien reaaliaikavaatimusten ja käyttökohteiden vuoksi.
Erilaiset viestityypit ja protokollat on esitetty seuraavassa taulukossa [15, s. 19].
Taulukko 2.1 IEC 61850 viestityypit ja vastaavat protokollat.
Tyyppi: Protokolla:
1 Nopeat viestit GOOSE, GSSE (laitteiden välillä)
IA Laukaisuviesti GOOSE, GSSE (laitteiden välillä)
2 Keskinopeat viestit MM S
3 Hitaat viestit MM S
4 Käsittelemättömät näytteistetyt sarvot SV (laitteiden välillä)
5 Tiedostonsiirto MMS
6 Aikasynkronointi SNTP
2.5.3 SCL-kuvauskieli
IEC 61850 standardin osassa 6 on määritelty SCL-kuvauskieli, jolla voidaan kuvata sähkönjakeluverkon automaatiojärjestelmien ja laitteiden toiminnallisuus, asettelut sekä yhteydet [16, s. 8]. Tärkein tavoite on, että standardin mukaisilla määrittelyillä mahdollistetaan yhteensopivuus eri valmistajien järjestelmätyökalujen välillä. SCL- syntaksi perustuu XML-määrittelyn versioon 1.0 [16, s. 8].
IEC 61850 standardi määrittelee neljä erilaista SCL-kuvaustyyppiä, joiden avulla voidaan kuvata koko sähkönjakeluverkon automaatiojärjestelmän rakenne sekä laitteiden väliset yhteydet: SSD, SCD, ICD ja CID. Jokainen tiedosto koostuu viidestä eri osiosta: otsikko, asema, tiedonsiirto, IED ja datatyyppi-määrittelyt. Jokaisen laitevalmistajan tulee toimittaa vähintään ICD-tiedosto laitteessa tai laitteen mukana.
SND-tiedosto määrittelee aseman kytkennän eli asemakuvan yhteydet sekä sähköasema- automaatiojärjestelmän toiminnallisuuden loogisten solmujen ja laitteiden avulla. SSD luodaan järjestelmän määrittelyyn käytettävässä työkalussa ja sitä voidaan käyttää syötteenä järjestelmän konfigurointityökalulle. Järjestelmän konfigurointityökalu käyttää SSD- tiedoston lisäksi ICD- tiedostoa syötteenä ja näiden tuloksena syntyy SCD-tiedosto.
ICD-tiedosto kuvaa yksittäisen laitteen ominaisuudet ja voi sisältää asettelujen oletusarvoja. SCD on täydellinen kuvaus sähköaseman toiminnallisuudesta asetteluineen.
SCD-tiedoston perusteella laitekohtainen konfiguraatiotyökalu voi muodostaa SCD- tiedostosta C/D-tiedoston, jonka avulla voidaan asetella ja konfiguroida yksittäinen laite.
Standardi ei vaadi, että laitteen tulisi pystyä käsittelemään CID-tiedosto sellaisenaan vaan laitevalmistajat voivat käyttää tähän viimeiseen vaiheeseen sovellusta, joka muuttaa SCL- muotoisen konfiguraation laitteelle sopivaan muotoon.
Kuvassa 2.13 on esitetty SCL-kuvauskielen sovellukset sekä tyypillinen järjestelmän konfigurointiprosessi, kuten se on standardissa esitetty. Eri sovellusten välillä siirrättävien tiedostojen sisältö on standardoitu, joten eri vaiheissa voidaan käyttää toisistaan riippumattomien valmistajien ohjelmistoja.
Ethernet-IEC 61850
IED Toimittaja A
IED konfigurointityökalu A
Otsikko Asemamäärittelyt Tiedonsiirtomäärittelyt
IED määrittelyt Tyyppimäärittelyt
Järjestelmä konfigurointi Järjestelmän määrittely Toimittaja В Toimittaja C
Kuva 2.13 SCL-kielen ja erityyppisten konfigurointitiedostojen käyttö.
Standardi mahdollistaa valmistajakohtaisten laajennusten tekemisen SCL-muotoisiin tiedostoihin. Eri valmistajien käyttämien työkalujen tulee säilyttää SCL-tiedostoihin lisätyt valmistajakohtaiset osuudet. [16, s. 22]
3 WEB-TEKNOLOGIAT JA NIIDEN SOVELLUKSET 3.1 Web-teknologiat
Web-teknologioihin ja niiden sovelluksiin tutustuttaessa on helppo havaita, että erilaisia teknologioita on tarjolla vähintään kymmenittäin. Tässä luvussa näistä tarkastellaan työn kannalta mielenkiintoisimpia. Erilaisten teknologioiden tuntemus luo pohjan Web- sovellusten eri osa-alueiden toteutustapojen ja olemassa olevien ratkaisujen vertailulle.
Nopeasti kehittyvänä ja muuttuvana sovellusalueena tiettyjen teknologioiden elinkaaret saattavat olla hyvin lyhyitä. Eräs suurimmista haasteista on löytää pitkän elinkaaren omaaviin laitteisiin sopivat teknologiat, jotka mahdollistavat jatkuvasti kasvavien vaatimusten mukaiset toiminnot.
Voidaan sanoa, että kaiken Web-teknologioihin liittyvän tiedonsiirron perusta on TCP/IP- protokolla. Sen avulla mahdollistetaan luotettava tiedonsiirto laitteiden ja järjestelmien välillä ja mahdollistetaan datapakettien reitittäminen laajoissa verkoissa. Kuvassa 3.1 on esitetty erilaisten Web-teknologioiden suhde protokolla kerrosmalliin [17].
Sovellukset
Sähköposti (MIME), Web/
WWW (XML, HTML), Tiedostonsiirto
I
Sovelluskerros HTTP, SMTP, POP, IMAP, FTP
Kuljetuskerros TCP, UDP
Verkkokerros IP, ARP, ICMP
Kuva 3.1 Web- ja Internet-teknologioiden suhde protokollamalliin.
Web-sivut siirretään //TYP-protokollan avulla. HTTP ei ota kantaa sen avulla siirrettävään dataan, joten Web-sivu voi olla käytännössä minkä tyyppinen tiedosto tahansa.
Protokollatasolle ei ole rakennettu tilakoneita vaan tilojen käsittely suoritetaan sovellustasolla. Nykyisin käytettävä versio HTTP 1.1 sisältää aikaisempaan 1.0 versioon verrattuna monia tiedonsiirron tehokkuutta ja turvallisuutta lisääviä ominaisuuksia.
Siirtoyhteyden avaamisen jälkeen tiedonsiirto perustuu asiakassovelluksen lähettämiin pyyntöihin, joihin palvelin vastaa.
HTTP-protokolla tarjoaa erilaisia metodeja tiedonsiirtoon, kuten OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE ja CONNECT. W3C suositusten mukaan GET-ja HEAD- metodien käyttö ei saisi muuttaa palvelimen tilaa ja toisaalta POST-, PUT- ja DELETE- metodien yhteydessä tilanmuutokset ovat mahdollisia. Muihin paitsi POST-ja CONNECT- metodeihin pätee, että samanlaisten peräkkäisten pyyntöjen tulisi aiheuttaa sama tilanmuutos niiden määrästä riippumatta. HTTP-määrittelyssä on otettu huomioon välimuistien-ja välimuistipalvelimien käyttö sekä niiden ohjaus. [18]
HTML on Web-ympäristöihin suunniteltu julkaisukieli [19]. HTML on SGML-standardin sovellus [19]. Tämän työn kannalta oleellisempi on kuitenkin XHTML. Hieman yksinkertaistaen voidaan sanoa, että kirjoitettaessa HTML-dokumentti XML-sääntöjä noudattaen se on käytännössä XHTML-dokumentti. XHTML-muotoisen dokumentin etuna on, että sen käsittelyssä voidaan käyttää XML-tekniikoita ja työkaluja, joiden avulla rakenteisen dokumentin käsittely tehostuu [20].
Rakenteisten dokumenttien, kuten XHTML, tyylien määrittelyyn on kehitetty CSN-kieli.
CSS-määrittelyn viimeisin valmis versio on 2.1. Tyylimäärittelyjen avulla voidaan tehokkaasti erottaa dokumenttien esitystapa varsinaisesta sisällöstä [21]. CSS-tyylisääntö sisältää valintalausekkeen, jonka avulla varsinainen tyylimäärittely kohdistetaan tiettyyn dokumentin osaan [21]. Tyylisäännöt voidaan kirjoittaa samaan dokumenttiin muun sisällön kanssa, mutta ylläpidon helpottamiseksi ne yleensä sijoitetaan yhteen tai useampaan erilliseen tyylitiedostoon.
XML-dokumenttien käsittelyyn on määriteltyYSX-kieliperhe. XSL:n osat ovat [22]:
• XSLT, joka on tarkoitettu XML-dokumenttien muunnosten tekemiseen.
• XPath, jonka lausekkeilla voidaan osoittaa XML-dokumentin osia. XSLT käyttää XPath-määrittelyn mukaista osoitusta.
• XSL-FO, joka määrittelee esitystapojen semantiikan.
XSLT-muunnos voidaan suorittaa palvelimessa tai asiakassovelluksessa. Palvelimessa suoritettu muunnos ei useinkaan näy asiakassovellukselle erillisenä toimintona eikä se aseta asiakassovellukselle mitään erityisvaatimuksia. Toisaalta asiakassovelluksessa tehtävä muunnos vapauttaa palvelimen resursseja, koska tällöin siellä ei tarvita muunnokseen kykenevää ohjelmistoa. Yhdistämällä XML-, XSL- ja CSS-tekniikoita voidaan dokumentin data, rakenne ja esitystapa erottaa toisistaan. Yleisesti tunnetuista selaimista esimerkiksi Mozilla Firefox ja Microsoft Internet Explorer tukevat suoraan XSLT:n käyttöä.
Web-sivujen toiminnallisuutta laajennetaan erilaisten skripti-kielien avulla. Skripti-kieli on ohjelmointikieli, jonka avulla voidaan liittää olemassa olevan järjestelmän palveluita osaksi omaa sovellusta [23, s. 1]. Skriptikielellä kirjoitettuja ohjelmia ei käännetä ajettavaksi ohjelmaksi vaan ne suoritetaan tulkkaamalla. Skripti-kieliä voidaan käyttää tarpeesta riippuen sekä asiakas- että palvelinsovelluksessa. Asiakassovellusten yhteydessä suosituin on ECMAScript-kielen laajennus JavaScript. Muita vaihtoehtoja ovat esimerkiksi Microsoft VBScript. ECMAScript syntyi 1990-luvun lopussa, kun silloisten JavaScript ja JScript toteutusten pohjalta haluttiin luoda standardoitu ratkaisu [23]. Nykyisellään ECMAScript-standardi määrittelee kielen ytimen, mutta sen laajentaminen on sallittua, kuten esimerkiksi JavaScriptin tapauksessa on tehty. JavaScript-kielen etuina on, että se perustuu standardoituun ratkaisuun ja sen käyttö on erittäin laajaa. Palvelimen toiminnallisuuden toteuttamiseen on tarjolla lukuisia ohjelmointi- ja skriptikieliä.
Suosituimmat näistä ovat PHP, Java ja ASP [24 , s. 161].
Palvelinpohjaisessa toteutuksessa dynaaminen eli pyydetyn datan mukainen sisältö on perinteisesti tuotettu CG/-rajapinnan kautta. Tämä mahdollistaa käytännössä minkä tahansa palvelinympäristön suoritettavissa olevan ohjelman ja ohjelmointikielen käyttämisen sisällön tuottamiseen. CGI on luonteeltaan vain vakiintunut käytäntö eikä sitä ole standardoitu. HTTP-pyynnön parametrit välitetään CGI-ohjelmalle käyttöjärjestelmän ympäristö-muuttuj ien välityksellä.
SS7-tekniikalla voidaan Web-sivuun upottaa HTML-kommenttien avulla osia, jotka Web- palvelin tulkkaa ja korvaa dynaamisesti luodulla datalla. Sekä CGI- että SSI-tekniikoihin liittyy merkittäviä suorituskykyä ja tietoturvaa heikentäviä ominaisuuksia ja nykyisin yleiskäyttöisiin Web-palvelin ympäristöihin on tarjolla tehokkaampia ratkaisuja.
Dynaamisen sisällön muodostamiseen ja esittämiseen selaimessa on käytössä muutamia yleisesti tunnettuja tekniikoita. Perinteisin näistä on määrittää (X)HTML sivu automaattisesti virkistettäväksi sopivalla syklillä. Tämä ratkaisu ei ole erityisen joustava ja jokaisella virkistyskierroksella haetaan koko sivu uudelleen. Toisaalta sen toiminta on varmaa eikä siihen juurikaan liity riippuvuuksia erilaisiin selaintoteutuksiin. Hieman kehittyneempi tapa on käyttää näkyvän alueen ulkopuolelle sijoitettua /Frawe-elementtiä, mihin data haetaan ennen näkyvälle alueelle siirtämistä. IFrame-elementin sisältö voidaan virkistää näytettävästä osuudesta riippumatta. Tällä tekniikalla saadaan näkymän virkistäminen tehtyä joustavammin ja dataa voidaan käsitellä ennen esittämistä. Tällä tekniikalla saavutetaan hyvä yhteensopivuus eri selaimien välillä, vaikka siinä hyödynnetään IFrame-elementtiä alkuperäisestä tarkoituksesta poikkeavalla tavalla.
Ajax edustaa viimeisimpää laajalle levinnyttä teknologiaa dynaamisten asiakasovellusten toteutuksessa. Periaatteessa Ajax on laajennus edellä esitettyyn IFrame-elementin käyttöön, mutta haettava data sijoitetaan tyypillisesti omaan tähän tarkoitukseen suunniteltuun JavaScript-luokan ilmentymään. Ensimmäisiä tämän tekniikan laajamittaisia hyödyntäjiä oh Intemet-yhtiö Google [24 , s. 24]. Ajax-teknologian avulla päästään jo hyvin lähelle aitojen sovellusten käyttötuntumaa. Toistaiseksi Ajax-teknologiaan liittyy selainriippuvia
ratkaisuja, mutta esimerkiksi Google on omissa palveluissaan osoittanut, että nämä ongelmat ovat hallittavissa.
Ajax-teknologian perusta on JavaScript-luokka, jonka avulla voidaan hakea dataa palvelimelta asynkronisesti ilman sivun päivittämistä [25]. Ajax ei sinänsä ole uusi tekniikka vaan tapa yhdistää uudella tavalla JavaScript-objekteja sekä XML-muotoista dataa [25]. Siirrettävän datan ei kuitenkaan tarvitse olla XML-muotoista, mutta usein se helpottaa tiedon jatkokäsittelyä, koska siinä voidaan hyödyntää DOM-mallia [25]. Kuvassa 3.2 on esitetty perinteisen Web-sovelluksen (A) ja Ajax-sovelluksen (B) toimintaperiaat
teen eroavaisuus [24 , s. 18-19].
Qselain Palvelin Qj Selain Palvelin
■Istunnon aloitus istunnon aloitus-
istunto ■Sovelluksen latau: Istunto
Asiakas
sovellus (JavaScript)
Tiedonsiirto
Web-
Web-
Web-
I stun non lopetus Istunnon
lopetus
Lopetus -sivu
Lopetus -sivu
Kuva 3.2 Perinteisen Web-sovelluksen ja Ajax-pohjaisen sovelluksen ero.
Asynkronisuus Ajax-teknologian tapauksessa tarkoittaa tiedonsiirron riippumattomuutta käyttäjän tekemistä toiminnoista. Teknisesti Ajax-teknologiassa tiedonsiirto tapahtuu aina HTTP-protokollan mukaisesti pyyntöön perustuen. Siirtotapahtuma voidaan kuitenkin suorittaa jaksollisesti ajastimien avulla tai sitten se liitetään tiettyyn käyttäjän suorittamaan toimenpiteeseen, kuten lomakkeella olevan painikkeen painallukseen.
HTML- ja XML-dokumenttien käsittelyyn on kehitetty W3C toimesta DOM- ohjelmointirajapinta. Se määrittelee dokumenttien loogisen rakenteen ja tavat kuinka dokumentin eri osia osoitetaan ja muokataan [26]. DOM-mallin avulla pyritään dokumenttien käsittely standardisoimaan erilaisten ohjelmointi-ja skriptikielien kesken.
Kaksiulotteisen vektorigrafiikan esittämiseen on käytännössä kaksi mahdollisuutta: SVG ja VML. Molempien syntaksi pohjautuu XML-määrittelyyn. SVG on W3C-työryhmän kehittämä ja VML on käytännössä ohjelmistoyhtiö Microsoftin kehittämä. Tästä johtuen kyseisin yrityksen selaintuotteessa on sisäänrakennettu tuki VML-grafiikalle. SVG- grafiikkaa käytettäessä tulee selaimeen olla toistaiseksi asennettuna erillinen ilmaiseksi saatavissa oleva ohjelma, jolla grafiikan esittäminen onnistuu.
Web-palvelujen määrittelyyn W3C on kehittänyt WSDL-kielen. WSDL:n avulla voidaan yksiselitteisesti määritellä asiakas- ja palvelinsovellusten välillä siirrettävät sanomat.
WSDL:n avulla sanomat voidaan määritellä esimerkiksi SCGP-viesteinä tai tavallisina HTTP-pyyntöinä. WSDL ei rajoita viestien liittämistä tiettyyn protokollaan. WSDL:n tarkoitus on helpottaa erilaisten Web-pohjaisten järjestelmien liittämistä toisiinsa ja sen avulla järjestelmien tarjoamat palvelut on mahdollista kuvata täydellisesti, joten palvelun käyttäminen voidaan automatisoida. [27]
Web-palvelujen yhteydessä puhutaan SOA-arkkitehtuurista. Tyypillisesti tämä käsite viittaa järjestelmiin joissa käytetään SOAP-sanomiin pohjautuvaa tiedonsiirtoa, mutta se voidaan laajentaa kuvaamaan palvelujen toteutusta muutoinkin. Palveluksi voidaan määrittää toiminto, jossa pyyntöön saadaan rakenteinen dokumentti vastauksena. Oleellista on data ja sen rakenne. [24 , s. 170].
Muita mielenkiintoisia teknologioita ovat perinteisten HTML-lomakkeiden korvaajaksi suunniteltu XForms, joka tulee olemaan osa XHTML 2.0 -määrittelyä sekä semanttinen Web. XForms-teknologian tarkoitus on erottaa lomakkeen toiminnot esityksestä [28].
XForms tekniikka mahdollistaa suuren joukon toimintoja, joiden tekemiseksi toistaiseksi vaaditaan skripti-kielten käyttöä, esimerkkinä syötteen tarkistus ja rajoittaminen [28].
Toistaiseksi selaimissa ei ole sisäänrakennettua XForms tukea, mutta XHTML 2.0 määrittelyn myötä tilanne todennäköisesti muuttuu.
Semanttisen Webin pääajatus on saattaa verkossa levitettävä informaatio sellaiseen muotoon, että erilaiset sovellukset voivat jakaa sitä keskenään. Tämän perustana on Internetissä jaettavan informaation kuvaukseen määritelty kieli RDF, jonka avulla informaatio esitetään ja siirretään [29]. Toinen merkittävä teknologia on informaation prosessointiin liittyvät määrittelyt, jotka esitetään (WZ-kielellä [30]. RDF ja OWL ovat W3C suosituksia. Yksinkertainen esimerkki semanttisen Webin käytöstä voisi olla vaikkapa hakukone joka haettaessa sanalla ”moottoriajoneuvo” antaa tulokseksi moottoripyöriä, autoja, mopoja, jne. Näitä hakutuloksia ei yhdistä tietty sana vaan semantiikka eli merkitys.
3.2 Tietoturva
Suojareleistä puhuttaessa on luonnollista, että turvallisuusnäkökohdat otetaan huomioon erityisen tarkasti. Laitteen käyttöön liittyviä turvallisuusasioita on mahdollista tarkastella hyvin monista näkökulmista, kuten laitteiden elektroniikan toteutuksen kannalta. Tässä kappaleessa keskitytään Web-sovellusten kannalta oleellisiin alueisiin eli tietoturvaan ja tiedon yhtenäisyyden varmistamiseen. Varsinkin tietoturvan osalta joudutaan Web- sovelluksissa kohtaamaan sellaisia uhkatekijöitä, joihin ei ole tällä sovellusalueella totuttu.
Sähkönjakeluverkon automaatiojärjestelmissä ja niissä käytetyissä protokollissa on perinteisesti luotettu protokollien itsensä tuomaan suojaan [31, s. 1]. Fyysisenä yhteytenä on yleensä käytetty RS-232 tai R.S-485 tyypin sarjaliikenneyhteyksiä ja erilaisia protokollia on käytössä kymmeniä, ehkä jopa satoja. Informaatiota ei näissä yleensä siirretä merkkipohjaisesti, koska hitailla yhteyksillä se on tehotonta. Merkkipohjaisissakin protokollissa informaation yhdistäminen lähteeseen ilman kyseessä olevan laitteen tai järjestelmän tuntemusta on erittäin vaikeaa.
Viimeistään IEC 61850 standardin myötä suojareleet on mahdollista kytkeä yleisiin tietoverkkoihin. Tästä johtuen suojareleen Web-sovelluksen yhteydessä kannattaa tarkastella Web-sovellusten kannalta yleisesti tunnettuja tietoturvariskejä:
Käyttäjä tunnistetaan käyttäen Bos/c-todentamista, joka on esitetty RFC 1945 (HTTP 1.0) määrittelyssä. Tämä tapa ei ole turvallinen, koska käyttäjätunnus ja salasana siirtyvät verkossa salaamattomina ja ne voidaan helposti selvittää [32, s. 48].
Hyökkääjä voi yrittää kytkeytyä asiakas- ja palvelinsovellusten väliin ja muuttaa sanomia tai käyttää niiden sisältöä omia tarkoitusperiä vastaavasti [33]. On syytä huomata, että verkossa olevat välimuistipalvelimet voivat salaamattomina muodostaa tietoturvariskin, koska niiden sisältö voi olla hyökkäyksen tekijän käytettävissä [18].
Hyökkääjä voi yrittää arvata huonosti valitut salasanat erilaisten sanalistojen avulla [33].
Lyhyet salasanat voidaan yrittää murtaa käymällä läpi mahdolliset merkki] onokombinaatiot [33]. Vahvojen salasanojen luomiseen löytyy monia hyviä ohjeita. Perusperiaatteet ovat kuitenkin yleensä seuraavat: pituus vähintään 8 merkkiä siten, että merkkijono sisältää sekä isoja että pieniä kirjaimia, numeroita ja erikoismerkkejä, mutta ei kuitenkaan todellisia sanoja, nimiä tai päivämääriä.
Puskurien ylivuotoon perustuvissa hyökkäyksissä pyritään hyödyntämään palvelimen ohjelmointivirheitä. Hyökkääjä pyrkii esimerkiksi antamaan HTTP-pyynnössä sillä tavoin muotoillun osoitteen, että sen käsittelyn yhteydessä palvelin kirjoittaa varattujen muistialueiden yli [33]. Tämä aiheuttaa tyypillisesti palvelinohjelmiston sekä pahimmassa tapauksessa käyttöjärjestelmän muuttumisen epävakaaksi [33]. Palvelimen ei tulisi lähettää HTTP-viesteissä palvelinohjelmiston tarkkaa versiota, koska hyökkääjä voi tämän tiedon perusteella päätellä tehokkaimman hyökkäystavan [32]. Hyökkäys voidaan kohdistaa suoraan TCP/IP protokollapinoon esimerkiksi väärentämällä sanoman pituuksia.
Protokollapinon epävakaus saattaa estää laitteen toiminnan ja estää viestien lähettämisen muille laitteille.
Hyökkääjä voi yrittää päästä käsiksi tietoihin käyttämällä HTTP-pyynnön osoitteessa sopivia suhteellisia polkuja. Esimerkiksi Windows-ja Unix-ympäristöissä merkinnällä voidaan siirtyä tiedostojärjestelmän hakemistohierarkiassa ylöspäin. Palvelimen tulisi hylätä tällaisia polkumäärityksiä sisältävät pyynnöt [32]
Tässä vaiheessa voidaan kuitenkin jo todeta, että suojareleiden kytkemistä julkiseen verkkoon ei suositella. Tietoliikenneverkkojen, joihin suojareleet kytketään, tulee olla suljettuja verkkoja. Periaatteena voidaan pitää, että henkilöt joilla on mahdollisuus käyttää laitetta suoraan sen omasta käyttöliittymästä, voivat kytkeytyä tähän suljettuun verkkoon.
Järjestelmän rakenteen kannalta on joissakin tapauksissa välttämätöntä käyttää julkisia verkkopalveluja ja silloin yhteydet tulee muodostaa salattuina.
3.2.1 Salaaminen ja asiakassovelluksen todentaminen
Tässä kappaleessa tutustutaan hieman tarkemmin siirrettävän tiedon salaamiseen ja asiakassovelluksen todentamiseen. Sulautettujen järjestelmien tietoturvavaatimukset poikkeavat yleisesti käytössä olevista sovelluksista kuten maksujärjestelmistä siinä, että varsinaisen siirrettävän tiedon salaaminen ei ole niin keskeisessä asemassa [33].
Oleellisempaa on, että asiakassovellus eli käyttäjä, on todennettu luotettavasti ja voidaan olla varmoja tiedon yhtenäisyydestä [33].
Siirrettävän tiedon salaamisessa käytetyimmät vaihtoehdot ovat SSL ja IPSEC. Niissä käytetyt algoritmit vaativat usein niin paljon suoritustehoa ja muistikapasiteettia, että monissa sulautetuissa järjestelmissä niiden käyttäminen on mahdotonta. Digest- todentaminen ei ole varsinaisesti salaukseen käytettävä menetelmä, vaikka sen määrittely sisältää siihen liittyviä toimintoja, mutta sillä voidaan suorittaa luotettava asiakassovelluksen todentaminen. Rajoituksena on, että sitä voidaan käyttää vain HTTP- protokollan yhteydessä. Kuvassa 3.3 on esitetty tiivistetysti erilaisten salaus- ja todentamismenetelmien suhde siirtokerroksiin. [33]
IPSEC Kuljetus
Sovellus
Verkko
Siirtoyhteys PAR
CHAP
PPTP L2TP Basic/Digest
todentaminen
Kuva 3.3 Salaus- ja todentamismenetelmien suhde siirtokerroksiin.
Basic-todentamisessa käyttäjätunnus sekä salasana liikkuvat verkossa salaamattomina Base64-koodattuina, joten ne on helppo kaapata käyttämällä verkkoliikenteen seurantaan tarkoitettuja ohjelmia, kts. kuva 3.4 [33]. Digest-todentaminen on huomattavasti turvallisempi menetelmä, koska siinä todentamiseen liittyvä informaatio koodataan käyttäen MD5-algoritmia, kts. kuva 3.5 [33].
Palvelin Asiakassovellus
HTTP 401 unauthorized
WWW-authenticate:basic realm=”Basic zone”
HTTP GET
Authorization: basic <Base64>
HTTP 200 OK HTTP GET
Kuva 3.4 HTTP Basic-todentaminen.
Palvelin Asiakassovellus
HTTP GET
-Authorization: Digest username=””, realm=”Digest zone”, nonce-”', algorithm=MD5, uri=””, qop=”’’, response=””, nc=””, cnonce=”"
HTTP 401 unauthorized
WWW-authenticate:digest realm-’Digest zone”, nonce-”’, algorithm=MD5, domain-”', qop=”auth”
HTTP 200 OK
Authentication-lnfo:rspauth="”, qop="”, nc=”", cnonce=’
HTTP GET
Kuva 3.5 HTTP Digest-todentaminen.
3.3 Kirjallisuuskatsaus
Bangemann ja Wollschlaeger [34] esittelevät artikkelissaan automaatiojärjestelmiin tarkoitettua ylläpidon Web-portaalia. Tässä järjestelmässä ei Web-palvelimia ole varsinaisesti hajautettu ohjausjärjestelmän osiin vaan keskeisessä osassa on yleisillä tekniikoilla toteutettu palvelin, joka on yhteydessä varsinaisiin prosessilaitteisiin kenttäväylän välityksellä. Asiakassovellukset toimivat normaalissa toimistoverkko- ja koneympäristössä. Tämä ns. kolmikerrosrakenne on luonnollinen ratkaisumalli silloin, kun Web sovelluksia rakennetaan perinteisiin automaatiojärjestelmiin, joita ei ole mahdollista muutoin verkottaa.
IEEE:n artikkelissa [35] Geyer ym. käsittelevät edellä esitettyyn järjestelmään liittyen XML-pohjaista mallinnusmenetelmää. Tällä mallinnusmenetelmällä esitetään mm.
automaatiojärjestelmän rakenne siten, että siitä on mahdollista luoda puurakenteinen navigointikäyttöliittymä. XML-pohjaisen kuvauksen etuina artikkelissa esitetään mm.
mahdollisuudet muuttaa XML kuvaukset muihin muotoihin XSLT:n avulla.
