Automaatio 1: Hissi. Oppimistavoitteet. Teoria (projektointi)

Transkriptio

1 Automaatio 1: Hissi Kurssin läpipääsyn kannalta ei ole tarpeen suorittaa tätä harjoitusta loppuun toimivaan PLC toteutukseen asti. Dokumentin lopussa oleva pisteytys luvusta käy ilmi että huomattavan määrän irtopisteitä voi kerätä käymällä läpi vain osan projektin vaiheista. Toimivan PLC toteutuksen aikaansaaminen kuitenkin kruunaa Automaation suunnittelu ja projektointi moduulin, koska se edellyttää suunnitteludokumentaation aktiivista hyödyntämistä ja systemaattista etenemistä projektin vaiheesta toiseen. Oppimistavoitteet Projektinhallinta, syventyen koneautomaatio-alan käytäntöihin V-malli ja kyky liittää suunnitteludokumentaatio V-mallin vaiheisiin; testauksen vaiheistus Koneautomaation suunnitteludokumentaatio: käyttötapauskuvaus, riskianalyysi, järjestelmätoimintojen määrittely o Kyky lukea ja kirjoittaa koneautomaation suunnitteludokumentaatiota osana V-mallin mukaisesta projektia PLC-kehitys koneautomaation suunnitteludokumentaatiota vastaan ja V-mallin vaiheiden mukaisesti Teoria (projektointi) Projekti voidaan määritellä kertaluontoisena tehtävänä, jolla on tavoite, aikataulu, resurssit ja suunnitelma. Yksittäisellä teollisuussektorilla muodostuu kokemuksen kautta hyviä käytäntöjä projektin suunnitteluun, minkä ansiosta suunniteltu aikataulu toteutuu myös käytännössä. Suomalaisten teollisuusautomaatio-alan vientiyritysten kannalta haasteena ei ole että saadaanko projekti ennemmin tai myöhemmin toimimaan tämä ei riitä nykyisessä kilpailutilanteessa. Haasteena on että saadaanko projekti valmiiksi suunnitellussa aikataulussa. Mitä kireämmäksi aikataulut voidaan suunnitella, sitä kannattavampaa liiketoimintaa voidaan harjoittaa. Prosessiautomaatiossa ja koneautomaatiossa on joitain eroja projektin vaiheistamisen käytännöissä. Tällä kurssilla syvennytään koneautomaation käytäntöihin hissi harjoitustyön kautta. Noudatetaan V-mallia, joka on koneautomaation lisäksi erittäin laajassa käytössä esim. ydinvoima-automaatiossa, autoteollisuudessa, raideliikennesektorilla, puolustusteollisuudessa, ilmailuteollisuudessa, sulautetuissa järjestelmissä sekä yleisesti IT alalla. Tämän lisäksi V-malliin pohjautuu automaatio-alan kannalta tärkeimmät turvallisuusstandardit. Näin ollen kun näet kuvan V-mallista, sinun tulee olla tietoinen siitä että mallista on useita variaatioita. Sinun tulee ensiksi selvittää että onko kysymyksessä pelkästään ohjelmistonkehitystä tukeva malli vain onko kohteena ohjelmistoa sekä fyysistä laitteistoa sisältävä järjestelmä. Tämän jälkeen kannattaa miettiä että onko malli suunnattu jollekin tietylle teollisuussektorille. Kuva 1 esittää koneautomaatio-alan V-mallin. Vasen laskeva haara sisältää työvaiheet, joissa selvitetään mitä asiakas haluaa, miten nämä tarpeet voidaan kuvata teknisesti yksikäsitteisessä muodossa, ja mitä korkean ja

2 matalan tason suunnitteluratkaisuja aiotaan noudattaa. Vasta tämän jälkeen toteutetaan järjestelmä. V- mallin oikea, nouseva haara puolestaan sisältää laadunvarmistukseen liittyviä vaiheita. Yleisin laadunvarmistustekniikka on testaus. Jokaisen laadunvarmistusvaiheen suunnittelu edellyttää lähtötietoja. V-malli on järjestetty niin, että jokaisen oikean haaran vaiheen lähtötiedot tuotetaan samalla tasolla olevassa vasemman haaran vaiheessa. Esimerkiksi yksikkötestaussuunnitelmat voidaan laatia heti kun detaalisuunnittelu on tuottanut moduulien tarkat rajapintakuvaukset. Testisuunnitelmat voidaan siis laatia ennen ohjelmointityön aloittamista. Kuva 1:en mallissa kaksi ylintä kerrosta koskevat koko järjestelmää. Tämän jälkeen prosessi haarautuu erillisiin ohjelmisto-, elektroniikka- ja mekaniikka suunnittelu prosesseiksi. Näiden prosessien tuotoksen voidaan myöhemmin integroida toisiinsa, jos kaikki ovat noudattaneet samoja järjestelmätoimintojen määrittelyjä. Näistä määrittelyistä esim. PLC ohjelmoija näkee että mihin I/O moduulin paikkaan tietty anturi tullaan kytkemään, eikä hänen tarvitse tietää elektroniikkasuunnittelun tarkempia yksityiskohtia. Elektroniikka- ja mekaniikkasuunnittelu tapahtuvat niitä varten erityisesti suunnitelluilla CAD ohjelmistoilla, jotka ovat tämän kurssin ulkopuolella ja joita ei näytetä Kuva 1:ssä. Kuva 1:en kolme alinta kerrosta kuvaavat siis PLC-kehitysprosessia.

3 Kuva 1 Koneautomaatio-alan V-malli Jokainen V-mallin vaihe tuottaa artefakteja (artifact). Artefakti on arkeologien ja kulttuuritutkijoiden keksimä termi, joka kuvaa mitä tahansa ihmisen tekemää esinettä. Sittemmin termi on otettu laajaan käyttöön IT-alalla, jossa sillä kuvataan ohjelmistonkehitysprosessissa syntyviä konkreettisia tuotoksia, kuten kaavioita, tekstidokumentteja ja ohjelmakoodia. Esimerkkejä Kuva 1:en V-mallia noudattavan projektin tuottamista artefakteista ovat järjestelmätoimintojen määrittely, moduulitestisuunnitelmat, testiraportit sekä PLC koodit. Suurin osa artefakteista on dokumentaatiota, joita niitä tarvitaan projektin systemaattiseen läpivientiin sekä siihen, että kehittäjät, asiakkaat ja turvallisuudesta vastaavat viranomaiset voivat vakuuttua siitä, että valmiin tuotteen laatu ja turvallisuus täyttävät sille asetetut odotukset. V-malli ei ratkaise sellaisia ongelmia, että kuinka muutoksia tai korjauksia voidaan tehdä mahdollisimman nopeasti. Teollisuuden projekteissa muutostilanteissa ei yleensä iteroida kaikkia V-mallin vaiheita perusteellisesti uudestaan. Mutkia oikaistaan joko kokemukseen ja hiljaiseen tietoon perustuen tai systemaattisemmin ketteriä (agile) kehitysmenetelmiä käyttäen. Nämä asiat ovat tämän kurssin aihepiirin ulkopuolella ja niihin sisältyy vielä runsaasti tutkimuksellisia haasteita, etenkin kun kysymyksessä on turvallisuuskriittiset tuotteet, joiden kehitysvaiheet tulee dokumentoida perusteellisesti. Mutkia ei

4 kuitenkaan kannata alkaa oikomaan ennen kuin osaa noudattaa V-mallia oikeaoppisesti ja on hankkinut jonkun verran kokemusta teollisuuden projekteista. V-mallin soveltaminen hissi harjoitukseen Tässä käydään läpi kaikki koneautomaation V-mallin vaiheet ja niiden keskeisimmät artefaktit. Joidenkin vaiheiden osalta artefaktit löytyvät valmiina tässä dokumentissa ja joidenkin vaiheiden osalta ne pitää tuottaa itse. Jälkimmäinen tapaus edellyttää lähtötietojen hakemista valmiiksi annetuista artefakteista. Toivottavasti harjoituksen aikana käy ilmi, että V-mallin vasemman haaran työvaiheisiin käytetty aika vähentää ohjelmointi- ja testausvaiheessa käytettyä aikaa ja siellä kohdattuja ongelmia. Tämän takia käytä nyt pari minuuttia siihen että tutkit Easyveepin hissin toimintaa. Osaisitko heti lähteä ohjelmoimaan sovellusta joka käyttäytyy täsmälleen samalla tavalla? Jos vastaus on kyllä, kerropa opettajalle seuraavan kerran kun näette, että miten lähtisit etenemään. Vaatimusmäärittely Teoria: Käyttötapaus Käyttötapaus (use case) on IT-alalla yleisesti käytetty tapa kuvata järjestelmän ja sen käyttäjän välistä interaktiota. Näin ollen käyttötapausten laatiminen on hyvä tapa varmistua siitä, että tuote tulee täyttämään loppukäyttäjien ja asiakkaan tarpeet. Käyttötapaus ei pyri toimimaan insinööreille suunnattuna spesifikaationa, joten käyttötapauksista pitää johtaa järjestelmätoimintojen määrittelyt seuraavassa vaiheessa. Koneautomaatiossa käyttötapaus kuvaa koneen ja sen käyttäjän välistä interaktiota, joten se toimii myös hyvänä lähtötietona, kun koneen turvallisuuteen liittyvässä riskinarvioinnissa kartoitetaan tästä interaktiosta syntyviä riskejä. Riskinarviointi edellyttää laajempia lähtötietoja, kuin mitä IT-alan käyttötapauspohja määrittelee. Tämän takia suomalaisessa työkoneteollisuudessa on laajassa käytössä VTT:n KOTOTU (Koneiden Ohjausjärjestelmien TOiminnallinen TUrvallisuus) hankkeessa luoma käyttötapauskuvaus. Alla olevissa esimerkeissä on käytetty kursiivia niiden kenttien osalta, jotka on lisätty koneautomaation tarpeisiin. Näiden tietojen perusteella voidaan arvioida riskin suuruus. Käyttötapaus 1: Hissin kutsuminen kun käyttäjä seisoo hissin ulkopuolella Elinkaarivaiheet: Testaus, Käyttöönotto, Normaali operointi, Asetusten teko, Vianhaku, Puhdistus Toimijat: Hissin käyttäjä, Asentaja, Huoltomies Muut henkilöt vaara-alueella: Rappukäytävässä liikkuvat henkilöt Toimijan esiehdot: Ei edellytetä perehtyminen käyttöohjeisiin, ei koulutusvaatimusta Käyttötapauksen esiehdot: Hätä-seis on vapautettu. Käyttäjä seisoo rappukäytävässä kerroksessa X kutsunappien luona. Hissiä ei ole kutsuttu hissin nykyisen olinpaikan ja kerroksen X väliselle kerrokselle rappukäytävän tai hissin sisäisten kutsunappien avulla. Tapauksen kulku:

5 1. Käyttäjä seisoo kerroksella X ja painaa kutsunappia. Kutsunapit ovat sen mallisia, että ne jäävät painettu tilaan, kunnes automaatiojärjestelmä siirtää ne takaisin vapautettu tilaan. Painettu tilassa nappien kohdalla palaa valo. 2. Mikäli hissi on matkalla jonnekin (käyttötapaus 1 tai 2), odotetaan kunnes tapaus on suoritettu loppuun. Mikäli kerros X on hissin matkan varrella, käyttötapaus 1 tai 2 tulee pitämään huolen siitä, että hissi pysähtyy kerroksessa X. Muussa tapauksessa tämä kutsu pannaan jonoon. 3. Odotetaan, että tämä kutsu otetaan jonosta työn alle. Suljetaan ovat ja ajetaan ylös/alas riippuen siitä, että missä suunnassa kerros X on. 4. Jos tullaan matkan varrella olevan kerroksen kohdalle ja jos tämän kerroksen nappi on painettu joko rappukäytävässä tai hissin sisällä, pysähdytään, avataan ovi, sammutetaan tämän kerroksen kutsunapit, suljetaan ovi välittömästi ja jatketaan matkaa kunnes saavutaan kerroksen X kohdalle, jolloin pysäytetään hissi ja avataan ovi. 5. Heti kun ovet ovat kokonaan auki, asetetaan kerroksen X kutsunapit rappukäytävässä ja hissin sisällä vapautettuun tilaan, jolloin nappien painettu tilaa kuvaavat valot sammuvat. 6. Tämän jälkeen suljetaan ovet välittömästi (ovien sulkemisen ajoituksen osalta Easyveep esimerkkisovellus eroaa oikeasta hissistä.) 7. Mikäli tällä välin on kutsuttu hissi muualle, aletaan suorittamaan jonossa seuraavana olevaa kutsua (käyttötapaus 1 mikäli kutsu on tehty rappukäytävän napilla ja käyttötapaus 2 mikäli kutsu on tehty hissin sisäisellä napilla). Poikkeukset: Toiminta on estetty jos hississä on ylipainoa (tätä poikkeusta ei toteuteta Easyveep ympäristössä). Lopputulema: Hissi on kerroksessa X ovet kiinni. Kerroksen X kutsunapit rappukäytävässä ja hissin sisällä ovat vapautettu tilassa. Suoritustaajuus: Päivittäin (8h) tehdään noin 100 siirtoa (nostoa tai laskua) (Tarkempaa arvioita varten pitää tietää enemmän rakennuksen sisäisestä liikennemäärästä.) Käyttötapaus 2: Kerrokseen ajo kun käyttäjä seisoo hississä Harjoitustehtävä: kirjoita erilliseen Word dokumenttiin käyttötapauskuvaus, joka vastaa Easyveep esimerkkisovelluksen toimintaa. Kuvauksessa tulee olla samat kentät kuin käyttötapaus 1:ssä. Teoria: Turvallisuus ja riskinarviointi Prosessiautomaatio ja koneautomaatio eroavat merkittävästi toisistaan siinä, miten turvallisuusasiat on ratkaistu. Yksi lähestymistapa on jakaa automaatio käyttöautomaatioon ja siitä täysin erilliseen turvallisuuteen liittyvään järjestelmään (TLJ). TLJ monitoroi prosessia ja puuttuu peliin jos se havaitsee riskitilanteen. Tällöin käyttöautomaatio voidaan toteuttaa ilman turvallisuusvaatimuksia ja sertifiointia. Toinen lähestymistapa on toteuttaa käyttöautomaatio siten, että voidaan osoittaa sen täyttävän sovellusalueelle relevanttien turvallisuusstandardien mukaiset määräykset. Prosessiautomaatiossa yleensä on erillinen TLJ kun taas suomalaisissa työkonealan yrityksissä on miltei aina päädytty siihen ratkaisuun, että on kustannustehokkaampaa olla käyttämättä erillistä TLJ:tä. Ydinvoima-alalla puolestaan on käytössä useita eri automaatiojärjestelmiä, joilla on eritasoisia turvaluokituksia. Tällä kurssilla keskitytään koneautomaation käytäntöihin, koska nämä perusperiaatteet tulevat vastaan muillakin sovellusalueilla jos joku vaikka diplomityövaiheessa paneutuu turvallisuusaiheeseen. (Teollisuuden teettämät turvallisuusaiheiset diplomityöt ovat tässä koulutusohjelmassa melko yleisiä.) V-mallin mukainen kehitysprosessi on keskeisten

6 turvallisuusstandardien lähestymistapa turvallisuuteen. V-malli on laajasti käytössä myös eiturvallisuuskriittisissä sovelluksissa, mutta turvallisuusaspektit laajentavat sitä esimerkiksi riskinarvioinnilla. Turvallisuuskriittisten automaatiosovellusten osalta pitää voida osoittaa viranomaisille että riskit on vähennetty hyväksyttävällä tasolle. Toisin sanoen, on yleisesti ymmärretty, että kaupalliset järjestelmät ovat sen verran monimutkaisia että niistä ei voi saada täysin turvallisia. Näin ollen riskit pitää tunnistaa ja niiden suuruus arvioida, jotta voidaan tarvittaessa määritellä riskejä vähentävät turvatoiminnot ja sitten toteuttaa turvatoiminnot standardien edellyttämällä tavalla. Turvallisuuden yksityiskohdat eivät mahdu tämän kurssin aihepiiriin, joten turvallisuuteen annetaan johdanto siitä näkökulmasta, että miten se liittyy automaatiosovelluksen projektinhallintaan ja suunnitteluun, mikä on tämän kurssin ydinasiaa. Näin ollen keskitytään siihen miten suunnitteludokumentaatiosta tunnistetaan riskit ja arvioidaan niiden suuruus (riskinarviointi) ja määritellään tämän perusteella turvatoiminnot. Riskinarvioinnin lähtötietona on suunnitteludokumentaatio. V-mallin vasemmassa haarassa tuotetaan erilaisia suunnitteludokumentteja, joten niiden systemaattiseen arviointiin on olemassa erilaisia riskinarviointimenetelmiä. OHA (Operational Hazards Analysis) on menetelmä, jonka avulla etsitään koneen ja sen käyttäjän interaktiosta syntyviä riskejä. OHAn heikkous on siinä että se ei edellytä lähtötietojen olevan missään tietyssä muodossa, joten OHA ei tarjoa systemaattista menetelmää lähtötietojen läpikäymiseen. Tämän takia VTT on kehittänyt OHAsta variaation käyttötapausanalyysi, jonka lähtötietona ovat tämän dokumentin mukaiset käyttötapaukset. Käyttötapausanalyysia on sovellettu laajasti suomalaisessa työkoneteollisuudessa. Kuva 2 esittää käyttötapausanalyysin työnkulun. Otetaan esimerkiksi käyttötapaus 1 Hissin kutsuminen kun käyttäjä seisoo hissin ulkopuolella. Use case act viittaa tapauksen kulku otsikon alta löytyviin numeroituihin vaiheisiin. Nämä vaiheet käydään yksitellen läpi ja jokaiseen sovelletaan vuorotellen käyttötapausanalyysin avainsanoja (Kuva 2: UCSA guidewords). Insinöörin tehtävä on päättää, että tulkitaanko vaiheen ja avainsanan kombinaatio vaaraksi (hazard). Jos vastaus on kyllä, siirrytään Kuva 2 ehdosta (salmiakkikuvio) hazard identified haaraan ja muussa tapauksessa ohitetaan seuraavat vaiheet ja palataan nuolia pitkin takaisin. Näin ollen menetelmä edellyttää että jokaisen käyttötapauksen jokaiseen vaiheeseen yritetään soveltaa jokaista avainsanaa. Tässä esimerkissä huomataan seuraava vaara: Vaihe 3: Sitten kun tämä kutsu otetaan jonosta työn alle, ajetaan ylös/alas riippuen siitä että missä suunnassa kerros X on. Avainsana: Liian aikaisin (too early) Tulkinta: Hissi lähtee liikkeelle ennen kuin ovet ovat kiinni. HUOM: Käyttötapauskuvauksessa ei tässä tapauksessa ollut virhettä, koska ohjeistettiin sulkemaan ovet ennen liikkeelle lähtöä. Kuitenkin havaitaan, että mahdollinen tekninen virhe voi aiheuttaa vakavasti otettavan vaaratilanteen.

7 Kuva 2 Käyttötapausanalyysin työnkulku Kuva 2 edellyttää että kun vaara on löytynyt, luodaan seuraavat artefaktit: vaarakuvaus ja riskin suuruuden arviointi (risk estimation). Vaarakuvaus vaaralle Hissi lähtee liikkeelle ennen kuin ovet ovat kiinni Elinkaarivaiheet: Testaus, Käyttöönotto, Normaali operointi, Asetusten teko, Vianhaku, Puhdistus Vaara-alue: Hissin oven ympäristö rappukäytävässä ja hissi Vaarallinen tilanne: Hissi kutsutaan kun ovet eivät ole kiinni Vaarallinen tapahtuma: Hissi lähtee liikkeelle kun ovet eivät ole kiinni Vaara: Vaara-alueella oleva henkilö on hissin oviaukossa ja kaatuu tai jää puristuksiin.

8 Suositellut turvallisuus toimenpiteet [HUOM: TÄYTETÄÄN VASTA RISKIN SUURUUDEN ARVIOINNIN JÄLKEEN]: Tarvitaan elektronisella tasolla toteutettu. turvatoiminto, joka varmistaa että hissi ei lähde liikkeelle ellei ovet ole kiinni. Riskin suuruuden arviointi vaaralle Hissi lähtee liikkeelle ennen kuin ovet ovat kiinni HUOM: Katso dokumentti Risk estimation guide IEC 62061, joka kuvaa tämän koneturvallisuusstandardin mukaisen riskinarvioinnin. Huomaa että riskinarviointi tehdään pahimman realistisen skenaarion mukaan. Vakavuus/Severity: 4 (death, loss of vision or a hand) Altistumistaajuus/Frequency of exposure: 5 (less than 1 hour) Tapahtumistodennäköisyys/Occurrence probability: 4 (Probable) [Siksi, koska hissin käyttäjät voivat olla vanhuksia tai muita henkilöitä, joiden henkinen ja fyysinen suorituskyky on heikentynyt.] Välttämisstodennäköisyys/Avoidance probability: 3 (Possible) Risk index: CI=5+4+3=12 SIL=3 Standardin taulukon mukaan riskin suuruus edellyttää SIL (Safety Integrity Level 3) tason turvatoimintoa, mikä on korkein taso koneautomaatiossa. Näin ollen ei riitä että turvatoiminto toteutetaan ohjelmistolla. Tyypillinen ratkaisu olisi erillinen elektroninen (siis ei sisällä ohjelmistoa) turvapiiri, joka tunnistaa jokaisen oven osalta että onko se kiinni. Hissiä kutsuttaessa turvapiiri lukitsee ovet mikäli kaikki ovet ovat kiinni (saatat pystyä kuulumaan tähän liittyvän loksahduksen kun olet hississä). Turvapiiri on toteutettu elektronisesti niin että hissiä liikuttavat toimilaitteet eivät voi käynnistyä, ellei turvapiiri ole kiinni. HUOM: turvapiirin suunnittelu ja toteuttaminen on tämän kurssin ulkopuolelle menevää asiaa, joten turvallisuusprosessia ei käydä läpi tämän pidemmälle. Tästä eteenpäin se on turvallisuusammattilaisten erikoisosaamista. Tähän asti käydyt vaiheet puolestaan ovat myös järjestelmäsuunnittelijoille kuuluvaa osaamista. Tehtävä: riskinarviointi Etsi Kuva 2:en menetelmällä yksi uusi vaara joko käyttötapauksesta 1 tai 2 ja kirjoita sillä vaarakuvaus ja riskin suuruuden arviointi.

9 Järjestelmätoimintojen määrittely Teoria Automaatiojärjestelmää ja sen ohjelmistoa ei ole yleensä mielekästä suunnitella siten, että jokaista käyttötapausta varten on sitä toteuttava komponentti tai moduuli, koska näin saattaa tulla paljon turhaa päällekäisyyttä. Käyttötapauskuvaukset kuvaavat koneen ja käyttäjän välisen interaktion, joten ne ovat hyödyllisiä kun selvitetään loppukäyttäjän tarpeita ja kun kartoitetaan tästä interaktiosta syntyviä riskejä. Järjestelmätoiminnot puolestaan kuvaavat miten sisääntulot prosessoidaan ja miten ulostulot muodostetaan, joten ne ovat askel kohti teknistä toteutusta. Järjestelmätoiminnot ovat yhteinen määritelmä ja sopimus ohjelmisto, elektroniikka ja mekaniikkainsinöörien välillä. Niiden määrittelyn jälkeen näiden aspektien kehittäminen jatkuu omassa haarassa. Järjestelmätoiminnot Kun analysoidaan molempia käyttötapauksia, havaitaan seuraavat 2 toimintoa: 1. Ajetaan nykyisestä paikasta kerrokseen X ja tarvittaessa pysähdytään matkan varrella. Tämän toiminnon ei tarvitse tietää että onko komento kerrokseen X saatu rappukäytävän vai hissin sisäisillä kutsunapeilla. 2. Monitoroidaan hissin ja rappukäytävän kutsunappeja, tarvittaessa laitetaan kutsuja jonoon ja puretaan jonon vanhin kutsu kun toiminto 1 on tullut valmiiksi. Kuva 3 I/O listaus Kuva 3 mukainen I/O listaus on yhteinen sopimus elektroniikka- ja ohjelmistoinsinöörin välillä. Elektroniikkainsinoori kytkee anturit ja toimilaitteet kyseisiin paikkoihin PLC:n I/O moduuliin (suoritettu kurssihenkilökunnan toimesta) ja ohjelmistoinsinööri liittää nämä paikat oikeisiin muuttujiin. Tämä listaus

10 pätee kaikkiin järjestelmätoimintoihin, minkä lisäksi toiminnot määrittelevät mitä signaaleja toiminto käyttää ja mitkä niiden tietotyypit ja merkitykset ovat. Järjestelmätoiminto 1: Ajetaan kerrokseen X Taulukko 1 Toiminnon käyttämät signaalit. Variable tarkoittaa ohjelmiston sisäistä signaalia (joka voi olla esim globaali muuttuja, ohjelman tai toimilohkon muuttuja - tällaisia detaaleja ei määritellä järjestelmätoiminnoissa.) Nimi Input/Output/ Tietotyyppi Merkitys Variable Elevator on 0. floor Input BOOL Kts Easyveepin dokumentaatio näistä Elevator on 1. floor Input BOOL signaaleista Elevator on 2. floor Input BOOL Door closed 0. floor Input BOOL Door closed 1. floor Input BOOL Door closed 2. floor Input BOOL Call button on 1. floor Input BOOL Button for 1. floor Input BOOL Start motor up Output BOOL Start motor down Output BOOL Open door floor 0 Output BOOL Open door floor 1 Output BOOL Open door floor 2 Output BOOL X Variable INT Kerros, jonne kuuluu ajaa Go Variable BOOL TRUE tarkoittaa että voidaan aloittaa ajo kerrokseen X Kuvaus: Toiminto käynnistyy kun Go saa arvon TRUE. Ajetaan nykyisestä paikasta kerrokseen X. Mikäli jo ollaan kerroksessa X, ei tehdä muuta kuin avataan ja suljetaan ovet. Muussa tapauksessa ainoa mahdollinen matkan varrella oleva kerros on kerros 1, joten jos X ei ole 1 ja jos Elevator on 1. floor ja jos jompikumpi 1. kerroksen kutsunapeista on tosi, menetellään seuraavasti: Tarkistetaan että onko kerroksen 1 kutsunappi hississä tai rappukäytävässä painettuna. Jos on, pysäytetään hissi, avataan ovet, sammutetaan 1. kerroksen kutsunapit ja suljetaan ovet. Easyveep simulaattori sulkee ovet heti kun ne ovat auenneet kokonaan, mutta teidän toteutuksessa saa olla viivettä ennen kuin sulkeminen aloitetaan. Tämän jälkeen jatketaan matkaa kerrokseen X, eli kunnes Elevator on X. floor on TRUE. Pysäytetään hissi, avataan ovet, sammutetaan X. kerroksen kutsunapit ja suljetaan ovet. Lopuksi toiminto muuttaa Go arvon FALSEksi. HUOM: Easyveep ympäristössä kutsunappien sammuttaminen tapahtuu simulaattorin toimesta automaattisesti kun kyseisen kerroksen ovet ovat kokonaan auki, joten teidän ei tarvitse sammutella niitä (eikä sitä varten ole edes tarjolla sopivia outputteja). Turvallinen tila: Hissi on pysäytetty, eli start motor up&down ovat FALSE. Käynnistävä tapahtuma: Toinen järjestelmätoiminto muuttaa signaalin Go arvoksi TRUE.

11 Koneen tilat, joissa sallittu: Hätäseis vapautettu [Hätäseis ei sisälly Easyveep ympäristöön, koska sitä ei toteuteta PLC:llä. PLC tai mikä tahansa ohjelmistototeutus olisi tarpeeton ja toisi vaan lisää komponentteja, jotka voi mennä rikki.] Järjestelmätoiminto 2: Kutsujen monitorointi Toiminto on aktiivinen vain jos toiminto 1 ei ole aktiivinen. Monitoroidaan hissin ja rappukäytävän kutsunappeja ja kun kutsu on havaittu käynnistetään toiminto 1 oikeilla X ja Go arvoilla. Tehtävä: kirjoita tämä toiminto samalla tarkkuudella kuin toiminto 1 yllä. HUOM: RIITTÄÄ ETTÄ HISSI TOTEUTTAA KAIKKI KUTSUT JOSSAIN JÄRJESTYKSESSÄ. ESIM JOS HISSI ON MENOSSA KERROKSESTA 0 KERROKSEEN 1 JA SAMAAN AIKAAN HISSI KUTSUTAAN KERROKSIIN 0 JA 2, EI OLE VÄLIÄ ETTÄ JATKAAKO SE KERROKSESTA 1 ENSIN KERROKSEEN 0 VAI 2. NÄILTÄ OSIN TOTEUTUS SAA EROTA EASYVEEP ESIMERKKITOTEUTUKSESTA. KUITENKIN HISSIN PITÄÄ PYSÄHTYÄ MATKAN VARRELLA OLEVIIN KERROKSIIN, JOS SE ON NIIHIN KUTSUTTU, MUTTA TÄMÄ ON JO HOIDETTU TOIMINTO 1:EN MÄÄRITTELYISSÄ. Arkkitehtuurisuunnittelu Arkkitehtuuri tässä tarkoittaa siis ohjelmistoarkkitehtuuria: tästä alaspäin V-malli koskee vain ohjelmistoa. Tässä ratkaistaan arkkitehtuurin suunnitteluperiaatteet. Oman toimilohkotyypin määrittely on perusteltua jos samaa koodia instantioidaan useammassa kohdassa. Tässä tapauksessa tällaista tarvetta ei ole näköpiirissä. Järjestelmätoiminnot 1 ja 2 voidaan joko toteuttaa samaan ohjelmaan tai erillisiin ohjelmiin. Erityiseksi tavoitteeksi annetaan testattavuus, siten että kumpikin toiminto voidaan yksikkötestata. Tämä tarkoittaa sitä että kummallekin toiminnolle löytyy oma moduuli, joka toteuttaa toiminnon kokonaisuudessaan eikä sisällä muuta toiminnallisuutta ja että tällä moduulilla on hyvin määritelty rajapinta. Näin ollen kumpikin toiminto toteutetaan omassa ohjelmassaan. Toiminnon 1 osalta rajapinta on kuvattu Taulukko 1:ssä. Kaikki nämä signaalit pitää määritellä globaaleiksi muuttujiksi, jotta ne näkyvät molemmissa ohjelmissa. Sen sijaan että muuttujat määriteltäisiin ohjelman VAR määrittely osassa, luodaan Global Variable List (klikkaa CoDeSysissä oikealla Application/Add Object/Global Variable List). Vinkki: jos listan nimi on esim gvl, niin jos ST koodissa kirjoitat gvl. niin työkalu näyttää valikon josta voi valita minkä tahansa listalla olevan muuttujan. gvl. etuliitteen käyttö ei kuitenkaan ole pakollista. Detaalisuunnittelu Tämä on selvästi haastavampi ohjelmointiharjoitus kuin mikään tähänastisista. Jotta ohjelmistonkehitys ei veisi liikaa aikaa, tässä annetaan vinkkejä miten ohjelmisto kannattaa suunnitella. Tässä luvussa mainittujen suunnitteluperiaatteiden noudattaminen on pakollista vain jos haluaa teknistä tukea. Aluksi vaikuttaa siltä että SFC kieli olisi sopiva. Kuitenkin SFC soveltuu ainoastaan tapauksiin, joissa vaiheiden sekvenssi on ennaltamääritelty. Tässä tapauksessa ei voida tietää että missä järjestyksessä hissiä kutsutaan eri kerroksiin. FBD kieli ei puolestaan sovellu, jos on vähänkään enemmän ehtolauseita tai silmukoita. Näin ollen kannattaa käyttää ST:tä. Huomataan että toiminto voidaan mallintaa tilakoneella. Taulukko 2 luettelee 5 tilaa, joissa ohjelma voi olla. IT alalla laajasti käytetyn tilakoneen (statechart) määritelmä [jos haluatte tietää formaalimman määritelmän tilakoneelle, suorittakaa tietojenkäsittelyteorian kurssi viereisessä talossa] on että järjestelmä on aina

12 täsmälleen yhdessä tilassa. Tilakone myös määrittelee että millä logiikalla voidaan vaihtaa tilasta toiseen. Koska PLC kielet eivät tue tilakoneita, lähdetään siitä että mistä tahansa tilasta voidaan siirtyä mihin tahansa tilaan heti kun uuden tilan aktiivinen jos ehto (kts Taulukko 2) toteutuu. Näin ollen ehdot pitää kirjoittaa siten että ne ovat toisensa pois sulkevia. Taulukon mukainen tilakone voidaan toteuttaa ST kielellä seuraavasti: IF <tila1 aktiivinen jos ehto tosi> THEN <tila1 toiminta> ENDIF; IF <tila2 aktiivinen jos ehto tosi> THEN <tila2 toiminta> ENDIF; jne. Taulukko 2 Järjestelmätoiminto 1:en toteuttavan ohjelman suunnittelu Tilan nimi Aktiivinen jos Toiminta Liikkeelle lähtö Ollaan kerroksessa Y, joka ei ole X ja Go on tosi ja kaikki ovet ovat Jos Y>X start motor down, muuten start motor up kiinni Saavutaan matkan varrella kerrokseen 1 ja avataan ovi Kerroksen 1 ovi kokonaan auki Ollaan kerroksessa X tai??? saavutaan kerrokseen X ja avataan ovi Kerroksen X ovi kokonaan auki Detaalisuunnittelun yhteydessä laaditaan moduulien yksikkötestit. Tässä yhteydessä riittää laatia yksikkötestit järjestelmätoimintoa 1 toteuttavalla toiminnolle. Katso tarkemmat vaatimukset Pisteytys luvusta dokumentin lopusta. Ohjelmiston integraatiotestaus Nyt mennään suoraan tämän vaiheen ohi, koska käytössämme on HIL testausympäristö (HIL selitettiin Lamppu harjoituksen yhteydessä), joka vastaa V-mallin seuraavaa vaihetta. Ohjelmiston integrointi elektroniikkaan Tämä vaihe suoritetaan HIL testaus ympäristössä eli normaalisti Easyveep ympäristössä. Tässä vaiheessa huomataan esim jos johdot eivät ole oikein kytketty PLC:n I/O moduuliin. Jotkut HIL ympäristöt mahdollistavat sähköisten vikojen kuten oikosulkujen aiheuttamisen kyseisiin johtoihin, mutta meidän ympäristö ei tue sitä.

13 Tässä vaiheessa testit laaditaan V-mallin vasemman haaran toiseksi ylimmässä vaiheessa luodun suunnitteluaineiston perusteella. Tässä harjoitustyössä tämä vaihe ohitetaan, koska kurssin työmäärä nousisi muuten liian korkeaksi. Kytke yksikkötestauksen valvomoelementit irti globaaleista muuttujista. Kenttätestaus Tässä vaiheessa käyttäjä kokeilee lopullista tuotetta sen oikeassa käyttöympäristössä, eli fyysistä hissiä. Harjoitustyössä kokeilut tehdään Easyveep ympäristössä. Testaile kunnes sovellus mielestäsi toimii käyttötapausten mukaan ja samalla tavalla kuin Easyveep esimerkkisovellus. Reflektointi Mieti projektinhallinnan tarpeellisuutta seuraavissa tapauksissa ja selitä näkemyksesi demon yhteydessä: Yksi henkilö tekee koko projektin Kaksi henkilöä (sähköinsinööritaustainen järjestelmäsuunnittelija ja PLC ohjelmoija) tekevät projektin Projektin koko on monta tuhatta I/Ota ja projektiin osallistuu useita ihmisiä saman yrityksen eri osastoilta. Suomalaiset työkonevalmistajat käyttävät yleensä alihankkijoita ohjelmiston teettämiseksi. V-malli on yksi tapa jäsentää projekti, jonka perusteella määritellään että mitkä työvaiheet kuuluvat alihankkijalle. Pisteytys (max 27p) Käyttötapaus 2 (5p) Riskinarviointi yhdelle vaaralle (5p) Järjestelmätoiminto 2 (5p) Järjestelmätoiminto 1 yksikkötestaus (5p) Nolla pistettä mikäli mistään kerroksesta ei voida ajaa mihinkään kerrokseen. Muussa tapauksessa minus 1 piste jokaisesta demossa havaitusta bugista (ei kuitenkaan ole mahdollista saada negatiivista pistemäärää). Yksikkötestauksesta ei vaadita testisuunnitelmia tai muuta kirjallista dokumentaatiota. Kenttätestaus (5p) Nolla pistettä mikäli kumpikaan käyttötapaus ei toimi missään olosuhteissa. Muussa tapauksessa minus 1 piste jokaisesta demossa havaitusta bugista (ei kuitenkaan ole mahdollista saada negatiivista pistemäärää). Yksikkötestauksesta ei vaadita testisuunnitelmia tai muuta kirjallista dokumentaatiota. Reflektointi (2p) 2p edellyttää syvällistä näkemystä.

14 Tiivistelmä tehtävänannosta Toteuta Easyveep hissimoduuli. Hissin toiminta pitää jakaa kahteen osaan seuraavasti: 1. Ajetaan nykyisestä paikasta kerrokseen X ja tarvittaessa pysähdytään matkan varrella. Tämän toiminnon ei tarvitse tietää että onko komento kerrokseen X saatu rappukäytävän vai hissin sisäisillä kutsunapeilla. 2. Monitoroidaan hissin ja rappukäytävän kutsunappeja, tarvittaessa laitetaan kutsuja jonoon ja puretaan jonon vanhin kutsu kun toiminto 1 on tullut valmiiksi. Toiminnot voidaan kirjoittaa joka kahdessa eri ohjelmassa tai yhdessä, ota kuitenkin huomioon toimintojen testattavuus. Toiminnot pitää pystyä yksikkötestaamaan erikseen. Toteutuskieleksi suositellaan ST:tä. Kirjoita toteutuksesta dokumentaatio, joka pitää sisällään käyttötapakuvauksen kerrokseen ajosta, kun käyttäjä seisoo hissin sisäpuolella, yksikkötestauksen toiminnolle 1 ja riskinarvioinnin yhdelle vaaralle. Lopuksi suorita reflaktointi.