Sulautettu ohjelmointi

Sulautettu ohjelmointi 1 "Esipainos" Hannu-Matti Järvinen Tommi Mikkonen Tampere 2010

2 Sulautettu ohjelmointi 1. Sulautetut järjestelmät... 11 1.1 Johdanto... 11 1.2 Sulautettujen järjestelmien ominaispiirteitä...14 1.3 Sulautettujen ohjelmistojen erityispiirteitä...16 1.4 Kokonaisjärjestelmän määrittely...17 1.4.1 Suunnittelun jakaminen osiin...18 1.4.2 Ohjelmiston ja laitteiston rajapinta...19 1.4.3 Ohjelmiston ja laitteiston yhteissuunnittelu...21 1.5 Eri alojen edustajien roolit...22 1.5.1 LVI-asiantuntijan näkökulma...23 1.5.2 Automaation asiantuntijan näkökulma...24 1.5.3 Tietokoneasiantuntija...24 1.5.4 Ohjelmistoasiantuntija...25 1.5.5 Suunnittelutyön eteneminen...26 1.5.6 Lisähuomioita...27 1.6 Sulautetut järjestelmät ja sulautettu ohjelmointi...28 1.7 Yhteenveto...28 2. Laitteistorajapinta...30 2.1 Tyypillinen sulautetun järjestelmän suoritin...30 2.2 Yleinen koneiden arkkitehtuuri...31 2.3 Suorittimen tilat ja rekisterit...33 2.4 Keskeytysjärjestelmä...34 2.4.1 Keskeytyksistä yleensä...34 2.4.2 Ulkoiset keskeytykset...35 2.4.3 Toiminta keskeytyksen tullessa...36 2.4.4 Keskeytyksen havaitseminen...36 2.4.5 Keskeytyksen palveleminen...37 2.4.6 Esimerkkejä keskeytysjärjestelmistä...40 2.4.7 Suorittimen alustus...41 2.5 Oheislaiteliittymät...42 2.5.1 Oheislaitteiden ohjaamisesta...43 2.5.2 Suora muistisiirto...44 2.6 Yksinkertaisia oheislaitepiirejä...45 2.6.1 Rinnakkaisliityntä...45 2.6.2 Sarjaliityntäpiirit...46 2.6.3 Ajastinpiirit...47

3 2.6.4 A/D-muunnin... 47 2.6.5 D/A-muunnin... 47 2.6.6 Muutamia yleisiä huomioita... 48 2.7 Laitteistorajapinta abstraktiona... 49 2.8 Yhteenveto... 49 3. Muistin hallinta... 51 3.1 Erityyppiset muistit... 51 3.1.1 Luku kirjoitusmuistit... 51 3.1.2 Lukumuistit... 52 3.1.3 Haihtumattomat muistit... 53 3.2 Flash-muistin käytöstä... 54 3.2.1 Kirjoituskertojen rajoitukset... 55 3.2.2 Muistitiedon päivittämisestä... 55 3.2.3 Päivitysesimerkki... 57 3.3 Ohjelman sijoittelu muistiin... 58 3.4 Ohjelman sisäinen muistinhallinta... 59 3.4.1 Staattisesti varattu muuttuja... 59 3.4.2 Dynaamisesti varattu muuttuja pinossa... 60 3.4.3 Dynaamisesti varattu muuttuja keossa... 61 3.5 Dynaamisen muistin hallinta osana ohjelmistosuunnittelua... 62 3.5.1 Joitakin tyypillisiä haasteita... 62 3.5.2 Vain varauksia -vaihtoehto... 63 3.5.3 Sekä varauksia että vapautuksia... 64 3.5.4 Muistinhallinnan algoritmeista... 65 3.5.5 Dynaaminen muisti monelle prosessille... 65 3.5.6 Roskaantuminen... 66 3.5.7 Ohjelmointikielistä dynaamisen muistin kannalta... 67 3.6 Muistinhallintayksikkö ja välimuisti... 68 3.6.1 Muistinhallintayksikkö... 68 3.6.2 Välimuisti... 71 3.7 Yhteenveto... 73 4. Prosessit ja säikeet... 74 4.1 Prosessit... 74 4.1.1 Prosessien tilamalli... 74 4.1.2 Lisätiloja... 75 4.1.3 Säikeet... 76

4 Sulautettu ohjelmointi 4.2 Keskeytykset...78 4.2.1 Keskeytyskäsittelyn aloitus ja lopetus...78 4.2.2 Käyttöjärjestelmäkutsut...80 4.3 Prosessien hallinnasta...80 4.3.1 Prosessielementti...81 4.2.4 Prosessin luominen...82 4.2.5 Prosessin päättäminen...84 4.2.6 Ohjelmallisesti aiheutetut keskeytykset...85 4.7 Suunnittelunäkökohtia...86 4.8 Yhteenveto...87 5. Rinnakkaisuus ja jako prosesseihin...89 5.1 Johdanto...89 5.2 Perusongelmat...90 5.2.1 Kriittinen alue...90 5.2.2 Poissulkeminen...91 5.2.3 Synkronointi...91 5.2.4 Poissulkemisen ja synkronoinnin vähentäminen...92 5.2.5 Lukkiutuminen ja nälkiintyminen...93 5.2.6 Testaamisesta...93 5.3 Aktiivisen lukituksen toteutus...94 5.4 Jako prosesseihin...95 5.4.1 Toiminnallinen jako...96 5.4.2 Skedulointiin perustuva jako...97 5.4.3 Rakenteeseen perustuva jako...97 5.4.4 Rinnakkaistaminen...98 5.4.5 Yhteenveto...98 5.5 Yhteenveto...99 6. Skedulointi eli vuoronnus...100 6.1 Lyhyesti reaaliajasta...100 6.1.1 Pehmeät ja kovat reaaliaikajärjestelmät...101 6.1.2 Reaaliaikaohjelmien tyypillisiä piirteitä...101 6.1.3 Milloin järjestelmä on reaaliaikainen?...102 6.2 Irrottamaton ja irrottava skedulointi...102 6.3 Skedulointimenetelmiä...103 6.3.1 FIFO eli jono...104 6.3.2 Kiertovuorottelu...105

5 6.3.3 Kiinteä prioriteetti... 106 6.3.4 Vaihteleva prioriteetti... 108 6.3.5 Lyhin ajoaika ensin... 109 6.3.6 Aikaisin määräaika ensin... 110 6.3.7 Skedulointialgoritmien vertailua...111 6.4 Reaaliaikajärjestelmien skedulointi...111 6.4.1 Käänteisprioriteettiongelma... 112 6.4.2 Kerran tehtävät ja toistuvat työt... 113 6.4.3 Jitter... 114 6.4.4 Staattinen skedulointi... 114 6.4.5 Dynaaminen skedulointi... 115 6.5 Skedulointiesimerkki... 116 6.6 Skeduloituvuuden analysoinnista... 117 6.6.1 Staattinen skeduloituvuus... 117 6.6.2 Dynaaminen skeduloituvuus... 118 6.7 Yhteenveto... 119 7. Ytimet... 121 7.1 Ytimen roolista... 121 7.2 Perusydintyypit... 122 7.2.1 Pollaavat ytimet... 123 7.2.2 Keskeytysohjatut ytimet... 125 7.2.3 Prosessiytimet... 127 7.2.4 Yhteenveto perusytimistä... 129 7.3 Valmiina saatavat ytimet... 130 7.3.1 Skaalattavuus... 131 7.3.2 Laitteistovalikoima... 131 7.3.3 Kommunikointi- ja poissulkemismenetelmät... 132 7.3.4 Kehitysympäristö... 132 7.3.5 Kustannukset... 133 7.4 Esimerkki: Linux-ydin... 134 7.5 Yhteenveto... 136 8. Laitteiston ohjaaminen... 137 8.1 Säätämisestä yleensä... 137 8.2 Joitakin säätäjiä... 139 8.2.1 Paikkasäätäjä (P-säätäjä)... 139 8.2.2 Integroiva säätäjä (I-säätäjä)... 140

6 Sulautettu ohjelmointi 8.2.3 Derivoiva säätäjä (D-säätäjä)...141 8.2.4 PI-säätäjä...142 8.2.5 PD-säätäjä...143 8.2.6 PID-säätäjä...143 8.2.7 Mikä säätäjä minnekin?...145 8.2.8 Säätäjän virittämisestä...145 8.2.9 Monimutkaisempia säätöjä...146 8.3 Mittaamisesta...146 8.4 Yhteenveto...147 9. Ohjelmistotyö...148 9.1 Johdanto...148 9.2 Ristikehitys...149 9.3 Testaus ja virheiden jäljitys yleensä...150 9.3.1 Virheen paikantaminen...151 9.3.2 Pöytätestaus...152 9.3.3 Testipedit...153 9.3.4 Profilointi...153 9.4 Testaus ja jäljitys kehitysympäristössä...154 9.4.1 Testaaminen ja jäljitys kehitysympäristön työkaluilla 154 9.4.2 Järjestelmän simulointi...155 9.4.3 Virtualisointi...155 9.5 Testaus ja jäljitys kohdejärjestelmässä...156 9.5.1 Johdanto...156 9.5.2 Logiikka-analysaattori...157 9.5.3 Emulointi...157 9.5.4 Erillinen testijärjestelmä...158 9.5.5 Tiedon siirto toiselle koneelle analysoitavaksi...159 9.6 Laitteiston testaus...159 9.6.1 Muistien testaaminen...160 9.6.2 Oheislaitteiden testaus...161 9.7 Iteratiivisuudesta kehitystyössä...161 9.8 Yhteenveto...163 10. Kohti suurempia sulautettuja ohjelmistoja...164 10.1 Ohjelmistopino...164 10.2 Ohjelmistojen siirrettävyydestä...166 10.2.1 Ehdollinen käännös...166

7 10.2.2 Ohjelmamakrot... 167 10.2.3 Moduulinen erillinen toteutus... 168 10.2.4 Siirrettävyysongelmia... 169 10.3 Vuotavat abstraktiot... 169 10.4 Joitakin sulautetun järjestelmän suunnitteluratkaisuja... 173 10.4.1 Kerrostaminen ja laitteiden kätkentä... 173 10.4.2 Väyläabstraktio... 174 10.4.3 Käynnistysrutiinit... 175 10.4.4 Vianjäljitysmoodi ja lokien keruu... 176 10.4.5 Muisti- ja ajoitusbudjetti... 176 10.5 Formaali vai epäformaali menetelmä?... 177 10.6 Yhteenveto... 179 11. Vikasietoisuus... 180 11.1 Vikasietoisuuden käsitteitä... 180 11.1.1 Ei vikasietoisuutta... 181 11.1.2 Ei-peittävä vikasietoisuus... 181 11.1.3 Vikaturvallinen järjestelmä... 182 11.1.4 Peittävästi vikasietoinen järjestelmä... 183 11.2 Turvallisuuskäsite... 183 11.3 Vikasietoisuuden saavuttaminen... 184 11.3.1 Datan redundanssi... 184 11.3.2 Ohjelmakoodin redundanssi... 185 11.3.3 Vikojen havaitsemista... 187 11.4 Ohjelmisto- ja laitteistovikasietoisuuden eroista... 188 11.4.1 Laitteistoviat... 188 11.4.2 Ohjelmistoviat... 189 11.4.3 Ohjelmiston sisäisestä vikasietoisuudesta... 191 11.5 Vika-analyysistä... 192 11.6 Esimerkkejä vikasietoisista järjestelmistä... 193 11.7 Vikasietoisuuden luokittelua... 194 11.7.1 Taso 1, normaalin toiminnan virhetilanteet... 195 11.7.2 Taso 2, vikaturvallinen toipuminen... 195 11.7.3 Taso 3, ei-peittävä itsestabiloituva vikasietoisuus... 196 11.7.4 Taso 4, peittävä vikasietoisuus... 197 11.7.5 Taso 5, korjaus konetta sammuttamatta... 198 11.7.6 Taso 6, Kaikkien laitteiden varmistus... 198 11.7.7 Taso 7, Koneiden monistaminen... 199

8 Sulautettu ohjelmointi 11.8 Käynnistys ja uudellenkäynnistys...199 11.9 Ohjelmistotyö ja ylläpito ohjelman suorituksen aikana...201 11.10 Yhteenveto...201 12. Esimerkki: Mikrohiiri...203 12.1 Laitteen suunnittelua...203 12.1.1 Mekaniikka: montako pyörää?...204 12.1.2 Suoritin...205 12.1.3 Muisti...206 12.2 Ohjelmiston rakenne...207 12.2.1 Testaus...207 12.2.2 Prosessijako...207 12.2.3 Skedulointi...208 12.2.4 Käyttöjärjestelmän ydin ja keskeytyskäsittely...209 12.3 Säädön periaatteet...209 12.4 Yhteenveto...210 13. Esimerkki: Symbian-ympäristö...212 13.1 Yleiskuvaus...212 13.2 Käyttöjärjestelmän ydin...213 13.3 Resurssien hallinta...214 13.3.1 Palvelimet resurssien kätkijöinä...214 13.3.2 Joitakin palvelimia...216 13.4 Aktiiviset oliot...218 13.5 Dynaamisen muistin hallinta Symbian-ympäristössä...219 13.5.1 Tyyppijärjestelmä ja nimeämiskäytännöt...219 13.5.2 Poikkeukset...221 13.5.3 Muistinvaraukset ja poikkeukset...221 13.5.4 Kaksivaiherakentaminen...223 13.6 Laajennukset...223 13.6.1 Symbian C++-sovelluskehitys...224 13.6.2 Java...224 13.6.3 Python...225 13.6.4 Web Runtime...226 13.6.5 OPL...226 13.7 Lopuksi...227 13.8 Yhteenveto...227 14. Kohti hajautettuja sulautettuja järjestelmiä...229

14.1 Johdanto... 229 14.2 Hajautettujen järjestelmien väyliä... 230 14.2.1 CAN-väylä... 231 14.2.2 CANopen... 233 14.2.3 LON-väylä... 234 14.3 Pienen sulautetun laitteen sisäinen hajautus... 235 14.3.1 OpenCL... 236 14.3.2 Network on Terminal Architecture... 237 14.4 Yhteenveto... 239 9

10 Sulautettu ohjelmointi

Sulautetut järjestelmät 11 1. Sulautetut järjestelmät Sulautettu järjestelmä on alunperin ohjelmistotyössä käytetty termi. Vastaavia muiden alojen termejä, jotka tarkoittavat lähes samaa asiaa, on eri aloilla käytössä useita, kuten esimerkiksi mekatroniikka, joka korostaa mekaniikan ja elektroniikan yhdistämistä. Nykykäytössä sulautettu järjestelmä viittaa useimmiten sellaiseen järjestelmään, jossa tietokoneen laitteisto ja ohjelmisto liittyvät toisiinsa saumattomasti siten, että kumpikaan ei ole käyttökelpoinen ilman toista, vaikka kumpikin saattavat hyödyntää yleiskäyttöisiä komponentteja, kuten vakiolisälaitteita, prosessoreita, käyttöjärjestelmiä tai ohjelmistokirjastoja. Toisaalta mikään ei välttämättä kerro käyttäjälle, mitä on toteutettu ohjelmistolla ja mitä laitteistolla, ja itse asiassa voi joskus olla jopa niin, että saman laitteen eri versioiden välillä eri osien välinen työnjako vaihtelee. Vastaavasti sulautetun järjestelmän kuvauksessa laitteisto käsittää laitteiston kokonaan, ei vain sen tietoteknistä osaa. 1.1 Johdanto Sulautetut järjestelmät sijoittuvat teknisten alojen kannalta monen alan rajamaille. Toisaalta niille ovat ominaisia tietyt ohjelmistojen erityispiirteet, toisaalta tietokonelaitteistojen piirteet. Usein sulautettu järjestelmä sisältää myös automaatiotekniikkaa esimerkiksi mekaanisen liikkeen tai kemiallisen prosessin ohjaamiseksi. Automaatio puolestaan vaatii lähes aina mittausta ja säätöä, mikä johtaa myös mittaussignaaleiden käsittelyyn ja säätötekniikan perusteisiin. Sulautetut järjestelmät ovat siis monen alan yhtymäkohdassa, ja sulautetun toteutuksen tekemiseen tarvitaan monen alan asiantuntijoita. Heistä jokaisella on oma näkemyksensä siitä, mitä sulautettu järjestelmä itse asiassa tarkoittaa jokainen tyypillisesti näkee ongelmakentän oman alansa projektion kautta.

12 Sulautettu ohjelmointi Tässä teoksessa sulautettuja järjestelmiä tarkastellaan lähinnä ohjelmistotekniikan näkökulmasta. Mukana on kuitenkin ripaus tietokoneiden laitteistoja ja säätöä. Ohjelmistotekniikan osalta sulautettujen järjestelmien ongelmakenttiä ovat muun muassa ohjelmistotuotanto käytettävyys ja käyttöliittymät laitteistonläheinen ohjelmointi reaaliaikaiset järjestelmät reaktiiviset järjestelmät vikasietoisuus ja hajautetut järjestelmät. Ohjelmistotuotanto käsittelee projektin läpivientiä, suunnittelumenetelmiä ja dokumentointia. Erityisesti käyttöliittymien ja käytettävyyden osuus laitteen onnistuneisuuteen on viime aikoina kasvanut, kun käyttäjäkunta on laajentunut entisestään tekniikan alan ihmisten ulkopuolelle. Laitteistonläheinen ohjelmointi tarkoittaa laitteistojen ohjaamista ohjelmallisesti, osittain symbolista konekieltä (assemblykieltä) käyttäen ja puristaen suorittimesta irti kaiken mahdollisen suorituskyvyn. Reaaliaikaisuus tarkoittaa järjestelmän ajoitusominaisuuksien ennustettavuutta ja annettujen aikavaatimusten täyttämistä. Reaktiivisuus puolestaan tarkoittaa sitä, että järjestelmä reagoi kaikkiin tapahtumiin riippumatta siitä, mitä muita tapahtumia on jo käsiteltävänä. Vikasietoisuus viittaa siihen, että sulautetut järjestelmät toimivat usein ilman ihmisen välitöntä ohjausta. Vian tullessa järjestelmän tulee selvitä siitä itse ainakin niin pitkälle, että vika ei aiheuta lisää vikoja. Lisäksi sulautetut laitteet voivat sisäisesti koostua hyvin monimutkaisesta kokonaisuudesta, jossa käytetään useita prosessoreita. Varsinkin viime aikoina kehitys on vienyt kohti hajautettuja laitearkkitehtuureja. Näihin taas liittyvät erilaiset middleware-tekniikat, jotka mahdollistavat helpomman hajautuksen toteutuksen. Tässä teoksessa sivutaan ohjelmistotuotantoa alussa. Käytettävyyden ja käyttöliittymien ongelmakenttää sivutaan vain satunnaisesti sen keskeisyydestä huolimatta, sillä monessa mielessä valintoja ohjaavat muuhun kuin käytettävissä olevaan teknologiaan liittyvät seikat. Laitteistonläheisestä ohjelmoinnista käsitellään oheislaitteiden liittämistä järjestelmään, mutta itse symbolinen konekieli oletetaan jo tunnetuksi. Myös joitakin käyttöjärjestelmiiin liittyviä yksityiskohtia käsitellään. Reaaliaikaisuudesta käsitellään perusteet ja skedulointi. Näiden lisäksi käsitellään myös vikasietoisuuden hallintaa. Lopuksi sivutaan lyhyesti hajautettuja sulautettuja järjestelmiä. Mukana on myös

Sulautetut järjestelmät 13 joitakin esimerkkijärjestelmiä, joiden tarkoituksena on havainnollistaa sulautetun ohjelmoinnin ongelmien ratkaisua käytännössä. Ohjelmistotekninen pääongelma vaihtuu järjestelmän koon mukaan. Kaikista pienimmissä järjestelmissä pääongelmat ovat laitteistonläheisessä ohjelmoinnissa. Näissä järjestelmissä on käytössä hyvin vaatimaton suoritin, jonka nopeudessa ja käytettävissä olevan muistin määrässä olisi paljonkin toivomisen varaa. Näin ongelmaksi tulee tarvittavien ohjelmien sovittaminen tarjolla olevaan tilaan ja ohjelmien nopeuttaminen vastaamaan tarvetta. Yleensä tällaisessa pienessä järjestelmässä on kuitenkin vain vähän toimintoja, joten järjestelmän reaktiivisuus on yksinkertaista ja reaaliaikaisuus helppo todeta. Järjestelmän koon kasvaessa reaaliaikaominaisuuksien ratkaiseminen käy vaikeammaksi, koska seurattavia tapahtumia on paljon. Jos järjestelmä on lisäksi reaktiivinen, niin kuin se yleensä on, tulee ajoituksien laskennasta hyvin haastava toimenpide. Järjestelmän kasvaessa lisää alkavat ohjelmistotuotannon ongelmat nousta esille. Kuvaavaa onkin erään teollisuuden johtohenkilön kommentti, että heidän sulautettujen järjestelmiensä ongelma on se, että ne eivät ole sulautettuja järjestelmiä. Tässä vaiheessa järjestelmä on kasvanut jo niin suureksi, että vain pieni osa sen tekijöistä kokee sen varsinaisena sulautettuna ympäristönä, varsinkin, kun ohjaava laite voi olla suorituskyvyltään ja muilta ominaisuuksiltaan pöytäkonetta muistuttava teollisuus-pc. Käyttöliittymien ja yleensä käytettävyyden ja käyttökokemuksen merkitys on kasvamassa sitä suuremmaksi, mitä suurempi joukko käyttäjistä ei ole tekniikan ammattilaisia. Käyttöliittymä niin kuin itse asiassa sulautettujen järjestelmien tapauksessa usein koko laite on suunniteltava sovellusalueen ehdoilla sille tutuilla toimintatavoilla. Ammattikäyttöön sovelluksia ja laitteita suunnitellessa voidaan myös ajatella koulutusta uusien järjestelmien käyttöönoton yhteydessä, mutta massamarkkinoille suunnattuja järjestelmiä suunniteltaessa ollaan usein todella vaikeiden suunnitteluratkaisujen edessä, varsinkin kun tällöin käyttäjäkunta saattaa olla hyvin heterogeeninen. Lisäksi on huomattava, että sovellusalueen tunteminen on ohjelmoijallekin hyvin tärkeää. Ratkaistavat asiat eivät aina ole kovin suoraviivaisia, eivätkä alan omat asiantuntijat välttämättä tiedä, mikä on ohjelmistoteknisesti tai algoritmisesti mahdollista ja mikä ei.

14 Sulautettu ohjelmointi 1.2 Sulautettujen järjestelmien ominaispiirteitä Kuten edellä jo todettiin, sulautettujen järjestelmien koko vaihtelee hyvin pienistä erittäin suuriin. Ehkä selkeimmin tunnistettavia sulautettuja järjestelmiä ovat pienimmät järjestelmät, kuten esimerkiksi älykkäät anturit, automaattikamerat, videolaitteet ja matkapuhelimet, jotka kuitenkin ovat monimutkaisuudessaan aikamoisia ohjelmistoteknisen osaamisen taidonnäytteitä. Matkapuhelinten "älysarjassa" sulautettu luonne alkaakin jo hämärtyä. Laite, jonka perustarkoitus ja koko viittaa hyvinkin kauas tietotekniikasta voi olla hankala yhdistää sulautetuksi laitteeksi. Tällaisia ovat esimerkiksi ovat pesukoneet ja hissit, sekä erilaiset työkoneet kuten kallioporakone, konttilukki tai veturi. Monimukaisimmasta päästä sulautettuja järjestelmiä ovat esimerkiksi lentokoneet ja monet avaruustekniikan laitteet kuten satelliitit ja luotaimet. Sulautetuissa järjestelmissä tietokone on käyttäjän kannalta tavallisesti sivuosassa. Käyttäjän ei tarvitse tietää tietokoneen olemassaolosta ja voisi jopa kärjistäen sanoa, että jos käyttäjän on se tiedettävä, on järjestelmä suunniteltu väärin. Käyttäjän kannalta on tärkeää, että itse perustoiminta, jota varten laite on tehty, toimii odotetusti: hissi siirtyy siihen kerrokseen, mihin käyttäjä sen halusikin. Tietenkin on olemassa sulautettuja sovelluksia, jossa tietokoneen mukanaolo on vähintäänkin ilmeistä, kuten GPS-paikantimessa 1. Laitteen käyttötarkoitus on kuitenkin paikan selvittäminen, ja tämän pitää voida tapahtua ilman perustietoja tietotekniikasta. Sulautetuille järjestelmille on tyypillistä myös se, että ne ovat suljettuja. Tämä tarkoittaa sitä, että järjestelmän voi ohjelmistoja tai toimintoja voi muuttaa tai lisätä vain järjestelmän toimittaja. Niin sanottu kolmas osapuoli ei voi tuottaa sovelluksia järjestelmään kuin aivan poikkeustapauksissa. Tämä nimenomainen ominaispiirre on osittain murtumassa, sillä jotkut sulautetuille järjestelmille tarkoitetut käyttöjärjestelmät tai usein oikeammin ohjelmointiympäristöt tarjoavat myös kolmansille osapuolille tarkoitetun rajapinnan. Lisäksi jotkut järjestelmät tarjoavat rajoitetumpaa ohjelmointimallia, jossa ohjelmistoon on lisätty mahdollisuus suorittaa muita ohjelmia virtuaalikoneen 1. Erilaisten paikantimien (ja myös monien muiden sulautettujen järjestelmien) toteutustekniikasta on mahdollista tehdä arvauksia suorituskyvyn perusteella. Mitä nopeampi laite on, sitä todennäköisemmin siinä on käytetty erikoistettuja laitteistokomponentteja, ja vastaavasti hitaiden laitteiden hitauden syy löytyy usein ohjelmistosta.

Sulautetut järjestelmät 15 avulla. Virtuaalikoneeseen on myös mahdollista lisätä erilaisia tietoturvaan liittyviä mekanismeja. Käytännön toteutuksista laajimmalle lienee levinnyt mobiili Java, jota tukevia puhelimia on satoja miljoonia. Viime aikoina on myös kasvanyt kiinnostus tarjota mahdollisuus suorittaa skriptejä omassa ajoajan ympäristössä, jonka avulla on mahdollista tarjota käännettäviä ohjelmia parempaa räätälöityvyyttä ja joustavuutta myös loppukäyttäjän näkökulmasta. Esimerkkejä ovat erilaiset web-pohjaiset ympäristöt ja vaikkapa Qt-sovelluskehyksen tarjoama QtScriptympäristö, johon on periaatteessa mahdollista lisätä laitekohtaisia rajapintoja. Suuri osa sulautetuista järjestelmistä on reaaliaikaisia, eli järjestelmän toiminnalle on asetettu paitsi toiminnallisia myös aikaan liittyviä vaatimuksia. Yhdistettynä pieneen suoritustehoon tämä voi tuottaa ohjelmoijalle melkoisia vaikeuksia. Lisähaastetta suunnittelutyöhön tuo se, että usein sulautetuista laitteista halutaan valmistaa useita toisistaan hivenen poikkeavia versioita, joissa esimerkiksi laitteistoa muuntelemalla saadaan aikaan eri markkinoille sopivia tuotteita. Tällöin ohjelmistoa pitää kaiken lisäksi pystyä muuntelemaan sunnitelmallisesti, mikä tietysti vaikeuttaa suunnittelua. Kaiken edellisen lisäksi järjestelmiltä vaaditaan erittäin suurta turvallisuutta ja vikasietoisuutta. Sulautetun järjestelmän tulisi kaikissa tilanteissa toimia siten, että se ei viallisenakaan tai väärin ohjattuna aiheuta vaaraa käyttäjälleen, ympäristölleen tai itselleen. Laitteiden pitäisi toipua virhetilanteista mahdollisimman automaattisesti, jopa niin, että käyttäjä ei huomaa mitään. Tietenkin laite voi ilmoittaa tarvitsevansa huoltoa, mutta kaikissa tilanteissa sen toiminnan pitää olla turvallista. Esimerkiksi autojen ABS-jarrut muuttuvat tavallisiksi jarruiksi, jos ABS-jarrujärjestelmään tulee vika. ABS:n tuoma hyöty menetetään, mutta jarrut kuitenkin toimivat yhä. Vaihtoehto (tietenkin tässä tapauksessa järjetön, mutta joidenkin järjestelmien kannalta hyväksyttävä) olisi esimerkiksi se, että auto pysäytetään vian tullessa väkisin. Tämän tapahtuminen ohitustilanteessa ei varmastikaan olisi turvallista. Toisaalta taas teollisuusrobotin pysäyttäminen vikatilanteessa on yleensä järkevin teko. Yhteenvetona suunnittelijan tulee siis tietää, millaisessa ympäristössä laitetta käytetään, jotta voisi päätellä oikeat reagointitavat, mikäli niitä ei ole kirjattu järjestelmä- ja ohjelmistovaatimuksiin tai käytettävissä ei ole alan asiantuntijaa. Kysyminen on kuitenkin yleensä kaikkein paras, yksinkertaisin ja nopein tapa selvittää kaikki yksityiskohdat.

16 Sulautettu ohjelmointi 1.3 Sulautettujen ohjelmistojen erityispiirteitä Sulautetuista järjestelmistä lukumääräisesti suurin osa on toteutettu suorituskyvyltään hyvin pienten suorittimien avulla. Toisaalta suurimmissa järjestelmissä ohjauskoneena voi olla hyvinkin tehokas suoritin, tai jopa kokonainen klusteri niitä, kuten esimerkiksi puhelinkeskuksen tapauksessa. Vastaava skaala pienestä suureen on nähtävissä myös järjestelmän pohjana olevassa ohjelmistossa. Kaikkein pienimmät sovellukset toimivat ilman selvää ydin sovellus-jakoa, jolloin koko ohjelmisto toimii loogisen toimintansa ohella samalla myös "käyttöjärjestelmän" ytimenä eli vastaa keskeytyksien ohjauksesta oikeaan palveluohjelmaan, ajanjaosta ja prosessien välisestä kommunikoinnista. Näin varsinkin silloin, jos suoritin on käskykannaltaan ja muistiavaruudeltaan erittäin vaatimaton pienimmissä suorittimissa muistiavaruus voi olla kahdeksan kilotavua, johon on mahduttava sovellus, ydin (tai ainakin sen toiminnot) ja oheislaitteiden ohjausrekisterit. Aivan pienimpiä sovelluksia lukuunottamatta järjestelmässä on tavallisesti selkeästi sovelluksesta erotettu ydin. Tällainen ydin on tyypillisesti hyvin pieni, jotta se mahtuisi yhdessä sovelluksen kanssa lukumuistiin. Ytimen pienuudesta seuraa, että sen palvelutkin ovat minimaaliset. Jotkin kaupalliset ytimet ovat sellaisia, että niistä voidaan koota hyvin erikokoisia ja samalla palveluiltaankin erilaisia versioita. Pienimmillään ne vievät tilaa vain joitain kilotavuja, mutta suurimmillaan ne tarjoavat täyden käyttöjärjestelmän suojauspiirteineen kaikkineen. Tietysti ytimen kokokin on noussut noin megatavuun; joissain tapauksissa jopa merkittävästi yli. Kun ytimestä karsitaan pois toimintoja sulautettua järjestelmää varten, tyypillisiä poistettavia osia ovat esimerkiksi virtuaalimuisti, sillä sitä ei reaaliaikajärjestelmissä yleensä voi muutenkaan käyttää ennakoitavuuteen liittyvistä syistä, tiedostojärjestelmä, koska laitteissa on harvoin massamuisteja (asia, joka on kyllä muuttumassa), sekä suojaukset, koska niiden ylläpito kuluttaa resursseja ja ohjelmien testausvaiheen luotetaan löytävän mahdolliset ongelmat, varsinkin jos kyseessä on järjestelmä, joka on täysin suljettu. Sen sijaan järjestelmät, joita käyttäjä voi laajentaa omilla sovelluksillaan, on yleensä suunniteltava siten, että käyttäjän sovellukset ja järjestelmän omat sovellukset on mahdollista erottaa toisistaan, jotta kaikkein tärkeimmät toiminnot voidaan taata joka tilanteessa. Näin ei kuitenkaan aina käytännössä käy, vaan esimerkiksi matkapuhelimeen on melko helppo toteuttaa sov-

Sulautetut järjestelmät 17 ellus, joka estää hätäpuhelun soittamisen varaamalla laitteen kaiken suoritusajan tai muistin omaan käyttöönsä. Toisaalta suurimmat ja monimutkaisimmat sulautetut järjestelmät voivat sisältää kokonaisia yleiskäyttöisiä käyttöjärjestelmiä sekä niihin liittyviä (yleiskäyttöisiä tai sovellusaluekohtaisia) kirjastoja. Tällöin ohjelmoijan kannalta osa sulautetun ohjelmoinnin ominaispiirteistä katoaa, sillä esimerkiksi muistinkulutuksen kannalta ei enää ole suurta merkitystä sillä, onko jonkun tietorakenteen koko täsmälleen optimi. Toisaalta osa haasteista on edelleen ohjelmoijan ratkaistava. Näitä ovat esimerkiksi järjestelmän ajallisesti oikea käyttäytyminen sekä yleensä se, että järjestelmän toiminnan voi millään tasolla varmistaa testien ja muiden apuvälineiden avulla. Usein onkin niin, että oikean toiminnan varmistaminen testitapausten avulla ohjaa suunnittelua. Siksi monet suunnitteluratkaisut, jotka periaatteessa saattaisivat jopa olla teknisesti edistyksellisempiä, voivat olla käyttökelvottomia, jollei toimintaa kyetä varmentamaan riittävällä tarkkuudella. 1.4 Kokonaisjärjestelmän määrittely Sulautetun järjestelmän määrittely on monen alan asiantuntijoiden yhteistyötä. Koko sulautetun järjestelmän idea johtaa tähän hyvin luonnollisesti. Eri alojen asiantuntijoiden olisi hyvä tuntea toistensa aloja jonkin verran, jotta keskusteluissa ei tulisi pahoja väärinymmärryksiä. Jo pienelläkin kokemuksella sulautettujen järjestelmien suunnittelusta eri tekniikan alojen edustajat löytävät yleensä keinot puhua asioista, mutta erityisesti silloin, kun sovellusalue on kaukana tekniikasta, on viestin välittämiseen kiinnitettävä paljon huomiota, jotta molemmat osapuolet ymmärtäisivät sen samoin. Tyypillisiä aloja, joita järjestelmiä tehtäessä on edustettuina, ovat ohjelmistotekniikka, tietokonetekniikka, tietoliikennetekniikka, elektroniikka, automaatiotekniikka, mekaniikka ja itse sovellusalueen asiantuntijat. Aina näitä kaikkia ei tarvita, ja joskus mukana voi olla myös muotoilijoita, käyttöliittymäsuunnittelijoita ja markkinointihenkilöstöä, ehkä järjestelmän tilaajakin. Tyypillistä on, että ensimmäisen version tavoitteena on tehdä toimiva perusratkaisu. Kun tuote vanhenee, yhä uusia ideoita nousee esiin perustoimintojen rinnalle, ja tarvitaan laajempaa asiantuntemustakin. Jälleen kerran hyvä esimerkki on matkapuhelin, joiden ensimmäisissä versiossa oli tarpeeksi työtä siinä, että laite ylipäätään toimi. Uusimpia mainostetaan kuorien värillä, muotoilulla, pelien lukumäärillä, musiikkisoittimella ja vaikkapa sisäänrak-

18 Sulautettu ohjelmointi ennetulla kameralla. Lisäksi viime aikoina erilaiset web-liitynnät, kuten Facebook-sovellus, ovat nousseet tärkeiksi, samoin kuin tietysti koko käyttökokemus laitteesta. Kuten matkapuhelinesimerkistäkin käy ilmi, vaikka käyttäjän kannalta kyse on samasta (tai samantapaisesta) laitteesta, ohjelmiston kannalta muutokset voivat olla niin suuria, että olisi perusteltua ymmärtää laite kokonaan uutena järjestelmänä. Kun kokonaisjärjestelmää määritellään, on tietoteknisen osan kokonaismäärittelyyn usein sopivimmat työkalut ohjelmistoasiantuntijalla. On tietenkin selvää, että sovellusalueen kieli kuvaa sillä tasolla parhaiten haluttua toimintaa, mutta tästä on vielä pitkä matka siihen, että järjestelmä on toteutettu. Kun kokonaisjärjestelmä on hahmoteltu, voidaan siirtyä yksityskohtaisempaan suunnitteluun, jossa asetetaan eri osa-alueiden väliset rajapinnat. Tietoteknisen toteutuksen puolella voidaan jatkaa tästä yleisestä jakotasosta vielä eteenpäin ainakin jonkin verran, ennen kuin laitteiston ja ohjelmiston välinen rajapinta lyödään lopullisesti lukkoon (niin sanottu ohjelmiston ja laitteiston yhteissuunnittelu; system codesign). Korostettakoon vielä, että suunnittelutyöhön osallistuvien on ymmärrettävä toistensa ammattikieltä edes kohtalaisesti, jotta pystyisivät ymmärtämään esitettyjen vaihtoehtojen vaikutuksen omiin osuuksiinsa. Silloin, kun ollaan tekemisissä uuden sovellusalueen kanssa, tämän projekti- tai sovellusaluekohtaisen terminologian opettelu on välttämättä tarvittava osa projektia, vaikka sitä harvoin aikataulutetaan perinteisen projektinhallinnan keinoin. 1.4.1 Suunnittelun jakaminen osiin Kun kokonaisjärjestelmä on saatu määriteltyä, työ jatkuu kuvassa 1.1 esitetyn kaavion mukaan kohti toteutusta. Kokonaismäärittelyä seuraa siis kokonaissuunnittelu ja työn jako osiin. Työn jakamiseen palataan seuraavissa kohdissa, joten siitä ei tässä sen enempää. Olennaista on huomata, että suunnittelun edetessä erikseen ohjelmisto- ja laitteistopuolella on huolehdittava siitä, että rajapinnan epäselvyydet tai muutostarpeet selvitetään välittömästi niiden ilmaantuessa, koska muuten ne tulevat vastaan vasta integrointivaiheessa. Tätä jatkuvaa keskusteluyhteyttä eri haarojen välillä kuvaavat katkoviivat ohjelmisto- ja laitteistosuunnittelun välillä. Lisäksi on syytä muistaa, että myös muihin toteutukseen osallistuviin osa-alueisiin on vastaavanlainen yhteys. Erityisesti sovellusalueen asiantuntijaa on syytä käyttää koko prosessin ajan konsulttina.

Sulautetut järjestelmät 19 kokonaismäärittely kokonaissuunnittelu työn jako osiin ohjelmistomäärittely laitteistomäärittely ohjelmistosuunnittelu laitteistosuunnittelu ohjelmiston toteutus laitteiston toteutus ohjelmistotestaus laitteistotestaus integrointi & testaus Kuva 1.1 Suunnittelun eteneminen perinteisen mallin mukaan. Tämä asiantuntija yleensä myös hyväksyy tuotteen, mikäli kyseessä ei ole tilaustyö. Tilaustyön tapauksessa asiakkaalla pitää yleensä olla keinot riittävään laadun- ja toiminnallisuuksien varmistukseen. Vaihtoehtoisesti myös tämä osa työstä on mahdollista alihankkia silloin, kun ollaan tekemisissä erikoistuneiden järjestelmien kanssa. Tällöin ongelmaksi voi tosin muodostua se, miten testausalihankkijan työ voidaan varmentaa. 1.4.2 Ohjelmiston ja laitteiston rajapinta Ohjelmiston ja laitteiston rajapinta sisältää monia asioita. Osa näistä on hyvin "korkealla" tasolla verrattuna toisiin, joita voi kuvata lähinnä "nippelitiedoiksi". Tosin hyvin pieniltä näyttävät asiat voivat olla hyvin erilaisia toteuttaa. Esimerkiksi se, onko oheislaite keskeyttävä vai ei, saattaa vaikuttaa yhdeltä suunnalta katsottuna vain siltä, kytketäänkö yksi johdin oheislaitteelta suorittimelle vai ei. Kuitenkin ratkaisu vaikuttaa kaikkeen kyseistä laitetta suoraan käyttävään ohjelmistoon, ja epäsuorasti myös ehkä muihinkin laitteisiin niiden johdotusta suunniteltaessa. Samaten suunnitteluratkaisulla voi olla vaikutusta siihen, onko mahdollista hankkia laitteistoa valmiina, vai onko sen valmistuksesta huolehdittava itse.

20 Sulautettu ohjelmointi Laitteistorajapintaa on ensinnäkin käytettävä suoritin. Millainen käskykanta ja rakenne siinä on? Miten nopea suoritin on? Onko se jokin erikoissuoritin (signaalisuoritin?) vai yleissuoritin? Onko laitteessa kenties monta suoritinta? Ovatko ne keskenään identtisiä vai onko yksi yleissuoritin ja toinen jokin erikoissuoritin? Tukeeko laitteisto liukulukuja? Jos järjestelmässä on useampia kuin yksi suoritin, niin miten nämä kommunikoivat keskenään? Onko käytössä väylä, yhteinen muisti (millainen) vai jokin muu mekanismi? Suoritin ei kuitenkaan kerro läheskään kaikkea tarvittavaa laitteistosta. Se on itse asiassa usein kaikkein helpoin ja suoraviivaisin määriteltävä komponentti, jonka valinta on usein jo etukäteen päätetty johtuen esimerkiksi saatavilla olevista ohjelmistotyökaluista, laitteistokokonaisuuksista, kustannuksista, energiatehokkuudesta ja fyysisestä koosta. Muita asioita, jotka täytyy ratkaista ovat muisti ja sen organisointi, oheislaitteet, erilaiset liitynnät muihin tietokoneisiin ja mahdolliset sovellusta varten tehtävät erityislaitteet. Muisti ei välttämättä ole yhtenäinen, vaan siinä saattaa olla aukkoja. Osa muistista on lukumuistia (ROM tai jokin muu muistityyppi, jonka sisältöä ei voi muuttaa ohjelmallisesti), osa luku-kirjoitusmuistia (RAM, muisti, joka tyhjenee, mikäli sen sähkönsyöttö katkeaa). Näiden väliin jäävät erilaiset muistit, jotka säilyttävät tiedon sähkökatkon yli, mutta joiden sisältöä voidaan muuttaa (esimerkiksi EEPROM, Flash- ROM). Näiden jälkimmäisten käyttö ei välttämättä ole yhtä näppärää kuin tavallisen luku kirjoitusmuistin, sillä tyhjennys tehdään tavallisesti erityiskäskyllä lohkolle kerrallaan, eikä piiri kestä muutoksia rajattomasti. Edellisten lisäksi järjestelmässä voi olla paristovarmennettuja luku kirjoitusmuisteja. Kaiken tämän fyysisen muistin kuvauksen lisäksi tulee selvittää, millainen muistinhallintayksikkö (MMU, Memory Management Unit) järjestelmässä on, vai onko sitä ollenkaan. Oheislaitteista tulee selvittää niiden lukumäärän ja tyypin lisäksi myös se, miten ne on sijoitettu keskusmuistiin, millaisten rekisterien tai käskyjen kautta niitä ohjataan ja miten sekä ovatko ne keskeyttäviä. Keskeytystapa on myös selvitettävä. Osa oheislaitteista voi olla erityisesti tätä sovellusta varten suunniteltuja, mihin palataan myöhemmin yksityiskohtaisemmalla tasolla. Muita olennaisia asioita ovat muun muassa liitynnät muihin järjestelmän tietokoneisiin. Nämä voivat olla toteutettuja sarjaliitynnöillä, väylillä tai valmiiden oheislaitepiirien kautta.

Sulautetut järjestelmät 21 1.4.3 Ohjelmiston ja laitteiston yhteissuunnittelu Monet toiminnot voidaan toteuttaa joko ohjelmistolla tai laitteistolla. Rajapinnan määrittely ei tällaisessa tilanteessa aina ole kovin selvää, sillä rajapinnan valintaan vaikuttavat sekä uudet tarjolla olevat ratkaisut että tehtävän laitteen luonne. Paras rajapinta on siis monen tekijän funktio, joissa taloudelliset tekijät, kuten esimerkiksi hinta, soveltuvat valmistustekniikat, käytettävissä oleva valmistuskapasiteetti ja monet muut seikat ovat mukana teknisten rinnalla. Näin varsinkin silloin, mikäli teknisesti eri vaihtoehdoilla ei ole selvää eroa. Lisäksi, vaikka ohjelmoija ei sitä aina tiedäkään, taloudelliset seikat ovat saattaneet vaikuttaa jo siihen, kannattaako kyseistä laitetta lainkaan toteuttaa. Yksi taloustekijä on laitteen oletettu valmistusmäärä. Mikäli laitteesta tehdään vain yksi tai muutama kappale, eivät standardikomponenteista koottujen laitteiden osakustannukset nouse merkittäviksi. Jos näiden komponenttien korvaaminen ohjelmallisesti on suurehkon työn takana, kannattaa käyttää laitteistoa ongelman ratkaisuun. Mikäli valmistusmäärät kasvavat, alkaa lisäkomponentin kustannus nousta niin, että sen korvaava ohjelmisto kannattaa tehdä. Tällaisesta tapauksesta voisi esittää esimerkkinä staattisen sähkömittarin kalibroinnin. Sähkömittari kalibroidaan perinteisesti siten, että erilaisilla säätövastuksilla tai -kondensaattoreilla säädetään lukemat kohdalleen. Vaikka nämä komponentit eivät maksa paljoakaan, eikä niiden latominen piirikortille, testaus ynnä muu sellainen nosta summaa kovin isoksi laitetta kohti, tuottaa 200000 mittarin vuosituotannossa jo pienikin säästö mittaria kohti hyvinkin sen ohjelmoijan palkan, joka toteuttaa kyseisen toiminnon ohjelmallisesti. Komponenttien vähentäminen ei kuitenkaan aina johda kustannusten vähenemiseen. Komponentin poisjättäminen voi aiheuttaa muiden komponenttien vaatimusten ja samalla hinnan monikertaistumista. Esimerkiksi suorittimeen suoraan liitetty sarjaliityntä aiheuttaa keskeytyksen joka tavun jälkeen. Tällaisessa järjestelmässä sarjaliityntä kuormittaa runsaasti suoritinta, ja tiedonsiirtonopeuden noustessa suorittimen koko kapasiteetti kuluu jo suhteellisen pienillä nopeuksilla sarjaliitynnän palvelemiseen. Mikäli sarjaliityntä kytketäänkin puskurimuistiin, johon mahtuu kerrallaan 16 alkiota, ja keskeytys generoidaan, kun muisti on puolitäysi, kuormittuu suoritin aiemmalla maksimikuormalla vain 10-12%. Ensimmäisenä mieleen tuleva ilmeinen suorituskykyä parantava vaihtoehto suorittimen korvaaminen nope-

22 Sulautettu ohjelmointi ammalla maksaa kuitenkin todennäköisesti paljon enemmän kuin tämä "ylimääräinen" komponentti. Kun tuotantomäärät kasvavat lisää, kääntyy joidenkin toimintojen toteutuksen edullisuus jälleen laitteistopuolen hyväksi. Tällöin kannattaa suunnitella oma sovelluskomponentti, joka säästää standardikomponenttien lukumäärän vähenemisen kautta tuotantokustannuksia (esimerkiksi edellä ollut puskurimuisti integroidaan osaksi suoritinta). Lisäksi komponentissa voidaan toteuttaa omia erityispiirejä tukemaan ohjelmien nopeaa suoritusta tai jopa korvata joitain tavallisesti ohjelmistolla toteutettavia algoritmeja laitteistolla. Lisähyöty on vielä sekin, että laitteen kopiointi on näin paljon vaikeampaa, ellei jopa mahdotonta. Ohjelmoitavien piirien kautta laitteistovaihtoehto alkaa olla käytettävissä jo suhteellisen pienissäkin tuotantomäärissä. Ohjelmiston ja laitteiston yhteissuunnittelu tarkoittaa siis tyypillisesti sellaista järjestelmän suunnittelua, jossa rajapinta määräytyy lopullisesti vasta suunnittelun aikana. Kuten edellä olevasta käy ilmi, tässä on eri tasoja riippuen tuotteen ominaisuuksista. Lisäksi tekniikan eri osa-alueiden kehitys johtaa siihen, että paras rajapinta muuttuu jatkuvasti. Hinnan lisäksi rajapintaan voivat vaikuttaa laitteelta vaadittu nopeus sekä lait, asetukset ja muut viranomaismääräykset. Nämä tavallisesti johtavat laitteistolla toteutettaviin ratkaisuihin: liukuluvut ovat nopeampia laitteistolla, ja vastaavasti turvakytkimet katkaisevat sähkönsyötön mekaanisesti, ei ohjelmallisesti. On syytä muistaa, että laitteiston ja ohjelmiston yhteissuunnittelu tarkoittaa kokonaisjärjestelmän kannalta usein yhtä komponenttia. Sen kohteena voi olla pieni osa koko ohjelmistosta ja laitteistosta, ja suurin osa järjestelmästä tehdään yhä perinteiseen malliin. Pisimmälle vietynä yhteissuunnittelu voi tarkoittaa sitä, että tarvittava ohjelmisto kirjoitetaan valmiiksi, ja tästä ohjelmasta generoidaan sekä laitteisto (suoritin ja oheislaitteet) että tämän laitteiston tarvitsema ohjelma. Joissakin ympäristöissä tätä kokonaisuutta voidaan myös simuloida ennen varsinaista generointia, jolloin järjestelmän verifiointi (ainakin periaatteessa) voidaan suorittaa jo ennen varsinaista toteuttamista. 1.5 Eri alojen edustajien roolit Tämän osuuden tarkoituksena on kuvata eri asiantuntijoiden roolia määriteltäessä ja suunniteltaessa sulautettua järjestelmää. Esimerkiksi voidaan ottaa mikä tahansa sovelluskohde: tässä esimerkkinä on rakennusautomaation järjestelmä, jonka tavoitteena on pitää huolta talon il-

Sulautetut järjestelmät 23 mastoinnista ja lämmityksestä. Koska ei ole mielekästä suunnitella järjestelmää vain yhtä tiettyä tapausta kohti, on järjestelmän oltava skaalattavissa annetuissa rajoissa. Työn alkuvaiheessa on suhteellisen helppo havaita, että järjestelmän toteuttamiseen tarvitaan ainakin LVI-alan asiantuntijoita, mahdollisesti automaation asiantuntijoita, tietokonetekniikan asiantuntijoita ja ohjelmistotekniikan asiantuntijoita. Kullakin osallistujalla on oma näkemyksensä siitä, mitä järjestelmä on, ja kukin näkee hieman erilaisia tarpeita kokonaisjärjestelmälle. Tätä esimerkkiä lukiessa ei kannata pohtia juuri esimerkin ongelmakenttää. LVI-asiantuntija on tässä sovellusalueen käytännön asiantuntija, automaation asiantuntija on edellä mainittu alueen teoreettisen osaamisen asiantuntija ja niin edelleen. 1.5.1 LVI-asiantuntijan näkökulma LVI-asiantuntijan (tai avaruus-, moottorinohjaus- tai ydinfysiikan asiantuntijan) näkökulma on sovellusalan näkökulma. Hänen tehtävänään on asettaa järjestelmän toiminnalliset tavoitteet, ja hän myös vastaa siitä, että mitään perustoimintaa ei unohdeta. Tämä on käytännössä usein vaikeaa, sillä asiantuntijalle alasta riippumatta ovat perusasiat itsestään selviä, ja hän helposti luulee, että muutkin tuntevat ne. Niinpä muiden pitää varmistua siitä, että he ovat ymmärtäneet sovellusalan tarpeet oikein. Muut osallistujat voivat ideoillaan laajentaa tai supistaa tavoitteita, sillä sovellusalueen asiantuntija on yleensä kiinnostunut vain sovellusalueen ongelmien ratkaisusta, eikä välttämättä ota huomioon ohjelmistoihin liittyviä modulaarisuus- tai muunneltavuusvaatimuksia lainkaan. Sovellusalueen asiantuntija tuntee oman alansa nykytekniikan, tietää, mitä siitä voidaan ottaa järjestelmään mukaan sellaisenaan, kuten esimerkiksi ohjainlaitteita ja antureita. Lisäksi hän tietää, millaisia laitteita kilpailijat ovat julkistaneet ja joskus myös sen, mitä eivät vielä ole julkaisseet, mutta aikovat. Sovellusalueen asiantuntija määrittää laitteistojen minimi- ja maksimitarpeet. Hän osaa antaa perusratkaisut sovellusalaan liittyvään matematiikkaan ja algoritmeihin. Erityisesti hänen tulee osata tulkita näitä, ja osata ilmaista niiden tarkoitus tai perustoiminta esimerkiksi peukalosääntöjen avulla. Kaiken kaikkiaan sovellusalueen asiantuntija, tässä tapauksessa siis LVI-asiantuntija, näkee koko järjestelmän LVIongelmana, jossa on hieman muutakin mukana.

24 Sulautettu ohjelmointi 1.5.2 Automaation asiantuntijan näkökulma Tässä esimerkissä automaation asiantuntija toimii sovellusalueen asiantuntijan tietämyksen täydentäjänä tuomalla siihen lisää teoreettista pohjaa automaatiotekniikan alueilla. Tällainen sovellusalueen lisäasiantuntija ei aina ole tarpeellinen, mutta toistaalta tällainen asiantuntija voi esittää uusia, korvaavia ratkaisuja, joiden toimivuus on selvitettävä varsinaisen sovellusalueen asiantuntijan kanssa. Esimerkkinä voisivat olla vaikkapa adaptiiviset säätöjärjestelmät, jotka mahdollistavat suuremman skaalautuvuuden. Kun uutta järjestelmää tehdään ainakin osittain uudelta pohjalta, voidaan törmätä sellaisiin ongelmiin, joita vanhoissa järjestelmissä ei ollut tai niihin ei voitu vaikuttaa. Tällaisessa tilanteessa lisäasiantuntijat voivat tuoda tarvittavaa lisätietämystä näiden uusien ongelmien ratkaisemiseen. Lisäasiantuntija näkeekin ongelman lähinnä oman alansa ongelmana, tässä tapauksessa siis automaatio-ongelmana. 1.5.3 Tietokoneasiantuntija Tietokone- ja digitaalitekniikan asiantuntija vastaa tarvittavan tietokonelaitteiston suunnittelusta tai valinnasta. Usein järjestelmään voidaan hankkia osia valmiina, ja tehtäväksi voi jäädä niiden yhteensovittaminen. Samankaltainen sovitusongelma on tarvittavien mitta- ja ohjauslaitteiden liittäminen tietokoneeseen: vaikka itse tietokone ja oheislaitteet saataisiin valmiina, ne täytyy saada keskustelemaan keskenään. Sovittamistyössä voidaan käyttää muiden alojen asiantuntijoita lisäasiantuntijoina. Esimerkissä LVI-suunnittelijalta saadaan tietää eri liityntätyyppien minimi- ja maksimimäärät. Aina tällainen lukumäärätasoinen tieto ei kuitenkaan ole riittävää, vaan tarvitaan syvällisempää apua. Esimerkiksi suunniteltava laite voi olla sellainen, että sitä tulee voida käyttää myös vaikeissa ympäristöolosuhteissa. Tällaisia tekijöitä ovat muun muassa pöly, kosteus, äärimmäinen lämpötila (ja lämpötilan vaihtelut), räjähdysvaara ja voimakkaat magneettikentät. Liitynnöille saatetaan antaa suuria vaatimuksia, esimerkiksi joissain ohjausjärjestelmissä liityntöjen tulee kestää jopa kilovolttien jännitettä siltä varalta, että jossain muualla järjestelmässä tulee vikoja tai lähistölle lyövä salama indusoi jännitepiikin. Eräs nykyajan erityisongelma on suojautua matkapuhelinten radiopurskeita vastaan. Lähes kaikissa sairaaloissa on kielletty matkapuhelinten käyttö (tosin nykyään usein turhaan ja vain varmuuden vuok-

Sulautetut järjestelmät 25 si), mutta ongelmia esiintyy muuallakin. Esimerkiksi käyvät autojen turvatyynyt, jotka varsinkin alkuaikoina saattoivat laueta matkapuhelimen aktivoituessa lähistöllä. Itse tietokonelaitteiston kohdalla tulee yhdessä ohjelmistoasiantuntijan kanssa päättää käytettävästä suorittimesta tai ainakin järjestelmän vaatimasta suurimmasta laskentatehosta, muistitilan tarpeesta ja millaista muistia tarvitaan (lukumuisti, luku-kirjoitusmuisti, kirjoitettava lukumuisti). Lisäksi tulee selvittää, mitä tehdään sähkökatkon tapahtuessa järjestetäänkö akkuvarmennus, suojataanko vain muisti ja sähkön palautuessa tehdään "pehmeä" käynnistys, tehdäänkö jotain muuta vai ei mitään. Myös käynnistyssekvenssiin tulee kiinnittää erityistä huomiota, sillä järjestelmä täytyy pystyä käynnistämään niin, että käynnistyksen aikana ei tapahdu mitään hallitsematonta. Osittain näitä käynnistysongelmia voidaan ratkaista ohjelmallisesti oikealla käynnistysjärjestyksellä, mutta aina tämä ei ole mahdollista, mikä vaatii sitten sen, että laitteistopuolella asia on hoidettu kuntoon. Tämäkin asiantuntija näkee ongelman oman alansa ongelmana, eli siis laitteisto-ongelmana, ja ohjelmisto on hänelle "musta laatikko". 1.5.4 Ohjelmistoasiantuntija Ohjelmistoasiantuntijan tehtävänä on suunnitella, toteuttaa ja testata ohjelmisto. Tämä ei vähänkään suuremmassa järjestelmässä ole tietenkään yhden henkilön tehtävä, niin kuin ei edellisissäkään tehtävissä. Työnsä pohjaksi hän saa: Sovellusalueen edustajalta perustiedot ongelmasta ja ratkaisumallit "korkealla tasolla". Sovellusalueen lisäasiantuntijoilta algoritmeja tai muita vastaavia ohjeita. Tietokonesuunnittelijalta laitteiston rakenteen, muun muassa suorittimen mallin, muistien ja oheislaitteiden sijoittelun muistiavaruuteen ja oheislaitteiden ohjaustiedot (datalehdet ynnä muut sellaiset). Yrityksellä on usein oma sovelluskehyksensä tai useita sellaisia, ja ohjelmiston tekijän tulee sovittaa ohjelmistonsa näiden kehysten mukaan toteutettaviksi. Lisäksi on asioita, joita tulee koko ryhmän miettiä. Tällainen asia on esimerkiksi se, mitä tehdä sähkökatkoksessa tai jossain muussa virhetilanteessa.

26 Sulautettu ohjelmointi Edellisten pohjalta ohjelmistosuunnittelijan tulee arvioida tarvittavien ohjelmien koko ja suorittimen tehontarve tietokoneasiantuntijaa varten. Koska nämä tarpeet vaikuttavat siihen, mitä tietokonelaitteiston suunnittelija tekee, voidaan helposti havaita, että kyseessä on yhteistyössä tapahtuva järjestelmän määrittely. Vastaavanlaisia rajapintoja on kaikkialle, koska jotkin sinänsä järkevät ratkaisut voivat johtaa ohjelmallisesti mahdottomaan erityisesti reaaliaikaympäristössä tai hyvin vaikeasti ratkaistavaan tilanteeseen. Kaiken kaikkiaan ohjelmistojen tekijän on huolehdittava siitä, että muilta osapuolilta saatu määrittely riittää ohjelmien määrittelyyn ja toteutukseen. Järjestelmän kokonaiskuvan hahmottamiseksi sen kokonaismäärittelyn tulisi olla kattava, ja tähän on yleensä ohjelmistoasiantuntijalla parhaat työkalut. On tietenkin selvää, että määrittely on yhteistyötä, ja siitä vastaavan henkilön tulee olla sen, joka siihen parhaiten pystyy, riippumatta siitä, mikä hänen koulutustaustansa on. Ohjelmistosuunnittelija näkee ongelman lähinnä ohjelmointiongelmana, jossa laitteisto on musta laatikko ja LVI- ja automaatiopuoli (eli sovellusalue) kertoo ratkaistavan ongelman. 1.5.5 Suunnittelutyön eteneminen Suunnittelutyö etenee vaiheittain siten, että alussa lähdetään järjestelmän vaatimuksista. Erityisesti on huolehdittava, että sovellusalueen perusvaatimukset tulevat täytettyä. Tätä pohjaa voidaan sitten ideapalavereissa täydentää ja tarkentaa. Vaatimusten pohjalta syntyy sitten pohdintaa eri ratkaisuvaihtoehdoista. Esimerkkinä olevassa ilmastointijärjestelmässä voidaan miettiä järjestelmän ohjausta. Toteutetaanko tarvittavien mittatietojen kerääminen ja ohjausten antaminen erillisjohdotuksella vai kenties jollain väyläratkaisulla vai ehkäpä langattomasti? Esille tulevia näkökohtia voisivat olla esimerkiksi seuraavat: Sinänsä on aivan sama, miten tiedot kerätään, kunhan ne kerätään. Erillisjohdotusta on käytetty ennenkin, miksei siis nytkin. Erillisjohdotus tarvitsee keskusyksikköön päätelaitteen tai vastaavan joka mittauspistettä tai ohjauspistettä kohti. Väyläratkaisuja ei tarvitse tehdä alusta lähtien uudestaan, vaan niitä on saatavilla valmiina, esimerkiksi LON (Luku 14). Erillisjohdotus vie enemmän johtoa, mutta väyläratkaisu vaatii enemmän älykkyyttä siihen liitetyille laitteille. Kumpi on edullisempaa?

Sulautetut järjestelmät 27 Väyläratkaisua ei ole vielä käytetty paljon, eikä tekijöillä ole siitä kokemusta. Uskalletaanko se ottaa käyttöön? Tulevaisuus on kuitenkin väylän tai langattoman ratkaisun, joten ei kannata tehdä enää erillisjohdotuksella. Väylä- tai langaton ratkaisu on paljon helpompi skaalata. Mutta mikä väyläratkaisu otetaan? Entä jos valitsemme väärän? Talon valaistuksen ja muun sähkönjakelun ohjauksen voisi järjestää samalla väylällä, mikä tuo kokonaissäästöjä (ja yhden lisäasiantuntijan projektiin). Entä jos väylää ei johdoteta, vaan käytetään langatonta ratkaisua? Ohjelmallehan on yhdentekevää, miten tieto siirtyy yksiköiden välillä. Langaton vaihtoehto voitaisiin asentaa jälkikäteenkin, kun johdotusta ei tarvitse tehdä. Häiritseekö langaton järjestelmä jotain muuta järjestelmää tai päin vastoin? Lopullinen ratkaisu syntyy sitten yhdessä esitettyjen argumenttien pohjalta. Teknisten argumenttien lisäksi vaikuttaa päätökseen muun muassa ratkaisun taloudellisuus sekä tehtävän tuotteen arvoitu elinikä valitulla tekniikalla. Joskus myös käytettävissä oleva aika estää uuden tekniikan käyttöönoton, mikäli tämän tekniikan käyttö aiheuttaisi viivästymistä siihen kouluttautumisen tai muun vastaavan syyn takia. 1.5.6 Lisähuomioita Edelliset kuvaukset painottuivat hyvin voimakkaasti tietoteknisiin ongelmiin. Näiden lisäksi tulevat käyttöliittymiin ja turvallisuuteen liittyvät ongelmat: kuka voi ohjata ilmastointijärjestelmää ja miten? Lisäksi esimerkiksi laitteiston kotelointi voi varsinkin erityisympäristössä olla vaikeaa, ja siinä tarvitaan omaa osaamista. Vaikka teknisessä tilassa olevan ilmastointi- ja lämmitysjärjestelmän ulkonäkö ei todennäköisesti ole sen myynnin kannalta kovinkaan tärkeää, niin joissain muissa projekteissa tilanne voi olla täysin toinen. Mitä useammin laite on näkyvillä ja loppukäyttäjän suorassa ohjauksessa, sitä tärkeämpää on, että se miellyttää käyttäjää myös ulkoisilta ominaisuuksiltaan.

28 Sulautettu ohjelmointi 1.6 Sulautetut järjestelmät ja sulautettu ohjelmointi Sulautettujen järjestelmien toteutuksen yhteydessä sulautettu ohjelmointi on välttämätöntä. Toisaalta aina joskus sulautettua ohjelmointia tarvitaan myös muunlaisissa yhteyksissä, kuten vaikkapa pöytäkoneen näytönohjaimen kapasiteettia hyödynnettäessä tai laiteajuria tai käyttöjärjestelmän ydintä toteutettaessa. Tästä syystä tässä teoksessa ei rajoituta vain sulautettuihin järjestelmiin, vaan pyritään tasolle, jossa ohjelmistoteknisesti olennaisimmat seikat tulisivat ilmi, jotta teknisten yksityiskohtien soveltaminen erilaisissa tilanteissa on mahdollista tarpeen mukaan. Yhteisiä piirteitä sekä sulautetuille järjestelmille sekä edellä mainituille suunnittelutehtäville ovat ainakin seuraavat: Tarkkaan rajattu mahdollisuus käyttää muistia, ja ymmärrys siitä, miten paljon muistia käytetään. Ymmärrys siitä, mitä taustalla olevan laitteiston oletetaan tekevän. Huolellisuus suorituskyvyn kannalta olennaisten suunnitteluratkaisujen osalta, jopa siten, että useita erilaisia toteutuksia kokeillaan eri tilanteissa. Työkalut on yleensä jollain lailla erikoistettu tähän nimenomaiseen tehtävään. Ohjelmointitehtävät vaativat tyypillisesti ajastuksen ja aikaan sidonnaisten tapahtumien hallintaa. Rinnakkaiset suoritukset ovat tavallisia. Edellä esitetyt seikat muodostavat sulautetun ohjelmoinnin tärkeimmät vaatimukset. 1.7 Yhteenveto Sulautetussa järjestelmässä ohjelmisto ja laitteisto ovat kiinni toisissaan niin saumattomasti, ettei kumpikaan ole käyttökelpoinen ilman toista. Sulautetun järjestelmän suunnittelussa tarvitaan tyypillisesti useita erilaisia insinööritieteitä, ja sulautetun ohjelmiston toteutuksessa joudutaan usein yhdistämään eri alojen asiantuntijoiden vaatimukset. Sulautettu ohjelmointi, jota väistämättä tarvitaan sulautetun järjestelmän toteuttamisessa, mutta myös yleisemmin laitteistonläheisten ohjelmistoteknisten ongelmien ratkaisussa vaatii sisään-