Edellisessä osassa HEOMF:n taso 4 laajensi kotitalouden energianhallinnan oman optimoinnin ulkopuolelle sähköjärjestelmään ja markkinoihin. Mitä pidemmälle järjestelmää kehitetään, sitä tärkeämmäksi muuttuu kuitenkin yksi asia: rakenne.
Automaatio syntyy helposti pala kerrallaan. Ensin tulee hintaan perustuva sääntö, sitten lämpötilaohjaus, sähköauton lataus ja aurinkotuotannon hyödyntäminen. Yksittäin ne voivat toimia hyvin, mutta kokonaisuuden kasvaessa samat säännöt voivat alkaa ohjata järjestelmää ristiriitaisiin suuntiin ja vikatilanteiden selvittäminen vaikeutuu.
HEOMF:ssa arkkitehtuurin tehtävä on erottaa mittaus, tulkinta, päätöksenteko, varsinainen laiteohjaus ja turvallisuudesta huolehtivat rajat toisistaan. Tarkoitus ei ole lisätä monimutkaisuutta, vaan tehdä jo syntyneestä monimutkaisuudesta hallittavaa.
Miksi arkkitehtuuria tarvitaan?
Yksinkertainen tason 1 hintareaktio voi toimia ilman selvästi näkyvää kerrosrakennetta. Tasolla 2 rajoitteita alkaa tulla enemmän, ja tasoilla 3–4 ennusteet, useat kuormat sekä ulkoiset signaalit tekevät rakenteesta käytännössä välttämättömän.
Arkkitehtuurin perusperiaate on yksinkertainen: mittaus ei tee päätöksiä, päätös ei suoraan sisällä laitekohtaista toteutusta eikä optimointi saa ohittaa turvarajoja. Kun vastuut erotetaan, järjestelmän toimintaa voidaan ymmärtää ja muuttaa ilman, että yhden osan muutos leviää hallitsemattomasti kaikkialle.
Kerros 1 – Mittaus
Kaikki alkaa datasta, mutta kaikkea mahdollista ei tarvitse mitata. Olennaista on kerätä ne suureet, joita päätöksenteko todella tarvitsee, ja varmistaa että tieto on riittävän luotettavaa ja ajantasaista.
Kotitalouden energianhallinnassa tällaisia mittauksia voivat olla kokonaiskulutus, hetkellinen ja vaihekohtainen teho, sisä- ja ulkolämpötilat, lämpöpumpun lämpötilat, käyttöveden lämpötila, aurinkotuotanto, akun varaustila sekä sähkön hinta.
Mittauskerroksen tehtävä ei ole tulkita, onko tilanne hyvä tai huono. Sen tehtävä on tuottaa mahdollisimman selkeä kuva siitä, mitä järjestelmässä todella tapahtuu. Jos tämä tieto on virheellistä tai vanhentunutta, kaikki ylemmät kerrokset tekevät päätöksiä huonon lähtötiedon perusteella.
Kerros 2 – Analyysi
Analyysikerros muuttaa raakadatasta päätöksenteolle käyttökelpoista tietoa. Se voi esimerkiksi arvioida, onko lämpöpumpun hyötysuhde heikentynyt, kuinka lähellä sähköliittymän tehorajaa ollaan, kuinka paljon rakennuksessa on lämpöjoustoa tai onko seuraaville tunneille odotettavissa merkittävää aurinkotuotantoa.
Tässä ei vielä päätetä, mitä laitteelle tehdään. Analyysin tehtävä on muodostaa tilamuuttujia ja tulkintoja, joita päätöslogiikka voi käyttää. Tämä erotus on tärkeä, koska muuten päätöksenteko alkaa lukea suurta määrää raakadataa suoraan ja yksittäinen sääntö kasvaa helposti vaikeasti hallittavaksi.
Kerros 3 – Päätöslogiikka
Tässä kerroksessa varsinainen optimointipäätös syntyy. Päätöslogiikka ratkaisee esimerkiksi, ladataanko sähköauto nyt vai myöhemmin, kasvatetaanko lämmitystä, rajoitetaanko tehoa tai odotetaanko parempaa käyttöhetkeä.
Hyvän päätöslogiikan pitää olla priorisoitu ja rajattu. Sen pitää pystyä ratkaisemaan tilanteet, joissa useat tavoitteet kilpailevat keskenään, eikä sama laite saa saada samanaikaisesti ristiriitaisia käskyjä eri automaatioista.
Kypsyystaso vaikuttaa siihen, kuinka kehittynyt päätöslogiikka on. Taso 2 voi toimia yksinkertaisilla säännöillä, taso 3 käyttää ennusteita ja taso 4 voi ottaa mukaan myös ulkoisia markkina- tai joustosignaaleja. Päätöksenteon vastuu pysyy silti omana kerroksenaan.
Kerros 4 – Ohjaus
Ohjauskerros toteuttaa päätöksen fyysisessä järjestelmässä. Toteutus voi olla releen vaihtaminen, lämpöpumpun ohjaussignaali, tehorajoitus, sähköauton latausvirran muuttaminen tai varaajan asetusarvon muutos.
Keskeinen periaate on, ettei ohjauskerroksen pitäisi itse päättää, miksi toiminto tehdään. Sen tehtävä on vastaanottaa päätös ja toteuttaa se hallitulla tavalla. Näin samaa päätöslogiikkaa voidaan kehittää ilman, että jokaisen laitteen tekninen toteutus sekoittuu optimointiin.
Kerros 5 – Turva
Turvakerros vastaa kysymykseen, mitä tapahtuu silloin kun optimointi epäonnistuu. Yhteys voi katketa, mittaus voi jäädä vanhaksi, ennuste voi olla väärä tai automaatio voi jäädä väärään tilaan.
Turvatoimintoihin voivat kuulua minimi- ja maksimirajat, toiminnon aikarajat, manuaalinen ohitus sekä ennalta määritelty fail-safe-tila. Niiden tarkoitus on varmistaa, ettei optimoinnin virhe pääse muuttumaan esimerkiksi liian kylmäksi rakennukseksi, käyttöveden ongelmaksi, pääsulakeylitykseksi tai laitteiston hallitsemattomaksi tilaksi.
Mitä korkeammalle kypsyystasolle siirrytään, sitä tärkeämpi tämä kerros on. Ennusteiden, ulkoisten tietolähteiden ja markkinasignaalien lisääntyessä myös mahdollisten vikatilanteiden määrä kasvaa.
Miksi kerrosten erottelu kannattaa?
Jos mittaus, analyysi, päätöksenteko ja varsinainen ohjaus pakataan samaan sääntöön, virheen lähteen selvittäminen vaikeutuu nopeasti. Samalla uusien toimintojen lisääminen kasvattaa olemassa olevan logiikan riippuvuuksia.
Kun kerrokset erotetaan, voidaan kysyä järjestelmällisesti: oliko lähtödata oikein, tulkitsiko analyysi tilanteen oikein, oliko päätös oikea ja toteutuiko laiteohjaus suunnitellusti? Vikatilanne pystytään paikallistamaan paljon tarkemmin.
Arkkitehtuuri ei siis tee järjestelmästä monimutkaisempaa. Se antaa jo olemassa olevalle monimutkaisuudelle rakenteen.
Arkkitehtuurin tarve kasvaa kypsyystason mukana
Tasolla 1 eri vastuut voivat vielä olla käytännössä saman automaation sisällä. Tasolla 2 kerroserottelu alkaa helpottaa rajoitteiden hallintaa. Tasolla 3 ennusteet ja useiden kuormien yhteisoptimointi tekevät selkeästä rakenteesta jo olennaisen, ja tasolla 4 turvakerroksen merkitys korostuu ulkoisen ohjauksen vuoksi.
Tämä ei tarkoita, että jokainen kotitalous tarvitsisi viisi erillistä ohjelmistokomponenttia. Kerrokset kuvaavat vastuita ja tiedonkulkua. Ne voivat toteutua samassa laitteessa tai ohjelmistossa, kunhan niiden tehtävät ovat loogisesti erotettavissa.
Yleinen virhe: yksi sääntö yrittää ratkaista kaiken
Hauraan automaation tunnistaa helposti säännöstä, joka alkaa muistuttaa tätä: “jos hinta on alle X, ulkolämpötila alle Y, aurinkotuotanto yli Z ja akun varaustila yli 40 prosenttia, tee…”
Yksittäinen ehto ei vielä ole ongelma, mutta kun samaan sääntöön lisätään jatkuvasti uusia mittauksia, päätöksiä ja laiteohjauksia, kokonaisuutta on vaikea testata ja ymmärtää.
Selkeämpi rakenne on se, että analyysi muodostaa tarvittavat tilatiedot, päätöslogiikka käyttää niitä ja ohjauskerros toteuttaa valitun toiminnon. Turvakerros voi vielä estää päätöksen, jos tärkeä raja ylittyy.
Arkkitehtuuri ei ole sidottu teknologiaan
Tämä rakenne ei ole Home Assistant -spesifi eikä edellytä omaa ohjelmointia. Sama periaate voidaan toteuttaa kaupallisessa energianhallintajärjestelmässä, itse rakennetussa ratkaisussa tai paljon yksinkertaisemmassa automaatiossa.
Ratkaisevaa ei ole käytetty teknologia, vaan se, ovatko mittaus, tulkinta, päätös, toteutus ja turvallisuus erotettu toisistaan riittävän selvästi.
Miksi arkkitehtuuri kuuluu HEOMF:iin?
HEOMF ei ole vain luokitus siitä, kuinka paljon automaatiota järjestelmässä on. Korkeampi kypsyystaso edellyttää, että lisääntyvä päätöksenteko pysyy ymmärrettävänä ja turvallisena.
Ilman selkeää rakennetta taso 2 jää helposti joukoksi erillisiä rajoitesääntöjä, taso 3 vaikeasti hallittavaksi ennusteautomaatioiden verkoksi ja taso 4 riskialttiiksi ulkoisen ohjauksen kokonaisuudeksi. Arkkitehtuuri on siksi osa kypsyyttä, ei siitä erillinen tekninen yksityiskohta.
Viisi kerrosta tiivistettynä
- Mittaus kertoo, mitä järjestelmässä tapahtuu.
- Analyysi tulkitsee mittaukset päätöksenteon kannalta hyödylliseksi tiedoksi.
- Päätöslogiikka valitsee, mitä järjestelmän pitäisi tehdä.
- Ohjaus toteuttaa päätöksen fyysisissä laitteissa.
- Turva rajaa toiminnan ja pitää järjestelmän turvallisena myös virhetilanteissa.
Kun nämä vastuut erotetaan, optimoinnin toimintaa voidaan kehittää ilman, että koko järjestelmän hallittavuus menetetään.
Seuraavaksi: riskit ja reunaehdot
Seuraavassa osassa tarkastellaan riskejä ja reunaehtoja: miksi hyväkään arkkitehtuuri ei yksin riitä, jos järjestelmän käyttöympäristöä, epävarmuuksia ja vikatilanteita ei tunneta.
HEOMF-pääsivulta löydät koko kypsyysmallisarjan, itsearvioinnin ja White Paperin. Arkkitehtuuria syvennetään erillisessä Optimoinnin arkkitehtuuri -sarjassa.