PLC toimilohko-ohjelmien mallintarkastus AS Automaatio- ja systeemitekniikan projektityöt, kevät 2009

Transkriptio

1 PLC toimilohko-ohjelmien mallintarkastus AS Automaatio- ja systeemitekniikan projektityöt, kevät 2009 Markus Hartikainen 4/12/2009

2 Sisältö 1. Johdanto 3 2. Mallintarkastuksen teoriaa Mitä on mallintarkastus Automata ja äärelliset tilakoneet Temporaalinen logiikka 7 3. Järjestelmän ominaisuuksien spesifiointi 9 4. PLC-ohjelmien mallintarkastus PLC:n rakenne ja toiminta PLC-ohjelmien mallintarkastukseen liittyvä tutkimus CASE: tuotantolinjan päätynostimen hissiohjelman verifiointi Tuotantolinjan ja sen eri osamoduulien kuvaus Verifiointi käyttäen NuSMV-mallintarkistinta NuSMV pähkinänkuoressa Päätynostimen mallintaminen NuSMV:llä Päätynostimen verifiointi NuSMV:llä Päätynostimen korjattu malli Verifiointi käyttäen UPPAAL-mallintarkistinta Lyhyesti UPPAAL:sta paletti_sisaan ohjelman ensimmäinen mallinnustapa paletti_sisaan ohjelman toinen mallinnustapa paletti_sisaan ohjelman kolmas mallinnustapa Tulokset ja mallintarkistimien vertailua Yleisiä havaintoja NuSMV vs. UPPAAL PLC-ohjelmien mallintarkastuksen tulevaisuus Projektiin käytetty aika Projektin alussa suunniteltu työn rakenne Toteutunut työn rakenne projektin lopussa Toteutunut aikataulu 57 Lähteet 58

3 1. Johdanto PLC eli Programmable Logic Controller on mikroprosessorilla varustettu sulautettu järjestelmä, jossa on tuloja ja lähtöjä (I/O) [2]. PLC:hen voidaan ohjelmoida toiminnallisuutta toimilohkoohjelmilla. Toimilohko-ohjelmilla tehdyt ohjelmat muistuttavat digitaalitekniikasta tuttua signaalien kulun esitystapaa, jossa ulostulojen arvot määräytyvät sisääntulosignaalien arvoista ja toimilohkon sisältävän logiikan toimintatavasta. Tässä työssä tutustutaan mallintarkastukseen ja sen teoriaan yhtenä formaalina verifiointimenetelmänä PLC-ohjelmien laadunvarmistusprosessissa. Tässä työssä verifioidaan osa kurssille AS Kappaletavaratuotannon automaatio tehdystä harjoitustyöstä. Harjoitustyönä AS :lle tehdään GWS:n tuotantolinjan päätynostimen ohjaus toimilohkopohjaisilla logiikkaohjelmilla [14]. Verifiointimallit tässä työssä rakennetaan NuSMV [15] ja UPPAAL [18] mallintarkastustyökaluilla. Yksi tapa verifioida logiikkaohjelmien oikeellisuutta on tehdä se manuaalisesti. Tekemällä ohjelmista totuustaulut, voidaan vertailla näiden totuustaulujen arvoja suunniteltuihin arvoihin. Mutta mitä tehdä, jos verifioitavassa ohjelmassa on 80 sisääntuloa? Tällöin ohjelman tilaavaruudeksi tulee 2 80 = tilaa. Jos pystyisimme testaamaan sekunnissa 10 7 totuustaulun riviä, olisi yhdessä vuodessa testattu riviä. Tällä vauhdilla testaus saataisiin valmiiksi 3.8 miljardin vuoden kuluttua. [24] Mallintarkistimella voidaan tyypillisesti tutkia tilan kokoinen tila-avaruus muutamasta sekunnista muutamaan minuuttiin tai tuntiin (riippuen mallintarkistimesta). Mallintarkastus on joukko menetelmiä ja algoritmeja toteutettuna tietokoneessa toimivaan mallintarkistin työkaluun, jonka avulla voidaan tutkia käyttäytyykö ohjelma sille asetettujen vaatimusten mukaisesti käymällä läpi ohjelmasta tehdyn mallin kaikki mahdolliset suorituspolut [24]. Luku 2 selventää mallintarkastuksen taustalla olevaa teoriaa pintapuolisesti. Luvussa 3 kerrotaan millä tavalla vaatimuksia voidaan kääntää mallintarkistimien ymmärtämään muotoon. Luvussa 4 kerrotaan PLC-järjestelmien rakenteesta sekä selvitetään jo tehtyä PLC-ohjelmien mallintarkistukseen liittyvää tutkimusta. Luvussa 5 selvitetään päätynostimen toiminta ja sen toiminnan tarkoitus osana tuotantolinjaa. Luvussa 5.2 tutkitaan NuSMV:n käyttömahdollisuuksia toimilohko-ohjelmien verifioinnissa. Luvussa 5.3 tutkitaan taas UPPAAL-työkalun mahdollisuuksia toimilohko-ohjelmien verifioimiseksi. Luvussa 6 esitetään työn tuloksia ja vertaillaan CASE-mallinnuksen perusteella NuSMV:tä ja UPPAAL:ia verifiointivälineenä. UPPAAL-työkalun graafinen käyttöliittymä ja automaattien piirtäminen ja simulointi graafisessa ympäristössä on käyttäjäystävällisempää ja usein helpommin ja nopeammin esitettävissä myös muille ihmisille kuin mallien rakentajille. Tämä työ pyrkii vastaamaan seuraaviin kysymyksiin: Mitä ongelmia mallintarkastuksessa voi ilmetä? Mitä kaikkea on otettava huomioon sovellettaessa mallintarkastusta verifioinnissa? Mitä hyviä ja huonoja puolia mallintarkastuksessa on? Minkälainen on mallintarkistuksen tulevaisuus PLC-ohjelmien verifioinnissa?

4 2. Mallintarkastuksen teoriaa 2.1 Mitä on mallintarkastus Mallintarkastus on järjestelmien verifiointiin tarkoitettu formaali menetelmä. Verifiointi tarkoittaa, että järjestelmän oikeellisuus testataan verifioitavien vaatimusten suhteen kattavasti. Mallintarkastus on siis testausta ja mallintarkistimeen (mallintarkastustyökalu) rakennetun mallin avulla voidaan testata vaatimuksia niin, että mallintarkistin käy läpi kaikki rakennetun mallin tilat. Mikäli malli ei toteuta verifioitavaa vaatimusta, mallintarkistin esittää tästä todisteena suorituspolun, joka johtaa ei-haluttuun tilaan. [22] Tässä työssä ei käydä läpi mallintarkistimien sisäisiä algoritmeja ja niiden toteutuksia. Tässä työssä tutustutaan mallintarkastukseen verifiointitekniikkana ja opetellaan käyttämään tähän työhön valittuja mallintarkistimia PLC toimilohko-ohjelmien verifioimiseen. Noudattaako mallimme tiettyä ehtoa φ? Miten tämä on määriteltävissä? Formaalisti kirjoitettuna malli M mallintaa ehtoa φ jos ja vain jos M = φ. Kuva 1. Mallintarkastuksen perusperiaate: formalisoitu vaatimus verifioidaan mallista. [22] Mallintarkastusprosessin kulku on seuraavanlainen [24]: 1. Rakennetaan verifioitavasta ohjelmasta malli. 2. Määritellään ne ominaisuudet, jotka halutaan mallista verifioida. 3. Käännetään määritellyt ominaisuudet temporaalilogiikan kaavoiksi. 4. Suoritetaan malli ja siitä verifioitavat ominaisuudet mallintarkistin-työkalussa. 5. Analysoidaan tulokset. 2.1 Automata ja äärelliset tilakoneet Automata on monikko sanasta automaton. Automaton on automaatti, jota tietojenkäsittelytieteessä usein käytetään. Se muistuttaa äärellistä tilakonetta (FSM). Automaton on siis tilakone, joka liikkuu tilasta toiseen tilasiirtymiä pitkin. UML:ää osaavat voivat huomata käsitteillä automaton ja UML:n

5 tilakone monia yhtäläisyyksiä. Automatonit kätkevät taustalleen paljon eksaktia ja tarkasti määriteltyä teoriaa mutta tässä dokumentissa on tarkoitus esittää teoriasta vain pintaraapaisu. Automaton muodostetaan seuraavalla tavalla [1, s.9]. Olkoon automaton A monikko A = {Q, E, T, qo, l}, jossa Q on äärellisten tilojen joukko E on äärellisten tilasiirtymien joukko on tilasiirtymien joukko q 0 on tilakoneen alkutila (voi olla useita) l kuvaa jokaiselle tilalle Q ne tilamuuttujat, jotka siinä tilassa ovat voimassa. Esimerkkinä automatonin muodostuksesta toimikoon kirjan Systems and Software Verification [1] yksinkertainen esimerkki. Kuvassa 1 on tulostimen automaton, jota voi käyttää kaksi käyttäjää kerrallaan. Kuva on piirretty käyttäen UPPAAL-työkalua [18]. UPPAAL:ista lisää sitä koskevassa luvussa. Kuvassa 1 W tarkoittaa odottamista (wait), P tulostamista (print) ja R prosessin lepäämistä (rest). Tilasiirtymien kohdalla olevat synkronoinnit kuten reqa? tarkoittavat, että tämä automaton saa kutsuja käyttäjiltä. reqa? tarkoittaa, että käyttäjä A haluaa käyttää tulostinta. Tilasiirtymissä myös päivitetään printer managerin tilamuuttujia Ra, Rb, Wa, Wb Pa ja Pb. Ra tarkoittaa, että käyttäjä A on levossa. Wa tarkoittaa, että käyttäjä A odottaa tulostimen vapautumista. Pa tarkoittaa, että tulostin tulostaa dokumenttia käyttäjälle A. Tilamuuttujat Rb, Wb ja Pb ovat kuten Ra, Wa ja Pa mutta ne kohdistuvat käyttäjään B. Käyttäjät A ja B täytyisi myös mallintaa erillisillä automatoneilla, jotta tätä printer manager automatonia voitaisiin simuloida ja verifioida UPPAAL:lla.

6 Kuva 2. Printer manager [1, s. 11] Kuvan 1 automaton on esitetty alla äärellisen automatonin tekstimuotoisella esitystavalla. A={Q, E, T, q 0, l}, jossa Q = {Rest, WaitA, WaitB, BothUsersWait, WaitAPrintB, PrintAWaitB, PrintA, PrintB} E = {req A, req B, beq A, beq B, end A, end B } q 0 = 0 T = { (Rest, req A, WaitA), (Rest, req B, WaitB), (WaitA, req B,BothUsersWait), (WaitA, beq A, PrintA), (WaitB, req A, BothUsersWait), (WaitB, beg B, PrintB), (BothUsersWait, beq A, PrintAWaitB), (BothUsersWait, beq B, WaitAPrintB), (WaitAPrintB, end B, WaitA), (PrintAWaitB, end A, WaitB), (PrintA, end A, Rest), (PrintA, req B, PrintAWaitB), (PrintB, end B, Rest), (PrintB, req A, WaitAPrintB) }

7 Automata eli automatonien verkko täytyy muuntaa mallintarkistimelle sen ymmärtämälle kielelle, jonka jälkeen mallin ominaisuuksia voidaan tutkia ja määritellä mallille vaatimuksia (specifications), joita mallista halutaan verifioida. Tulostimella voidaan ajatella olevan ainakin kaksi vaatimusta: 1. Kaikilla mahdollisilla suoritusketjuilla tilaa P A edeltää aina tila W A. 2. Kaikilla mahdollisilla suoritusketjuilla, tilaa W A seuraa tila P A jossakin vaiheessa. Mallintarkistin ilmoittaisi vaatimuksen yksi pitävän paikkansa ja esittäisi vaatimukselle kaksi suoritusketjun, missä se ei pidä paikkaansa. Pelkän verifioinnin lisäksi mallintarkastusalgoritmit tarjoavat siis apuja siitä, miksi jokin vaatimus ei pidä paikkaansa. Tällöin mallintarkistin esittää yhden suoritusketjun, joka todistaa että malli ei noudata verifioitavaa ominaisuutta. Useissa mallintarkastimissa kuten NuSMV ja UPPAAL, voi käyttäjä lisäksi valita minkälaisen suoritusketjun hän haluaa (esimerkiksi lyhimmän mahdollisen tai ensimmäisen verifioinnissa vastaantulevan). [1, s. 12] 2.2 Temporaalinen logiikka Temporaalisen logiikan avulla saadaan kuvattua englanninkieliset vaatimukset formaaleiksi logiikan lauseiksi, rajaten vaatimusten monitulkintaisuuden mahdollisuuksia pois. Ensimmäisen kertaluvun logiikkaa ei käytetä mallintarkastuksen yhteydessä, sillä lauseista tulisi pitkiä ja vaikeasti tulkittavia. [1, s. 28] Mallintarkastuksen tutkimus ja kehitys on jakaantunut moneen eri koulukuntaan mallintarkastuksessa käytettävän teorian pohjalta. Suurimmat suuntaukset ovat Computational Tree Logic ja Linear Temporal Logic (CTL ja LTL) sekä näiden johdannaiset. Logiikat eroavat toisistaan ja CTL:n avulla suoritus kuvataan puumuodossa, kun LTL kuvaa suorituksen polkuna. Kummallakin on omat hyvät ja huonot puolensa, joita tämän työn puitteissa en lähde analysoimaan sen tarkemmin. Esimerkiksi CTL:n avulla voidaan tehokkaammin verifioida onko suoritusketjussa kaikille mahdollisille poluille reitti, joka kulkeutuu takaisin alkutilaan. Järjestelmän suoritus koostuu sekvenssistä, joissa järjestelmä käy sen eri tiloissa. Tilamuuttujat voivat saada eri arvoja, joiden mukaan järjestelmän tilat muuttuvat (tieto ja toimenpiteet) toisiin. Siispä esimerkiksi väite P on totta tilassa q jos ja vain jos [1, s. 28] Boolean operaattoreiden ( (negaatio), ) lisäksi temporaalilogiikka koostuu itse temporaalioperaattoreista. Niiden avulla tilojen suoritussekvenssien tarkastelu on mahdollista pukea formaaliin muotoon. Tyypillisimpiä PLTL-logiikan (LTL with Past operators) operaattoreita on esitetty taulukossa 1. Taulukko 1.P LTL-logiikan temporaalioperaattoreita. Operaattori X ( next state ) F ( finally ) Selitys X(P) on totta nykyisellä ajanhetkellä, jos P on totta seuraavalla ajanhetkellä. F(P) on nyt totta nykyisellä ajanhetkellä, jos P tulee olemaan totta jollain ajanhetkellä tulevaisuudessa.

8 G ( globally ) U ( for until ) W ( weak until ) O( once ) Y( previous state ) G(P) on totta, jos P on totta kaikilla ajanhetkillä. hälytys U kuittaus kertoo, että hälytys-tila on päällä, kunnes se on kuitattu. φ 1 W φ 2 kertoo, että φ 1 on totta, kunnes φ 2 tapahtuu, jos tapahtuu. Eli φ 2 :sen tapahtumista ei ole vaadittu. O(P) on nyt totta, jos P on nyt totta tai on ollut jollain menneellä ajanhetkellä totta. Y(P) on nyt totta, jos P oli totta edellisellä ajanhetkellä. CTL:ään kuuluu muitakin temporaalioperaattoreita, jotta suoritusketjut saadaan kuvattua puumuotoisina. Tällöin monenlaiset tulevaisuuden tilat voivat olla mahdollisia. Operaattorit A ja E määrittelevät eri suoritusketjuja joukkona, jossa yksi joukon alkio on kokonainen suoritusketju. Taulukko 2. CTL temporaalilogiikan operaattoreita. Operaattori A ( all executions ) Selitys AP kertoo, että kaikki suoritukset poispäin nykyisestä tilasta johtavat P:hen. EP kertoo, että nykyisestä tilasta on suorituspolku P:hen. E ( there exists an execution ) A:n ja G:n ero on tärkeä havaita. A(φ) kertoo, että kaikki seuraavat yhden askeleen suoritukset johtavat aina φ:hin puussa, kun G(φ) tarkoittaa, että φ on totta kaikilla suoritusaskelilla yhdessä suoritusketjussa. [1, s. 31]

9 3. Järjestelmän ominaisuuksien spesifiointi Järjestelmän spesifiointi voidaan jakaa ominaisuuksiin esimerkiksi seuraavasti [1, s. 77]: Saavutettavuus (reachability property) kertoo onko spesifioitu tila/tilat saavutettavissa. Turvallisuus (safety property) kertoo, että tietyissä olosuhteissa jokin ei-toivottu tapahtuma ei ikinä tapahdu. Liveness kertoo, että tiettyjen olosuhteiden aikana vaadittu ominaisuus lopulta tapahtuu aina ja kaikissa mahdollisissa ohjelman suoritusketjuissa. Reiluuden vaatimus (fairness property) kertoo, että tiettyjen olosuhteiden vallitessa, jokin tapahtuma tapahtuu (tai ei tapahdu) äärettömän usein (infinitely often) ohjelman ajon aikana. Esimerkiksi skedulerissa voitaisiin vaatia, että prosessi saa suoritusaikaa lopulta aina, kun se sitä ensin pyytää. Jotta ominaisuuksia voitaisiin ylipäätään tarkastaa ohjelmasta formaalisti, on ohjelmistokehityksen vaatimusten laatiminen oltava systemaattista ja kurinalaista työtä. Vaatimukset käännetään formaaliin temporaalilogiikan muotoon englanninkielisistä järjestelmän vaatimuksista: In all cases a system shall stop immediately when emergency-stop button is pressed. Vaatimukset eivät saa olla epätäsmallisiä tai monitulkintaisia: System shall be safe to use. Edellinen lause ei kerro mitä turvallisuuteen sisältyy. Erilaisia turvallisuus-ehtoja voi olla lukemattomia. Näistä kaikki halutut ominaisuudet tulee kirjoittaa auki systeemin vaatimuksia suunniteltaessa. Mallintarkastuksen avulla voidaan tutkia mallin oikeellisuus järjestelmän vaatimuksia vasten. Jos vaatimukset eivät ole kunnollisia, ei mallintarkastuksesta ole mitään apua. Tällöin painopiste tulisi yrityksessä ensin laittaa vaatimusten systemaattiseen analysointiin ja kirjoittamiseen. Mallintarkistin ei siis konstruoi vaatimuksia itsestään, vaan tämä prosessi jää ihmiselle. Kone ei voi tietää, miten ihminen haluaa sen toimivan, ellei ihminen koneelle sitä ensin kerro. Järjestelmältä vaadittavia ominaisuuksia voidaan tarkastella laajuudeltaan tai tyypiltään erilaisissa konteksteissa [9, 10]. Aina (global) tarkoittaa, että ominaisuuden on oltava koko suorituspolun ajan totta. Ennen R:ää (before R) tarkoittaa, että ominaisuus kohdistuu R:ää pienempiin indekseihin suorituksessa. Q:n jälkeen (after Q) tarkoittaa, että ominaisuus kohdistuu Q:n jälkeisiin indekseihin tai Q:n kanssa yhtäsuureen indeksiin. Q:n ja R:n välissä tarkoittaa, että vaatimus sisältää sekvenssin kaikki indeksit Q:n ja R;n väliltä [Q..R[. Q:n jälkeen, kunnes R tapahtuu tarkoittaa, että vaatimus sisältää indeksit, jossa o Q on totta, kunnes R tapahtuu [Q..R[ tai o Q on totta aina, jos R ei koskaan tapahdu.

10 Kuva 3. LTL-ominaisuuksien eri ulottuvuudet [10]. Seuraavaksi esitetään tyypillisimpiä suunnittelumalleja formaaleille vaatimuksille, jotka on saatu spesifioinnin suunnittelumalleihin keskittyviltä verkkosivuilta [9]. Suunnittelumallien käyttö helpottaa omien formaalien vaatimusten luontia, sillä dokumentoituja suunnittelumalleja on jo sovellettu menestyksekkäästi jossain muussa samanlaisessa ongelmassa. Absence suunnittelumalli Absence suunnittelumalli spesifioi, että P on false eri ulottuvuuksissa. Taulukko 3. Absence suunnittelumalli. Global Before R After Q Between Q and R After Q until R G( P) (FR) ( PUR) G(Q (G( P))) G((Q R FR) ( PUR)) G((Q R) ( PU(R G( P))))

11 Existence suunnittelumalli Existence suunnittelumalli spesifioi, että P:stä tulee lopulta totta sen ulottuvuudessa. Taulukko 4. Existence suunnittelumalli. Global Before R After Q Between Q and R After Q until R FP RU((P R) (G R)) (G( Q)) (F(Q (FP))) G((Q R) ( RU((P R) (G( R))))) G((Q R) ( RU(P R))) Muita suunnittelumalleja ovat esimerkiksi Universality, Precedence, Response jne [9]. Ajoitetut- ja reaaliaikavaatimukset eivät ole esitettynä tässä luvussa. Näihin paneudutaan UPPAALmallintarkistinta koskevassa luvussa.

12 4. PLC-ohjelmien mallintarkastus 4.1 PLC:n rakenne ja toiminta PLC-ohjelmat muistuttavat digitaalielektroniikan piirikaavioita. Esimerkiksi tikapuulogiikka (Ladder Diagram) on kehitetty alun perin relelogiikoiden kuvaamiseen. Tikapuulogiikasta tehtiin ohjelmointikieli PLC:n kehityksen myötä. Tuloihin kytketään antureita, jotka ovat yhdistetty PLC:n IO:hon. PLC:n ohjelmamuistissa on ohjelma, jota PLC suorittaa. Ohjelma saa siihen kytkettyjen antureiden tiedot, joiden mukaan se ohjaa PLC:n ulostuloihin kytkettyjä toimilaitteita. [2] Anturit voivat olla joko digitaalisia tai analogisia. Digitaalisilla antureilla voidaan ohjata prosesseja on/off periaatteella. Sisääntulona saadaan tieto siitä, että (esimerkiksi pinnankorkeus on säiliön ylärajalla) prosessissa on jokin tila, joka on joko päällä tai pois päältä. Digitaalisia antureita ovat esimerkiksi rajakytkimet, painonapit, läheisyyskytkimet. Digitaalisia toimilaitteita ovat esimerkiksi solenoidiventtiilit, releet, moottorin startterit jne. Analogisilla antureilla voidaan saada tietoa prosessin tilasta jollakin toiminta-alueella. Analogisia antureita ovat esimerkiksi paine-, lämpötilaja nopeusanturit. Analogiset toimilaitteet voivat ohjata prosessia logiikassa toteutetun säädön avulla. Analogisia toimilaitteita voidaan siis ohjata muillakin arvoilla kuin pelkästään päälle tai pois. Tyypillisesti digitaaliset anturit määritellään PLC:n boolean-muuttujiksi ja analogiset integermuuttujiksi. Tyypillisesti PLC-sykli koostuu yksinkertaistettuna sisääntulojen lukemisesta, ohjelman suorituksesta (logiikka) ja ulostulojen talletuksesta (kuva 1). Tämän jälkeen odotetaan, kunnes seuraavan syklin alku tulee vastaan. Tyypillisesti sykliaika on PLC:stä ja ohjelman koosta riippuen noin millisekuntia. Kuitenkin niin, että saman ohjelman sykliaika on aina sama. Kuva 4. PLC:n yksinkertaistettu suoritusrakenne. [4] Itselleni helpoimmin tulkittava logiikoiden ohjelmointikieli on Function Block Diagram (FBD), joka muistuttaa digitaalitekniikasta tuttua signaalien esitystapaa. Sequential Function Chart (SFC)

13 sopii nimensä mukaisesti ohjaussekvenssien kuvaamiseen korkealla tasolla. SFC:hen kuuluvat sekvenssin askeleet ja askeleiden sisällä toteutettavat tapahtumat ovat edelleen ohjelmoitu käyttäen joitain muita alemman tason IEC-logiikkaohjelmointikieliä kuten FBD:tä, ST:tä jne. IEC standardin logiikkaohjelmointikielistä on saatavilla tietoa esimerkiksi lähteestä [5]. 4.2 PLC-ohjelmien mallintarkastukseen liittyvä tutkimus PLC-ohjelmien muuntamista mallintarkistimille sopivaan muotoon on tutkittu jo kauan. Lähteessä [4] on tutkittu Structured Text (ST) muotoisten PLC-ohjelmien muuntamista NuSMVmallintarkistimen kielelle. Tutkimuksessa on kehitetty algoritmi, jolla voidaan kääntää STmuotoisia PLC-ohjelmia NuSMV-malliksi. Mallin tila-avaruuden suuruutta on hallittu sillä, että vain ohjelman uloimmat inputit ja outputit ovat tilakoneen tilamuuttujia ja PLC-ohjelman sisäisten toimilohkojen logiikka on määritelty vain mallin moduulin sisäiseksi logiikaksi makroilla, joka ei täten kasvata tilojen määrää. Tutkimuksessa on käännetty kehitetyllä algoritmilla 175 voimalaitoksen PLC-ohjelmaa NuSMV-malliksi. Tutkimus väittää, että kombinatorinen tilaavaruuden räjähdys oli vältettävissä ja PLC-ohjelman kääntäminen NuSMV-malliksi ei kestänyt keskimäärin kuin 50 sekuntia per ohjelma [4]. Tutkimus rajasi kuitenkin hyvin tehokkaasti kaikki ongelmia tuottavat asiat, kuten viiveet, ajastimet ja integer-muuttujien käytön tutkimuksen ulkopuolelle. Integer-muuttujat edustavat prosessin analogisia mittauksia ja jos integer-muuttujan skaala on ohjelmassa esimerkiksi väliltä , niin yhden muuttujan tilojen määrä on huomattavasti suurempi kuin boolean-muuttujan. Tila-avaruuden räjähtäminen mallintarkastuksessa on usein ongelmana, kun prosessia halutaan mallintaa liian tarkasti. Tila-avaruuden pienentämiseen ja hallintaan on olemassa erilaisia tekniikoita, joita myös lähteessä [1] on selitetty. Tutkimuksessa [7] on käsitelty systemaattista tapaa prosessimallien luomiseksi PLC-ohjelmien mallintarkastuksessa. Prosessimallien avulla voidaan konstruoida PLC-ohjelman toiminnalta vaaditut formaalit turvallisuusvaatimukset (safety properties), eli miten ohjelma ei saa toimia. Tutkimuksessa prosessi jaettiin ensin pienempiin osaprosesseihin (moduuleihin), joiden toimintaa analysoitiin tarkemmin. Jokaisen osaprosessin toimilaitteen toiminnasta muodostettiin tilakone. Tämän jälkeen muodostettiin kokonaisien osaprosessien tilakoneet, joissa yksittäisten toimilaitteiden tilakoneet olivat yhdistetty niin, että tilasiirtymien ehtoina (guard) oli oikeanlainen ja haluttu toiminta. Kun nyt oli tiedossa prosessien sallitut tilasiirtymät, jotka johtavat prosessin oikeaan toimintaan, saatiin ei-toivotut tilasiirtymät pääteltyä näistä. Näistä ei-toivotuista tilasiirtymistä tehtiin PLC-ohjelmalle turvallisuusvaatimukset eli niitä ei saa koskaan tapahtua PLCohjelman suorituksen aikana. [7] Etelä-Koreassa ydinenergian alalle on tehty paljon tutkimusta prosessia ohjaavien ohjelmien vaatimusten analysoinnissa sekä ohjelmien testauksessa ja verifioinnissa. NuSCR-nimisellä ohjelmalla voidaan tehdä vaatimusmäärittely formaalisti ja analysoida sen yksitulkintaisuutta ja täydellisyyttä NuSRS-ohjelmalla. Formaaleista vaatimuksista voidaan sitten kääntää FBD-ohjelma automaattisesti. Todella mielenkiintoinen tutkimus, jossa NuSCR spesifiointikieli on kehitetty yhdessä ydinalan asiantuntijoiden kanssa. Valitettavasti tämän projektityön puitteissa en keskity aiheeseen enempää mutta lisää kannattaa lukea lähteistä [11,12,13].

14 5. CASE: tuotantolinjan päätynostimen hissiohjelman verifiointi Projektin kokeellisen osuuden tarkoituksena on rakentaa kokoonpanolinjan 1. päätynostimelle mallit NuSMV:llä ja UPPAAL:illa aikaisemmin kurssille AS tekemieni logiikkaohjelmien pohjalta. Mallien teon lisäksi tutkin alkuperäisen ohjelman toimintavaatimuksia kurssin AS harjoitustyöohjeesta ja konstruoin näistä tekstimuotoisista vaatimuksista formaaleja mallintarkastimelle syötettäviä vaatimuksia (temporaalilogiikan lauseita). Toivottuna tuloksena on saada tieto siitä, toimivatko mallinnetut osat ohjelmasta niiden vaatimusten mukaisesti. Huomattava eroavaisuus formaalissa verifioinnissa on, että sen avulla voidaan tarkastettavat vaatimukset testata kattavasti mallista (kaikkien ohjelman suoritusketjujen läpikäynti). Tavallisessa testauksessa, joka on usein manuaalisesti suoritettavaa testitapausten läpiajoa, ei yhtäkään vaatimusta voida useinkaan testata täysin kattavasti. 5.1 Tuotantolinjan ja sen eri osamoduulien kuvaus Automaation tietotekniikan laboratoriossa yhtenä opetus- ja tutkimusympäristönä on GWS:n valmistama joustava kokoonpanolinja, jollaisia on käytössä mm. elektroniikkateollisuudessa. Linjalla koottavat osat kulkevat työvaiheelta toiselle palettien kuljettamina. Järjestelmä havaitsee palettien sijainnin induktiivisten ja optisten antureiden avulla. Lisäksi paleteissa on saattomuisti (DC, Data Carrier), jonka avulla määrätään, mihin työvaiheeseen paletti seuraavaksi on menossa. Joustavan kokoonpanolinjan osien toiminta on selitetty taulukossa 5. Kuva 5. Tuotantolinjan päätynostin. Taulukko 5. Kokoonpanolinjan yksiköt [14]. Päätynostin 1 (PN1) Startmoduuli (ST) Työasema 1 (TA1) Työasema 2 (TA2) Päätynostin 2 (PN2) Päätynostin 1 nostaa paletit alakuljettimelta pääkuljettimelle yksi kerrallaan (kuva 3). Startmoduulissa ja työasemamoduuleissa on kolme rinnakkaista kuljetinta, joiden välillä paletteja siirretään risteysvaihteen avulla. Keskimmäisessä risteyksessä sijaitsee saattomuistin luku- ja kirjoituspää. Oikean- ja vasemmanpuolisilta risteyksiltä paletti siirretään keskimmäiselle risteykselle, jossa paletin saattomuistiin kirjoitetaan määrätty koodi.saattomuistiin kirjoitettu koodi luetaan ja paletti siirretään koodista riippuen joko oikean- tai vasemmanpuoliselle kuljettimelle tai paletti jatkaa keskimmäistä pääkuljetinta pitkin eteenpäin. Työasemamoduulissa on lisäksi send-nappi, jolla työasemalla oleva valmis paletti lähetetään seuraavaan työvaiheeseen, sekä pause-kytkin, jonka avulla työaseman elektroniikkatyöntekijä mahdollistaa itselleen kahvitauon. Identtinen työasema 1:sen kanssa. Linjan loppupäässä oleva päätynostin 2 laskee saapuvat paletit yksi kerrallaan linjaston alapuolella sijaitsevalle palautuskuljettimelle, josta paletit palautuvat linjan alkuun päätynostin 1:lle.

15 Kurssin AS harjoitustyöohjeesta poimittuja vaatimuksia edustavat taulukossa 6 vasemmalla puolella olevat lauseet. Kurssin AS puitteissa vaatimukset ovat sopivalla tasolla, jotta opiskelijat saavat itse miettiä mitä nuo vaatimukset voisivat tarkoittaa. Oikeissakin projekteissa asiakkaalta saadut vaatimukset ovat monesti aluksi alla olevan kaltaisia. Näistä vaatimuksista ohjelmasuunnittelijoiden täytyy yhdessä projektin eri sidosryhmien kanssa jalostaa tarkempia yksiselitteisiä ja tarkasti oikeat toiminnot sisältäviä toimintokuvauksia. Ilman niitä luotettavasti toimivan järjestelmän toteuttaminen on mahdotonta. Taulukossa 6 oikealla puolella on esitetty esimerkkejä millä tasolla vaatimusten täytyisi olla, jotta järjestelmän tekninen suunnittelu voitaisiin aloittaa. Taulukon vaatimukset eivät kuitenkaan ole täysin asiakasvaatimukset kattavia. Esimerkiksi valvomo-ohjauksilla on varmasti myös muita vaikutuksia kokoonpanolinjan turvallisuuteen. Taulukko 6. Vaatimusten tarkentaminen. Asiakasvaatimukset Hihnoja ja hissejä ei saa ohjata molempiin suuntiin yhtä aikaa. Päätynostin toimii yleisimmissä tilanteissa kokoonpanolinjan osana. Järjestelmä-/tekniset vaatimukset 1. Hissin ohjaus ei saa olla samoilla sisääntulojen arvoilla samaan aikaan ylös ja alas missään tilanteissa. 2. Hihnojen ohjaukset eivät saa olla samoilla sisääntulojen arvoilla samaan aikaan ulos ja sisään missään tilanteissa. 3. Hissin tulee kuljettaa kaikki sen luo tulleet paletit ylemmälle hihnalle keskimäärin 5 sekunnin kuluessa. Paletin kuljettaminen saa kestää enintään 10 sekuntia. 4. Hissi ei saa missään tilanteessa ottaa sisäänsä kuin yhden paletin kerrallaan. Päätynostin toimii automaattisesti kokoonpanolinjan osana kaikissa tilanteissa. Turvallisuus ja poikkeustilanteet on huomioitu järkevällä tavalla. Valvomo-ohjauksen käyttäminen ei saa aiheuttaa vaaratilanteita. 5. Hissin kuljetin sisään pysähtyy kaikissa tilanteissa, kun paletti on hississä tai hissi ei ole alhaalla. 6. Hissi ei saa kuljettaa ylemmälle hihnalle kuin yhden paletin kerrallaan, vaikka paletteja tulisi hihnalta sen luo monta peräkkäin. 7. Hissin tulee pysähtyä kaikissa tilanteissa heti sen jälkeen (< 1 sekunti), kun hätäseis-painiketta on painettu joko valvomosta tai kokoonpanolinjastosta. 8. Hissi saa liikkua vain, jos kuiluanturi ei ole aktivoitunut (hissikuilussa sinne kuulumatonta liikettä havaittu). 9. Hissiä ei saa voida manuaalisesti ohjata mihinkään suuntaan, mikäli kuiluanturi on päällä ja/tai paletin stoppari on alhaalla. Vaatimusten määrittelyn jälkeen seuraava vaihe olisi ryhtyä suunnittelemaan päätynostimelle automaatteja jne, joiden perusteella logiikkaohjelma sitten toteutettaisiin. Tässä tilanteessa hissiohjelma on jo kuitenkin valmis ja projektityössä tehdään reverse engineering tyylisesti valmiista ohjelmista hissiohjelman malleja, joista mallintarkistimella verifioidaan taulukossa 6 olevien vaatimusten mukaisia ominaisuuksia. Mallintarkastus on teollisuudessakin monesti ollut käytössä reverse engineering projekteissa, joissa valmiiksi toteutettuja järjestelmiä tahdotaan verifioida. Tämä prosessi voi olla hankala toteuttaa, jos toteutettu järjestelmä on alun alkaen toteutettu puutteellisia ohjelmistonkehitysprosesseja noudattaen (huono dokumentoinnin ja vaatimusten taso sekä ohjelman rajapintojen huono suunnittelu jne. vaikeuttavat ohjelman toiminnan hahmottamista ja

16 mallintamista). Parempi tapa olisi käyttää mallintarkistusta ja muita systemaattisia suunnittelumenetelmiä suunnittelun apuna jo projektin alusta lähtien. Tällöin tätä suunnittelun systemaattisuutta voitaisiin käyttää apuna verifioimaan suunnittelun oikeus ennen ohjelman varsinaista toteuttamista. 5.2 Verifiointi käyttäen NuSMV-mallintarkistinta NuSMV pähkinänkuoressa NuSMV [15] on avoimen lähdekoodin mallintarkistin. NuSMV:n saa asennettua ainakin Windowsille ja Linuxille [15]. NuSMV:ssä ei ole tällä hetkellä mitään virallista graafista mallien kehitysympäristöä. Mallit on näppärä tehdä esimerkiksi emacs-editorilla [16]. Emacs:iin on saatavilla SMV:n syntaksin korostaja (syntax highlighting) [17]. Vaikka NuSMV:n syntaksi hieman poikkeaa SMV:n syntaksista, on se avainsanoiltaan kuitenkin niin samanlaista, että mielestäni se on hyvin toimiva sellaisenaan myös NuSMV:lle. NuSMV:tä voidaan käyttää äärellisten tilakoneiden mallintamiseen. Tilakoneet voivat olla joko täysin synkronoituja tai täysin asynkronisia prosesseja tai jotain siltä väliltä. Syy NuSMV:n valintaan mallintarkistimeksi tässä projektissa on se, että se sopii hyvin digitaalisten piirien kuvaamiseen (FBD-ohjelmat muistuttavat digitaalisten piirien kuvauskieltä hyvin paljon) kuten SMV mutta se on kuitenkin tehokkaampi kuin vanhempi SMV [15]. Toinen syy on se, että itselläni ei ole niin paljon tietoa tässä vaiheessa mallintarkistimista, joten vaihtoehdoksi jäi uskoa kuulemani ja lukemani perustelut NuSMV:n sopivuudelle digitaalisten piirien verifioinnissa. Alla on model_template.smv ohjelma, jossa on kuvattu yksinkertaisen toimilohko-ohjelman malli ja yksi mallista verifioitava ominaisuus. Käytän tämän projektin puitteissa alla olevaa rakennetta myös päätynostimen mallien muodostamisessa. Moduulissa main on annettu VAR-lohkossa digitaalisen piirin input-muuttujat (tilamuuttujat) sekä luotu instanssi moduulista PLCOhjelma1 muuttujaan suorituslogiikka. Instanssille annetaan parametrina main-lohkossa määritellyt inputmuuttujat. Moduulien parametrien tyypit määritellään NuSMV:ssä implisiittisesti, joten siitä ei tarvitse huolehtia [15]. Assign-lohkossa on kuvattu tilamuuttujien input1 ja input2 alkutilat ja seuraavat tilat init- ja nextmääreillä. Esimerkkiohjelmassa input1:sen ja input2:sen seuraava tila voi epädeterministisesti olla joko 0 tai 1. Tämä joukon sijoitus NuSMV:ssä on kätevä generoitaessa kaikki mahdolliset inputien kombinaatiot. PlcOhjelma1:n moduulissa ei ole mitään erilaista paitsi DEFINE-lohko. Tässä lohkossa on kätevä antaa erilaiset vakiot ja pitkät sijoituslausekkeet. Ne toimivat kuten C:n makrot eli viitattaessa esimerkkiohjelman and_block:iin korvataan se DEFINE-lohkon lausekkeella input1 &!input2.

17 Kuva 6. NuSMV-ohjelma syntaksin rakenteen kuvaamiseksi.

18 5.2.2 Päätynostimen mallintaminen NuSMV:llä Logiikka koostuu neljästä FBD-ohjelmasta: paletti_sisaan, hissi_ylos, paletti_ulos ja hissi_alas. Seuraavista logiikkaohjelmista ja niiden mallista on jätetty pois muutamien toimilaitteiden ohjaus kuten hissille tulevan liukuhihnan ja ylemmällä tasolla olevan hissiltä lähtevän liukuhihnan ohjaukset. Nämä ovat toteutettu alkuperäisessä logiikkaohjelmassa niin, että niitä pidetään jatkuvasti päällä. Liukuhihnojen ohjaukset eivät ole sama asia, kuin hissin oma liukuhihna, jota voidaan ohjata joko sisään tai ulos. Hissin liukuhihnan ohjaukset ovat tässä työssä mallinnettu. Kuva 7. Pelkistetty FBD-ohjelma kurssin AS harjoitustyöstä. Seuraavilla sivuilla on ohjelmien (kuva 7) NuSMV-malli.

19 Kuva 8. NuSMV:n main-moduuli.

20 Päätynostimen main-moduulissa (kuva 8) on 9 boolean-tyyppistä input-muuttujaa (2 9 =512 tilaa) ja logiikkaohjelmia mallintavien moduulien instansseihin viittaavat muuttujat. Rakennetussa mallissa (kuvan 8 main-moduulin ASSIGN-kenttä) melkein kaikki inputit toimivat vapaasti toisistaan riippumattomasti eli epädeterministisesti, jolloin inputtien arvot voivat vaihdella satunnaisesti (0 tai 1). Kaikki inputit eivät oikeassa prosessissa kuitenkaan ole toisistaan täysin riippumattomia, vaan tietyt inputien arvot riippuvat toisista inputtien arvoista, ulostulojen arvoista ja prosessin tilasta. Kuvan 8 main-moduulissa on input hissi_ylhaalla riippuvainen inputista hissi_alhaalla. Näin mallintarkistin ei tutki tilanteita, joissa hissi olisi samanaikaisesti sekä ylhäällä, että alhaalla. Lisäksi paletti_ulos_hissista input voi olla tosi vain, jos paletti ei ole hississä. Myös hissin alas ajaminen valvomosta manuaalisesti on mallissa estetty, sillä on haluttu nähdä rikkooko jokin muukin logiikan toiminta sen hissille asetetun vaatimuksen, että hissiä ei pidä voida ohjata samanaikaisesti sekä ylös että alas. Kaikkihan on tietysti mahdollista eli kaikki anturit voivat hajota samaan aikaan johtuen jostakin sähköiskusta tms. Nämä ovat hyviä maailmanlopun skenaarioita turvatoimintojen suunnittelussa. On virhealtista tehdä minkäänlaisia oletuksia siitä, miten prosessin inputtien arvot voivat vaihdella ja rajoittaa niiden muutoksia oletuksiin perustuen. Logiikkaohjelman ulkoinen ympäristö (prosessi) on kuitenkin usein mallinnettava siksi, että saadaan rajoitettua inputtien erilaisten kombinaatioiden määrää tehokkaasti, jolloin mallintarkastus nopeutuu tai tulee ylipäänsä mahdolliseksi [23]. paletti_sisaan ohjelman ja TON-lohkon mallintaminen Paletti_sisaan (kuva 9) ohjelman mallissa VAR-kentässä on output-muuttujat stoppari_alas ja hissinkuljetin_sisaan. Tila-avaruuden kasvua saadaan hillittyä laittamalla inputtien ja outputtien välissä olevien lohkojen (AND OR jne.) logiikka DEFINE-kenttään, jolloin tilojen määrä ei kasva. DEFINE-kentässä NuSMV:ssä määritellään makroja, joiden arvo korvataan implisiittisesti siinä käytettyjen muuttujien arvoilla. Näin yhtä toimilohko-ohjelmaa mallintaa yksi moduuli NuSMV-kielellä. RS-kiikun ja TON-lohkon ulostuloilla on omat muuttujansa sen sijaan, että ne olisivat määritelty DEFINE-kentässä. RS-kiikkua ei pystytä määrittelemään makrolla, sillä case-lausetta ei voida kirjoittaa makroksi. TON-lohkolla on oma moduulinsa, koska moduulien instansseja ei pystytä määrittelemään makroilla. Muutoin kuvan 9 malli lienee selkeä ja helppotulkintainen. Ohjelman Delay-moduuli (kuvassa 10) [8] toimii niin, että paletin täytyy olla ollut stopparilla >= 1s, jotta t_on.output-muuttuja antaa ykkösen ulos. Vapaasti toisistaan riippumattomilla input-muuttujilla verifioinnin jälkeen voitaisiin rakentaa ohjelman mallille realistisempi ympäristö (environment), jossa järjestelmän inputit muuttuvat tiettyihin oletuksiin pohjautuen matkien oikeata prosessia. Esimerkiksi, jos stoppari on ollut ylhäällä koko ajan ja hississä ei ole ollut palettia, niin paletti_hississa-anturin tila ei voi muuttua. Joka tapauksessa, jos todellista ympäristöä vapaammin toimiva malli noudattaa sille syötettyjä verifiointiehtoja, niin todellinen ohjelmakin selviää sille asetetuista vaatimuksista.

21 Kuva 9. Paletti_sisaan ohjelman malli.

22 Kuva 10. TON-lohkon malli.

23 hissi_ylos ohjelman mallintaminen Hissi_ylos ohjelma on mallinnettu samalla periaatteella kuin paletti_sisaan ohjelmakin. Kuvasta 11 nähdään, että logiikka nostaa hissin ylös, kun paletti on sisällä. RS-kiikulla ohjataan hissin nostooutputia, kun hississä on paletti. Reset-dominantin kiikun ulostulo Q1 saa arvon 0, kun kuiluanturi aktivoituu, hissin valvomosta pysäytetään hissi napilla tai kun hissi on yläasennossa. Hissin yläasennon input-muuttujan jälkeen on laitettu TON-viivelohko auttamaan tilanteissa, joissa linjaston paineilmataso ei pysy tarpeeksi korkealla. Selvemmin sanottuna ohjataan hissiä ylöspäin vielä 0.5 sekuntia kauemmin kuin saadaan anturitieto siitä, että hissi on ylhäällä. Kuva 11. Hissi_ylos ohjelman toimilohko-ohjelma. Kuvassa 12 on hissi_ylos ohjelman malli, johon viitataan main-moduulista. Main-moduulissa luodaan moduulista hissi_ylos-niminen instanssi. HissiYlosController ottaa kuvassa 11 näkyvät logiikan inputit parametreinaan. HissiYlosController-moduulissa on viivelohkon instanssi t_on. Delay-moduuli on samanlainen, kun aikaisemmassa paletti_sisaan ohjelman mallissa. Viivelohkolle syötetään sisäänmenona hissi_ylhaalla muuttuja ja viiveen kesto (katso paletti_sisaan ohjelman malli).

24 Kuva 12. HissiYlosController-moduuli. paletti_ulos ohjelman mallintaminen Paletti_ulos ohjelmassa ohjataan hissin omaa liukuhihnaa paletin saattamiseksi ulos hissistä silloin, kun hissi on ylä-asennossaan. Hihna käynnistyy, kun paletti on hississä ja hissi on ylhäällä. Vastaavasti hihnan ohjaus hissistä ulospäin pysähtyy, kun paletti_ulos_hissista anturi antaa pulssin siitä, että paletti on saatu kokonaan pois hissistä.

25 Kuva 13. Paletti_ulos ohjelman malli. hissi_alas ohjelman mallintaminen Hissi ajetaan alas, kun hissi ajetaan alas joko valvomosta manuaalisesti tai kun paletti_ulos_hissista anturi aktivoituu. Hissi pysähtyy, kun kuilu-anturi indikoi hissiin kuulumatonta liikettä hississä tai kun hissi on alhaalla tai kun hissi pysäytetään manuaalisesti valvomosta.

26 Kuva 14. Hissi_alas ohjelman malli Päätynostimen verifiointi NuSMV:llä paletti_sisaan ohjelman verifiointiehdot Ensimmäinen verifiointiehto (kuva 15) tarkastaa stopparin logiikan toimintaa. Siinä tutkitaan kaikki suorituspolut, jotta voidaan varmistua siitä, että stoppari toimii niin kuin on ajateltu. Ehto tarkastaa, että stoppari on aina silloin alhaalla, kun sen laskeutumisehto toteutuu ja se on alhaalla kunnes paletti_ohi_stopparin anturi nostaa stopparin ylös. Until-määreen oikeanpuoleisessa lauseessa täytyy myös ottaa mukaan suoritusketju, jossa paletti_ohi_stopparin anturitietoa ei koskaan saada. Tällöin stoppari pysyy ikuisesti alhaalla. Jos tuota ehtoa ei ensimmäiseen verifiointiehtoon lisätä, evaluoituu tämä ehto mallintarkastuksessa falseksi, sillä sellainen suoritusketju on mallissa mahdollinen, jossa paletti_ohi_stopparin anturi ei koskaan muutu ykköseksi.

27 Toisessa verifiointiehdossa tutkitaan stopparin ylösnostamisen logiikkaa. Stopparin ylösnostaminen tutkitaan jo ehdossa 1 mutta selkeyden vuoksi stopparin noston logiikka tutkitaan erillisessä ehdossa. Kolmas verifiointiehto tutkii hissin liukuhihnan toimintaa. Mikäli hissi on alhaalla ja palettia ei ole hississä, niin hissinkuljetin_sisaan on päällä, kunnes hihnan pysäytysehto on annettu. Tämä verifiointiehto on kuten ensimmäinen verifiointiehto. Neljäs verifiointiehto on kuten toinen verifiointiehto. hihnan pysäyttäminen tutkitaan jo kolmannessa verifiointiehdossa mutta selkeyden vuoksi tämä on eroteltu omaan ehtoonsa. Kaikkien neljän ehdon mallintarkastus osoittaa, että malli noudattaa kaikkia näitä ehtoja. Kuva 15. Paletti_sisaan ohjelman mallin verifiointiehdot.

28 hissi_ylos ohjelman mallin verifiointiehdot Ensimmäinen verifiointiehto (kuva 16) tarkastaa, että aina kun mikään pysäytysehto ei ole voimassa (kuiluanturi päällä, hissi yläasennossa tai hissi pysäytetty valvomosta) ja paletti on hississä, niin hissi_ylos output muuttuu ykköseksi seuraavalla PLC-syklillä. Toinen verifiointiehto tarkastaa, että aina kun pysäytysehto on voimassa (kuiluanturi päällä, hissi yläasennossa tai hissi pysäytetty valvomosta) niin seuraavalla PLC-syklillä hissi_ylos output on nolla eli hissi ei liiku ylös. Kolmas verifiointiehto on kuten toinenkin mutta tässä on vain osoitettu, että verifiointiehdoissa voidaan käyttää myös mallille syötettäviä input-muuttujia. Tämähän on mallintarkastuksessa tarkoituskin, että ei tarvitse sekaantua logiikkaan, vaan verifioida, että mallin ulostulot käyttäytyvät tietyillä input-muuttujien arvoilla toivotulla tavalla. Hissi_ylhaalla input-muuttujan käyttö olisi kuitenkin hankalaa. Jotta hissi pysähtyy, on tämän muuttujan oltava mallissa tosi 50 syklin ajan. Tästä syystä kolmannessa verifiointiehdossa on käytetty viivelohkon ulostuloa. Neljäs verifiointiehto tarkastaa, että hissi liikkuu sen käynnistämisen jälkeen ylös niin kauan, kunnes pysäytysehto on annettu (kuiluanturi päällä, hissi yläasennossa tai hissi pysäytetty valvomosta). Huomattavaa neljännessä verifiointiehdossa on, että until-määreen oikeanpuoleisessa ehdossa on oltava mukana myös tapaus, jossa hissi_ylos output on tosi koko ajan. Tämä tulee kyseeseen, mikäli pysäytysehtoa ei koskaan saada logiikalle (or_gate säilyy nollana). Tämä on mahdollista esimerkiksi silloin, kun hissi_ylhaalla anturi on epäkunnossa. Kuvan 16 mallintarkastuksessa NuSMV:llä kaikki annetut ehdot evaluoituvat todeksi.

29 Kuva 16. Hissi_ylos ohjelman mallin verifiointiehdot. paletti_ulos ohjelman mallin verifiointiehdot Ensimmäinen verifiointiehto tarkastaa, että hihna ulos menee aina päälle yhden syklin päästä inputien havaitsemisesta eli silloin kun hissi on ylhäällä ja paletti on hississä. Toinen ehto tarkastaa, että hihna ulos vastaavasti pysähtyy seuraavan syklin päästä pysäytysehtojen havaitsemisesta. Kolmas ehto tarkastaa itsessään molemmat ehdot 1 ja 2 sekä myös sen, että hihna ulos säilyy päällä koko ajan silloin, kun sen pitääkin. Kaikkien kolmen ehdon mallintarkastus osoittaa, että malli noudattaa kaikkia näitä ehtoja.

30 Kuva 17. Paletti_ulos ohjelman mallin verifiointiehdot. hissi_alas ohjelman mallin verifiointiehdot Ensimmäinen verifiointiehto tarkastaa hissin alaspäin ohjauksen käynnistämisen. Toinen verifiointiehto tarkastaa, että hissin alaspäin ohjaus pysähtyy oikein. Kolmas verifiointiehto tarkastaa, että hissin ohjaus alas käynnistyy oikeilla inputeilla ja että hissin ohjaus alaspäin säilyy päällä, kunnes pysäytysehto on annettu. Kaikkien kolmen ehdon mallintarkastus osoittaa, että malli noudattaa kaikkia näitä ehtoja.

31 Kuva 18. Hissi_alas ohjelman mallin verifiointiehdot. Koko päätynostimen mallin yhteiset verifiointiehdot Ensimmäinen koko mallista verifioitava vaatimus on, että hissin ohjaukset eivät missään tilanteissa saa olla päällä samanaikaisesti sekä ylös että alas. Toinen verifioitava vaatimus on, että hissin hihnaa ei saa milloinkaan ohjata sekä sisään että ulos samanaikaisesti. Kolmas verifiointiehto kysyy mallilta, että pysähtyykö hissin hihnan ulospäin ohjaus aina, jos hissi ei ole ylhäällä. Neljäs verifiointiehto kysyy mallilta, että pysähtyykö hissin hihnan ohjaus sisään aina kun hissi ei ole alhaalla. Viides verifioitava vaatimus on, että hissi ei saa koskaan liikkua, kun kuilu-anturi on aktiivisena. Mallintarkastus osoittaa, että malli ei noudata ensimmäistä kolmea verifiointiehtoa (kuvat 20-22). Malli noudattaa kuitenkin ehtoja 4 ja 5.

32 Kuva 19. Koko mallin yhteiset verifiointiehdot. Kuvassa 21 näkyy suorituspolkua, joka todistaa että malli ei noudata 1. verifiointiehtoa. Alkutilassa (state 1.1) kaikki inputit ovat nollia (kuva 21). Seuraavassa tilassa (kuva 21) paletti_ulos_hissista aktivoituu. Tämä voi johtua vaikka siitä, että työntekijä nojaa anturiin. Paletti_ulos_hissista anturi käynnistää logiikkaohjelman mukaisesti hissin alasajon, jos hissi on ylhäällä. Tilassa 1.3 hissi onkin ylhäällä, jolloin hissi_alas output-muuttuja muuttuu ykköseksi. Tilassa 1.4 hissi on alhaalla ja paletti on hississä, jolloin hissi_ylos output-muuttuja aktivoituu. Tilassa 1.4 hissi_alas output on vielä aktiivisena eli tässä tilassa sekä hissi_alas että hissi_ylos ovat aktiivisina. Kuvassa 20 näkyy suorituspolkua, joka todistaa että malli ei noudata 2. verifiointiehtoa. Tämän aiheuttavat virheelliset anturitiedot eli sellaiset anturitiedot prosessista, joita ei normaalisti tapahdu. Jos halutaan kuitenkin suunnitella ja toteuttaa vikasietoinen järjestelmä täytyy tällaisia tilanteita myös huomioida. Kuvan 22 suorituspolku todistaa, että hissin hihnaa voidaan ohjata ulos myös silloin, kun hissi ei ole ylhäällä. Kun katsotaan paletti_ulos ohjelman logiikkakaaviota huomataan, että hihnan ohjaamista ulos ei lopeta mikään muu kuin se, että paletti_ulos_hissista anturi on aktivoitunut.

33 Kuva 20. Mallintarkastus: hihnaa ei saa ohjata samanaikaisesti sekä ulos että sisään. Kuva 21. Mallintarkastus: hissiä ei saa ohjata sekä ylös että alas samanaikaisesti.

34 Kuva 22. Mallintarkastus: hissin hihnaa ei saa ohjata kuin ylä- tai ala-asennoissa.

35 5.2.3 Päätynostimen korjattu malli Mallintarkastuksen perusteella korjaamme logiikkaohjelmat paletti_ulos ja hissi_alas sellaisiksi, jotta korjattu malli noudattaisi myös näitä edellisessä luvussa noudattamatta jääneitä verifiointiehtoja. Hissin hihnan ulos ohjaamisen pysäytysehtoihin on lisättävä OR-lohko, jonka avulla huomioidaan hihnan pysäyttämisestä myös silloin, kun hissi ei ole ylhäällä tai hissinkuljetin_sisaan on päällä. Hissin alaspäin ohjauksen käynnistysehtoihin on lisättävä ANDlohko, joka huomioi, että aina kun hissi lähtee alaspäin, niin paletti ei ole enää hississä. Aikaisemmin tutkittiin pelkästään paletti_ulos_hissista anturia. Vastaavasti hissin alaspäin ohjauksen pysäytysehtoihin (OR-lohkoon) lisätään kaksi inputtia paletti_hississa ja hissi_ylos. Nyt hissin alaspäin ohjaus pysähtyy myös niissä tilanteissa, kun hississä huomataan olevan paletti tai hissi_ylos ohjaus on aktiivisena. Kuvassa 23 näkyy päätynostimen korjattu logiikkakaavio, jossa muutetut osat näkyvät vihreällä värillä. Kuva 23. Päätynostimen korjattu logiikkakaavio.

36 Logiikkakaavion korjauksen jälkeen täytyy myös tehtyä mallia korjata. Malliin tehdyt muutokset näkyvät parhaiten vaikkapa vertaamalla tiedostoja keskenään diff-komennon avulla. Muutoksia täytyy tehdä myös verifiointiehtoihin. Verifiointiehtoihin tehdyt muutokset näkyvät tiedostossa paatynostin_korjattu.smv. Mallintarkastus antaa mallin korjauksen jälkeen kuvan 24 mukaisen tuloksen. Malli noudattaa nyt kaikkia verifiointiehtoja. Kuva 24. Mallintarkastus korjatun mallin jälkeen.

37 5.3 Verifiointi käyttäen UPPAAL-mallintarkistinta Lyhyesti UPPAAL:sta UPPAAL mallintarkistin on saatavilla ilmaiseksi ei-kaupalliseen käyttöön [18]. UPPAAL on suunniteltu reaaliaikajärjestelmien mallintamiseen ja verifiointiin ajoitettujen automata-verkkojen avulla. Sen ovat kehittäneet yhteistyössä Uppsalan ja Aalborgin yliopistot. UPPAAL:in virallisilla verkkosivuilla on runsaasti erilaista koulutusmateriaalia. Aloitin tutustumisen UPPAAL:iin dokumentilla UPPAAL2K: Small Tutorial [19]. Alla on listattu UPPAAL:in mallintamisen ja verifioinnin peruskäsitteitä, joihin kannattaa tutustua lähteen [19] avulla. UPPAAL:in käyttöliittymä jakaantuu kätevästi kolmeen eri välilehteen: Editor, Simulator ja Verifier. Editor-tilassa on tarkoitus luoda malleja (templates) kuten C++:ssa. Näistä malleista voidaan luoda haluttu määrä instansseja ja instansseista prosesseja. UPPAAL:in ajettava järjestelmä koostuu siis prosesseista. Template koostuu tilojen lisäksi template:n instantioinnissa sille annettavista parametreista ja template:n omista sisäisistä parametreista ja kelloista. UPPAAL:issa aikaa käsitellään jatkuvana. UPPAAL:in tiloilla ei siis ole suorituksen aikana jotain tiettyä aikaa, vaan aika on annettu aika-ikkunoina (esim välillä [0-10] tai [0-10)). Invariantit ovat tila-vahteja, jotka pakottavat suorituksen siirtymään seuraavaan tilaan, kun suoritus on pysynyt tilassa invariantin ehtoon asti. Urgent location on tila, jossa aika ei voi kulua mutta mallin muita normaaleja tiloja voidaan suorittaa myös tämän tilan aikana. Committed location on kuten urgent location mutta committedtilan aikana vain committed-tilasta lähtevä tilasiirtymä voidaan suorittaa. Siis committed-tilasta täytyy poistua saman tien. Kanavien avulla (channels) voidaan käynnistää eri automatoneissa olevia tilasiirtymiä, kuin missä kanavaan lähettävä automatonin tilasiirtymä on (synkronointi). Kanavien avulla voidaan synkronoida eri prosessien välistä suoritusta joko hand-shaking:in tai broadcast:in avulla. Handshaking tarkoittaa, että kanava lähettää kutsun, johon yksi toinen kanavaa kuunteleva prosessi vastaa ja aloittaa suorituksensa. Broadcasting-kanava tarkoittaa, että kanavaan lähetettyä viestiä voivat kuunnella kaikki kanavan kuuntelijoiksi rekisteröityneet prosessit (Observer suunnittelumalli). Tutkimuksessa [20] ajoitettuja automata-malleja generoitiin automaattisesti PLC toimilohkoohjelmista. Ensimmäinen UPPAAL-malli mallintaa paletti_sisaan ohjelmaa, jonka FBD on kuvassa 7. Malli on tehty tutkimusta [20] mukaillen mutta manuaalisesti. Tällä mallinnustavalla on kuitenkin rajoitteensa. Mikäli kaikista toimi-lohko-ohjelman lohkoista (AND, OR jne.) tehdään oma automaton, ei malli skaalaudu isompiin ohjelmiin eksponentiaalisen tila-avaruuden kasvun vuoksi. Tutkimuksessa [20] käytettiin mallintarkistuksen sijaan UPPAAL TRON:ia, joka on tarkoitettu reaaliaikajärjestelmien online-testaukseen [21].

38 Järkevämpi ja enemmän käytetty tapa toimilohko-ohjelmien mallintamiseen on tehdä yksi PLCohjelman syklin kuvaava automaton, ja tämän mahdolliset apu-automatonit (mahdollisimman vähän mutta sen verran, että malli on luettava). Aikaa sisältävistä lohkoista (viiveet, ajastimet jne.) kannattaa tehdä oma automaton (mallista tulee selkeämpi). Tällä tavalla mallit skaalautuvat paremmin isompien järjestelmien mallintamiseen, koska tiloja säästetään synkronointimuuttujien käytön vähenemisellä sekä itse tilojen vähenemisellä, sillä jokaiselle toimilohkolle ei tarvitse tehdä omia tiloja omaan automatoniin. Ohjelman lohkojen logiikka voidaan suorittaa pääsääntöisesti yhdessä tilasiirtymässä samalla kertaa paletti_sisaan ohjelman ensimmäinen mallinnustapa Editor-välilehden Project Declarations kentässä olen määritellyt mallin globaalit muuttujat ja kellot. Scan_time kello on PLC:n sykliaikaa mallintava kello. TON-viivelohkossa oleva timer_pt muuttuja on käytettävä kello. TON-lohko toimii niin, että kun sille syötetään sisään arvo 1, niin TON-lohko antaa ulostulon yksi vasta, kun sisäänmeno on ollut yksi TON-lohkolle määriteltävän PT-ajastimen ajan. Taulukossa int in[4] ovat ohjelman inputit. flags-taulukossa säilytetään toimilohkon ulostulojen arvoja PLC-syklin suorituksen aikana. Näitä tarvitaan, jotta suorituksessa seuraavaksi oleva toimilohko saa sisääntulona edellisen lohkon logiikan suorittaman ulostulon käyttöönsä. Taulukossa int out[2] ovat PLC-syklin lopussa päivitettävät ulostulojen arvot. Taulukossa bool BlockHandled[4] säilytetään tietoa siitä, mitkä ohjelman toimilohkot ovat PLCsyklin aikana jo suoritettu. Näin tätä tietoa voidaan käyttää tilasiirtymien vahteina (transition guards). Vahtien avulla seuraavan toimilohkon logiikka suoritetaan vasta, kun on ensin suoritettu edellisen lohkon logiikka. Indeksissä nolla on koko toimilohko-ohjelman suorituksen tila syklin aikana. Tämä asetetaan arvoon true viimeiseksi suoritettavassa toimilohkossa AND_Block2. Chan synchro[3]-kanavien avulla voidaan siirtää logiikan suoritus oikealle toimilohkolle oikeaan aikaan. Indeksissä nolla suoritus siirtyy ensimmäiselle kolmen inputin AND-lohkolle jne. Broadcast chan tonsynchro-kanava on määritelty broadcast-tyyppiseksi ja erilliseksi muiden lohkojen suorituksesta muutamien seikkojen tähden. Broadcast-tyyppisellä kanavalla ei tarvitse huolehtia automatonien lukkiutumista (deadlocks), sillä yhdenkään automatonin tilasiirtymän ei tarvitse vastata välttämättä tonsynchro-kanavaan lähetettyyn viestiin. Tällä TON-lohkon malli on saatu yksinkertaisemmaksi, sillä joka tilaan ei tarvitse nyt piirtää kaikkia mahdollisia tilasiirtymiä. Esimerkiksi jos ollaan tilassa timer_running ja tonsynchro-kanavaan lähetetään viesti. Mikäli vahtina käytetyn flags[0]-muuttujan arvo olisi true ja kanavana käytettäisiin tavallista kanavaa, seuraisi tästä prosessin lukkiutuminen, sillä tavalliseen kanavaan lähetettyyn viestiin on pakko vastata (eli UPPAAL:issa tilasiirtymä on pakko tehdä).