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-

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Julkaisun laji Opinnäytetyö. Sivumäärä 43

Julkaisun laji Opinnäytetyö. Sivumäärä 43 OPINNÄYTETYÖN KUVAILULEHTI Tekijä(t) SUKUNIMI, Etunimi ISOVIITA, Ilari LEHTONEN, Joni PELTOKANGAS, Johanna Työn nimi Julkaisun laji Opinnäytetyö Sivumäärä 43 Luottamuksellisuus ( ) saakka Päivämäärä 12.08.2010

Lisätiedot

Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari Sessio 3. Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan korkeakoulu

Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari Sessio 3. Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan korkeakoulu Automaation ja sähkötekniikan maisteriohjelman Projektityökurssi-case Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari 10.10.2016 Sessio 3 Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan

Lisätiedot

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

Lisätiedot

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen 1 AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen Projektisuunnitelma Tommi Salminen, Hanna Ukkola, Olli Törmänen 19.09.2014 1 Projektin

Lisätiedot

A13-03 Kaksisuuntainen akkujen tasauskortti. Projektisuunnitelma. Automaatio- ja systeemitekniikan projektityöt AS-0.

A13-03 Kaksisuuntainen akkujen tasauskortti. Projektisuunnitelma. Automaatio- ja systeemitekniikan projektityöt AS-0. A13-03 Kaksisuuntainen akkujen tasauskortti Projektisuunnitelma Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Syksy 2013 Arto Mikola Aku Kyyhkynen 25.9.2013 Sisällysluettelo Sisällysluettelo...

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

13/20: Kierrätys kannattaa koodaamisessakin

13/20: Kierrätys kannattaa koodaamisessakin Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy

Lisätiedot

ADM Arkkitehtuuritason automaatio #tdarc

ADM Arkkitehtuuritason automaatio #tdarc ADM Arkkitehtuuritason automaatio #tdarc Kalle Launiala http://abstractiondev.wordpress.com kalle.launiala@citrus.fi Ohjelmistoteollisuus elää murrosta Ohjelmistoteollisuudesta halutaan perusteollisuutta

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus

Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena on luoda valmis sekvenssiohjelma säätötekniikan

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

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

TTY TKT-1110 Mikroprosessorit TKT. HEW-ohjeet ver 1.0

TTY TKT-1110 Mikroprosessorit TKT. HEW-ohjeet ver 1.0 Johdanto Nämä ohjeet opastavat sinut tekemään kurssiin TKT-1110 Mikroprosessorit liittyvät harjoitustyöt. Ohjeet sisältävät kolme osiota. Ensimmäisenä esitellään projektin luonti, mikä tehdään ainoastaan

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia

Lisätiedot

Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta. Harjoite 15: Keskittyminen ja sen hallinta

Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta. Harjoite 15: Keskittyminen ja sen hallinta Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta Harjoite 15: Keskittyminen ja sen hallinta Harjoitteen tavoitteet ja hyödyt Harjoitteen tavoitteena on varmistaa, että

Lisätiedot

Virtualisointiympäristössä on kolme pääosaa: isäntä (host), virtualisointikerros ja vieras (guest).

Virtualisointiympäristössä on kolme pääosaa: isäntä (host), virtualisointikerros ja vieras (guest). 1 Virtualisoinnin avulla voidaan purkaa suora linkki suoritettavan sovelluksen (tai käyttöjärjestelmän tms.) ja sitä suorittavan laitteiston välillä. Näin saavutetaan joustavuutta laitteiston käytössä.

Lisätiedot

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014

ATK tähtitieteessä. Osa 3 - IDL proseduurit ja rakenteet. 18. syyskuuta 2014 18. syyskuuta 2014 IDL - proseduurit Viimeksi käsiteltiin IDL:n interaktiivista käyttöä, mutta tämä on hyvin kömpelöä monimutkaisempia asioita tehtäessä. IDL:llä on mahdollista tehdä ns. proseduuri-tiedostoja,

Lisätiedot

BIM Suunnittelun ja rakentamisen uusiutuvat toimintatavat Teppo Rauhala

BIM Suunnittelun ja rakentamisen uusiutuvat toimintatavat Teppo Rauhala BIM Suunnittelun ja rakentamisen uusiutuvat toimintatavat Teppo Rauhala Proxion 19.10.2015 Proxion BIM historiikkia Kehitystyö lähtenyt rakentamisen tarpeista Työkoneautomaatio alkoi yleistymään 2000 luvulla

Lisätiedot

LAATURAPORTTI Iteraatio 1

LAATURAPORTTI Iteraatio 1 LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja

Lisätiedot

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems Advanced Test Automation for Complex Software-Intensive Systems = Advanced Test Automation for Complex Software- Intensive Systems Pääteemana kompleksisten ja erittäin konfiguroitavien softaintensiivisten

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

Hakeminen. Päivähoitoyksikössä toteutetaan yhteisesti suunniteltua/laadittua toimintakäytäntöä uusien asiakkaiden vastaanottamisessa.

Hakeminen. Päivähoitoyksikössä toteutetaan yhteisesti suunniteltua/laadittua toimintakäytäntöä uusien asiakkaiden vastaanottamisessa. Päivähoidon laatukriteerit Hakeminen Päivähoitoyksikössä toteutetaan yhteisesti suunniteltua/laadittua toimintakäytäntöä uusien asiakkaiden vastaanottamisessa. Henkilökunta tuntee päivähoitoyksikkönsä

Lisätiedot

Ohjelmointi 1 / syksy /20: IDE

Ohjelmointi 1 / syksy /20: IDE Ohjelmointi 1 / syksy 2007 10/20: IDE Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/8 Tämän luennon rakenne

Lisätiedot

AS Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma

AS Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma PiccSIM - TrueTime integrointi Henri Öhman 31.1.2012 1. Projektityön tavoite PiccSIM on Aalto-yliopistolla kehitetty simulointiympäristö,

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Ohjelmistotekniikan pääaine

Ohjelmistotekniikan pääaine Ohjelmistotekniikan pääaine Ari Korhonen 7.11.2012 Ohjelmistotekniikan opetus! Tietotekniikan laitoksessa tutkitaan ja opetetaan laajaalaisesti tieto- ja ohjelmistotekniikan menetelmiä ja niiden soveltamista.

Lisätiedot

Liiketoimintajärjestelmien integrointi

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

Lisätiedot

Tehosta valaistustoimintaasi

Tehosta valaistustoimintaasi Tehosta valaistustoimintaasi CityTouch workflow application Valaistusinfrastruktuurin hallinta CityTouch workflow application / OMAISUUDENHOITO 3 workflow application 04 Yksinkertaisuus 06 Läpinäkyvyys

Lisätiedot

11/20: Konepelti auki

11/20: Konepelti auki Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon

Lisätiedot

Teoreettisen viitekehyksen rakentaminen

Teoreettisen viitekehyksen rakentaminen Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen

Lisätiedot

Aalto-yliopiston laatujärjestelmä ja auditointi. Aalto-yliopisto Inkeri Ruuska, Head of Planning & Management Support

Aalto-yliopiston laatujärjestelmä ja auditointi. Aalto-yliopisto Inkeri Ruuska, Head of Planning & Management Support Aalto-yliopiston laatujärjestelmä ja auditointi Aalto-yliopisto Inkeri Ruuska, Head of Planning & Management Support 16.11.2016 The quality policy principles governing the activities of Aalto University

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

A13-03 Kaksisuuntainen akkujen tasauskortti. Väliaikaraportti. Automaatio- ja systeemitekniikan projektityöt AS Syksy 2013

A13-03 Kaksisuuntainen akkujen tasauskortti. Väliaikaraportti. Automaatio- ja systeemitekniikan projektityöt AS Syksy 2013 A13-03 Kaksisuuntainen akkujen tasauskortti Väliaikaraportti Automaatio- ja systeemitekniikan projektityöt AS-0.3200 Syksy 2013 Arto Mikola Aku Kyyhkynen 22.10.2013 Sisällysluettelo Sisällysluettelo...

Lisätiedot

Linux. 00 Keskeiset piirteet. Unix ja Linux Helsingin ammattikorkeakoulu Stadia Vesa Ollikainen (muokannut M.Mäki-Uuro) Kysymyksiä

Linux. 00 Keskeiset piirteet. Unix ja Linux Helsingin ammattikorkeakoulu Stadia Vesa Ollikainen (muokannut M.Mäki-Uuro) Kysymyksiä Linux 00 Keskeiset piirteet Tux-pingviinin kuva: Larry Ewing, Simon Budig ja Anja Gerwinski Kysymyksiä 1. Mikä Linux on? 2. Kuinka Linux syntyi ja kehittyy? 3. Mitkä ovat Linuxin vahvuudet? 2 1 Linux on

Lisätiedot

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT Rakennusautomaation käytettävyys Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT 2 Oma tausta Perusinsinööri DI, lvi-tekniikka, TKK 1993 Herääminen käytettävyysasioihin noin 2002 Tekniikan

Lisätiedot

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland Epäonnistuminen ei ole vaikeaa Approximately 40% of mission-critical mainframe projects

Lisätiedot

ISO Standardisarja Eräitä ulottuvuuksia Kari Komonen

ISO Standardisarja Eräitä ulottuvuuksia Kari Komonen ISO 55000 Standardisarja Eräitä ulottuvuuksia 6.11.2014 Kari Komonen Eräitä käsitteitä omaisuus, omaisuuserä kohteet, asiat tai kokonaisuudet, joilla on tai voi olla arvoa organisaatiolle omaisuudenhallinta

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

Oppimistavoitteet kurssilla Rinnakkaisohjelmointi

Oppimistavoitteet kurssilla Rinnakkaisohjelmointi 17.5.2006 1/5 Oppimistavoitteet kurssilla Rinnakkaisohjelmointi Rinnakkaisuus ja rinnakkaisuuden soveltaminen tietojenkäsittelyjärjestelmissä Kurssin Tietokoneen toiminta perusteella ymmärtää, miten ohjelman

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

Hankkeen toiminnot työsuunnitelman laatiminen

Hankkeen toiminnot työsuunnitelman laatiminen Hankkeen toiminnot työsuunnitelman laatiminen Online-hanketyöpaja innovaatioiden siirto -hanketta valmisteleville 24.11.2011 Työsuunnitelma Vastaa kysymykseen mitä projektissa tehdään, jotta tuotokset

Lisätiedot

Siirtymä maisteriohjelmiin tekniikan korkeakoulujen välillä Transfer to MSc programmes between engineering schools

Siirtymä maisteriohjelmiin tekniikan korkeakoulujen välillä Transfer to MSc programmes between engineering schools Siirtymä maisteriohjelmiin tekniikan korkeakoulujen välillä Transfer to MSc programmes between engineering schools Akateemisten asioiden komitea Academic Affairs Committee 11 October 2016 Eija Zitting

Lisätiedot

Onnistuuko verkkokurssilla, häh?

Onnistuuko verkkokurssilla, häh? Onnistuuko verkkokurssilla, häh? Draama opetusmenetelmänä ja tuloksena kansainvälinen tieteellinen artikkeli Pentti Haddington, Helsingin yliopisto, Tutkijakollegium Oulun yliopisto, Kielikeskus Kehittämishanke

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Agenda. Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali Harjoitustyöt Demoharjoitus Tentti ja arvostelu Muuta?

Agenda. Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali Harjoitustyöt Demoharjoitus Tentti ja arvostelu Muuta? OHJ-4301 Sulautettu Ohjelmointi (http://www.cs.tut.fi/~sulo/) 5op, to 12-14, 14, TB 109 Arto Salminen, arto.salminen@tut.fi Agenda Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali

Lisätiedot

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

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

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus 10.2.2016 Hakuprosessi Rahoitusta tutkimukseen ja innovointiin 4. Lataa hakemus osallistujaportaaliin

Lisätiedot

Tietorakenteet ja algoritmit

Tietorakenteet ja algoritmit Tietorakenteet ja algoritmit Kurssin sisältö pääpiirteittäin Tarvittavat pohjatiedot Avainsanat Abstraktio Esimerkkiohjelman tehtäväkuvaus Abstraktion käyttö tehtävässä Abstrakti tietotyyppi Hyötyjä ADT:n

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

21 May 15 June In Rovaniemi and Pori www.ramk.fi/summerschool www.samk.fi/summerschool. Levi HL ja JH

21 May 15 June In Rovaniemi and Pori www.ramk.fi/summerschool www.samk.fi/summerschool. Levi HL ja JH 21 May 15 June In Rovaniemi and Pori www.ramk.fi/summerschool www.samk.fi/summerschool TAUSTAA RAMKIN JA SAMKIN YHTEISTYÖLLE KESÄKOULUSSA Magellan verkosto, USA RAMK ja SAMK ainoat korkeakoulut ko. verkostossa

Lisätiedot

Kansallinen palveluväylä - yleiskuva ja tilanne nyt , Jyväskylä Pauli Kartano Valtiovarainministeriö, JulkICT

Kansallinen palveluväylä - yleiskuva ja tilanne nyt , Jyväskylä Pauli Kartano Valtiovarainministeriö, JulkICT Kansallinen palveluväylä - yleiskuva ja tilanne nyt 20.5.2014, Jyväskylä Pauli Kartano Valtiovarainministeriö, JulkICT Kansallinen Palveluarkkitehtuuri -ohjelma 2014-2017 Perustietovarannot Julkisen hallinnon

Lisätiedot

.NET ajoympäristö. Juha Järvensivu 2007

.NET ajoympäristö. Juha Järvensivu 2007 .NET ajoympäristö Juha Järvensivu juha.jarvensivu@tut.fi 2007 Käännösprosessi C# lähdekoodi C# kääntäjä CILtavukoodi JITkäännös Ajettava natiivikoodi Kehitysympäristössä ohjelmoijan toimesta Ajonaikana.NET

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka

Lisätiedot

Liikehavaintojen estimointi langattomissa lähiverkoissa. Diplomityöseminaari Jukka Ahola

Liikehavaintojen estimointi langattomissa lähiverkoissa. Diplomityöseminaari Jukka Ahola Liikehavaintojen estimointi langattomissa lähiverkoissa Diplomityöseminaari Jukka Ahola ESITYKSEN SISÄLTÖ Työn tausta Tavoitteen asettelu Johdanto Liikehavaintojen jakaminen langattomassa mesh-verkossa

Lisätiedot

AVL-puut. eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta

AVL-puut. eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta AVL-puut eräs tapa tasapainottaa binäärihakupuu siten, että korkeus on O(log n) kun puussa on n avainta pohjana jo esitetyt binäärihakupuiden operaatiot tasapainotus vie pahimmillaan lisäajan lisäys- ja

Lisätiedot

JWT 2016 luento 11. to 21.4.2016 klo 14-15. Aulikki Hyrskykari. PinniB 1097. Aulikki Hyrskykari

JWT 2016 luento 11. to 21.4.2016 klo 14-15. Aulikki Hyrskykari. PinniB 1097. Aulikki Hyrskykari JWT 2016 luento 11 to 21.4.2016 klo 14-15 Aulikki Hyrskykari PinniB 1097 1 Viime luennolla o AJAX ja JSON, harjoitustyön tehtävänanto, vierailuluento avoimesta datasta Tänään o APIt rajapinnoista yleisesti

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

14. Luento: Kohti hajautettuja sulautettuja järjestelmiä. Tommi Mikkonen,

14. Luento: Kohti hajautettuja sulautettuja järjestelmiä. Tommi Mikkonen, 14. Luento: Kohti hajautettuja sulautettuja järjestelmiä Tommi Mikkonen, tommi.mikkonen@tut.fi Agenda Johdanto Hajautettujen järjestelmien väyliä LON CAN Pienen laitteen sisäinen hajautus OpenCL Network

Lisätiedot

Tähtitieteen käytännön menetelmiä Kevät 2009

Tähtitieteen käytännön menetelmiä Kevät 2009 Tähtitieteen käytännön menetelmiä Kevät 2009 2009-01-12 Yleistä Luennot Luennoija hannu.p.parviainen@helsinki.fi Aikataulu Observatoriolla Maanantaisin 10.00-12.00 Ohjattua harjoittelua maanantaisin 9.00-10.00

Lisätiedot

Kyselytutkimus standardeista ja. Mikko Turku / Kyselytutkimus standardeista ja. niiden käytöstä elintarvikevalvonnassa

Kyselytutkimus standardeista ja. Mikko Turku / Kyselytutkimus standardeista ja. niiden käytöstä elintarvikevalvonnassa Kyselytutkimus standardeista ja niiden käytöstä elintarvikevalvonnassa 1 Aineisto ja menetelmä Kysely yrityksille ja valvojille keväällä 2015 Osa kysymyksistä yhteisiä Tietämykset ja käsitykset standardeista

Lisätiedot

Kontrollipolkujen määrä

Kontrollipolkujen määrä Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot

MetSta ry» Verkkojulkaisut» Koneturvallisuus» Artikkelit» Nro 05/2010» 13.4.2010» Martti Launis, Työterveyslaitos

MetSta ry» Verkkojulkaisut» Koneturvallisuus» Artikkelit» Nro 05/2010» 13.4.2010» Martti Launis, Työterveyslaitos kirjoittaja: TaM Martti Launis, vanhempi asiantuntija, Työterveyslaitos otsikko: Miten koneen käyttöön liittyvät työtehtävät suunnitellaan ihmisille sopiviksi? SFS-EN 614-2 Ergonomiset suunnitteluperiaatteet,

Lisätiedot

How to Support Decision Analysis with Software Case Förbifart Stockholm

How to Support Decision Analysis with Software Case Förbifart Stockholm How to Support Decision Analysis with Software Case Förbifart Stockholm (Valmiin työn esittely) 13.9.2010 Ohjaaja: Prof. Mats Danielson Valvoja: Prof. Ahti Salo Tausta -Tukholman ohikulkutien suunnittelu

Lisätiedot

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla Tervetuloa mukaan Sisällysluettelo yleistä... 3 MY KNX... 3 Kirjaudu KNX organisaation kotisivulle... 4 Partnerluettelo... 5

Lisätiedot

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

Lisätiedot

Yhteenveto. Ymmärrä kokonaisuus

Yhteenveto. Ymmärrä kokonaisuus Mikko Jokela Yhteenveto Poista tiedon monistaminen Järjestele hallittaviin kokonaisuuksiin Mahdollista informaation kulku Luo tiedolle saavutettavuus Käännä oikealle kielelle Ymmärrä kokonaisuus Yritykset

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

Ohjelmistoarkkitehtuurit. Syksy 2010 Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin

Lisätiedot

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/ Koodaamme uutta todellisuutta FM Maarit Savolainen 19.1.2017 https://blog.edu.turku.fi/matikkaajakoodausta/ Mitä on koodaaminen? Koodaus on puhetta tietokoneille. Koodaus on käskyjen antamista tietokoneelle.

Lisätiedot

Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä

Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti - tiivistelmä Ympäristölainsäädäntö seuranta ja vaikuttaminen Loppuraportti Tiivistelmä Huhtikuu 2007 1 1 Hankkeen tausta ja tarpeet EU:n ympäristösäätely

Lisätiedot

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laatudokumentoinnin kehittäminen, sähködokumentaatio-mapin sisältö. 3D-mallinnus ja sen käyttö Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laadunhallintaan

Lisätiedot

Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta

Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta 30-60 minuuttia valmentajan aikaa, ja Harjoituslomake ja kynä noin 1-2 viikkoa oman työn tarkkailuun. Tavoitteet Harjoite on kokonaisvaltainen

Lisätiedot

Suoritusten seuranta ja opiskelijan edistyminen

Suoritusten seuranta ja opiskelijan edistyminen Suoritusten seuranta ja opiskelijan edistyminen Opettaja voi halutessaan ottaa käyttöön toiminnon, jossa hän määrittelee etenemispolun opintojaksolle. Hän voi jokaisen aktiviteetin kohdalla määritellä

Lisätiedot

S14 09 Sisäpeltorobotti AS Automaatio ja systeemitekniikan projektityöt. Antti Kulpakko, Mikko Ikonen

S14 09 Sisäpeltorobotti AS Automaatio ja systeemitekniikan projektityöt. Antti Kulpakko, Mikko Ikonen S14 09 Sisäpeltorobotti AS 0.3200 Automaatio ja systeemitekniikan projektityöt Antti Kulpakko, Mikko Ikonen 1. Projektin tavoitteet Projektin tavoitteena on toteuttaa ohjelmisto sisäpeltorobottiin seuraavien

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,

Lisätiedot

Polaarisatelliittidataan perustuva lumentunnistusalgoritmi (valmiin työn esittely)

Polaarisatelliittidataan perustuva lumentunnistusalgoritmi (valmiin työn esittely) Polaarisatelliittidataan perustuva lumentunnistusalgoritmi (valmiin työn esittely) 24.01.2011 Ohjaaja: Niilo Siljamo, Ilmatieteen Laitos Valvoja: Harri Ehtamo Esityksen sisältö Termejä Tausta Menetelmät

Lisätiedot

RIVER projekti. Idea projektin takana

RIVER projekti. Idea projektin takana RIVER projekti Idea projektin takana This project has been funded with support from the European Commission (Reference: 517741-LLP-1-2011-1-AT-GRUNDTVIG-GMP) This publication reflects the views only of

Lisätiedot

Luento 0: Kurssihallinto Tietokoneen rakenne (2 ov / 4 op) Syksy 2006

Luento 0: Kurssihallinto Tietokoneen rakenne (2 ov / 4 op) Syksy 2006 Luento 0 581365 Tietokoneen rakenne (2 ov / 4 op) Syksy 2006 Teemu Kerola Helsingin yliopisto Tietojenkäsittelytieteen laitos Luento 0-1 Tietokoneen rakenne Asema opetuksessa u 1999 HajaTilin pakollinen,

Lisätiedot

Hybridivalvomon tilatiedon hallinnan kehittäminen

Hybridivalvomon tilatiedon hallinnan kehittäminen AS- 0.3200 Automaatio- ja systeemitekniikan projektityöt 23.9.2014 Projektisuunnitelma Työn suorittaja: Niklas Paganus Työn ohjaaja: Leena Salo Hybridivalvomon tilatiedon hallinnan kehittäminen Sisällysluettelo

Lisätiedot

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } } Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.

Lisätiedot

VAHTIn riskien arvioinnin ja hallinnan ohjeen sekä prosessin uudistaminen - esittely

VAHTIn riskien arvioinnin ja hallinnan ohjeen sekä prosessin uudistaminen - esittely VAHTIn riskien arvioinnin ja hallinnan ohjeen sekä prosessin uudistaminen - esittely 13.12.2016 Ari Uusikartano, UM, ryhmän puheenjohtaja VAHTI Taustaa 13.12.2016 Vanha ohje 7/2003 - Varsin kattava ja

Lisätiedot

Suoritusten seuranta ja opiskelijan edistyminen

Suoritusten seuranta ja opiskelijan edistyminen Suoritusten seuranta ja opiskelijan edistyminen Opettaja voi halutessaan ottaa käyttöön toiminnon, jossa hän määrittelee etenemispolun opintojaksolle. Hän voi jokaisen aktiviteetin kohdalla määritellä

Lisätiedot

AU Automaatiotekniikka. Toimilohko FB

AU Automaatiotekniikka. Toimilohko FB AU080401 Automaatiotekniikka Toimilohko FB Tarkoitus Dokumentissa kuvataan, mikä on toimilohko (FB) miten toimilohko muodostetaan ja miten sitä sovelletaan S7 ohjelmointiympäristössä (STEP7) mitä etua

Lisätiedot

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista

Lisätiedot

Power Steering for ATV

Power Steering for ATV AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Power Steering for ATV 27.1.2014 Juuso Meriläinen Antti Alakiikonen Aleksi Vulli Meriläinen, Vulli, Alakiikonen 1/6 Projektin tavoite Projektityössä

Lisätiedot

30 Opetussuunnitelma OSAAMISEN ARVIOINTI ARVIOINNIN KOHTEET JA AMMATTITAITOVAATIMUKSET OSAAMISEN HANKKIMINEN. järjestelmätyöt: työskentely

30 Opetussuunnitelma OSAAMISEN ARVIOINTI ARVIOINNIN KOHTEET JA AMMATTITAITOVAATIMUKSET OSAAMISEN HANKKIMINEN. järjestelmätyöt: työskentely Hyväksymismerkinnät 1 (7) Näytön kuvaus: Opiskelija osoittaa osaamisensa ammattiosaamisen näytössä toimimalla tieto- ja tietoliikennealan yrityksissä erilaisissa työkokonaisuuksissa ja tehtävissä sekä

Lisätiedot