Lento-ohjelmistojen kehitysprosessit nanosatelliiteille

Koko: px
Aloita esitys sivulta:

Download "Lento-ohjelmistojen kehitysprosessit nanosatelliiteille"

Transkriptio

1 Henry Sanmark Lento-ohjelmistojen kehitysprosessit nanosatelliiteille Sähkötekniikan korkeakoulu Kandidaatintyö Espoo Vastuuopettaja: TkT Pekka Forsman Työn ohjaaja: DI Hannu Leppinen

2 aalto-yliopisto sähkötekniikan korkeakoulu kandidaatintyön tiivistelmä Tekijä: Henry Sanmark Työn nimi: Lento-ohjelmistojen kehitysprosessit nanosatelliiteille Päivämäärä: Kieli: Suomi Sivumäärä:6+31 Tutkinto-ohjelma: Automaatio- ja systeemitekniikka Vastuuopettaja: TkT Pekka Forsman Ohjaaja: DI Hannu Leppinen Aalto-yliopistossa sekä useissa muissa yliopistoissa ympäri maailmaa on käynnissä monia tieteellisiä nanosatelliittiprojekteja. Yhteydet näiden satelliittien ja maa-asemien välillä ovat rajattuja, joten satelliiteilta vaaditaan autonomista toimintaa. Tässä kandidaatintyössä luodaan katsaus kehitysprosesseihin, joilla tuotetaan autonomisen toiminnan mahdollistavia lento-ohjelmistoja nanosatelliiteille. Nanosatelliitit ovat pieniä, massaltaan alle 10 kilogramman satelliitteja. Näitä käytetään uuden tekniikan viemisessä avaruuteen entistä pienemmillä kustannuksilla sekä yksinkertaisissa tieteellisissä tehtävissä. Monet nanosatelliitiprojektit ovat yliopistojen opetusprojekteja, joiden tarkoituksena on kehittää opiskelijoiden avaruusosaamista esimerkiksi opinnäytetöiden yhteydessä. Pieni koko sekä opiskelijaläheisyys tuovat nanosatelliittien kehitykselle omia piirteitä, jotka näkyvät myös ohjelmistokehityksessä. Työssä tarkastellaan nanosatelliitteja sekä tutkitaan näiden projektien erityispiirteitä vertaamalla niitä suurempiin satelliitteihin ja satelliittiprojekteihin painottaen ohjelmistokehitystä. Työssä käydään läpi nanosatelliittien tehtävät, keskustietokoneen sekä ohjelmiston rakenteelliset ominaisuudet sekä kuvataan prosesseja, jotka johtivat näihin ratkaisuihin. Lopuksi tietoja sovelletaan Aalto-1 -satelliittiin tapaustutkimuksena ja arvioidaan sen ohjelmistokehityksen vaiheita. Avainsanat: nanosatelliitti, keskustietokone, sulautettu ohjelmisto, ohjelmistokehitys, vikasietoisuus, Aalto-1

3 aalto university school of electrical engineering abstract of the bachelor s thesis Author: Henry Sanmark Title: Flight Software Development Processes for Nanosatellites Date: Language: Finnish Number of pages:6+31 Degree programme: Automation and systems technology Supervisor: D.Sc. (Tech.) Pekka Forsman Advisor: M.Sc. (Tech.) Hannu Leppinen There are several ongoing scientific nanosatellite projects in many universities around the world, including Aalto University. Connections between these satellites and ground stations are limited. Therefore autonomous functionality is a necessity. This bachelor s thesis gives an overview of the development processes of flight software that provides autonomous functionality for nanosatellites. Nanosatellites are small and lightweight satellites, mass less than 10 kilograms. These satellites are used to carry new technology into space at lower cost and for simple scientific missions. Many nanosatellite projects are universities educational projects which aim to improve students space education with, for example, theses. Small size and student oriented developing brings a new characteristic in developing phases which are also seen in software development. This work examines the definition of nanosatellites and studies the characteristics of these projects, also comparing these projects to traditional satellites and satellite projects with an emphasis on software development. This thesis reviews nanosatellite missions, the architecture of on-board computers and software and describes the processes how these solutions are achieved. Finally, this information is applied to the Aalto-1 satellite as a case-study and its software development phases are analyzed. Keywords: nanosatellite, on-board computer, embedded software, software development, safety-critical, Aalto-1

4 iv Esipuhe Kun lapselta kysytään: "Mikä on unelma-ammattisi?" on vastaus usein astronautti. Avaruus on kiehtonut kaikkia vuosien ajan sen tuntemattomuuden, suuruuden sekä kaukaisuuden vuoksi. Avaruus on myös mahdollistanut oman maailmamme tehokkaampaa tutkimista sellaisesta ympäristöstä käsin, mistä ei voitu vielä sata vuotta sitten edes unelmoida. Avaruustekniikka on tuonut tietoa maailmastamme sekä kehittänyt käyttämäämme jokapäiväistä tekniikkaa mahdollistaen paremman käsityksen Maasta ja maailmankaikkeudesta. Samasta syystä hain mukaan Aalto-yliopiston Aalto-1 -nanosateliittiprojektiin, jossa pääsin itse olemaan mukana tämän tekniikan kehityksessä, vaikka en aivan astronautiksi päässytkään. Tekemäni työni Aalto-1:n ohjelmiston parissa sekä tämä kandidaatintyö ovat opettaneet minulle enemmän kuin useimmat kurssit yhteensä. Olen pystynyt käyttämään oppimiani taitoja merkittävässä projektissa sekä ensimmäistä kertaa tuottamaan tieteellistä informaatiota. Lisäksi iloitsen siitä, että olen voinut olla osallisena Suomen ensimmäisen satelliitin kehityksessä. Tekninen osaaminen on saanut vuoden 2013 kesän ja syksyn aikana suuren harppauksen eteenpäin, ja koen oppineeni jotain tärkeää ja merkityksellistä. Haluan erityisesti kiittää ohjaajaani DI Hannu Leppistä erinomaisesta ohjauksesta ja työstä, jonka hän teki tämän kandidaatintyön onnistumiseksi. Lisäksi haluan kiittää Aalto-1 kordinaattoria Jaan Praksia siitä, että olen päässyt mukaan Aalto-1 -projektiin. Lisäksi kiitän TkT Pekka Forsmania siitä, että sain tehdä työni omasta aiheestani. Kiitän myös suuresti ohjelmiston kehitysryhmän muita jäseniä Petri Niemelää sekä Nuno Silvaa erinomaisesta työstä satelliitin keskustietokoneen parissa. Suuret kiitokset myös Ianille, Annalle, Ellalle, Niklakselle sekä vanhemmilleni työni oikolukemisesta. Erityisesti haluan kiittää tuesta ystäviäni sekä vanhempiani, jotka jaksoivat kannustaa tämän koko ajan. Viimeisimpänä haluan kiittää Automaatioja systeemitekniikan kiltaa siitä, että se on auttanut minua eteenpäin jahtaamaan unelmiani sekä antanut unohtumattomia kokemuksia ja oppeja elämää varten. Kiitos. Otaniemi, Henry J. O. Sanmark

5 v Sisältö Tiivistelmä Tiivistelmä (englanniksi) Esipuhe Sisällysluettelo Lyhenteet ii iii iv v vi 1 Johdanto 1 2 Nanosatelliitit tutkimuskäytössä Nanosatelliitit Keskustietokone ja ohjelmisto Ohjelmistokehityksen prosessit Yleistä Tietokoneen rakenne Prosessori ja muisti Virheiden valvonta Käyttöjärjestelmä Ohjelmistoarkkitehtuurin yleispiirteet Ohjelmiston ajonaikaiset prosessit Vikasietoisuus Ohjelmointikäytännöt Ohjelmistosuunnittelun vaiheet Kehitysvaiheet Ohjelmakoodin laatu ja uudelleenkäytettävyys Varmistaminen, kelpuutus ja testaus Projektinhallinta Riskienhallinta Kehitysperiaatteet Aalto Yleistä Tietokoneen rakenne Ohjelmiston vaatimukset tehtävään Ohjelmistosuunnittelu Yhteenveto 26 Viitteet 28

6 vi Lyhenteet API AaSI COTS CubeSat CS DSP EPB ESA FDIR GNU IDE KISS LEO NASA OBC OBDH OCD GS UNIX VHF/UHF RTOS S-kaista SBC WBS WDT Ohjelmarajapinta (Application Program Interface) Aalto-1 spektrometri (Aalto-1 Spectral Imager) Kulutustuotepohjainen tavara (Commercial Off-The-Shelf ) Yleinen nanosatelliittistandardi Kommunikaatiojärjestelmä (Communication System) Digitaalinen signaaliprosessori (Digital Signal Processor) Plasmajarru (Electrostatic Plasma Brake) Euroopan avaruusjärjestö (European Space Agency) Vian havainnointi, eristäminen sekä palautuminen (Failure Detection, Isolation and Recovery) Vapaa käyttöjärjestelmäprojekti ja siihen liittyvät työkalut (GNU s Not UNIX ) Integroitu kehitysympäristö (Integrated Design Environment) Yksinkertaisuuteen pyrkivä ajatusmalli (Keep it Simple Stupid) Matala Maan kiertorata, noin km merenpinnan yläpuolella (Low Earth Orbit) Yhdysvaltain ilmailu- ja avaruushallinto (National Aeronautics and Space Administration) Keskustietokone (On-Board Computer) Tietojenhallintajärjestelmä (On-Board Data Handling) Prosessorin omat virheenetsintätyökalut (On-Chip Debug) Maa-asema (Ground Segment) Vuonna 1969 Bell Labsin kehittämä käyttöjärjestelmä Korkean taajuuden radiokaista välillä 300 MHz - 3 GHz (Very High Frequency, Ultra High Frequency) Reaaliaikakäyttöjärjestelmä (Real-Time Operating System) Korkean taajuuden radiokaista välillä 2 GHz - 4 GHz Yhdelle piirilevylle integroitu tietokone (Single-Board Computer) Työnositus (Work Breakdown Structure) Vahtikoira-ajastin (Watchdog Timer)

7 1 Johdanto Alle 10 kilogramman satelliitit eli nanosatelliitit ovat yleistyneet huomattavasti viimeisen kymmenen vuoden aikana pääosin yliopistovetoisten projektien ansiosta. Nanosatelliittien selkeimmät edut verrattuna perinteisiin satelliitteihin ovat pienemmät kehitys- ja laukaisukustannukset [1, s. 4], mikä mahdollistaa uuden teknologian testaamisen avaruudessa aikaisempaa helpommin. Nanosatelliitit ovat yleensä yliopistojen opetusprojekteja, joten näiden projektien avulla kehitetään paljon tarvittavaa avaruusosaamista. [1, s ] [2, s. 856] Satelliittien autonominen toiminta perustuu keskustietokoneiden sekä ohjelmiston toteutukseen. Niiden toimiessa pitkän kantaman päässä rajattujen yhteyksien varassa vaaditaan sulautetulta järjestelmältä robustia sekä laaja-alaista toiminnallisuutta. Toimintoihin lukeutuvat esimerkiksi hyötykuormien ohjaaminen sekä informaation välittäminen maahan. Keskeisessä osassa sulautettua järjestelmää on keskustietokoneen ohjelmisto, jonka suorituskyky, toimintavarmuus sekä virhetilanteissa toimiminen ovat välttämättömiä vaatimuksia satelliitin tehtävän onnistumiselle. Koska ohjelmisto toimii avaruudessa, virhetilanteiden kohdalla ongelmaa ei voi helposti korjata. Tämä saattaa vaarantaa koko tehtävän onnistumisen. Tämänkaltaisen lento-ohjelmiston kehittäminen vaatii huolellista suunnittelu- ja ohjelmointityötä sekä tarkkaa projektinhallintaa. Tutkimuksen tavoitteet Tämän kandidaatintyön tarkoituksena on luoda katsaus nanosatelliittien ohjelmistojen kehittämiseen liittyviin prosesseihin. Saatujen havaintojen pohjalta tehdään yhteenveto nanosatelliittien ohjelmistoteknisistä ratkaisuista sekä niiden suunnittelun ja kehityksen vaiheista. Työssä tarkastellaan eri nanosatelliittiprojekteja ja verrataan niiden ohjelmointi- sekä suunnitteluratkaisuja keskenään. Kerättyä tietoa sovelletaan perinteisiin avaruusprojekteihin ja tarkastellaan niiden eroa nanosatelliitteihin. Lisäksi otetaan esille tapaustutkimuksena Aalto-yliopiston kehittämä nanosatelliitti Aalto-1, tarkastellaan sen ohjelmistokehityksen prosesseja ja arvioidaan tehtyjä ratkaisuja. Menetelmät Työn teoriaosa on tehty aineistotutkimuksena, mutta Aalto-1:een liittyvä osuus perustuu meneillään olevaan lento-ohjelmiston kehitystyöhön, jossa olen itse ollut mukana. Avaruustutkimuksen tieteenalana nanosatelliitit ovat uusi ilmiö, minkä vuoksi valtaosa lähdeaineistosta on muiden nanosatelliittiprojektien raportteja. Tässä työssä esitettävä tarkempi teoria pohjautuu avaruustekniikan sekä sulautetun ohjelmiston kehityksen tunnettuihin perusteoksiin.

8 Työn rakenne Aluksi tarkastellaan yleisesti nanosatelliitteja, keskustietokonetta ja sen ohjelmistoa sekä perehdytään ohjelmiston oleellisiin piirteisiin ja perustietoihin. Tämän jälkeen keskitytään varsinaisiin kehitysprosesseihin eli siihen miten lento-ohjelmistoja on kehitetty ja mitä kehitykseen liittyviä asioita on otettava huomioon. Työn loppuosassa tarkastellaan Aalto-1:n ohjelmistoteknisiä sekä kehitysprosessin ratkaisuja. Yhteenvedossa tarkastellaan havaittuja tietoja ja arvioidaan niiden pohjalta nanosatelliittiprojektien ohjelmistokehitystä. 2

9 3 2 Nanosatelliitit tutkimuskäytössä Tässä luvussa tutustutaan tarkemmin nanosatelliittien määritelmään. Luvussa myös tarkastellaan niiden eroja perinteisiin suuriin satelliitteihin ja perehdytään tarkemmin, miksi nanosatelliitit ja CubeSat-standardi kehitettiin sekä mitä niillä on saatu aikaan. Lopulta keskitytään keskustietokoneen ja siihen kehitetyn ohjelmiston pääpiirteisiin. 2.1 Nanosatelliitit Viimeisen kolmenkymmenen vuoden aikana mikroelektroniikka on kehittynyt suurin harppauksin, mistä johtuen perinteinen avaruustekniikka ei ole pysynyt samassa määrin kehityksen mukana. Kulutustuotepohjaisten (Commercial Off-The-Shelf, COTS) nanosatelliittien kehittyminen on helpottanut kehittyneen tekniikan viemistä avaruuteen. COTS-teknologia on mahdollistanut satelliittien valmistamisen entistä halvemmalla ja nopeammin sekä pienentänyt niiden kokoa, mikä on lisännyt mahdollisuuksia pienemmän budjetin tutkimuksiin suuren luokan avaruusprojektien rinnalla. Erityisesti Kalifornian polyteknisen valtionyliopiston (Cal Poly) sekä Stanfordin yliopiston kehittämä ja ylläpitämä CubeSat-standardi nanosatelliiteille on edistänyt avaruustekniikan opetusta yliopistoissa. [3, s ] CubeSat-standardi määrittelee satelliitin kuutioksi, jonka särmä on 10 senttimetriä ja massa korkeintaan 1,33 kilogrammaa. Yksittäisiä kuutioita voidaan myös pinota useamman kuution yhdistelmiksi. [4] Standardin tarkoituksena on tarjota erityisesti yliopistoille entistä helpompi lähestymistapa kehitystyöhön vähentämällä kehitysaikaa ja kustannuksia sekä tarjoamalla entistä paremmat mahdollisuudet laukaisuille. COTS-tekniikan ansiosta avaruuteen voidaan viedä nanosatelliittien mukana helposti ja halvalla uutta tekniikkaa, jota ei olla aiemmin testattu avaruusympäristössä. Tämä tekniikka on suorituskykyistä ja luotettavaa maassa käydyn kehitystyön pohjalta. Tätä tekniikkaa ei kuitenkaan olla testattu riittävästi avaruusolosuhteissa esimerkiksi säteilytestein, joten sen vieminen suuriin satelliitteihin ei olisi siihen liittyvien kustannusten ja riskien vuoksi järkevää. [3, s. 598] [5, s. 326] Vaikka nanosatelliitit lentävät matalalla Maan kiertoradalla (low Earth orbit, LEO), jossa ei esiinny suuria määriä säteilyä verrattuna muihin kiertoratoihin on kuitenkin säteilyn vaikutus huomattava [1, s. 11]. COTS-komponenttien testaamattomuuden vuoksi on oleellista keskittyä satelliitin kokonaisvaltaiseen järjestelmäsuunnitteluun yksittäisten laitteiden tarkastelun sijaan, sillä pienentyneet kustannukset sekä alle vuoden pituinen lentoaika tuovat uusia haasteita. Kehityksen tärkeimmiksi lähtökohdiksi nousevat esimerkiksi yksinkertaiset rajapinnat komponenttien välillä sekä kerrostettu, vikasietoinen systeemiarkkitehtuuri. Riskien pienentämisen ja lennon epäonnistumisen välttämisen sijaan pyritäänkin ratkaisuihin, joissa turvataan satelliitin toiminta jos jokin osajärjestelmä ei toimi. [1, s. 7] [3, s ] Tarkan järjestelmäsuunnittelun vuoksi tärkeimpänä lähtökohtana onnistuneelle nanosatelliittiprojektille on tehokas projektinhallinta, jossa pienet motivoituneet kehittäjäryhmät pyrkivät aktiiviseen vuorovaikutuksen keskenään [3, s. 580]. Projektinhallinta tulee usein ongelmaksi erityisesti yliopistojen opiskelijoiden kehittämissä

10 4 Kuva 1: CubeSat-standardin mukaan rakennettu nanosatelliitti [6]. nanosatelliiteissa, joissa opiskelijoilla ei ole tarpeeksi kokemusta suurista projekteista ja jatkuvasta suunnitelmien vaihtelevuudesta. Tällöin opiskelijoiden motivaatiota sekä vuorovaikutusta pyritään kehittämään erilaisten kannustimien avulla. Yliopisto voi tarjota opintopisteitä, opinnäytetyöaiheita sekä järjestää opiskelijoiden keskuudessa opetustapahtumia uusien sekä vanhojen tekijöiden kesken. [1, s. 14] Opetuksellisesti nanosatelliittiprojektit ovat tärkeitä, sillä niiden kautta opiskelijat pääsevät tekemään teorian pohjalta konkreettista työtä. He pystyvät opinnäytetöiden pohjalta soveltamaan osaamistaan suurissakin projekteissa. [3, s. 598]. Yleinen piirre opiskelijoiden kehittämissä nanosatelliiteissa on luoda satelliitti, jolla on vain yksi tehtävä, kun suurimmilla satelliiteilla niitä voi olla useampia. Tällöin projekti saadaan pidettyä kokemattomien kehittäjien sekä samalla satelliitin suorituskyvyn vaatimissa rajoissa. [1, s. 11] 2.2 Keskustietokone ja ohjelmisto Keskustietokone (On-board Computer, OBC) on satelliitin autonomisen toiminnan keskeisin osa. Tietokone ja siinä oleva ohjelmisto ohjaa kaikkia satelliitin toimintoja sen muistissa olevan tiedon avulla. Laskettu tai kerätty data välitetään satelliitin eri osajärjestelmiin käytössä olevaa väylää pitkin. Näitä satelliitin lennon perustoimintoja ajavia toimenpiteitä sekä tiedon välittämistä osajärjestelmien kesken suoritetaan tietojenhallintajärjestelmässä (On-board Data Handling, OBDH). Vaikka tietokoneen fyysiset ratkaisut voivat erota merkittävästi satelliittien kesken, niissä

11 on havaittavissa suunnittelun kannalta yhteisiä piirteitä. [7, s. 628] [8] Yleisesti OBC ja sen ympärillä toimiva kokonaisuus voidaan mieltää sulautetuksi järjestelmäksi (embedded system). Suurimpana erona perinteisiin tietokoneisiin on muistin rajallinen määrä sekä käytössä oleva laskentateho, mikä pitää ottaa huomioon satelliitin ohjelmistoa kehittäessä. Muistia voi olla käytössä paljonkin, mutta sitä ei voida lisätä kesken lennon ja sitä saatetaan rajoittaa virrankulutuksen vuoksi [9, s. 3]. Erityisesti nanosatelliiteissa käytetään usein vähävirtaisia ja yksinkertaisia mikroprosessoreja, joilla pyritään yksinkertaiseen ja robustiin järjestelmään [2] [8] [10] [11] [12]. Yleensä näillä on myös rajallinen laskentateho verrattuna suurempiin satelliitteihin. Tämän vuoksi sulautetuissa järjestelmissä pyritäänkin ajamaan vain tehtävän kannalta oleelliset ohjelmat [7, s. 628]. Prosessorit sekä laskenta eivät kuitenkaan rajoitu vain OBC:hen, vaan esimerkiksi myös hyötykuormilla voi olla oma älynsä. Itsenäinen äly voi olla esimerkiksi asennonsäädössä sekä paikannuksessa, joissa laskettu data on OBC:lla käsiteltävissä. Sulautettujen järjestelmien eräs erityispiirre on useamman prosessorin muodostama hajautettu kokonaisuus [7, s. 628] [9, s. 2]. Tässä kandidaatintyössä kuitenkin keskitytään OBC:lle kehitettyyn ohjelmistoon. OBDH:n lisäksi keskustietokoneen pitää lähettää avaruudessa keräämänsä data maa-asemalle. Radioyhteys maa-aseman ja satelliitin välillä on kriittinen osa satelliitin toimintaa. Sen avulla saadaan tietoa satelliitin tilasta sekä kerätään lennon aikana kerätty data. Nanosatelliitin lähettämät viestit koostuvat pääasiassa telemetriasta sekä hyötykuormien keräämästä informaatiosta, jotka lähetetään joko VHF-, UHF- tai S-radiokaistaa pitkin. Maa-asemalta satelliitille voidaan lähettää etäkomentoja, joilla voidaan ohjata satelliittia tai päivittää sen ohjelmistoa. [2] Yleisesti on käytössä pakettipohjainen AX.25 amatööriradioprotokolla, joka toimii 145,825 MHz taajuudella [7, s. 772]. Onnistuneen radioyhteyden varmistamiseksi maa-asemalta vaaditaan myös toimivaa seurantaohjelmistoa. Tällöin antenni suunnataan satelliittia kohti sen saapuessa kiertoradallaan havaittavalle alueelle, jotta saadaan mahdollisimman kuuluva yhteys Maan ja satelliitin välille [1, s. 295]. Avaruusympäristö tuo ohjelmistosuunnitteluun uusia haasteita. Satelliitin ollessa helposti tavoittelemattomissa vaikeissa olosuhteissa voivat vakavat ohjelmistovirheet vaarantaa sen koko toiminnan. Tästä hyvä esimerkki on Yhdysvaltain ilmailuja avaruushallinnon (National Aeronautics and Space Administration, NASA) Deep Impact-luotaimen tehtävän keskeytyminen ohjelmavirheeseen syyskuussa 2013 [13]. Virheen vuoksi luotain käynnisti itseään jatkuvasti uudestaan, mikä esti yhteydenoton Maasta sekä kulutti akut loppuun. Ohjelmavirheiden lisäksi avaruusympäristössä havaitaan runsaasti säteilyä esimerkiksi Auringosta, mikä vaikuttaa OBC:n sekä ohjelmiston toimintaan. Säteily voi vaikuttaa esimerkiksi komponenttien virrankulutukseen, digitaalisen kellon tarkkuuteen hidastamalla sitä, bittivirheiden määrään ja sen myötä koko ohjelmiston virheelliseen toimintaan [7, s. 636]. Tämän vuoksi ohjelmiston täytyy olla vikasietoista, ja avaruusohjelmistojen suunnittelussa noudatetaankin yleisesti turvallisuuskriittisen ohjelmiston periaatteita [5, s. 275]. Tällöin painotetaan erityisesti riskienhallintaa, testausta sekä dokumentointia. Esimerkiksi Euroopan Avaruusjärjestö (European Space Agency, ESA) määrittelee kehittämänsä standardin ECSS-E-ST-40C avulla runsaasti vaatimuksia ohjelmiston toiminnalle 5

12 ja sen kehitykselle, minkä noudattamista vaaditaan ohjelmiston hyväksyttämiseen heidän avaruusohjelmissaan [14]. Ohjelmoinnissa käytetään useimmiten kielinä C:tä ja C++:aa, mutta myös Ada on suosittu [9, s. 3] [7, s. 657]. Nämä sallivat erityisesti muistinhallinnan tehokkaamman käsittelyn, joka on sulautetuissa ohjelmistoissa tärkeää. Ohjelmointiteknisesti kehittäjän pitää olla erittäin tietoinen tietokoneen fyysisistä ominaisuuksista, sillä monet ratkaisut perustuvat prosessorin ja muistin ominaisuuksiin sekä OBC:n liitäntöihin. Kirjoitusasussa pyritään selkeään koodiin, ja ESA on määritellyt ohjeita oikeaoppisen ohjelmakoodin kirjoittamiselle [15]. 6

13 7 3 Ohjelmistokehityksen prosessit Kolmannessa luvussa perehdytään nanosatelliittien ohjelmistoihin ja niiden kehityksen vaiheisiin. Aluksi havainnollistetaan miten ohjelmistokehitys sulautetulle järjestelmälle eroaa perinteisestä ohjelmistokehityksestä. Seuraavaksi tutkitaan keskustietokoneen fyysisiä ominaisuuksia ja sen arkkitehtuuria sekä käyttöjärjestelmää. Tämän jälkeen pohditaan, miten nämä otetaan huomioon ohjelmistokehityksessä. Sitten tarkastellaan ohjelmiston arkkitehtuuria ja sitä, millä vaatimuksilla se on suunniteltu ja kehitetty. Lopulta selvitellään ohjelmistokehityksen vaiheet sekä ohjelmiston että kokonaisen projektin kannalta. 3.1 Yleistä Tärkeimmät lähtökohdat avaruudessa toimivalle ohjelmistolle on vakaa toiminta ja laiteläheinen ohjelmointi. Ohjelmiston kehitys aloitetaan vasta kun tietokoneen komponenttien suunnittelu on edennyt riittävän pitkälle ohjelmistosuunnittelua varten. Ohjelmiston ja laitteiston täytyy kehittyä rinnakkain, sillä kehityksessä ei voida odottaa toisen valmistumista. Laitteisto ja ohjelmisto määrittelevät toinen toisilleen vaatimuksia kokonaisuutena. Täten ohjelmistokehityksen täytyy alkaa mahdollisimman aikaisin. Ohjelmiston kehityksessä otetaan huomioon esimerkiksi piirilevyn pinniasetelma sekä prosessorin omat virheenetsintätyökalut (On-Chip Debug, OCD). Virheitä etsitään koko kehitysprosessin ajan myös kehitysvaiheessa olevasta laitteistosta, mutta viimeisimmät virheet voidaan löytää vasta valmiista tietokoneesta. [9, s ] Sulautettujen ohjelmistojen kehityksessä on keskeisenä ristiinkääntäminen (cross compiling). Ohjelmointityö tehdään eri prosessori- sekä käyttöjärjestelmäalustalla olevalla tietokoneella, joten ohjelmiston kääntämisessä täytyy ottaa huomioon erot kehityskoneen ja OBC:n välillä. Ohjelmisto käännetään kehitysympäristöstä kohdeympäristöön siihen tarkoitetuilla kääntäjillä ja apuna käytetään erilaisia työkaluketjuja (toolchain). [10] 3.2 Tietokoneen rakenne Nanosatelliitteissa OBC on usein yhdelle piirilevylle integroitu tietokone (Single- Board Computer, SBC), joka ohjaa valtaosaa satelliitin kaikista toiminnoista [16, s. 5]. Yhdelle piirille integroituna on OBC:n etuna pieni koko sekä alhainen virrankulutus, jotta se saadaan mahdutettua CubeSat-standardin määrittelemään kokoon ja noudattamaan standardin toiminnallisia vaatimuksia. Tieto välitetään satelliitin muille osajärjestelmille erilaisia väyliä pitkin, ja nanosatelliiteissa käytetään yleensä I 2 C- tai CAN-väylää. Erityisesti I 2 C on suosittu, koska monet mikroprosessorit tukevat sitä suoraan ja se kuluttaa vähän virtaa. [2] Kuvassa 2 nähdään yksinkertaistettu lohkokaavio tietokoneen rakenteesta.

14 8 Kuva 2: Yksinkertaistettu lohkokaavio tietokoneen rakenteesta. Tietokoneen sisäiseen väylään on kiinnittyneenä eri komponentteja sekä portteja. Kuvassa on esitetty myös mahdollinen rinnakkainen keskusyksikkö. Tietokoneen väylän rajapinnan kautta informaatio välitetään satelliitin väylään, jota kautta data välittyy muille osajärjestelmille. Suomennettu Pisacanin teoksesta "Fundamentals of Space Systems". [7, s. 628] Prosessori ja muisti ARM-arkkitehtuuri on viime vuosina yleistunut nanosatelliittien prosessoreissa sen helpon saatavuuden, halvan hinnan ja laskentatehon vuoksi. Sen ongelmana on kuitenkin herkkyys avaruuden säteilylle, jolloin täytyy huolehtia mekaanisesta suojauksesta sekä ohjelmiston vikasietoisuudesta. [2] Peruslähtökohtana sulautetun järjestelmän kehittämiselle on 32-bittisen RISC-arkkitehtuuriin (Reduced instruction set computing) pohjautuvan prosessorin valinta, sillä se tarjoaa nykyään parhaimman suorituskyvyn sulateutuissa järjestelmissä [9, s. 51] [17, s. 54]. Tämä on vain viitteellinen suositus, sillä lopullisen prosessorin valintaan vaikuttaa useita eri tekijöitä. Näitä ovat esimerkiksi kokemus toimivuudesta aikaisemmilta lennoilta (flight heritage), kehitystyökalujen tarjonta ja käyttöjärjestelmätuki. Käytettävät suorittimet eivät siis ole pelkästään ARM-arkkitehtuurin mikroprosessoreja, vaan myös DSPsuorittimia, mikrokontrollereita sekä FPGA-piirejä on käytössä. Erityisesti DSPsuorittimista sekä mikrokontrollereista löytyy A/D-muunnos analogisen signaalin näytteistämiseksi, joka voi olla joidenkin nanosatelliittien tehtävien kannalta keskeinen vaatimus. [16, s. 17] Nykyisten nanosatelliittien prosessorien kellontaajuus vaihtelee välillä MHz riippuen satelliitin ajonaikaisten suoritusten vaatimuksista [10] [12] [18]. Prosessorin yksi tärkeimmistä ominaisuuksista suorituskyvyn sekä muistinhallinnan kannalta on MMU-yksikön (Memory Management Unit) olemassaolo. Se sallii ytimen, käyttäjän sekä tehtäväkohtaisten muistiavaruuksien erottamisen toisistaan, mikä parantaa muistinsuojausta [16, s. 17] ja tekee järjestelmästä robustimman. OBC:lle on integroituna myös muisti sekä tallennustila. RAM-muistia (Random- Access Memory) käytetään useissa nanosatelliiteissa parista megatavusta kymme-

15 neen megatavuun asti [8] [12] [18] ja sen tarkoituksena on sisältää lennonaikaisten muuttujien tiedot sekä kaikki ajonaikainen data. Tallennustilaa nanosatelliiteilla on yleensä erillisellä Flash ROM-muistilla, jonka määrä vaihtelee voimakkaasti satelliittien välillä. Kyseisellä muistilla sijaitsee käyttöjärjestelmä, ohjelmisto sekä tehtävän aikana kerätty tieteellinen data. Lisäksi tietokoneen käynnistyksen kannalta tärkeää katoamatonta (non-volatile) PROM tai EEPROM-muistia (Electrically Erasable Programmable Read-Only memory) kuuluu tietokoneen rakenteeseen, joka mahdollistaa myös uudelleenkäynnistyksen avaruudessa. Tähän muistialueeseen sisältyy esimerkiksi käyttöjärjestelmän käynnistyslatain. [17, s. 91] Virheiden valvonta OBC:n tulee olla tietoinen omasta tilastaan ja valvoa mahdollisia virhetilanteita. Tätä tehdään ohjelmistollisesti, mutta myös laitetasolla valvotaan virheitä ja pyritään palautumaan niistä. Virheiden valvonnan perinteisin ratkaisu laitetasolla on vahtikoira-ajastin (watchdog timer, WDT). Se valvoo ettei ohjelmisto tai laitteisto toimi virheellisesti ja kaikki ohjelmat suoritetaan oikeassa järjestyksessä. Ajettavat ohjelmat nollaavat ajastimen suorituksensa jälkeen. Jos joudutaan tilanteeseen, missä ohjelman suoritus ei lopukaan odotetusti eikä ajastin nollaudu, käynnistetään laitteisto uudestaan normaalin suorituskäytännön mukaisesti. Ohjelma, joka kommunikoi vahtikoira-ajastimen kanssa ja nollaa sen, seuraa aktiivisesti kaikkia osajärjestelmiä ja tarkkailee satelliitin toimintaa kokonaisuutena. [7, s ] Toinen ohjelmiston valvontaan liittyvä laitetason ratkaisu liittyy virheellisiin bitteihin, joita syntyy esimerkiksi säteilyn vaikutuksesta. Tällöin erilaisten enkooderien ja dekooderien yhdistelmillä käytetään hyväksi esimerkiksi Hammingin virheenkorjausta, jolla virheellisen datankäsittelyn jälkeen bitit saadaan korjattua oikeiksi. Kyseisessä virheenkorjauksessa lasketaan enkoodereissa ja dekoodereissa pariteettibittejä. Datan eheys selvitellään vertailemalla näitä bittejä keskenään ja virhetilanteessa korjataan bitti oikeaksi. [7, s ] Käyttöjärjestelmä Tietokoneen laitetason suunnittelun lisäksi toinen ohjelmistosuunnittelun päätekijä on käytössä oleva käyttöjärjestelmä sekä siinä olevat kirjastot. [16, s. 17]. Yleisesti sulautetuissa järjestelmissä suositaan reaaliaikakäyttöjärjestelmiä (Real-time operating system, RTOS) ja näitä käytetään myös nanosatelliiteissa esimerkiksi kaupallissa CubeSat Kitissä [9, s. 254] [19]. Reaaliaikakäyttöjärjestelmät tarjoavat ratkaisuja erityisesti lennoille, joissa vaaditaan aikakriittistä toimintaa sekä tehokasta vuorovaikutusta laitteiston kanssa [20, s. 2-3]. Toinen mahdollinen käyttöjärjestelmävaihtoehto on Linux ja sen pohjalta kehitetyt variaatiot, kuten uclinux. Näitä käytetään esimerkiksi Aalto-1:ssä sekä UWE-2:ssa [8] [21]. Näissä saadaan erityisesti hyödyksi valmis monipuolinen tuki erilaisille laitteistoille sekä valmiit kirjastot esimerkiksi kuvanpakkaukseen. Tällöin kuitenkin menetetään huomattavia etuja reaaliaikaisuudessa. Nanosatelliitin tehtävä ei välttämättä vaadi reaaliaikaisuutta, jolloin Linux on käyttöjärjestelmävalintana toimiva. On myös kehitetty ratkaisuja, joissa ei käytetä 9

16 lainkaan käyttöjärjestelmää vaan satelliitin OBDH toimii yhden kontrollisilmukan varassa [16, s. 18]. Tämänkaltaisessa ratkaisussa päästään eroon kokonaisen käyttöjärjestelmän ajamisen haitoista, kuten turhien resurssien käytöstä sekä käyttöjärjestelmäkohtaisista virheistä. 3.3 Ohjelmistoarkkitehtuurin yleispiirteet Ohjelmistoarkkitehtuurilla on useita eri määritelmiä. Kuitenkin IEEE standardi määrittelee sen siten, että se on ohjelmistojärjestelmän perusorganisaatio. Se sisältää järjestelmän osat, niiden keskinäiset suhteet sekä suhteet ympäristöön ja periaatteet järjestelmän suunnitteluun. [22] Aikaisemmin todettiin, että nanosatelliittien suunnitelussa pyritään yksittäisten osajärjestelmien yksityiskohtaisen suunnittelun sijaan painottamaan kokonaisvaltaista järjestelmäsuunnittelua (systems engineering). Lisäksi todettiin, että OBC ohjaa miltei kaikkia satelliitin toimintoja. Näiden kahden havainnon perusteella voidaan päätellä, että myös ohjelmiston arkkitehtuurissa pyritään kokonaisvaltaiseen toimintaan sekä vahvaan modulaarisuuteen erityisesti OBDH:ssa. Tällöin ohjelmisto voidaan rakentaa siten, että erilaiset moduulit hoitavat osajärjestelmiä ajurirajapintojen kautta omana prosessinaan. Tällöin yksittäisen järjestelmän virhe ei uhkaa koko satelliitin toimintaa. Monissa nanosatelliittiprojekteissa, kuten ION-2:ssa, UWE-2:ssa sekä Aalto-1:ssä käytetään kyseistä modulaarista ratkaisua [1, s. 242] [3, s ] [8] [21] ja tämä on yleinen tapa kehittää sulautettuja järjestelmiä robustiuden varmistamiseksi sekä kehittämisen helpottamiseksi [5, ]. Rakennetta, jossa voidaan havaita selvästi käyttöjärjestelmätaso, laitteistotaso, datankäsittelytaso sekä alijärjestelmien omat ohjelmistomoduulit kutsutaan staattiseksi arkkitehtuuriksi [17, s. 90]. Kuvassa 3 on esitetty yksinkertaistettu esimerkkikuva UWE- 2 nanosatelliitin ohjelmistoarkkitehtuurista ja sille kehitetystä ULF-ohjelmistosta, jossa havaitaan selkeä modulaarisuus. 10 Kuva 3: UWE-2 nanosatelliitin arkkitehtuuri. Arkkitehtuuri on jaettu selviin moduuleihin, jossa ULF-ohjelmisto keskustelee tietokoneen komponenttien sekä uclinuxin kanssa. ULF puolestaan ohjaa OBDH toimintaa ja ohjaa eri osajärjestelmiä. [8]

17 Monissa nanosatelliiteissa noudatetaan erilaista ohjelmiston käyttäytymismallia kuin perinteisissä avaruuslaitteistoissa: OBDH käynnistetään vasta kun satelliitti on kiertoradalla eikä ole päällä esimerkiksi laukaisun aikana. Lisäksi koko ohjelmisto voidaan päivittää ja käynnistää uudelleen lennon aikana, mikä on perinteisille satelliiteille harvinaista. [3, s. 582] Tällöin käyttöjärjestelmä sekä kaikkien osajärjestelmien käynnistyminen riippuu käynnistyslataimen toiminnasta. ION-nanosatelliitissa saatiin lisättyä vikasietoisuutta siten, että kaikki ohjelmisto ladattiin käynnistyslataimen kautta alustettavasta massamuistista RAM-muistiin [1, s. 244] Ohjelmiston ajonaikaiset prosessit Koska nanosatelliiteilla on korkeintaan pari erilaista tieteellistä tehtävää, ohjelmiston ajonaikaista suorittamista voidaan pitää yksinkertaisena prosessina. Tämän vuoksi ohjelmiston eri vaiheet suoritetaan joissakin satelliiteissa yksinkertaisella silmukalla (loop). Näin tehdään erityisesti sellaisissa nanosatelliiteissa, joissa ei ole käyttöjärjestelmää, kuten UWE-1:ssä [8] [16, s. 18]. Tämä toisaalta ei ole Fortescuen mukaan suotavaa, vaan ohjelmistossa tulisi välttää näitä silmukkoja robustisuuden säilyttämiseksi sekä kehittämisen helpottamiseksi [3, s. 580]. UWE-2:n edeltäjän UWE-1:n kohdalla ohjelmiston lisäkehitys koituikin ongelmaksi, kun uusia ominaisuuksia ei pystytty kehittämään valitussa ratkaisussa helposti [8]. Siksi yksinkertaisuus joudutaan toteuttamaan eri tavalla. Yleisin käytössä oleva ratkaisu on sisällyttää modulaarisen ohjelmiston keskelle vuorottaja (scheduler), joka kommunikoi yksinkertaisten rajapintojen kautta muiden moduulien kanssa. Vuorottaja lataa järjestelmän muistista aikamääritellyn tapahtumasarjan ja suorittaa sen mukaan kutsut eri moduuleille. Tällöin myös pystytään hallitsemaan yksinkertaista silmukkaa tehokkaammin järjestelmän vakautta. [9, s ] [1, s. 242] [17, s. 111] Sulautettujen järjestelmien tärkeimpiä ominaisuuksia ovat suoritustapa, vuorottaminen sekä vuorovaikutusmalli muiden osajärjestelmien kanssa (InterProcess Communication, IPC). Suoritustavat voivat olla joko aika- (time-triggered) tai tapahtumapohjaisia (event-triggered). Aikapohjaisessa suorituksessa järjestelmän toimintoja ajetaan jaksottaisesti ja pyritään saamaan järjestelmiltä haluttuja tietoja, eli pollataan. Tapahtumapohjaisessa suorituksessa seuraava toiminto ajetaan edeltävän tapahtuman jälkeen ilman selkeää jaksollisuutta. Erityisesti RTOS-järjestelmissä aikapohjaisuus on suositumpaa. Vuorottaja puolestaan asettaa tärkeysjärjestykseen tehtävien ajon ja määrää, kuinka pitkään ja milloin toimintoja ajetaan. Vuorottaminen voidaan suorittaa erilaisilla algoritmeilla, jotka kehitetään järjestelmän kohdalla tapauskohtaisesti. Nanosatelliiteissa ollaan käytetty algoritmien sijaan myös asetustiedostoja, joissa määritellään tietyt ajanjaksot esimerkiksi kuvan ottamiseen. Tämä sallii myös vuorottamisen logiikan helpon päivittämisen. Vuorovaikutusmallissa taas kuvataan datan liikkumista osajärjestelmien kesken. Yksi tapa toteuttaa tämä on sanomavälitteinen vuorovaikutus (message passing), jossa jokaisella sanomalla on tietty toiminnallisuus. Tällöin osajärjestelmät osaavat vastaanottaessa tietyn sanallisen viestin suorittaa haluttuja toimintoja. [16, s. 16] [20, 11.2] [1, s. 244] 11

18 Vikasietoisuus Vikasietoisuus on ohjelmistoarkkitehtuurin keskeinen ominaisuus. Tällöin puhutaan vian havainnoinnista, eristämisestä sekä palautumisesta (Failure Detection, Isolation and Recovery, FDIR). Vikasietoisuus voidaan toteuttaa monilla eri tavoilla, ja aikaisemmin määriteltiinkin miten laitteistotasolla voidaan korjata virheellistä dataa esimerkiksi Hamming-virheenkorjauksella. Ohjelmistopuolella voidaan kehittää erillinen viankorjauksen moduuli. Se keskustelee muiden järjestelmien kanssa ja havaittuaan virheen aloittaa mahdolliset korjaustoimeenpiteet. Esimerkiksi virransyötön häiriintyessä akkujen hajottua moduuli kytkee ylimääräiset osajärjestelmät pois päältä virran säästämiseksi ja käynnistää järjestelmien uudelleenkonfiguroinnin. Pahimmassa mahdollisessa tilanteessa järjestelmä voidaan viedä turvatilaan (safe mode). Yleinen suositus on, että FDIR suoritettaisiin aina mahdollisimman alhaisella eli laiteläheisellä tasolla ohjelmiston arkkitehtuurissa. Virheviesti pyritään välittämään asteittain korkeammalle tasolle ja korjaamaan siinä raportoitu ongelma. Esimerkiksi asennonsäätöjärjestelmään liittyvässä ongelmassa yritetään aluksi lähettää aikaisempi viesti uudestaan väylän kautta. Jos tämä ei onnistu, pyritään selvittämään asennonsäätöjärjestelmän tila ja mahdollisesti uudelleenkonfiguroimaan se. Tämän epäonnistuttua pyritään asennonsäätöjärjestelmän omalla ohjelmistolla ottamaan se pois käytöstä. Jos tämäkään ei onnistu, FDIR päämoduuli asettaa järjestelmän turvatilaan välittäen tiedon Maahan ja odottaa komentoja jatkotoimenpiteisiin. [17, s ] Turvakriittisten ohjelmistojen kehityksessä on noussut esille viime vuosina suoritusajan ja muistiavaruuden osiointi. Tämä johtaa juurensa ohjelmistokehityksen erityisesti testaamisen kasvaneisiin kustannuksiin ohjelmakoodin määrän lisääntyessä ja monimutkaistuessa. Modulaarinen arkkitehtuurisuunnittelu ei täysin ratkaise testaukseen liittyviä ongelmia, sillä monet moduulit voivat olla vuorovaikutuksessa keskenään. Suoritusajan ja muistiavaruuden osiointi tarkoittaa sitä, että useampaa käyttöjärjestelmäistuntoa ajetaan samanaikaisesti toisistaan riippumatta. Tämä toteutetaan usein käyttöjärjestelmätasolla siten, että suorituksessa on mikrokerneli, joka vaihtaa suorituksessa olevaa istuntoa sille annettujen tietojen perusteella. Lisäksi se vahtii MMU:n kanssa, etteivät istunnot joudu vuorovaikutukseen keskenään. ESA on kehittänyt omaaa EagleEye-referenssisatellittia, jossa pyritään käyttämään kyseistä tekniikkaa erityisesti maakuvaussatelliiteissa. Suoritusajan ja muistiavaruuden osionti on yleistä lentoteollisuudessa, mutta ei ole vielä yleistynyt avaruustekniikassa. Kehitys kuitenkin viittaa siihen, että kyseistä tekniikkaa tullaan käyttämään tulevina vuosina avaruustekniikassa. [23] Koska nanosatelliittiprojektit noudattavat turvakriittisen ohjelmiston pääperiaatteita, on odotettavissa kyseisen tekniikan yleistymistä myös nanosatelliittiprojekteissa. Tämä kehitys kuitenkin riippuu siitä, kuinka monimutkaisiksi nanosatelliittien ohjelmistot kehittyvät Ohjelmointikäytännöt Eurooppalaisessa avaruusteollisuudessa noudatetaan tarkasti ESA:n standardeja. Näillä määritellään millä tavalla avaruudessa käytettävän järjestelmän kuuluisi toimia, mitä sen kehityksessä pitää ottaa huomioon ja millä tavalla se pitää testata.

19 Standardeja on useita, ja ne kattavat myös ohjelmistokehityksen. ECSS-E-ST-40C määrittelee ohjelmistokehityksen vaiheet sekä valmiissa tuotteessa vaadittavat määriteltävät ja raportoitavat ominaisuudet. Ohjelmistoarkkitehtuurin kohdalla keskitytään erityisesti siihen, että määritellään ohjelmiston korkean tason hierarkia, rajapinnat, käytettävät luokat, datan prosessointi, ohjelmistokomponenttien välinen vuorovaikutus sekä kokonaisvaltainen toiminta. Lisäksi ESA:lla on omat määritelmänsä koodin kirjoitusasulle. Tällä pyritään ohjelmistokehittäjien kesken helposti luettavaan, ymmärrettävään sekä samankaltaiseen koodiin. Kirjoitusasu määrittelee koodin laatuun liittyviä kriteerejä. Erityisesti C:lle ja C++:lle on määritelty yksiselitteisiä kielellisiä vaatimuksia, jotka lisäksi kunnioittavat ISO/IEC sekä ISO/IEC standardeja. Näitä ovat esimerkiksi ehtolauseen sulkujen ja kommenttien muotoiluun sekä funktioiden nimeämiseen ja käyttöön liittyvät vaatimukset. [14] [15] Nanosatelliittiprojekteissa ei yleensä noudateta näitä standardoituja ratkaisumalleja. Opiskelijoiden kesken ei välttämättä ole opittu käyttämään yleisesti hyväksyttyjä standardeja, vaan on keskitytty käyttämään opittuja ohjelmistokirjoitustyylejä tai määritelty projektille oma kirjoitusstandardi. Tämä näkyy esimerkiksi ICube-projektissa [24]. Tällöin kokemattomalla opiskelijayhteisöllä voi jäädä huomaamatta ESA:n standardeissa korostettuja piirteitä, mikä voi tuottaa arkkitehtuurin suunnittelun puolella selkeitä ongelmia. Toisaalta CubeSat-standardia noudattavat projektit pystyvät jakamaan informaatiota projektien kesken niin hyvin, että tätä ongelmaa saadaan hyvin kompensoitua. CubeSat-standardi perustuu vahvaan yhteisöllisyyteen sekä informaation avoimeen jakamiseen projektien kesken [1, s. 19]. Tämän vuoksi arkkitehtuurin suunnittelussa on nanosatelliittien kohdalla hyvinkin paljon samankaltaisuuksia. Niiden määrittelyssä noudatetaan usein toisilleen läheisiä periaatteita kuten modulaarisuutta. 3.4 Ohjelmistosuunnittelun vaiheet Kehitysvaiheet Onnistuneen nanosatelliittiprojektin kehitys vaatii tarkan suunnitelman sekä selkeät välitavoitteet. Koska koko satelliitin toiminta suunnitellaan kokonaisuutena järjestelmätasolla, tämä näkyy ohjelmiston suunnittelussa. Ohjelmiston suunnittelu voidaan jakaa viiteen eri vaiheeseen: vaatimuksien keräämiseen, esisuunnitteluun, yksityiskohtaiseen suunnitteluun, toteutukseen sekä loppukäyttöön. Pisacane [7, s ] on esittänyt kuvassa 4 eri kehitysvaiheisiin liittyviä toimeenpiteitä, kun kehitetään avaruusympäristössä toimivia ohjelmistoja. Eri vaiheisiin keskittyvää ohjelmistokehitystä kuvaavia malleja kutsutaan vaihejakomalleiksi. Ne antavat erilaiset lähtökohdat ohjelmiston suunnitteluun, mutta kuitenkin yhtenäistävät ja ohjaavat suunnitelun vaiheita. Vaihejakomallien ideana on muodostaa selkeät toisiaan seuraavat vaiheet ohjelmistokehityksen aikana sekä havannoillistaa niiden keskinäistä järjestystä. Näitä vaihejakomalleja ovat esimerkiksi Evo-malli (evolutionary delivery), erilaiset protoilumallit sekä vesiputousmalli (waterfall model) [25, s. 29]. Nämä kuvaavat siirtymien kautta eri vaiheiden totetuk- 13

20 14 Kuva 4: Ohjelmistokehityksen vaiheet. Kuvaajasta nähdään ohjelmiston eri kehitys- ja suunnitteluvaiheissa tehtävät toimenpiteet projektin eri osien kannalta tarkasteltuna. [7, s. 656] sia ja niistä seuraavia toimenpiteitä. Jokaisessa mallin vaiheessa sovelletaan kuvassa 4 esitettyjä toimeenpiteitä. Kuvassa 5 on esitetty vesiputousmalli, joka on yksi mahdollinen tapa kehittää lento-ohjelmistoja nanosatelliiteille. Kuva 5: Vesiputousmalli nanosatelliitin ohjelmistokehityksessä. Kyseisessä mallissa kehitys aloitetaan mallin yläpäästä ja vesiputouksen tapaisesti siirrytään aina alempiin vaiheisiin. Jos kehityksessä joudutaan palaamaan aikaisempiin vaiheisiin muuttuneiden suunnitelmien mukaisesti, joudutaan tämä puolestaan tekemään portaittain yläspäin. [7, s. 663] [25, s. 24] Kehitys aloitetaan projektin määrittelyllä ja pohtimalla mitä satelliitin pitää kokonaisuudessaan tehdä. Ohjelmiston elinkaari määrittelee kokonaisuudessaan kehitys-

21 ja toimintavaiheet suunnittelun alkuhetkistä aina satelliitin kiertoradalta putoamiseen asti. Tähän kuuluvat yleiset ohjelmiston vaatimukset (General Software Engineering Requirements) sekä yksittäiset ohjelmiston prosessit (Individual Software Engineering Processes). Yleiset vaatimukset käsittävät dokumentaation, testaamisen ja ohjelmiston kokonaisvaltaisen kehityksen vaatimukset. Yksittäisissä prosesseissa pyritään kuvaamaan yksityiskohtaisesti jokaisen osajärjestelmän tai moduulin kehitys ja välitavoitteet. [3, s. 639] Ohjelmiston kokonaisvaltaiselle toiminnalle joudutaan määrittelemään myös tarkempia vaatimuksia esimerkiksi rajapinnoille sekä käytettäville algoritmeille. Eickhoffin mukaan [17, s. 132] ohjelmiston vaatimuksien määrittelyt voidaan listata seuraavasti: Ohjelmistoarkkitehtuurin vaatimukset Toiminnalliset vaatimukset, kuten funktioiden hierarkiajärjestys sekä erilaisten lento- ja hyötykuormien sekä varustelutilojen määrittely Ohjelmiston sekä algoritmien suorituskyvyn suunnittelu OBDH:n toiminnallisuuden määritelmä Vuorottamisen sekä aikakriittisyyden määrittely FDIR-määrittely Kehitystyöprosessiin liittyvät vaatimukset, kuten projektinhallinta sekä noudatettavat standardit Varmistamisen (verification) sekä kelpuuttamisen (validation) vaatimukset Kun projektin vaatimukset on määritelty, keskitytään arkkitehtuurisuunnitteluun, jota kuvattiin luvussa 3.3. Arkkitehtuurisuunnitelun kautta määritellään myös ohjelmiston moduulit sekä niiden väliset rajapinnat. Kun arkkitehtuuri on suunniteltu, voidaan keskittyä yksittäisten moduulien määrittämiseen ja kokonaisen ohjelmiston toiminnallisuuteen. [25, s. 287] Ohjelmakoodin laatu ja uudelleenkäytettävyys Viime vuosina on kiinnitetty entistä enemmän huomiota ohjelmiston uudelleenkäytettävyyteen. Suuremmissa avaruusohjelmissa ohjelmien uudelleenkirjoittaminen tuottaa turhia kuluja sekä hidastaa kehitysprosessia. Siksi ohjelmistot halutaan rakentaa siten, että samaa ohjelmakoodia voidaan saumattomasti käyttää tulevissa avaruusohjelmissa. [7, s. 661] ION ja ION-2 nanosatelliittiprojekteissa havaittiin ongelmia ohjelmiston uudelleenkäytettävyydessä, sillä aikaisemman projektin ohjelmistoa ei pystynyt helposti käyttämään uudessa projektissa. Lähes koko ohjelmisto jouduttiin rakentamaan uudestaan. Modulaarinen ohjelmisto on perinteisin keino uudelleenkäytettävyyden parantamiseksi. [1, s. 241] Myös UWE-2 satelliitissa ollaan haettu uudelleenkäytettävyyttä. Projektissa kehitettyä UFL-järjestelmää voidaan 15

22 käyttää vapaasti muissa nanosatelliittiprojekteissa, jotka pyörivät Linuxin päällä. [8] Uudelleenkäytettävyyteen sekä yhteisöllisyyteen on lanseerattu SAVOIR-ohjelma (Space Avionics Open Interface Architecture), jossa on mukana ESA ja useita muita eurooppalaisia avaruustekniikan järjestöjä. Ohjelma pyrkii pienentämään rajoja avaruusohjelmiston kehityksessä, sillä rakenteellisesti niissä on paljon samankaltaisuuksia niin toiminnallisuudessa kuin laitteistossa. Kyseinen ohjelma parantaa huomattavasti kehitystyötä, kun samankaltaisia ohjelmistoratkaisuja ei jouduta jatkuvasti kehittämään uudestaan. Tämä helpottaa myös järjestelmien integrointia. [26] [27] Lisäksi NASA on lanseerannut OSAL-rajapinnan (Operating System Abstraction Layer), joka myös helpottaa ohjelmiston uudelleenkäytettävyyttä. Se tarjoaa kattavan ohjelmarajapinnan (Application Program Interface, API) erityisesti reaaliaikakäyttöjärjestelmille sulautettuihin järjestelmiin. Tällöin pystytään helposti kehittämään uudelleenkäytettävää ohjelmistoa sekä nopeuttamaan kehitystä yhteisen rajapinnan avulla. [28]. Modulaarisen ja uudelleenkäytettävän ohjelmiston lisäksi tehtäväkriittisille ohjelmistoille pätee kolme perussääntöä, jotka tulee ottaa huomioon ohjelmiston kehityksessä. Nämä kolme tärkeintä tekijää ovat luettavuus, päällekkäisyys, sekä todistettavuus. Koska ohjelmakoodi on ihmisen tekemää ja ihmisen luettavaa, luettavuus mahdollistaa loogisten ajatusketjujen seuraamisen ja ymmärtämisen. Tähän kuuluu selkeä kommentointi sekä hankalasti ymmärrettävien algoritmien yksityiskohtainen selittäminen tai toteuttamisen välttäminen. Kun ohjelmiston virheet ovat helposti havaittavissa, voidaan välttyä vakavilta ohjelmistovirheiltä. Lisäksi funktioiden toteutuksissa käytettävät loogisesti vaikeaselkoiset keinot, jotka lyhentävät algoritmia muutamalla rivillä, eivät välttämättä tee ohjelmasta parempaa. Tämä voi vain hankaloittaa sen lukemista ja ymmärtämistä. Lisäksi käännetty ohjelma ei välttämättä ole yhtään suorituskykyisempi tai pienempi, kuin helpommin toteutetussa mutta koodiriveiltään pidemmässä ratkaisussa. Toisen säännön mukaan ei myöskään ole mielekästä tehdä useita eri funktioita samankaltaisen toiminnallisuuden suorittamiseen. Tämä lisää ohjelman kuormitusta ja yksittäiset muutokset rikkovat funktoiden välisiä riippuvuuksia sekä vaarantavat toiminnallisuuden. Todistettavuudella puolestaan viitataan modulaariseen arkkitehtuuriin, jolla pyritään välttämään suuria asiakokonaisuuksia ja hankalia logiikoita. Ohjelmiston toiminta voidaan todistaa perusteellisesti ja kehittäjän ajattelemalla tavalla, eikä ohjelmisto toimi suunnittelemattomasti. Näillä kolmella päätekijällä pystytään parantamaan huomattavasti ohjelmakoodin toimintavarmuutta. [5, s. 91] [9, s ] Varmistaminen, kelpuutus ja testaus Suunnitelmien toteuttamisen seuraamiseksi sekä kokonaisen kehityksen varmistamiseksi pyritään noudattamaan V-mallia. Tällöin erityisesti loppupäässä ohjelmiston varmistaminen sekä kelpuuttaminen ovat tärkeässä osassa. V-mallin mukaan aluksi pyritään määrittelemään projektin suunnitelma sekä toiminnallisuuden jokainen osatekijä tarkasti, jolloin kuljetaan mallin vasenta laitaa alaspäin. Mallin alapäässä on toteutusvaihe, jonka jälkeen on vuorossa varmistaminen mallin oikealla laidalla. 16

23 Tällöin noustaan mallia ylöspäin ja tarkastellaan jokaisen saman suunnitteluvaiheen toteutusta iteratiivisesti ja sitä kuinka toteutus vastaa suunnitelmaa. Varmistamisen jälkeen seuraa kelpuutus, jossa kokonaisuus testataan läpikotaisin ja verrataan suunniteltuihin vaatimuksiin. Nämä vaiheet tulee erikseen dokumentoida. V-mallin noudattaminen on lähes välttämättömyys kriittisten ohjelmistojen kehityksessä, sillä sen avulla pystytään helposti seuraamaan haluttujen suunnitelmien toteutumista. [7, s ] [17, s ] 17 Kuva 6: V-malli avaruusohjelmiston kehityksessä. V:n vasen puoli tarkoittaa asteittaista eri vaiheiden suunnittelua ja oikea puoli puolestaan jokaisen vaiheen varmistamista sekä testausta. Kuvassa on havainnoillistettu, kuinka V-mallia voidaan käyttää lomittain ohjelmiston eri osien suunnittelussa. [17, s. 149]. Ohjelmiston testaus on kehityksen kriittisin vaihe ja se voi viedä jopa puolet koko ohjelmiston kehitykseen kuluneesta ajasta. Sillä pyritään etsimään kaikki mahdolliset ohjelmavirheet ja korjaamaan ne ennen varsinaista lentoa. Avaruusohjelmistossa vaaditaan erityisen tarkkoja testejä virheiden löytämiseksi, ja usein nämä toteutetaan kehittämällä lentoa mallintava simulaattori varsinaisen ohjelmiston kehityksen rinnalla. Reaaliaikajärjestelmissä ohjelmiston testaus suoritetaan kahdessa osassa. Ensin testataan funktioiden toimivuus ja sen jälkeen aikakriittisyys. [7, s ] Projektinhallinta Nanosatelliittiprojektit ovat harvoin suuren kehittäjäryhmän työstämiä. Koko projektin aktiivinen henkilömäärä on yleensä noin kaksi- tai kolmekymmentä ja nämä jakautuvat useisiin eri työryhmiin. Työryhmät voidaan jakaa esimerkiksi mekaaniseen suunnittelun ryhmäksi, asennonsäätöjärjestelmäryhmäksi, elektroniikkaryhmäksi, maa-asemaryhmäksi sekä ohjelmistoryhmäksi. Täten jokaisen ryhmän koko vaihtelee kolmesta viiteen henkilöön. Kaikkien näiden ryhmien yläpuolella on vielä hallinnoiva ryhmä, johon kuuluu projektin pääkoordinaattori ja järjestelmäsuunnittelijat sekä yliopistoprojekteissa lisäksi muutama valmistunut opiskelija ja opetushenkilökuntaa. Pääkoordinaattori vastaa loppukädessä projektin etenemisestä sekä

24 lopullisista päätöksistä. Lisäksi jokaisessa työryhmässä on erikseen oma ryhmänjohtaja, joka johtaa ryhmän sisäistä toimintaa. Esimerkiksi ohjelmistoryhmän ryhmänjohtaja vastaa suurista linjoista ja muu ryhmä suunnittelee keskenään ohjelmiston rakenteen ja ohjelmoi sen. Vastaavaa pienempiin moduuleihin eli työryhmiin jaettua rakennetta kutsutaan työnositukseksi (Work Breakdown Structure, WBS). Yliopistoprojekteissa projektinhallinnassa tulee ongelmaksi työvoiman jatkuva vaihtelevuus, sillä monet tekijät ovat projektissa mukana esimerkiksi tietyn opinnäytetyön ajan muutamasta kuukaudesta vuoteen. Tämän vuoksi vanhempien opiskelijoiden aktiivinen osallistuminen ryhmänohjaajina on tärkeää, jotta aikaisemmat suunnitelmat esimerkiksi ohjelmistoarkkitehtuurin osalta saadaan välitettyä uudelle kehittäjäsukupolvelle. [1, s ] [5, s ] Onnistuneessa projektissa organisaatiolla on toimiva sisäinen kommunikaatio ja aikataulutus. Ryhmien kommunikoinnin varmistamiseksi järjestetään usein tapaamisia, jotta projektin kokonaissuunnitelmaa noudatettaisiin. Näitä voivat esimerkiksi olla ohjelmistoryhmällä hyötykuorman ohjelmistokehitykseen liittyvät tapaamiset, joissa keskustellaan nimenomaisesti tietyn hyötykuorman ohjelmiston kehityksestä. Ryhmän tulisi olla tietoinen keskinäisistä kontaktimahdollisuuksista, sillä todennäköisesti osa työstä tehdään toimistoajan ulkopuolella. Opiskelijoiden kohdalla täytyy ottaa huomioon myös muut opinnot, joten jokainen ryhmän jäsen joutuu olemaan saatavilla liukuvalla aikataululla. Parhaiten kehityksen seuraamista voidaan edistää selkeällä määräajat sisältävällä aikataululla, joka rakennetaan työnositusmallin pohjalta. [5, s ] Riskienhallinta 18 Kuva 7: NASA NPR riskienhallintaprosessi. Mallissa käydään läpi toimenpiteet asteittain riskin tiedostamisesta aina dokumentaatioon asti. [5, s. 346] Riskienhallinta on avaruusohjelmissa jatkuvasti läsnä koko ohjelmistokehityksen aikana, sillä pienetkin virhetilanteet voivat vaarantaa koko lennon onnistumisen. Vaikka ryhmänjohtaja on päävastuussa riskienhallinnan suunnittelusta, on jokainen ryhmän jäsen vastuussa ohjelmiston kehityksestä ja riskien havainnoinista. Kuvassa

25 7 esitetty standardisoitu NASA NPR malli suuren mittakaavan satelliittiprojekteille kuvaa yksinkertaistetusti miten riskejä kuuluisi hallita ja miten riskitekijät vaikuttavat koko projektin läpi. Riskienhallinta alkaa riskintunnistuksesta, jossa pyritään etsimään ja dokumentoimaan kaikki mahdolliset tehtävää vaarantavat tapahtumat. Tästä seuraa analysointi, jossa selvitellään sen todennäköisyys sekä seuraukset tehtävälle. Suunnitelmassa kehitetään toimenpiteet, miten mahdollisen riskin kanssa menetellään sen tapahtuessa sekä siihen liittyvät sykliset jatkotoimenpiteet. Jatkotoimenpiteitä esitettiin luvussa 3.3 FDIR toteutuksen yhteydessä. Riskinseurannalla pyritään puolestaan tarkastelmaan riskin aiheuttamia muita toimenpiteitä, ja millaisia uusia tapahtumia riskienhallinnan jatkotoimenpiteet voivat aiheuttaa. Hallinta itsessään kertoo riskin kaiken saadun informaation perusteella lopulliset toimenpiteet. Tämän toimen kautta voidaan lopulta todeta, että riskin aiheuttamaa haittaa on pienennetty jos hallinta on onnistunut toimenpide. Lopulta riski dokumentoidaan ja raportoidaan koko kehitysryhmän tietoisuuteen, että koko projekti pystyy ottamaan sen olemassaolon huomioon. [5, s ] Kehitysperiaatteet ESA on määrittänyt omat suosituksensa ohjelmistokehitykselle ja sen vaiheille suurissa avaruusohjelmissa. Standardeilla määritellään ohjelmiston suunnittelun vaatimukset ja miten esimerkiksi arkkitehtuuri pitää kehittää. Tällöin muun muassa määrittelyvaiheessa pitää jokainen ohjelmistokomponentti suunnitella siten, että sen alemmat kerrokset toimivat samojen käytettyjen kehitystyökalujen kanssa ristiriidatta. Lisäksi standardi määrittelee kuinka nämä vaiheet dokumentoidaan. Standardiin perustuvien ratkaisujen kautta helpotetaan huomattavasti järjestelmätason suunnittelua ja saadaan paranneltua integraatiota. [14] 19 Kuva 8: Integroitu suunnitteluympäristö. Mallissa jokainen kehitysryhmä pystyy yhteisen ympäristön avulla välittämään tietoa muille kehitysryhmille ja noudattamaan yhteistä järjestelmätason suunnittelua sekä yhteensopivia ratkaisumalleja. [3, s. 659]

26 Yksi standardien pohjalta kehitetty malli on integroitu suunnitteluympäristö (Integrated Design Environment, IDE), jonka tehtävänä on suoraviivaistaa kehitysprosessia sekä selkeyttää ryhmien välistä kommunikaatiota. Tämä pätee koko projektiin, mutta se myös selkeyttää ohjelmistokehityksen periaatteita sekä välittää hyvin tietoa projektin kokonaisvaltaisesta tilasta. [3, s. 659] Tällöin ohjelmistoryhmä pystyy suunnittelemaan ohjelmiston aikaisemmin todetun järjestelmäsuunnitelun periaatteen mukaisesti. Vaikka nanosatelliittiprojekteissa ei standardin mukaista ESA IDE:ä käytettäisi, on samankaltaisia ratkaisuja olemassa paljonkin esimerkiksi keskitetyssä sähköisissä dokumentaatioiden ja muun informaation säilytyspaikassa. Kuvassa 8 on esitetty IDE:n pääidea. Nanosatelliittiprojekteissa pyritään mahdollisimman läpinäkyvään informaation välittämiseen projektien välillä, ja CubeSat-yhteisö luo tähän mahdollisuuden. Toisin kuin monissa yrityksissä missä tiedonkulkua pyritään kilpailijoiden takia estämään, CubeSat-yhteisössä vaihdetaan ajatuksia sekä käytettäviä ratkaisuja aktiivisesti projektien kesken, julkaistaan raportteja sekä järjestetään konferensseja. Yhteisö järjestää kahdesti vuodessa työpajoja, jossa kehittäjät voivat olla aktiivisessa vuorovaikutuksessa keskenään. Tämä läpinäkyvyys pätee myös ohjelmistojen kehitykseen, jossa ohjelmistoratkaisuja sekä jopa valmista ohjelmakoodia voidaan käyttää kahdessa erillisessä projektissa. Kuitenkaan mitään keskinäistä yhtä ohjelmistoratkaisua ei ole olemassa, vaan yhteisön kautta saadaan avoimesti tietoa useista erilaisista ratkaisuista. [1, s. 19] 20

27 21 4 Aalto-1 Tässä luvussa tarkastellaan tapaustutkimuksena Aalto-yliopistossa kehitettävää Aalto- 1 nanosatelliittia. Aluksi esitellään Aalto-1:n tehtävä sekä rakenne kokonaisuudessaan ja lopulta tarkastellaan sen ohjelmiston kehitystä edellisissä luvuissa saatujen tietojen perusteella. Tässä luvussa otetaan esille tärkeimpiä piirteitä siitä miten nanosatelliittien yleiset kehityskäytännöt näkyvät Aalto-1:n ohjelmiston kehityksessä ja mitä eroja siinä on muihin nanosatelliittiprojekteihin verrattuna. Ohjelmistosuunnittelua käsittelevä luku 4.3 perustuu omiin henkilökohtaisiin havaintoihini. 4.1 Yleistä Aalto-1 on Aalto-yliopistossa kehitettävä nanosatelliitti sekä samalla Suomen ensimmäinen satelliitti. Projekti aloitettiin vuonna 2010 ja valmis satelliitti on suunniteltu laukaistavaksi vuoden 2014 loppupuolella. Aalto-1 perustuu CubeSat-standardiin, tarkemmin 3U malliin jossa on yhdistetty yhden akselin suuntaiseksi kolme standardin määrittelemää kuutioita. Tämä tekee sen mitoiksi 10x10x34 senttimetriä sekä massaksi noin 4 kilogrammaa. [29] Kuva 9: Taiteilijan näkemys Aalto-1 satelliitista kiertoradalla. 3D-mallin hahmottanut Pekka Laurila. Nanosatelliitilla on yhteensä kolme hyötykuormaa. Päähyötykuormana on Teknologian tutkimuskeskuksen VTT:n kehittämä kuvaava spektrometri (Aalto-1 Spectral Imager, AaSI) sekä toissijaisina hyötykuormina Helsingin ja Turun yliopistoissa kehitetty sateilynilmaisin (Radiator Monitor, RADMON) sekä Ilmatieteen laitoksen kehittämä sähköpurjeeseen perustuva plasmajarru (Electrostatic Plasma Brake, EPB). Satelliitti on kehitetty pääasiallisesti opiskelijavoimin Aalto-yliopistossa,

28 mutta hyötykuormat ovat kehitetty avaruustekniikan tutkijoiden toimesta yliopiston ulkopuolella. [29] Tietokoneen rakenne Satelliitin keskustietokone on ARM-arkkitehtuuriin perustuva SBC-tietokone ja käyttöjärjestelmänä toimii Linux. Rajoittuneen laskentatehon vuoksi käytettävää Linuxia on kuitenkin kevennetty. Tämän vuoksi ei käytetä perinteisiä GNU-projektin kirjastoja, vaan glibc on korvattu sulautettuihin järjestelmiin tarkoitetulla kevyellä uclibc:llä. Rajoittuneeseen laskentatehoon sekä pieneen kokoon liittyy myös tietokoneen vähäinen virrankulutus. OBC:n kolmas kehitysversio käyttää 32 megatavua SDRAM-muistia sekä kaksi 8 megatavun käynnistysmuistia. Massamuistina on 256 megatavun kokoinen NAND Flash-muisti. [12] [21] Tietokone toimii kahden erillisen prosessorin varassa. Näiden toimintaa säädetään fyysisen vuorottajan (arbiter) avulla. Vuorottajan tehtävä on vaihtaa käytössä olevaa prosessoria, jos toinen prosessoreista ei tietyissä tilanteissa ole käytössä esimerkiksi vikatilanteessa. Kommunikointi hyötykuormien sekä muiden järjestelmien välillä on toteutettu kolmella eri väylällä, jotka ovat I 2 C, UART sekä SPI. Kuvassa 10 on esitetty tietokoneen yksinkertaistettu arkkitehtuuri vuorottajan kanssa ja kuvassa 11 tietokoneen väylät. [12] 22 Kuva 10: Tietokoneen arkkitehtuuri. Vuorottaja kytkee toisen prosessoreista päälle. Tämän jälkeen kaikki laskettu informaatio välitetään vuorottajalle, jonka välittää muualle satelliittiin. [12] 4.2 Ohjelmiston vaatimukset tehtävään Aalto-1:n ohjelmisto on pyritty kehittämään nanosatelliittien ohjelmistokehityksen yleisten periaatteiden mukaisesti mahdollisimman uudelleenkäytettäväksi sekä ro-

Sulautettujen järjestelmien skaala on niin laaja, että on erittäin vaikea antaa yleispätevää kuvausta siitä millainen on sulautettu järjestelmä.

Sulautettujen järjestelmien skaala on niin laaja, että on erittäin vaikea antaa yleispätevää kuvausta siitä millainen on sulautettu järjestelmä. Sulautettujen järjestelmien skaala on niin laaja, että on erittäin vaikea antaa yleispätevää kuvausta siitä millainen on sulautettu järjestelmä. On arvioitu, että maailmassa on tällä hetkellä enemmän sulautettuja

Lisätiedot

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi 1. Luento: Sulautetut Järjestelmät Arto Salminen, arto.salminen@tut.fi Agenda Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu

Lisätiedot

Ohjelmiston testaus ja laatu. Testaustasot

Ohjelmiston testaus ja laatu. Testaustasot Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu

Lisätiedot

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin

AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin AS-0.1103 C-ohjelmoinnin peruskurssi 2013: C-kieli käytännössä ja erot Pythoniin Raimo Nikkilä Aalto-yliopiston sähkötekniikan korkeakoulu - Automaation tietotekniikan tutkimusryhmä 17. tammikuuta 2013

Lisätiedot

Tietokoneen muisti nyt ja tulevaisuudessa. Ryhmä: Mikko Haavisto Ilari Pihlajisto Marko Vesala Joona Hasu

Tietokoneen muisti nyt ja tulevaisuudessa. Ryhmä: Mikko Haavisto Ilari Pihlajisto Marko Vesala Joona Hasu Tietokoneen muisti nyt ja tulevaisuudessa Ryhmä: Mikko Haavisto Ilari Pihlajisto Marko Vesala Joona Hasu Yleisesti Muisti on yksi keskeisimmistä tietokoneen komponenteista Random Access Memory on yleistynyt

Lisätiedot

Turvakriittisen projektin menetelmät ja työkalut

Turvakriittisen projektin menetelmät ja työkalut Turvakriittisen projektin menetelmät ja työkalut 1. Vaatimushallinta Vaatimushallintaan kohdistuu turvaluokitelluissa projekteissa paljon odotuksia. Etenkin jäljitettävyys vaatimuksiin, testaukseen ja

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

S11-09 Control System for an. Autonomous Household Robot Platform

S11-09 Control System for an. Autonomous Household Robot Platform S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on

Lisätiedot

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

Lisätiedot

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Teknillinen korkeakoulu Sähkö- ja tietoliikennetekniikan osasto AS-0.3200 Automaatio- ja systeemitekniikan projektityöt CeilBot 2DoF camera actuator Antti Riksman Sisältö 1 CeilBot 3 2 Projektin tämän

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1

Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1 Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1 Dr. Michael Huelke, BGIA in close collaboration with Philippe Lubineau and Daniel Renault, CETIM Käännös/m atti.sundquist@ sundcon.fi Sichere

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

TIES530 TIES530. Moniprosessorijärjestelmät. Moniprosessorijärjestelmät. Miksi moniprosessorijärjestelmä?

TIES530 TIES530. Moniprosessorijärjestelmät. Moniprosessorijärjestelmät. Miksi moniprosessorijärjestelmä? Miksi moniprosessorijärjestelmä? Laskentaa voidaan hajauttaa useammille prosessoreille nopeuden, modulaarisuuden ja luotettavuuden vaatimuksesta tai hajauttaminen voi helpottaa ohjelmointia. Voi olla järkevää

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Tässä tiivistelmässä standardi tarkoittaa standardia SFS-EN 13849-1.

Tässä tiivistelmässä standardi tarkoittaa standardia SFS-EN 13849-1. 15.8.2007/MS Sovellusohjelmistoja koskevien vaatimusten tiivistelmä standardista SFS-EN 13849-1: Koneturvallisuus. Turvallisuuteen liittyvät ohjausjärjestelmän osat. Osa 1: Yleiset suunnitteluperiaatteet.

Lisätiedot

TK081001 Palvelinympäristö

TK081001 Palvelinympäristö TK081001 Palvelinympäristö 5 opintopistettä!! Petri Nuutinen! 8 opintopistettä!! Petri Nuutinen! RAID RAID = Redundant Array of Independent Disks Useasta fyysisestä kiintolevystä muodostetaan yhteinen

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen

TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op. FT Ari Viinikainen TIEP114 Tietokoneen rakenne ja arkkitehtuuri, 3 op FT Ari Viinikainen Tietokoneen rakenne Keskusyksikkö, CPU Keskusmuisti Aritmeettislooginen yksikkö I/O-laitteet Kontrolliyksikkö Tyypillinen Von Neumann

Lisätiedot

Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan

Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan CC1991:n ja CC2001:n vertailu Tutkintovaatimukset (degree requirements) Kahden ensimmäisen vuoden opinnot Ohjelmistotekniikan

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

Ohjelmistoprojektien hallinta Vaihejakomallit Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli

Lisätiedot

Avoimen lähdekoodin kehitysmallit

Avoimen lähdekoodin kehitysmallit Avoimen lähdekoodin kehitysmallit Arto Teräs Avoimen lähdekoodin ohjelmistot teknisessä laskennassa -työpaja CSC, 25.5.2009 Avoimen lähdekoodin kehitysmallit / Arto Teräs 2009-05-25

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Suomen avoimien tietojärjestelmien keskus COSS ry Avoimen ohjelmistoliiketoimintaverkoston ja -yhteistyön koordinoija Ilkka Lehtinen Matti Saastamoinen Avoimuus ja vapaus - Pieni tulipalo v. 1492 mahdollisti

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

UML -mallinnus TILAKAAVIO

UML -mallinnus TILAKAAVIO UML -mallinnus TILAKAAVIO SISÄLLYS 3. Tilakaavio 3.1 Tilakaavion alku- ja lopputilat 3.2 Tilan nimi, muuttujat ja toiminnot 3.3 Tilasiirtymä 3.4 Tilasiirtymän vai tilan toiminnot 3.5 Tilasiirtymän tapahtumat

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Kurssilla: Johdatus käyttäjäkeskeiseen tuotekehitykseen 23.1.2008 Johanna Viitanen johanna.viitanen@soberit.hut.fi Luennon aiheet Tuotekehityksen

Lisätiedot

Advanced Test Automation for Complex Software-Intensive Systems

Advanced Test Automation for Complex Software-Intensive Systems Advanced Test Automation for Complex Software-Intensive Systems Aiheena monimutkaisten ohjelmistovaltaisten järjestelmien testauksen automatisointi Mistä on kyse? ITEA2-puiteohjelman projekti: 2011-2014

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

Lisätiedot

Ohjelmistojen virheistä

Ohjelmistojen virheistä Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen

Lisätiedot

VHDL/Verilog/SystemC. Jukka Jokelainen 20.10.2009

VHDL/Verilog/SystemC. Jukka Jokelainen 20.10.2009 VHDL/Verilog/SystemC Jukka Jokelainen 20.10.2009 Sisältö Mitä ihmettä on hardwaren ohjelmointi? VHDL Verilog SystemC Analogiaelektroniikan yhdistäminen digitaaliseen maailmaan Yhteenveto ja pohdintaa Hardwaren

Lisätiedot

Teollisuusautomaation standardit Osio 9

Teollisuusautomaation standardit Osio 9 Teollisuusautomaation standardit Osio 9 Osio 1: SESKOn Komitea SK 65: Teollisuusprosessien ohjaus Osio 2: Toiminnallinen turvallisuus: periaatteet Osio 3: Toiminnallinen turvallisuus: standardisarja IEC

Lisätiedot

Tableaun hyödyntäminen Toyota Rahoituksessa

Tableaun hyödyntäminen Toyota Rahoituksessa Tableaun hyödyntäminen Toyota Rahoituksessa Lauri Varonen Toyota Finance Finland Oy Myynti & markkinointi 12.6.2015 Toyota Finance Finland Oy Tehtaan omistama rahoitusyhtiö 3 Toyota Finance Finland Oy

Lisätiedot

Projektisuunnitelma. Projektin tavoitteet

Projektisuunnitelma. Projektin tavoitteet Projektisuunnitelma Projektin tavoitteet Projektin tarkoituksena on tunnistaa erilaisia esineitä Kinect-kameran avulla. Kinect-kamera on kytkettynä tietokoneeseen, johon projektissa tehdään tunnistuksen

Lisätiedot

OHJ-4301 Sulautettu Ohjelmointi

OHJ-4301 Sulautettu Ohjelmointi OHJ-4301 Sulautettu Ohjelmointi (http://www.cs.tut.fi/~sulo/) 5op, to 12-14, TB 109 Arto Salminen, arto.salminen@tut.fi Läpäisyvaatimukset Hyväksytysti suoritetut: Tentti Harjoitustyöt Harjoitustyöt 3

Lisätiedot

9. Luento: Ohjelmistotyö. Tommi Mikkonen, tommi.mikkonen@tut.fi

9. Luento: Ohjelmistotyö. Tommi Mikkonen, tommi.mikkonen@tut.fi 9. Luento: Ohjelmistotyö Tommi Mikkonen, tommi.mikkonen@tut.fi Agenda Johdanto Ristikäännös Testaus ja virheen jäljitys Yleensä Kehitysympäristössä Käyttöympäristössä Laitteiston testaus Iteratiivisesta

Lisätiedot

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

Lisätiedot

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008 Meeri Nieminen Asiakkaan vaihtoehdot Asiakkaan vaihtoehdot EMCS-järjestelmän käyttöön XML-sanomarajapinta oman järjestelmän

Lisätiedot

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma

KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma KONTTI - Teolliset komponenttiohjelmistot Tekesin ETX-ohjelma Strateginen selvityshanke Eila Niemelä 1 Lähtökohta Selvitys suomalaisen teolllisuuden komponenttipohjaisten ohjelmistojen kehittämisestä ja

Lisätiedot

Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori

Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori Insinöörikoulutuksen Foorumi 2012 Seminaariesitelmä Timo Turunen ja Matti Welin Monitori koulutusalarajat ylittävä

Lisätiedot

S12-11. Portaalinosturi AS-0.3200. Projektisuunnitelma 2012. Oleg Kovalev

S12-11. Portaalinosturi AS-0.3200. Projektisuunnitelma 2012. Oleg Kovalev S12-11 Portaalinosturi AS-0.3200 Projektisuunnitelma 2012 Oleg Kovalev Sisällys 1. Työn tavoite... 3 2. Projektin osa-alueet... 3 2.1. Suunnittelu... 3 2.2. Komponenttien hankinta... 3 2.3. Valmistus...

Lisätiedot

PC-LAITTEEN TESTAAMINEN

PC-LAITTEEN TESTAAMINEN PC-LAITTEEN TESTAAMINEN PC-Check-ohjelma Kun laite on koottu, on perusteltua testata sen toiminta ennen käyttöönottoa. Tätä varten on luotu erilaisia ohjelmia, joilla voi laitteen eri osat testata. Yksi

Lisätiedot

Meidän visiomme......sinun tulevaisuutesi

Meidän visiomme......sinun tulevaisuutesi Meidän visiomme... Asiakkaittemme akunvaihdon helpottaminen...sinun tulevaisuutesi Uusia asiakkaita, lisää kannattavuutta ja kehitystä markkinoiden tahdissa Synergy Battery Replacement Programme The Battery

Lisätiedot

Pikaintro käyttöjärjestelmiin

Pikaintro käyttöjärjestelmiin Tietotekniikan laitos Jyväskylän yliopisto TIES406 Tietotekniikan opintojen aktivointi, luento 17.8.2011 Outline Tietokonelaitteisto 1 Tietokonelaitteisto 2 3 4 Outline Tietokonelaitteisto 1 Tietokonelaitteisto

Lisätiedot

CT50A2602 Käyttöjärjestelmät Seminaarityö. Tietokoneen muisti nyt ja tulevaisuudessa

CT50A2602 Käyttöjärjestelmät Seminaarityö. Tietokoneen muisti nyt ja tulevaisuudessa CT50A2602 Käyttöjärjestelmät Seminaarityö Tietokoneen muisti nyt ja tulevaisuudessa Jyrki Eurén Raimo Asikainen Janne Laitinen Teppo Lapinkoski Manu Toivanen Pasi Ruuth Johdanto Taustaa Työn taustana ryhmän

Lisätiedot

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Autonomisen liikkuvan koneen teknologiat. Hannu Mäkelä Navitec Systems Oy

Autonomisen liikkuvan koneen teknologiat. Hannu Mäkelä Navitec Systems Oy Autonomisen liikkuvan koneen teknologiat Hannu Mäkelä Navitec Systems Oy Autonomisuuden edellytykset itsenäinen toiminta ympäristön havainnointi ja mittaus liikkuminen ja paikannus toiminta mittausten

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Ohjelmistoarkkitehtuuriin vaikuttavia tekijöitä. Kari Suihkonen

Ohjelmistoarkkitehtuuriin vaikuttavia tekijöitä. Kari Suihkonen Ohjelmistoarkkitehtuuriin vaikuttavia tekijöitä Kari Suihkonen Ohjelmistoarkkitehtuuriin vaikuttavia tekijöitä Tuote Ohjelmisto Ulkoiset tekijät Sisäiset tekijät 2 Hissin ohjausjärjestelmä ohjelmistotuotteena

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Projektityökaluilla tuottavuutta toimintaan, Espoo, 12.11.2014 Kari Kärkkäinen

Projektityökaluilla tuottavuutta toimintaan, Espoo, 12.11.2014 Kari Kärkkäinen Projektityökaluilla tuottavuutta toimintaan, Espoo, 12.11.2014 Kari Kärkkäinen 1 TEKNISEN PALVELUN KUMPPANI VUODESTA 1986 Comatec Group: Insinööritoimisto Comatec Oy Rantotek Oy Insinööritoimisto Metso

Lisätiedot

5. Luento: Rinnakkaisuus ja reaaliaika. Tommi Mikkonen, tommi.mikkonen@tut.fi

5. Luento: Rinnakkaisuus ja reaaliaika. Tommi Mikkonen, tommi.mikkonen@tut.fi 5. Luento: Rinnakkaisuus ja reaaliaika Tommi Mikkonen, tommi.mikkonen@tut.fi Agenda Perusongelmat Jako prosesseihin Reaaliaika Rinnakkaisuus Rinnakkaisuus tarkoittaa tässä yhteydessä useamman kuin yhden

Lisätiedot

Kieliversiointityökalu Java-ohjelmistoon. Ohje

Kieliversiointityökalu Java-ohjelmistoon. Ohje Kieliversiointityökalu Java-ohjelmistoon Ohje 2/6 SISÄLLYSLUETTELO 1 YLEISTÄ OHJELMASTA... 3 2 PÄÄ-IKKUNA...4 3 YLÄVALIKKO... 4 3.1 TIEDOSTO... 4 3.2 TOIMINTO... 4 3.3 ASETUKSET... 5 3.4 OHJE... 5 4 VÄLILEHDET...5

Lisätiedot

A11-02 Infrapunasuodinautomatiikka kameralle

A11-02 Infrapunasuodinautomatiikka kameralle A11-02 Infrapunasuodinautomatiikka kameralle Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Lassi Seppälä Johan Dahl Sisällysluettelo Sisällysluettelo 1. Projektityön tavoite

Lisätiedot

Tietojenkäsittelyn perusteet 2. Lisää käyttöjärjestelmistä

Tietojenkäsittelyn perusteet 2. Lisää käyttöjärjestelmistä Tietojenkäsittelyn perusteet 2 Lisää käyttöjärjestelmistä 2011-02-09 Leena Ikonen 1 Systeemiohjelmat Systeemiohjelmiin kuuluvat Kääntäjät ja tulkit (+debuggerit) Käyttöjärjestelmä Linkittäjät Lataajat

Lisätiedot

1 YLEISTÄ. Taitaja2002, Imatra Teollisuuselektroniikkatyö Protorakentelu 1.1 PROJEKTIN TARKOITUS

1 YLEISTÄ. Taitaja2002, Imatra Teollisuuselektroniikkatyö Protorakentelu 1.1 PROJEKTIN TARKOITUS Taitaja2002, Imatra Teollisuuselektroniikkatyö Protorakentelu 1 YLEISTÄ 1.1 PROJEKTIN TARKOITUS Tämä projekti on mikrokontrollerilla toteutettu lämpötilan seuranta kortti. Kortti kerää lämpöantureilta

Lisätiedot

POHJOIS-KARJALAN AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma. Mikael Partanen VAATIMUSMÄÄRITTELYT

POHJOIS-KARJALAN AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma. Mikael Partanen VAATIMUSMÄÄRITTELYT POHJOIS-KARJALAN AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma Mikael Partanen VAATIMUSMÄÄRITTELYT Opinnäytetyö Syyskuu 2011 SISÄLTÖ 1 JOHDANTO... 3 2 KÄSITTEET... 3 2.1 Kiinteistöautomaatio... 3 2.2

Lisätiedot

Robottialustan instrumentointi ja käyttöönotto

Robottialustan instrumentointi ja käyttöönotto Niilo Heinonen Hannu Häyrinen Matias Katajamäki Tuomas Pylvänen Robottialustan instrumentointi ja käyttöönotto AS-0.3200 Automaatio- ja systeemitekniikan projektityöt 1. Projektin tavoite Projektin puitteissa

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x

Lisätiedot

Heuristisen arvioinnin muistilista - lyhyt versio

Heuristisen arvioinnin muistilista - lyhyt versio Alla oleva kymmenkohtainen muistilista on sovellettu Jakob Nielsenin heuristisen arvioinnin muistilistasta (Nielsen, 1994), hyödyntäen Keith Instonen wwwpalveluiden arviointiin muokattua samaista listaa

Lisätiedot

Käyttöjärjestelmät: prosessit

Käyttöjärjestelmät: prosessit Käyttöjärjestelmät: prosessit Teemu Saarelainen Tietotekniikka teemu.saarelainen@kyamk.fi Lähteet Stallings, W. Operating Systems Haikala, Järvinen, Käyttöjärjestelmät Eri Web-lähteet Käyttöjärjestelmä

Lisätiedot

Sulautettu tietotekniikka 2007 2013 Ubiquitous Real World Real Time

Sulautettu tietotekniikka 2007 2013 Ubiquitous Real World Real Time Sulautettu tietotekniikka 2007 2013 Ubiquitous Real World Real Time for First Lives 2009 Kimmo Ahola 1 Mitä ohjelma tarjoaa Rahoitusta Resursseja Tietoa Päätösten tukea Verkostoja Luottamusta - Mahdollisuuksia

Lisätiedot

L models. Käyttöohje. Ryhmä Rajoitteiset

L models. Käyttöohje. Ryhmä Rajoitteiset Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Käyttöohje Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1

Lisätiedot

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä Simo Tauriainen www.ponsse.com 25.8.2011 Ponsse-konserni Ponsse Oyj on tavaralajimenetelmän metsäkoneiden myyntiin, tuotantoon, huoltoon ja

Lisätiedot

LÄÄKINTÄLAITTEEN VASTAANOTTOTARKASTUS

LÄÄKINTÄLAITTEEN VASTAANOTTOTARKASTUS LÄÄKINTÄLAITTEEN VASTAANOTTOTARKASTUS SGS Fimko Oy Ilpo Pöyhönen Ilpo.Poyhonen@sgs.com Hermiankatu 12 B 33720 Tampere, Finland Puh. 043 8251326 MISTÄ PUHUTAAN Tarkoitus Vastaako hankinnassa sovitut asiat

Lisätiedot

Teemat. Vaativien säätösovellusten käyttövarmuus automaation elinkaarimallin näkökulmasta. 3.11.2005 Tampere. Vaativat säätösovellukset

Teemat. Vaativien säätösovellusten käyttövarmuus automaation elinkaarimallin näkökulmasta. 3.11.2005 Tampere. Vaativat säätösovellukset PROGNOS vuosiseminaari Kymenlaakson ammattikorkeakoulu Lappeenrannan teknillinen yliopisto Vaativien säätösovellusten käyttövarmuus automaation elinkaarimallin näkökulmasta Tampere Teemat Vaativat säätösovellukset

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden

Lisätiedot

Mikrokontrollerit. Mikrokontrolleri

Mikrokontrollerit. Mikrokontrolleri Mikrokontrollerit S-108.2010 Elektroniset mittaukset 18.2.2008 Mikrokontrolleri integrointi säästää tilaa piirilevyllä usein ratkaisu helpompi ja nopeampi toteuttaa ohjelmallisesti prosessori 4-64 bittinen

Lisätiedot

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi Laadukas vaatimustenhallinta Pekka Mäkinen www.softqa.fi Esityksen perusajatuksia Vaatimuksilla on elinkaari ja ne muuttuvat. Tuotteen elinkaari vaikuttaa vaatimuksiin. Vaatimusten keruussa ja -hallinnassa

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

Kooste kotitehtävien vastauksista. Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011

Kooste kotitehtävien vastauksista. Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011 Kooste kotitehtävien vastauksista Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011 1.) Järjestelmän ylläpitomalli? ja 2.) Järjestelmän jatkokehittämismalli? OPH on omistaja ja ylläpitäjä ja huolehtii

Lisätiedot

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Tuotanto, konseptit, oppiminen yritystoiminnan kehittämisen uudet näkökulmat 25.5.2011 Aalto-yliopiston

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Tehosta valaistustoimintaasi

Tehosta valaistustoimintaasi Tehosta valaistustoimintaasi CityTouch LightPoint Valaistusinfrastruktuurin hallinta CityTouch LightPoint / OMAISUUDENHOITO 3 Tervetuloa valaistuksen hallinnan uuteen, älykkääseen maailmaan. Kaupungin

Lisätiedot

PCI DSS 3.0. Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com. 15.1.2014 Nixu 2014 1

PCI DSS 3.0. Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com. 15.1.2014 Nixu 2014 1 PCI DSS 3.0 Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com 15.1.2014 Nixu 2014 1 Yleistä PCI DSS standardin kehittämisestä PCI SSC (Payment Card Industry Security Standards Council)

Lisätiedot

Tietokoneen rakenne: Harjoitustyö. Motorola MC68030 -prosessori

Tietokoneen rakenne: Harjoitustyö. Motorola MC68030 -prosessori kevät 2004 TP02S-D Tietokoneen rakenne: Harjoitustyö Motorola MC68030 -prosessori Työn valvojat: Seppo Haltsonen Pasi Lankinen RAPORTTI 13.5.2004 Sisällysluettelo sivu Tiivistelmä... 1 Lohkokaavio... 2

Lisätiedot

Perusopetuksen matematiikan pitkittäisarviointi 2005-2012

Perusopetuksen matematiikan pitkittäisarviointi 2005-2012 5.10.2015 MAOL RAUMA / JoJo 1 Perusopetuksen matematiikan pitkittäisarviointi 2005-2012 5.10.2015 MAOL RAUMA / JoJo 2 Opetushallitus Koulutuksen seurantaraportti 2013:4 5.10.2015 MAOL RAUMA / JoJo 3 1

Lisätiedot

Virtuoosi POS-järjestelmien joukossa

Virtuoosi POS-järjestelmien joukossa Virtuoosi POS-järjestelmien joukossa Menestyvä liiketoiminta muistuttaa monin osin huippuunsa viritettyä orkesteria jossa eri osien sopusuhtainen vuorovaikutus ja integrointi luovat sykähdyttävän esityksen.

Lisätiedot

LIITE. asiakirjaan. komission delegoitu asetus

LIITE. asiakirjaan. komission delegoitu asetus EUROOPAN KOMISSIO Bryssel 12.10.2015 C(2015) 6823 final ANNEX 1 PART 6/11 LIITE asiakirjaan komission delegoitu asetus kaksikäyttötuotteiden vientiä, siirtoa, välitystä ja kauttakulkua koskevan yhteisön

Lisätiedot

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013 Virtualisointi Pertti Pennanen DOKUMENTTI 1 (5) SISÄLLYSLUETTELO Virtualisointi... 2 Virtualisointiohjelmia... 2 Virtualisointitapoja... 2 Verkkovirtualisointi... 2 Pertti Pennanen DOKUMENTTI 2 (5) Virtualisointi

Lisätiedot

7. Koneenohjausjärjestelmien suunnittelumallit. OhAr 5.10. 2010 Veli-Pekka Eloranta

7. Koneenohjausjärjestelmien suunnittelumallit. OhAr 5.10. 2010 Veli-Pekka Eloranta 7. Koneenohjausjärjestelmien suunnittelumallit OhAr 5.10. 2010 Veli-Pekka Eloranta Sulautettujen järjestelmien mallikieli Sulake-projekti, 2008-2009 Arkkitehtuuriarviointeja (ATAM) teollisuuskumppanien

Lisätiedot

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.

Lisätiedot

SATAKUNNAN AMMATTIKORKEAKOULU Sähkötekniikan koulutusohjelma. M-koodit Omron servojen ohjauksessa. Luovutettu. Hyväksytty

SATAKUNNAN AMMATTIKORKEAKOULU Sähkötekniikan koulutusohjelma. M-koodit Omron servojen ohjauksessa. Luovutettu. Hyväksytty SATAKUNNAN AMMATTIKORKEAKOULU Sähkötekniikan koulutusohjelma M-koodit Omron servojen ohjauksessa Tekijän nimi Ryhmätunnus Syventävä työ Jouni Lamminen EE01POS 4. vuosikurssin syventävä Luovutettu Hyväksytty

Lisätiedot

Luento 1 (verkkoluento 1) Ohjelman sijainti Ohjelman esitysmuoto Laitteiston nopeus

Luento 1 (verkkoluento 1) Ohjelman sijainti Ohjelman esitysmuoto Laitteiston nopeus Luento 1 (verkkoluento 1) Tietokonejärjestelmä Järjestelmän e eri tasot Ohjelman sijainti Ohjelman esitysmuoto Laitteiston nopeus 1 Tietokone- järjestelmäj ä Käyttäjä Tietokonelaitteisto Oheislaitteet

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

Kojemeteorologia. Sami Haapanala syksy 2013. Fysiikan laitos, Ilmakehätieteiden osasto

Kojemeteorologia. Sami Haapanala syksy 2013. Fysiikan laitos, Ilmakehätieteiden osasto Kojemeteorologia Sami Haapanala syksy 2013 Fysiikan laitos, Ilmakehätieteiden osasto Kojemeteorologia, 3 op 9 luentoa, 3 laskuharjoitukset ja vierailu mittausasemalle Tentti Oppikirjana Rinne & Haapanala:

Lisätiedot

IEC 61508-3 sisältö ja rakenne

IEC 61508-3 sisältö ja rakenne 1(41) IEC 61508-3 sisältö ja rakenne Matti Vuori, Tampereen teknillinen yliopisto Huom! Esityksessä käytetyt standardin suomenkieliset tekstit, termit ja kaaviot ovat standardin käännöksen vielä hyväksymättömästä

Lisätiedot