RAKENNUSSÄÄTÖJÄRJESTELMIEN HISTORIAA

Säätöjärjestelmien rakentaminen kiinteistönohjaukseen on mielenkiintoista puuhaa, sillä säätöjärjestelmät ovat kiintoisa sekoitus elektroniikkaa, ohjelmistotekniikkaa ja säätötekniikkaa. Järjestelmien toteutuksessa eri vuosikymmenillä näkyy mainiosti puolijohde- ja ohjelmistotekniikan kehittyminen.

Ensimmäinen toteutettu säätöjärjestelmä 1980-luvulla oli ohjelmistoteknisesti yksinkertainen ja käsitti useita mikropiirejä alhaisen integraatioasteen johdosta. Seuraavan sukupolven järjestelmä 1990-luvulla oli jo korkean tason ohjelmointikielellä ohjelmoitavissa, ja se oli verkotettavissa paikallisesti. Erillisten mikropiirien määrä oli pudonnut puoleen. Kolmas järjestelmä 2000-luvulla on jo monipuolisen olioperustaisen ohjelmointiarkkitehtuurin tukema. Lisäksi se on verkottunut standardeilla protokollilla Internetiin, ja näin ollen kaikkialta käytettävissä. Mikropiirien määrä ei enää vähentynyt sillä uusia ominaisuuksia, esim. useita standardeja väyläliityntöjä (Ethernet, 1-Wire, I2C, CAN, RS-232) tuli paljon lisää.

Juuso

Ensimmäinen 1980-luvulla toteutettu rakennuksen säätöjärjestelmä oli Juuso. Juuso ohjasi aluksi vain valaistusta ja se perustui 1976 esiteltyyn Zilogin Z80A -mikroprosessoriin. Puolijohdeteknologiana oli NMOS, ja virrankulutus siksi suurehko, 5W. Muistia valaistuksenohjausjärjestelmässä oli 4 KB EPROM ja 2 KB RAM. Fyysisesti järjestelmä mahtui yhdelle Euro-kortille ja se toteutettiin ns. räppäämällä. Järjestelmää ohjelmoitiin assembler-kielellä, ja siihen toteutettiin oma moniajokäyttöjärjestelmä Multinel. Sähkötehojen ohjaus tehtiin releiden avulla joita ohjattiin transistoriasteen kautta. Puolijohdereleet olivat kalliita ja niiden vuotovirta suuri, siksi ohjaukseen valittiin perinteiset releet. Sähköjännitteen tunnistus tehtiin kapasitiivisesti kytketyn optoisolaattorin avulla. Omilla korteillaan olevat optoisolaattorit ja releohjaimet oli kytketty järjestelmän sisäisen, oman 8-bittisen rinnakkaisväylän avulla rinnakkaisliityntäpiiriin Z80A PIO.

Ohjelmointityö tehtiin PC:ssä toimivalla makroassemblerilla ja käännöksen tulos ohjelmointiin erillisellä ohjelmointilaitteella EPROM-piiriin. Yksi ohjelmiston muutos ja koodin latausjakso kohdelaitteistoon vei aikaa n. 10 minuuttia. Tämä opetti tarkaksi ohjelmointityössä. Parin vuoden jälkeen järjestelmään lisättiin Z80A DART -piiri jolloin järjestelmään tuli asynkroninen sarjaliikenne. Liityntä oli oma virtasilmukkatoteutus jotta järjestelmä toimisi luotettavasti useiden kymmenien metrien etäisyyksillä. Tämän liitynnän avulla saatiin järjestelmä kytkettyä asynkronisella sarjaliikenteellä senaikaiseen PC:hen johon toteutettiin MS Windows-pohjainen valaistuksen ohjauskäyttöliittymä.

Ulkomaailmaa havaitsevia antureita Juusoon ei saatu kuin yksi, ulkotilan valonvoimakkuutta mittaava anturi. Analogisten anturien signaalinkäsittely ja muuntaminen digitaalimuotoon oli tämän ajan teknologialla senverta monimutkaista ja kallista että tällaiseen edulliseen järjestelmään niitä ei saatu sisällytettyä. Valonvoimakkuuden anturi oli yksinkertainen, LDR-vastus määritti astabiilin multivibraattorin värähtelytaajuuden, jota Z80A CTC-ajastinpiiri mittasi. Näin valaistuksen määrä saatiin hämäräkytkintoimintoa varten riittävällä tarkkuudella mitattua.

Juuson laajennus

Seuraavaksi haluttiin ohjata kiinteistön lämmitystä. Z80-pohjainen järjestelmä oli kuitenkin kankea ohjelmoida koska ohjelmointikieli oli alkeellinen. Lisäksi ohjelmat sijaitsivat EPROM-muistilla jolloin ohjelman lataaminen oli hidasta. Puolijohdeteknologia oli kuitenkin edistynyt 1980-luvulta, FLASH-muistit olivat tulleet markkinoille. Lisäksi tehokkaampia ja integrointiasteeltaan kehittyneempiä prosessoreita oli tullut saataville. Alkuperäinen järjestelmä oli kuitenkin hyvin toimiva, ja siihen liitetyt releohjaus ja jännitetulot olivat hyviä. Siksi päätettiin toteuttaa lähiverkko johon olisi liitetty vanha Z80-pohjainen järjestelmä, uusi järjestelmä sekä ohjaus-PC. Lähiverkko toteutettiin olemassa olevan virtasilmukkaliitynnän pohjalta. Siihen lisättiin optoisolaattorit galvaanisen erotuksen vuoksi häiriöiden minimoimiseksi sekä mahdollisuus useamman väylälähettimen rinnakkaiseen kytkentään. Tähän väylään toteutettiin oma verkkoprotokolla, JuusoNET. Verkon nopeudeksi asetettiin vaatimaton, mutta tarkoitukseen täysin riittävä 1200 bit/s.

Juuson laajennus 1990-luvulla toteutettiin 1985 esiteltyyn Freescalen (silloin Motorola) 68HC11 prosessorin ympärille. Integraatioaste oli kasvanut kymmenessä vuodessa senverran, että kaikki tarvittavat oheispiirit (PIO, CTC, DART) oli nyt integroitu prosessorin kanssa samalle piirille. Muistipiirien koot olivat myös kasvaneet voimakkaasti, muistia oli helposti toteutettavissa (= yhdellä fyysisellä piirillä) 32 KB FLASH EPROM ja 32 KB RAM. Puolijohdeteknologiana oli jo CMOS, jolloin tehonkulutus oli pienempi, n. 2 W. Fyysisesti järjestelmä mahtui puolikkaalle Euro-kortille. Järjestelmää ohjelmoitiin C-kielellä ja Multinel-käyttöjärjestelmä siirrettiin myös tähän ympäristöön. Suorituskyvyn vuoksi Multinel jouduttiin vielä toteuttamaan assembler-kielellä. Liitäntä rakennuksen sähköverkkoon tehtiin vanhan järjestelmän kautta, olivathan molemmat järjestelmät nyt kytketty JuusoNETiin. Ohjelmisto yritettiin toteuttaa oliopohjaisesti. Ohjelmisto oli jaettu pieniin osamoduloihin jotka kommunikoivat toistensa kanssa lähettämällä viestejä. Viestien välitys toimi myös väylän yli, joten toisessa prosessorissa oleva ohjelmamoduli kykeni lähettämään viestin toiselle modulille tietämättä lainkaan missä fyysisessä prosessorissa viestin vastaanottava moduli sijaitsi. Ensimmäisiä yrityksiä hajautuksen hallintaan.

Lämpötilan mittaukset toteutettiin PT100-antureilla niiden hyvän stabiilisuuden vuoksi. Toteutusajankohtana oli myös saatavilla puolijohdeantureita, mutta niiden stabiilisuus vielä arvelutti. Operaatiovahvistintekniikka oli kehittynyt valtavasti, joten PT100-antureiden signaalit vahvistettiin yksinkertaisella operaatiovahvistinkytkennällä ja tämä käsitelty signaali johdettiin 68HC11-prosessorin 10-bittiseen A/D-muuntimeen.

Saara

2000-luvulla syntyi tarve taas uuden järjestelmän luomiseksi; tällä kertaa kesämökkikiinteistön kaukovalvontaan. Tärkeimmäksi vaatimukseksi tuli ajan hengen mukaisesti Internetin kautta käytettävyys ja Web-käyttöliittymä. Aluksi tutkittiin Italialaisen Elsistin Netmaster modulia. Tämä olisi täysin valmis teollisuusautomaatiossa käytetty yksikkö, Ethernet-liityntä ja Java-ohjelmoitavuus valmiina. Järjestelmän valmius houkutteli, mutta ongelmaksi katsottiin modulin I/O-liityntöjen soveltumattomuus suoraan 240 VAC jännitteiden käsittelyyn. Tulot kestivät vain 30V ja lähtöjen virrankesto on alle 10A jolloin eniten käytettyjen 10A sulakkeiden takana olevia sähkökäyttöjä ei voida suoraan ohjata. Seuraavaksi tarkasteltiin amerikkalaisen Rabbit Semiconductorin RabbitFLEX kehityskittiä jossa olisi Ethernet-liityntä ja 1-Wire liitynnät vakiona. 1-Wire -liitynnän kautta voidaan suoraan ohjata relekortteja ja optoisolaattorikortteja jolloin 240 VAC jännitteiden käsittely olisi helppoa. Rabbit-prosessoreita ohjelmoidaan omalla C-kielen variantilla. Toteutukset ovat tehokkaita, mutta ohjelmistokoodin yleispätevyys epäilytti. Kuinka helposti olemassa olevia C-kielisiä ohjelmanpätkiä olisi sovitettavissa Rabbitille? Ja kuinkahan taattua on järjestelmän kehitys on kun ollaan sidottuja yhteen valmistajaan? Siksi haluttiin yleispätevämpää ratkaisua.

Lisätutkimusten jälkeen Systronixin TINI-moduli tuntui hyvältä vaihtoehdolta. Moduli on 72-pinnisessä SIMM-formaatissa jossa on prosessori ja suurin osa tarvittavista liitäntäpiireistä muisteineen. Useampi valmistaja tekee TINI-yhteensopivia moduleja ja niitä kaikkia ohjelmoidaan Java-kielellä. Java-kieli on moderni olioperustainen kieli, ja valmiita luokkakirjastoja Javalla toteutettuna on valtavasti tarjolla. Lisäksi ohjelmien siirrettävyys on hyvä Java-kielen standardoinnin johdosta. Perinteisen TINI-modulin huono puoli on heikko suorituskyky koska Javan tavukoodia ajetaan Intelin 8051-pohjaisella prosessorilla. Siksi ruotsalaisen Imsysin vuonna 2003 kehittämä TINI-yhteensopiva SNAP-moduli tuntui vielä paremmalta ratkaisulta. Se on yhteensopiva alkuperäisen TINI-modulin kanssa, mutta siinä Imsysin itse kehittelemä prosessori ajaa Java-tavukoodia pääosin suoraan, jolloin suorituskyky on 10-20 kertainen alkuperäiseen TINI-moduliin verrattuna.

Anturointitekniikka on edelliseen järjestelmään verrattuna kokenut valtavan muutoksen. Antureiden integrointiaste on kohonnut riittävästi jotta analogisia suureita (lämpötila, paine, kosteus) mittaavat anturit voidaan kytkeä suoraan digitaaliseen 1-Wire väylään. Lisäksi antureiden valmistuksen yhteydessä tapahtuvan kalibroinnin ansiosta antureiden tarkkuudet ovat 0,5°C rajoissa. Analogiaelektroniikan suunnittelua ei enää juurikaan tarvita säätöjärjestelmiä toteutettaessa.

HAVAITUT KEHITYSTRENDIT

Suunnittelutyö on kallista ja ainakin länsimaissa edelleen kallistumaan päin. Siksi suunnittelun osuutta kokonaiskustannuksissa pyritään jatkuvasti minimoimaan. Parhaiten tämä onnistuu käyttämällä valmiita standardiratkaisuja. Standardit ratkaisut ovat kuitenkin aina toteutukseltaan yksilöllisiä ratkaisuja monimutkaisempia koska niiden täytyy olla sopeutuvaisia erilaisiin sovelluskohteisiin. Siksi standardoidut ratkaisut ovat järkeviä vasta kun puolijohdetekniikka on kehittynyt riittävästi jotta standardiratkaisun yleiskäyttöoisyydestä johtuva sisäinen tehottomuus ei ole enää niin suuri haitta. Esimerkiksi 1980-luvun ja 1990-luvun järjestelmissä standardiratkaisut käsittivät vain prosessorin ja muistit. 2000-luvun järjestelmä on rakennettu lähes yksinomaan standardiratkaisujen päälle. Standardiratkaisuja käyttäen sovelluksen teko on erittäin nopeaa, mutta toisaalta kokonaisresurssien suhteen ei välttämättä optimaalinen. Yleiskäyttöisyyden vuoksi komponentteihin laitettuja kaikkia ominaisuuksia kun harvoin tulee tietyssä sovellutuksessa täysimääräisesti käytettyä.

Vaikka standardiratkaisujen käyttö onkin tehostanut kehitystyötä, aikaa uuden järjestelmän kehittämiseen on yllättäen mennyt suunnilleen saman verran kuin aikaisempienkin järjestelmien. Standardiratkaisujen käytöstä säästynyt aika on mennyt lähes täysin kehittyneempien käyttöliittymien tekoon. Web-selaimella käytettävissä olevan järjestelmän suunnittelu on ollut yllättävän työlästä. Graafisen ulkoasun suunnittelu ja toteutus ovat sellaisia tekijöitä joita ei aikaisemmissa järjestelmissä ollut lainkaan. Lisäksi Internetin kautta tapahtuva etäkäyttö asettaa aivan uudenlaisia vaatimuksia tietoturvalle. Luultavasti tämä kehitystrendi tulee jatkumaan; perinteisen teknisen suunnittelun osuus vähenee, käyttöliitymien ja graafisten ulkoasujen suunnitteluun kuluva aika kasvaa.

© 2006-2009 Jarkko Vuori

Powered by Tynamo™