HEOMF – Optimoinnin arkkitehtuuri – Osa 10: Mittaus – ilman dataa ei ole optimointia

Energianhallintajärjestelmä voi näyttää ulospäin toimivalta, vaikka sen päätökset perustuisivat puutteelliseen tietoon. Käyttöliittymä näyttää arvoja, automaatiot käynnistyvät ja optimointi tuottaa suunnitelman – mutta mikään näistä ei vielä kerro, ovatko lähtötiedot riittäviä, tuoreita ja keskenään johdonmukaisia.

Sarjan kolmannessa osassa käsiteltiin mittausta arkkitehtuurin perustana ja osana suljettua ohjausloopia. Tässä osassa mennään käytännöllisemmälle tasolle: mitä kotitalouden energiakeskuksesta kannattaa oikeasti mitata ja milloin arvio tai johdettu tieto riittää?

Kaikkea ei tarvitse mitata – mutta päätöksen kannalta olennainen pitää tuntea

Mittausjärjestelmän tavoite ei ole kerätä mahdollisimman paljon dataa. Tavoite on tehdä järjestelmän tila riittävän havaittavaksi suhteessa niihin päätöksiin, joita energianhallinta tekee.

Jos tehtävänä on vain seurata vuosikulutusta, laskutusmittauksen energiadata voi riittää hyvin. Jos tehtävänä on estää liittymän ylikuormitus, tarvitaan aivan erilaista ja nopeampaa tietoa. Jos taas optimoidaan lämpöpumpun käyttöä, sähkötehon lisäksi tarvitaan tietoa rakennuksen ja lämmitysjärjestelmän tilasta.

Siksi hyvä lähtökysymys ei ole mitä kaikkea voisin mitata, vaan:

Mitä tietoa tämä päätös tarvitsee, jotta se voidaan tehdä riittävän luotettavasti?

Liittymän mittaus muodostaa yhteisen referenssin

Koko talon verkkoliittymän mittaus on energianhallinnan tärkeimpiä tietolähteitä, koska se näyttää kaikkien laitteiden yhteisvaikutuksen riippumatta siitä, kuinka hyvin yksittäiset kuormat on integroitu.

Tarpeesta riippuen hyödyllisiä suureita ovat esimerkiksi:

• verkosta otettava ja verkkoon vietävä hetkellinen teho
• vaihekohtaiset virrat tai tehot, jos liittymän rajoitteet ovat vaihekohtaisia
• ostettu ja myyty energia pidemmällä aikavälillä

Kokonaistehon mittaus toimii samalla myös eräänlaisena riippumattomana tarkistuspisteenä. Jos sähköauton integraatio ilmoittaa latauksen olevan pois päältä mutta liittymän teho kasvaa odotetusti lataustehon verran, järjestelmällä on syy epäillä ilmoitettua tilaa.

Teho ja energia vastaavat eri kysymyksiin

Energia ja teho eivät kilpaile keskenään mittausarvoina. Ne palvelevat eri tehtäviä.

Suure	Mitä se kertoo?	Tyypillinen käyttö
Teho, kW	Mitä järjestelmä tekee juuri nyt tai lyhyellä aikavälillä	Kuormanhallinta, tehorajat, aurinkoylijäämä, ohjauksen verifiointi
Energia, kWh	Kuinka paljon energiaa on kertynyt ajanjaksolla	Kustannukset, kulutusvertailut, tuotanto, säästöjen todentaminen

Energiadata ei siis ole vain raportointia varten. Sitä voidaan käyttää myös optimoinnin mallien kalibrointiin, ennusteisiin ja toteutuneen hyödyn laskentaan. Nopeaan kuormanhallintaan se ei kuitenkaan yleensä korvaa riittävän tuoretta tehotietoa.

Kaikkia kuormia ei tarvitse mitata erikseen

Yksittäisten laitteiden mittaus on hyödyllistä, mutta siitä ei kannata tehdä itseisarvoa.

Kuormakohtainen mittaus on erityisen hyödyllinen, kun:

• laite on suuri suhteessa talon kokonaiskuormaan
• laitetta ohjataan aktiivisesti
• ohjauksen toteutuminen pitää pystyä varmistamaan
• laitteen kulutusta tarvitaan erilliseen kustannus- tai hyötysuhdelaskentaan
• laitteen tila ei muuten ole luotettavasti pääteltävissä

Jos taas pieni kuorma ei vaikuta optimointipäätökseen eikä sen erillistä kulutusta tarvita analyysiin, koko talon mittaus voi olla aivan riittävä.

Suora mittaus, readback ja johdettu tila ovat eri tietolähteitä

Kaikki optimoinnin tarvitsema tieto ei tule fyysiseltä anturilta. Järjestelmässä voidaan käyttää usean tasoista tietoa.

1. Suora mittaus: esimerkiksi virtamittaus, lämpötila tai tehomittari.
2. Laitteen readback: laite ilmoittaa oman toimintatilansa tai asetusarvonsa.
3. Johdettu tila: järjestelmä päättelee esimerkiksi “EV latautuu”, koska latausrele on sallittu ja mitattu teho on noussut odotetulle tasolle.
4. Arvio tai ennuste: esimerkiksi auton varaustila, rakennuksen lämpökapasiteetin tila tai huomisen aurinkotuotanto silloin, kun suoraa mittausta ei ole.

Näillä ei ole samaa varmuutta. Hyvän tilannekuvan pitää pystyä erottamaan toisistaan mitattu arvo, laitteen ilmoittama tila ja järjestelmän oma arvio.

Tämä on erityisen tärkeää silloin, kun päätöksen turvallisuus tai käyttäjän tavoitteen saavuttaminen riippuu tiedon oikeellisuudesta.

Lämpöjärjestelmässä pelkkä sähkömittaus ei riitä

Lämmityksen optimointi on hyvä esimerkki järjestelmästä, jossa kulutustieto yksin kertoo liian vähän.

Tarpeellisia tietoja voivat olla esimerkiksi:

• sisä- ja ulkolämpötila
• meno- ja paluulämpötila
• käyttöveden lämpötila
• kompressorin tai vastusten tila ja teho
• lämmityksen tavoite- tai säätöarvot

Kaikkia näitä ei tarvita jokaiseen optimointiin. Jos järjestelmä vain siirtää pienen määrän lämmitystä muutaman tunnin sisällä, sisälämpötila ja laitteen tila voivat riittää. Jos tavoitteena on arvioida COP:ia tai rakennuksen lämpövarastoa tarkemmin, mittausvaatimus kasvaa.

Aurinkosähkössä tuotanto ja liittymä pitää nähdä yhdessä

Invertterin tuotantoluku kertoo, paljonko aurinkosähköjärjestelmä tuottaa. Se ei yksin kerro, paljonko tästä tuotannosta on juuri nyt vapaana uudelle kuormalle.

Jos paneelit tuottavat 6 kW ja talon muut kuormat käyttävät 4 kW, todellinen ylijäämä on noin 2 kW. Siksi ylijäämäohjauksen kannalta liittymän vienti tai tuotannon ja muun kulutuksen yhteinen laskenta on olennaisempi suure kuin pelkkä invertterin hetkellinen tuotanto.

Sama periaate koskee akkua: varaustila kertoo kapasiteetista, mutta päätös tarvitsee usein lisäksi tiedon lataus- ja purkutehosta sekä järjestelmän senhetkisestä verkkovirrosta.

Datan ikä kuuluu jokaiseen ohjausarvoon

Yksi tärkeimmistä mittausominaisuuksista ei ole itse arvo vaan sen tuoreus.

Esimerkiksi auton varaustila 42 prosenttia voi olla täysin oikea arvo mutta väärä lähtötieto, jos se on mitattu kuusi tuntia sitten ja autoa on sen jälkeen käytetty. Samoin liittymän teho 3,2 kW ei auta pääsulakkeen suojaamisessa, jos arvo ei ole päivittynyt viimeiseen minuuttiin.

Siksi ohjauksen käyttämän tietorakenteen pitäisi sisältää mahdollisuuksien mukaan muutakin kuin numero:

value
timestamp
age
valid / invalid
source

Tällöin optimointi voi tehdä eri päätöksen puuttuvan tiedon perusteella sen sijaan, että vanha arvo jää järjestelmään näyttämään normaalilta.

Tarkkuus, resoluutio ja päivitysväli eivät ole sama asia

Mittauksesta puhuttaessa “tarkkuus” sekoittaa helposti kolme eri ominaisuutta:

• mittaustarkkuus: kuinka lähellä arvo on todellista suuretta
• resoluutio: kuinka pieni muutos mittauksessa voidaan havaita
• päivitysväli: kuinka usein uusi arvo saadaan

Kuormanhallinnassa muutaman prosentin mittavirhe voi olla hyväksyttävä, jos data päivittyy nopeasti ja turvamarginaali on riittävä. Hitaasti päivittyvä erittäin tarkka mittaus voi olla samaan tehtävään huonompi.

Energiakustannusten jälkilaskennassa tilanne voi olla päinvastainen: sekuntitason päivitystä ei tarvita, mutta kertymän pitää olla riittävän tarkka pitkällä aikavälillä.

Mittauksen aikavaatimus tulee ohjattavasta ilmiöstä

“Reaaliaikainen mittaus” ei ole yksi tekninen vaatimus. Sopiva aikaskaala riippuu tehtävästä.

Tehtävä	Tyypillinen datan aikavaatimus
Liittymän nopea kuormanhallinta	Sekunneista kymmeniin sekunteihin järjestelmästä riippuen
Aurinkoylijäämän ohjaus	Usein sekunneista minuutteihin
Sähköauton hintaperusteinen ajoitus	Vartti- tai tuntitason suunnitelma, mutta toteutuksen tilatieto nopeammin
Rakennuksen sisälämpötila	Minuuteista pidempään, koska prosessi muuttuu hitaasti
Kustannus- ja energiaseuranta	Mittausjakson mukainen kertymä riittää

Tarkat arvot riippuvat laitteista ja suojaustavoitteista. Oleellista on, ettei samaa päivitysvaatimusta aseteta mekaanisesti kaikelle datalle.

Mittauspaikka valitaan päätöksen perusteella

Mittarin fyysiselle paikalle ei ole yleistä “paras–hyvä–heikko” -järjestystä. Oikea paikka riippuu siitä, mitä halutaan tietää.

Esimerkiksi:

• Liittymän rajalla mitataan koko talon vaikutus verkkoon ja vaihekohtaiset rajat.
• Invertteriltä saadaan aurinkojärjestelmän oma tuotanto.
• Sähköauton syötöstä voidaan varmistaa todellinen latausteho.
• Lämpöpumpun omasta rajapinnasta voidaan saada prosessitietoa, jota ulkoinen sähkömittari ei näe.

Usein paras tilannekuva syntyy usean lähteen yhdistelmästä eikä yhdestä mahdollisimman “hyvästä” mittarista.

Mittaus tarvitsee myös laadunvalvonnan

Mittausarvo voi olla teknisesti saatavilla ja silti väärä. Anturi voi jumittua samaan arvoon, integraatio voi lakata päivittymästä, yksikkö voi muuttua tai laitteen ohjelmistopäivitys voi muuttaa tietokentän merkitystä.

Siksi datalle kannattaa tehdä ainakin yksinkertaisia tarkistuksia:

• onko arvo päivittynyt odotetussa ajassa
• onko se fysikaalisesti uskottavalla alueella
• muuttuuko se järkevästi suhteessa muihin mittauksiin
• vastaako yksikkö ja etumerkki järjestelmän määritelmää
• onko lähde käytettävissä vai fallback-tilassa

Esimerkiksi invertterin tuotanto, liittymän vienti ja suurten kuormien tehot eivät ole toisistaan riippumattomia. Niiden välisiä ristiriitoja voidaan käyttää mittausvirheiden tai puuttuvan datan havaitsemiseen.

Yksi totuus per suure – tai ainakin selkeä lähdehierarkia

Kun sama tieto on saatavana useasta paikasta, järjestelmään syntyy helposti ristiriitoja. Esimerkiksi sähköauton tila voi tulla valmistajan pilvestä, latauslaitteelta ja erillisestä tehomittarista.

Hyvä arkkitehtuuri määrittää, mikä lähde vastaa mistäkin asiasta. Esimerkiksi:

• auton varaustila: auton oma integraatio, jos tieto on tuore
• latauksen todellinen teho: paikallinen energiamittari
• latauksen sallittu tila: energianhallinnan oma ohjaustila

Jos lähteet ovat eri mieltä, järjestelmän pitäisi tunnistaa ristiriita eikä vain käyttää viimeksi vastaanotettua arvoa.

Feedback sulkee päätöksen takaisin todellisuuteen

Mittaus ei pääty siihen, että optimointi saa lähtötiedot. Ohjauksen jälkeen järjestelmän pitää mahdollisuuksien mukaan tarkistaa, toteutuiko odotettu muutos.

mittaus
→ tilannekuva
→ päätös
→ ohjaus
→ readback / fyysinen vaste
→ uusi tilannekuva

Jos sähköauton lataus sallitaan, odotetaan tehomittauksessa lataustehoa. Jos käyttövedelle annetaan boost-pyyntö, voidaan tarkistaa muuttuiko laitteen tila ja alkoiko lämpötila kehittyä odotettuun suuntaan.

Verifioinnin ei aina tarvitse olla täydellinen. Sen pitää olla riittävä suhteessa siihen, kuinka merkittävä ohjaus on.

Puuttuva mittaus ei aina estä optimointia

Järjestelmän ei tarvitse odottaa täydellistä anturiverkkoa ennen kuin siitä on hyötyä. Joissakin tapauksissa mittaus voidaan korvata turvallisella arviolla tai konservatiivisella fallbackilla.

Olennaista on, ettei arviota esitetä mitattuna totuutena. Jos auton varaustila puuttuu, järjestelmä voi esimerkiksi valita sellaisen oletuksen, joka varmistaa käyttäjän asettaman lataustavoitteen mieluummin liian aikaisin kuin liian myöhään. Jos aurinkoennuste puuttuu, järjestelmä voi jättää osan ennakoivasta ylijäämäohjauksesta tekemättä.

Tämä jatkaa edellisen osan pilvi- ja fallback-ajattelua: järjestelmän pitää tietää paitsi arvo myös sen luotettavuus ja käytettävyys.

Historiadata tekee mittauksesta enemmän kuin hetkellisen sensorin

Reaaliaikainen tilannekuva mahdollistaa ohjauksen. Historiadata puolestaan mahdollistaa järjestelmän parantamisen.

Sen avulla voidaan esimerkiksi:

• arvioida rakennuksen lämpövastetta
• verrata ennustettua ja toteutunutta aurinkotuotantoa
• todentaa, syntyikö ohjauksesta oikeasti säästöä
• havaita hitaasti kehittyviä laite- tai integraatiohäiriöitä
• säätää optimoinnin parametreja todellisen käyttäytymisen perusteella

Mittausarkkitehtuurissa tarvitaan siis sekä riittävän tuore käyttötilanne että luotettava historia. Ne ovat eri datatuotteita, vaikka ne voivat syntyä samasta anturista.

Mittauksen taso asettaa optimoinnin ylärajan

Optimointialgoritmi ei voi päätellä luotettavasti sellaista järjestelmän tilaa, josta sillä ei ole mittausta, toimivaa mallia tai hyväksyttyä arviota.

Toisaalta enemmän mittareita ei automaattisesti tee optimoinnista parempaa. Olennaisempaa on, että järjestelmällä on oikeat tiedot oikealla aikaskaalalla ja että niiden laatu tunnetaan.

Hyvän mittausarkkitehtuurin tavoite ei ole täydellinen näkyvyys, vaan riittävä havaittavuus päätöksentekoa varten.

Seuraavaksi: käyttäjän rooli

Kun järjestelmä pystyy muodostamaan luotettavan tilannekuvan, seuraava kysymys ei ole enää tekninen anturikysymys. Järjestelmän pitää tietää myös, mitä käyttäjä oikeastaan haluaa ja milloin hänen pitää voida ohittaa automatiikka.

Osa 11: Käyttäjä – järjestelmän heikoin lenkki vai tärkein osa? käsittelee tavoitteita, käyttötiloja, manuaaliohjausta ja sitä, kuinka paljon käyttäjän pitäisi joutua osallistumaan päivittäiseen optimointiin.

Optimoinnin arkkitehtuuri -sarjan pääsivulta löydät kaikki sarjan osat.