Kotitalouden energianhallinnassa sanaa optimointi käytetään helposti kaikesta automaattisesta ohjauksesta. Laite käynnistyy halvan hinnan aikana, aurinkoylijäämä ohjataan kuormalle tai sähköauton lataus estetään kalliin vartin ajaksi – ja kaikkea kutsutaan optimoinniksi.
Arkkitehtuurin kannalta on hyödyllistä tehdä tarkempi ero. Yksittäinen sääntö voi olla hyvä ja täysin tarkoituksenmukainen ohjaus, mutta järjestelmätason optimointi alkaa siitä, että useiden mahdollisten toimintatapojen välillä tehdään valinta yhteisten tavoitteiden ja rajoitteiden perusteella.
Tässä osassa kysymys ei siis ole siitä, millä ohjelmointikielellä optimointi toteutetaan. Kysymys on siitä, mitä päätöksentekovastuuta optimointikerrokselle kuuluu.
Sääntö ja optimointi eivät ole vastakohtia
Yksinkertainen sääntö, kuten jos hinta < X, salli lataus, voi toimia erinomaisesti rajatussa tilanteessa. Se ei kuitenkaan vielä ratkaise sitä, mitä tehdään, jos samaan aikaan:
- sähköauto pitäisi saada aamuksi tiettyyn varaustasoon
- lämpöpumpulla olisi edullinen lämmitysikkuna
- käyttövesi tarvitsee lämpöä
- aurinkotuotantoa on ennustettu myöhemmäksi
- liittymän tehoraja estää kaikkien kuormien yhtäaikaisen käytön
Tässä vaiheessa tarvitaan päätöksentekoa, joka tarkastelee vaihtoehtoja yhdessä.
Optimointijärjestelmä voi silti sisältää paljon sääntöjä. Esimerkiksi turvallisuusrajat, määräajat ja käyttäjän asettamat ehdot ovat usein juuri sääntöjä. Oleellista on, että ne ovat osa yhteistä päätösmallia eivätkä joukko toisistaan tietämättömiä automaatioita.
Optimointi tarvitsee tavoitteen, vaihtoehdot ja rajoitteet
Optimointiongelma voidaan yksinkertaistaa kolmeen kysymykseen.
- Mitä yritetään saavuttaa? Esimerkiksi pienempi kustannus, pienempi tehopiikki tai parempi oman tuotannon hyödyntäminen.
- Mitä voidaan muuttaa? Esimerkiksi latauksen ajankohtaa, lämmityksen tavoitetta tai akun lataus- ja purkutehoa.
- Mitä ei saa rikkoa? Esimerkiksi pääsulakkeen rajaa, lämpötilarajoja, auton lähtöaikaa tai laitteen omia käyttöehtoja.
Yksinkertaisimmillaan malli voidaan kirjoittaa näin:
minimoi tavoitefunktio
rajoitteilla:
- liittymän teho ≤ sallittu raja
- sisälämpötila hyväksytyllä alueella
- käyttövesi riittävä
- auton lataustavoite saavutetaan määräaikaan mennessä
- laitteiden omat rajat täyttyvätTavoitefunktion ei tarvitse olla pelkkä eurokustannus. Siinä voidaan painottaa myös mukavuutta, tehopiikkejä, akun käyttöä tai muita tavoitteita. Käytännössä tärkeää on, että painotukset ovat tietoisia eivätkä synny vahingossa automaatioiden suoritusjärjestyksestä.
Optimointi on kompromissien tekemistä
Kotitalouden energiajärjestelmässä yhtä aikaa hyvä ratkaisu ei aina ole jokaisen yksittäisen tavoitteen paras ratkaisu.
Halvin sähkö voi olla yöllä, mutta lämpöpumpun hyötysuhde voi olla parempi lämpimämmällä päiväjaksolla. Aurinkotuotanto painottuu päivään. Sähköauto tarvitsee tietyn energiamäärän ennen lähtöä. Samalla kuormia ei ehkä voida käyttää yhtä aikaa liittymän tehorajan vuoksi.
Optimoinnin tehtävä on löytää näistä sellainen kokonaisuus, joka täyttää pakolliset ehdot ja toteuttaa asetetut tavoitteet mahdollisimman hyvin.
Paikallisesti halvin päätös ei siis välttämättä ole järjestelmätasolla halvin päätös.
Teho on rajoite ja joskus myös kustannus
Jos optimointi tarkastelee vain kilowattitunteja ja niiden hintaa, kaikki joustavat kuormat voivat päätyä samalle halvalle vartille. Tällöin energiakustannus näyttää hyvältä mutta hetkellinen kokonaisteho voi nousta tarpeettoman korkeaksi.
Teho voi tulla optimointiin kahdella eri tavalla:
- Kovana rajoitteena: esimerkiksi liittymän vaihevirtaa tai kokonaistehoa ei saa ylittää.
- Taloudellisena tavoitteena: jos verkkotariffi tai muu hinnoittelu tekee korkeasta huipputehosta kallista.
Näitä ei pidä sekoittaa toisiinsa. Pääsulakkeen suojaaminen on fyysinen vaatimus. Tehomaksun välttäminen on taloudellinen optimointitavoite. Sama tehomittaus voi palvella molempia, mutta päätöksen merkitys on eri.
Eri aikajänteillä tehdään eri päätöksiä
Yksi optimointikerros ei välttämättä tarkoita yhtä aikaskaalaa. Kotitalouden energianhallinnassa päätöksiä tehdään useilla aikajänteillä.
| Aikajänne | Tyypillinen tehtävä | Luonne |
|---|---|---|
| Sekunnit–minuutit | Toteutuneen tehon rajoitus, nopea fallback, kuorman sallittavuus | Usein paikallinen ja deterministinen |
| Vartit–tunnit | Sähköauton lataus, käyttövesi, lämmityksen ajoitus | Spot-hinta, nykytila ja lyhyen ajan ennusteet |
| Vuorokausi–muutama päivä | Lämpövaraston käyttö, aurinko- ja sääennusteiden hyödyntäminen, lataustarpeiden suunnittelu | Ennakoiva suunnittelu |
| Pidempi seuranta | Rakennusmallin oppiminen, kulutusrajojen tarkennus, tariffi- ja sopimuskustannusten seuranta | Mallin ja parametrien kehittäminen |
Nopein tehorajoitus ei siis välttämättä kuulu samalle algoritmille, joka suunnittelee huomisen lämmitystä. Ylemmän tason optimointi voi pyrkiä välttämään tehopiikin ennakolta, mutta kenttä- ja suojakerroksen pitää tarvittaessa pystyä reagoimaan toteutuneeseen tilanteeseen nopeammin.
Kulutusvaikutus ei luo omaa kuukausioptimointia
Kuukausitason laskenta voi helposti johtaa väärään arkkitehtuuripäätelmään. Esimerkiksi kulutusvaikutuksellisessa hybridisopimuksessa kulutusvaikutus lasketaan kuukausittain, mutta tämä ei tarkoita, että kulutuksen ajoitus pitäisi optimoida eri tavalla kuin pörssisähkössä.
Kun verkosta ostettava energiamäärä pysyy samana ja kulutusvaikutus on lineaarinen, varttien keskinäinen hintajärjestys on sama. Halvemmalle vartille siirtäminen parantaa molempia samalla tavalla.
Tätä on käsitelty tarkemmin Pörssisähkö vai hybridi -sarjassa. Arkkitehtuurin kannalta tärkeä johtopäätös on, ettei laskutusjaksoa pidä automaattisesti tulkita optimoinnin aikajänteeksi.
Optimointi tarvitsee tilannekuvan ja ennusteen
Pelkkä hintalista ei riitä järjestelmätason päätökseen. Optimoinnin pitää tietää myös lähtötila.
Tarvittavia tietoja voivat olla esimerkiksi:
- liittymän nykyinen kokonaisteho
- sisä- ja ulkolämpötila
- lämpöpumpun tila ja käytettävissä oleva jousto
- auton arvioitu tai mitattu varaustila ja lähtöaika
- aurinkotuotannon ennuste
- aktiiviset käyttötilat ja käyttäjän ohitukset
- mittausten tuoreus ja laitteiden käytettävyys
Ennuste ei ole totuus. Hyvän optimoinnin pitää siksi pystyä laskemaan suunnitelma uudelleen, kun hinta, sää, käyttäjän tarve tai laitteen tila muuttuu.
Suunnitelma ja toteutus pitää erottaa toisistaan
Optimointikerroksen hyvä ulostulo ei välttämättä ole yksittäinen komento “rele päälle”, vaan suunnitelma, tavoite tai sallittu toimintajakso.
Esimerkiksi sähköautolle voidaan muodostaa:
tavoite:
- auto valmis klo 06:00
- vähintään 80 %
suunnitelma:
- lataus sallittu valituissa edullisissa varteissa
- kokonaistehoraja aina voimassaAutomaatiokerros yhdistää tämän suunnitelman nykytilaan ja käyttötiloihin. Kenttäkerros toteuttaa fyysisen pyynnön vain sallituissa rajoissa.
Tämä työnjako tekee optimointialgoritmista vähemmän riippuvaisen laitteiden yksityiskohdista.
Optimointi voi asua samassa ohjelmistossa kuin automaatio
Edellisessä osassa automaation rooliksi määriteltiin yhdistäminen ja deterministinen työnkulku. Tämä ei tarkoita, että optimoinnin pitäisi välttämättä pyöriä eri palvelimella tai eri ohjelmistossa.
Pienessä järjestelmässä optimointilogiikka voi hyvin olla esimerkiksi Node-REDissä, Home Assistantin yhteydessä tai samassa tietokoneessa muun automaation kanssa.
Arkkitehtuurin kannalta tärkeää on looginen rajapinta: optimointikoodi ei saisi joutua tuntemaan kaikkia laitekohtaisia yksityiskohtia, eikä fyysisten turvarajojen pitäisi riippua siitä, että optimointialgoritmi on juuri sillä hetkellä käynnissä.
Päätöksestä pitää pystyä kertomaan miksi
Kun optimointi valitsee useiden vaihtoehtojen välillä, pelkkä lopputulos ei riitä järjestelmän ylläpitoon. Päätöksestä pitäisi jäädä ainakin riittävä perustelu.
Esimerkiksi:
EV-lataus ei käynnisty:
- aamun lataustavoite voidaan vielä saavuttaa myöhemmin
- nykyinen vartti on kallis
- ennusteessa on edullisempi ikkuna
- tehoraja ei pakota muutokseenTämä tekee optimoinnista testattavaa. Jos lopputulos näyttää väärältä, voidaan tarkistaa lähtötiedot, rajoitteet ja tavoite sen sijaan, että etsitään satunnaisesti laukeavaa automaatiota.
Mikä ei kuulu optimointikerrokselle?
Optimoinnin pitäisi keskittyä vaihtoehtojen valintaan, ei fyysisen toteutuksen yksityiskohtiin.
- sen ei tarvitse tietää releen IP-osoitetta
- sen ei tarvitse kirjoittaa suoraan Modbus-rekisteriä
- sen ei pitäisi korvata laitteen omaa turvallisuuslogiikkaa
- sen ei pitäisi käsitellä vanhentunutta mittausta hiljaisesti tuoreena
Se voi antaa hyvinkin yksityiskohtaisen tavoitteen, mutta alempien kerrosten tehtävä on muuttaa tavoite kyseisen laitteen ymmärtämäksi turvalliseksi toteutukseksi.
Optimoinnin laatu näkyy myös siinä, mitä se jättää tekemättä
Hyvä optimointi ei tarkoita sitä, että järjestelmä yrittää jatkuvasti siirtää jokaista kilowattituntia. Jokaisella ohjauksella voi olla hinta: lämpötila vaihtelee, kompressorin käynnit lisääntyvät, akun häviöt kasvavat tai käyttäjän kokema ennustettavuus heikkenee.
Siksi optimointiin kannattaa sisällyttää myös muutoksen kustannus tai ainakin hysteresis ja päätösten vakaus. Jos kahden vaihtoehdon taloudellinen ero on käytännössä merkityksetön, järjestelmän ei tarvitse vaihtaa tilaa vain siksi, että laskennallinen minimi siirtyi hieman.
Hyvä optimointi ei tee mahdollisimman paljon päätöksiä. Se tekee tarpeelliset päätökset oikeista syistä.
Seuraavaksi: rajapinnat
Kun päätöksenteon rooli on määritelty, seuraava kysymys on, miten optimointi, automaatio ja kenttäkerros keskustelevat keskenään ilman että niiden vastuut vuotavat toistensa puolelle.
Osa 8: Rajapinnat – järjestelmän tärkein suunnittelukohde käsittelee tietovirtoja, ohjauspyyntöjä, sallittuja toimintoja ja sitä, miten laiteriippuvuuksia voidaan rajata.
Optimoinnin arkkitehtuuri -sarjan pääsivulta löydät kaikki sarjan osat.