Simulaatiosta todelliseen maailmaan hybridijärjestelmän avulla

Nykyään energiaomavaraisuus talouksissa ja organisaatioissa on tärkeää. Hybridijärjestelmillä voi omavaraisuutta parantaa käyttämällä useampaa, toisiaan täydentävää energiamuotoa. Eri energianlähteitä yhdistämällä vahvistetaan koko järjestelmän tehokkuutta ja pienennetään energianlähteiden heikkouksia sekä simulaation avulla voidaan arvioida kokonaisuutta ennen toteutuksen aloitusta.

Hybridijärjestelmät ovat askel kohti vihreää siirtymää, koska ne vähentävät riippuvuutta fossiilisista energialähteistä. Hybridijärjestelmän avulla lämmityksessä voidaan päästä jopa omavaraisuuteen, ja oikeilla valinnoilla säästetään energiaa (Ekolämmöx). Vihreän energian käytön lisääminen on Geoenergialoikka- ja HAAVE-hankkeiden yhteinen tavoite. Biokaasun tuotantoa ja sen jalostusta Keski-Pohjanmaan alueella on tutkittu HAAVE-hankkeessa, jossa suunniteltiin automaattinen biokaasun tuotantojärjestelmä.

Teoreettisessa hybridijärjestelmässä geoenergia tarjoaisi peruslämmön, ja suurempi tarve voitaisiin kattaa tuotetun biokaasun avulla, jolloin energiakaivoa ei kuormitettaisi tarvetta enempää ja se pääsisi palautumaan. Biokaasu voi myös tuottaa tarvittaessa sähköenergiaa lämpöpumpun toimintaan. Näin järjestelmä olisi kokonaisuudessaan omavarainen sekä lämmön että sähkön osalta.

Kasattu automaattinen tuotantojärjestelmä on suunniteltu kauan ennen osien saapumista. Tuotannon toiminta on tiivistetty arvoihin, joiden avulla tuotantoa hallitaan Geoenergialoikka-hankkeen jäsenten kehittämällä ohjelmalogiikalla. Järjestelmää voidaan simuloida asettamalla sen arvot tilaan, joka vastaa todellista tilannetta tulkittujen arvojen perusteella.

Hybridikäyttö lämmityksessä tarkoittaa sitä, että rakennuksen lämmityksessä käytetään kahta tai useampaa energialähdettä, joiden etuja pystytään automaatiojärjestelmällä hyödyntämään tarpeen mukaan. Hybridijärjestelmässä on usein toisen lämmönlähteen lisäksi mukana lämpöpumppu, kuten ilma-, vesi- tai maalämpöpumppu. Hybridikäytössä täydentävä lämmitysjärjestelmä käynnistyy silloin, kun päälämmönlähteen tuottama lämpö ei ole riittävä tai hyötysuhde heikkenee liikaa esimerkiksi kylmillä keleillä. (Lämpöpumppuhinta.)

Kylmät vuodenajat voivat rasittaa lämmitysjärjestelmää, jolloin hybridilämmityksellä on monia hyötyjä, kuten luotettavampi lämmöntuotto toisen lämmönlähteen tullessa mukaan. Joustavuus myös paranee hybridijärjestelmän mukautuessa paremmin erilaisiin talon lämmitystarpeisiin. (Lämpöpumppuhinta.)

Automaation simulaatio auttaa optimoimaan prosessin eri osia; erilaisten skenaarioiden avulla on mahdollista tunnistaa pullonkaulat, optimoida toimintoja ja parantaa kokonaistehokkuutta (Technia). Järjestelmälogiikan testauksessa simulaatiot olivat tärkeässä asemassa, sillä niiden avulla varmistettiin logiikan toimivuus ja se, että järjestelmä noudatti suunniteltuja toimintoja. Näin simulaatiot toimivat prosessin hahmotteluna, eikä laitteistoa tarvitse kuormittaa logiikkatesteillä järjestelmän kasauksen jälkeenkään. Muutoksia voitiin myös testata nopeammin kuin todellisella laitteistolla.

Esimerkiksi Siemens tarjoaa simulointiin PLCSIM-ohjelman, joka on osa TIA Portal -ohjelmistoa. Saatavilla on myös kehittyneempi ja kalliimpi PLCSIM Advanced, joka tarjoaa enemmän ominaisuuksia, kuten Ethernet-lähiverkkokommunikoinnin simulaation ja laajemmat sekä tarkemmat mahdollisuudet simulaatioon. Teoriassa tietokoneen voi muuttaa maksimissaan 16 eri itsenäiseksi logiikaksi (SolisPLC).

Suurin osa kehitystyön ajan testailusta tapahtui tässä simuloidussa ympäristössä. Järjestelmän suunnittelijoiden yhteistyöllä yritettiin ennustaa ongelmia ja järjestelmän käyttäytymisen erikoisuuksia. Virhetiloihin valmistauduttiin tekemällä hälytyksiä antureiden arvojen perusteella havaituista virheistä, mutta täydellinen ennakointi on mahdotonta. Oikeaa maailmaa ja reaktioita ei voitu kohdata ennen järjestelmän käynnistämistä.

Järjestelmän ensimmäisen ajon ollessa takana, voitiin vertailla kehityksen aikaisia olettamuksia ja tuloksia käytännön järjestelmän toimintaan. Vertailemalla järjestelmiä esitetään havaittuja eroja operaatioissa. Esimerkkien avulla havainnollistetaan kehityksessä esiin nousseita asioita, joiden huomioiminen ehkäisisi vastaavia ongelmia tai ajojen epäonnistumisia. Kootut opit auttavat hybridijärjestelmien käyttöönoton edistämisessä, jolloin vertailu toimii myös koulutusmateriaalina.

Simulaatiolla voidaan vähentää riskejä analysoimalla ja kehittämällä tulevaa järjestelmää ennen kuin aloitetaan kalliiden investointien toteuttaminen. Tehokkuutta voidaan arvioida laskemalla esimerkiksi, kuinka suuren osan geoenergia täyttäisi lämmitystarpeesta ja kuinka paljon biokaasu voisi sitä täydentää. Simulaatiossa voidaan parhaiten analysoida järjestelmän logiikan toimintaa ja dynaamisuutta. Edistyykö automaatiologiikka suunnitellulla tavalla, kun tulevien signaalien havaitaan osuvan kynnyksiin?

Laskutoimintojen ja arvokäännösten tulokset on myös tarkistettava simulaatiotestien aikana, koska ne käyttävät kehitysalustan omia toimintoja ja tietotyyppejä. Sisään tuleva analoginen signaali osoittaa luetun ominaisuuden suuruuden kokonaisarvona, mutta se pitää kääntää luettavaksi, käyttäjälle järkeenkäyväksi tiedoksi. Järjestelmä vaatii lisäksi operaatioiden keston syöttämistä desimaaliarvoina, joista johdetaan esimerkiksi koko prosessin päättymisaika kalenteriarvoksi.

Puuttuva ja hyvin olennainen ominaisuus on järjestelmän fyysisyys. Suunnittelussa ja rakentamisenkin aikana voidaan pohtia mahdollisia haasteita ja osien kulumista, mutta simulaatiossa ei voi suoraan testata materiaalin virtausta, kaasun painetta tai osien toimintaa.

Simulaatiossa prosessin suorituskyky on aina käytännössä maksimitasolla eikä koskaan laske sen alapuolelle. Todellisuudessa esiintyy viiveitä tai muita suorituskykyyn vaikuttavia tekijöitä. Laitteet toimivat aina ikään kuin uusina, eivätkä ne koskaan vanhene tai kulu. Osien käyttö todennäköisesti vaikuttaa niiden toimintaan ja tarkkuuteen ajan myötä.

Tapahtumat toteutuvat siis kokonaan ns. täydellisessä maailmassa, ja virheet ovat vain kehittäjän kompastuksia. Virheenkäsittelyä voidaan tehdä simuloimalla eri virhetapauksia: minkälaisia virheitä voisi tapahtua prosessin aikana ja miten ne käsitellään, jotta toiminta voi jatkua eteenpäin tai pysähtyä odottamaan käyttäjän päätöstä. Todellisessa ajossa voi kuitenkin tapahtua virheitä, joita ei ole otettu huomioon simulaatiossa.

Koska simuloidussa järjestelmässä ei tapahdu oikeaa virtausta tai painetta, asetetaan näitä esittävien signaalien arvot manuaalisesti. Simulaatiossa antureiden mittausarvot ovat aina tasaisia, kun taas todellisuudessa mittausarvot vaihtelevat jatkuvasti, ellei sitten mennä asteikon ala- tai ylärajan ulkopuolelle, mikä olisi virhetila. Venttiilien asento ja säiliöiden tasokytkimet täytyy myös asettaa manuaalisesti. Käyttöliittymässä näkyvät venttiilien valot helpottavat säätämistä, kun oikeasti niiden tulisi asettua itsestään venttiilin saadessa signaalin.

Järjestelmän märkätestauksella haluttiin varmistaa putkiston tiiviys, pumppauksen toiminta ja arvojen tarkkuus logiikassa. Syöttötankkiin päästettiin letkulla vettä, kunnes alatason anturi havaitsi nesteen. Sillä hetkellä ilmenivät anturin ja putkiston liitosten tiivistysten puutteet. Vesitestiä jatkettiin pienen liimaustauon jälkeen. Automaattista prosessia ei käynnistetty, vaan järjestelmää hallittiin manuaalisesti. Jokainen pumppausyritys loppui sulakkeen laukeamiseen. Moottorille piti hankkia uudet, suuremmat sulakkeet, joiden toimitus kesti viikkoja.

Johdotusvirheen takia osa antureista ei antanut oikeanlaisia mittaustuloksia. Virheellisyys määritettiin vertaamalla mitattuja arvoja suunnittelussa laskettuihin arvoihin. Esimerkiksi lämpötila-anturin mittausarvon tulisi olla lähellä huoneen lämpötilaa prosessin ollessa alkutilassa ennen käynnistystä.

Kaasulinjaan kytketty kaasupainemittari ei antanut oikeanlaisia mittausarvoja vaihtelevissa tilanteissa. Tapauksessa, jossa kaasulinjassa ei ollut painetta, mittari näytti lähellä nollaa olevaa arvoa, mikä oli tässä tapauksessa oikein. Toisessa tapauksessa kaasun painetta linjassa nostettiin, ja tämänkin jälkeen mittari näytti samankaltaista, lähes nollan mittausarvoa. Tämän todettiin olevan virheellinen mittaus, ja mittarin toimivan poikkeavalla tavalla. Myös kaksi kaasuventtiiliä jouduttiin jättämään käsin asetettaviksi, koska paine letkuissa ei olisi ollut riittävä niiden automaattiseen toimintaan. Venttiilien kääntämisestä laitettiin käyttäjälle muistutus käyttöliittymään vaiheen käynnistystä kutsuttaessa.

Automaattisen operaation aikana esiintyi ongelma, kun virtauksenvarmistus vaati liian nopeaa reaktiota pumppaukseen eikä ehtinyt havaitsemaan tarpeeksi vahvaa virtausta. Tarkastusaikaa pidennettiin, ja operaatio lähti käyntiin. Operaation pyöriessä virtauksenvarmennusongelma toistui ja esti pumppauksen ja sekoituksen toteutumisen päivien ajan. Virheen syyksi paljastui yrityksien välissä kuluneeksi jäänyt varmennusajastin, joka hylkäsi seuraavan pumppauksen automaattisesti.

Prosessin testauksen aikana alkoi kertyä useita eri kehitysideoita, erityisesti käyttöliittymässä esitettävään tietoon liittyen. Siinä olisi esimerkiksi hyödyllistä näyttää kunkin vaiheen tai toiminnon kesto sekä arvio valmistumisesta. Käyttöliittymän ja logiikan yhdistämisessä tuli vastaan myös sadan muuttujan raja, joka hankaloitti tiedon lisäystä. Joitakin tietoja jouduttiin yhdistämään saman monibittisen muuttujan alle tilaa vapauttamaan.

Ajonaikaisten muutosten tekeminen vaati varovaisuutta, koska tiettyjen osioiden päivitys tyhjentää niiden tilannetiedot. Ohjelmassa on eri paikkoja järjestelmän muuttujille sekä fyysisesti että kehitysohjelmiston hierarkiassa. Järjestelmän laitteiston välisen keskustelun signaalit asetetaan ns. tageina omaan listaan. Prosessin muuttujat, kuten signaalien käännetyt arvot, pidetään niille varatuissa tietokantapalikoissa, mikä auttaa pitämään järjestystä muuttujien lukumäärän ollessa yli sata. Järjestelmän ajon aikana ei ollut mahdollista lisätä muuttujia tietokantoihin, mutta tagilista sijaitsee laitteen toisessa muistiosiossa, johon lisääminen ei tyhjennä tietokantoja.

Ajastimia katsoessa huomattiin aikakäännöksissä oleva ongelma: kun haluttu arvo syötettiin desimaalilukuina johdetun arvon ollessa tuntien tai päivien pituisia, ne tallentuivat puolitettuina käännetyn arvon ylittäessä tietyn rajan. Käynnissä olevan ajastimen määräaikaa ei myöskään pystytty muuttamaan suoraan, vaan muutos tulisi voimaan seuraavalle kierrokselle.

Järjestelmä ja prosessi suunniteltiin automaattisiksi, minkä rinnalle kehitettiin manuaalinen hallinta. Pohdittiin molempien hallintatapojen osittaista yhdistämistä, jotta käyttäjä voisi ajon aikana muuttaa järjestelmän tilaa. Tämä olisi kuitenkin vaatinut mittavia muutoksia, joten päätettiin, että eri toiminnot tehtäisiin kutsuttaviksi etuajassa. Ratkaisu olisi helpompi toteuttaa, ja sillä vältettäisiin järjestelmätilan poikkeuksien aiheuttamia ongelmia.