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-

Concurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo

Concurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

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

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

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

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

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

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

Lisätiedot

Ohjelmiston testaus ja laatu. Testaustasot

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

Lisätiedot

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

Lisätiedot

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

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

Lisätiedot

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

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

Lisätiedot

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

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

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä

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

Software product lines

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

Lisätiedot

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

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

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

Lisätiedot

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

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

Lisätiedot

Turvakriittisen projektin menetelmät ja työkalut

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

Lisätiedot

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

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

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

Lisätiedot

Uudelleenkäytön jako kahteen

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

Lisätiedot

Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1

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

Lisätiedot

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

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

Lisätiedot

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

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

Lisätiedot

AS-0.3200 Automaatio- ja systeemitekniikan projektityöt

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

Lisätiedot

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

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

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

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

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

ELM GROUP 04. Teemu Laakso Henrik Talarmo

ELM GROUP 04. Teemu Laakso Henrik Talarmo ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

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

Lisätiedot

TK081001 Palvelinympäristö

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

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

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

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

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

Lisätiedot

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

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

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

Lisätiedot

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

Rekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä

Rekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,

Lisätiedot

Avoimen lähdekoodin kehitysmallit

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

Lisätiedot

Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan

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

Lisätiedot

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

kertaa samat järjestykseen lukkarissa.

kertaa samat järjestykseen lukkarissa. Opetuksen toistuva varaus ryhmällee TY10S11 - Tästä tulee pitkä esimerkki, sillä pyrin nyt melko yksityiskohtaisesti kuvaamaan sen osion mikä syntyy tiedon hakemisesta vuosisuunnittelusta, sen tiedon kirjaamiseen

Lisätiedot

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

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

Lisätiedot

Projektityö

Projektityö Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:

Lisätiedot

Lyhyesti uusista DI-ohjelmista Isohenkilökoulutus to Opintoasianpäällikkö Mari Knuuttila

Lyhyesti uusista DI-ohjelmista Isohenkilökoulutus to Opintoasianpäällikkö Mari Knuuttila Lyhyesti uusista DI-ohjelmista 2015 Isohenkilökoulutus to 28.8.2014 Opintoasianpäällikkö Mari Knuuttila Master s Programmes at SCI Starting 2015 (in English) Master s Programme in Engineering Physics *

Lisätiedot

Ammatillinen opettajakorkeakoulu

Ammatillinen opettajakorkeakoulu - Ammatillinen opettajakorkeakoulu 2 JYVÄSKYLÄN KUVAILULEHTI AMMATTIKORKEAKOULU Päivämäärä 762007 Tekijä(t) Merja Hilpinen Julkaisun laji Kehittämishankeraportti Sivumäärä 65 Julkaisun kieli Suomi Luottamuksellisuus

Lisätiedot

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

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

Lisätiedot

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

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

Lisätiedot

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

Integrointi. Ohjelmistotekniikka kevät 2003

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

Lisätiedot

Ohjelmistojen virheistä

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

Lisätiedot

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön

Lisätiedot

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

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

Lisätiedot

Ohjelmistoradio. Mikä se on:

Ohjelmistoradio. Mikä se on: 1 Mikä se on: SDR = Software Defined Radio radio, jossa ohjelmisto määrittelee toiminnot ja ominaisuudet: otaajuusalue olähetelajit (modulaatio) olähetysteho etuna joustavuus, jota tarvitaan sovelluksissa,

Lisätiedot

Heuristisen arvioinnin muistilista - lyhyt versio

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

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

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

Lisätiedot

Muistitko soittaa asiakkaallesi?

Muistitko soittaa asiakkaallesi? webcrm Finland 1 webcrm Finland Muistitko soittaa asiakkaallesi? Riippumatta siitä, oletko myyntipäällikkö, markkinoija vai työskenteletkö HR tehtävissä, voit käyttää CRM ratkaisua erilaisiin tarpeisiin.

Lisätiedot

Additions, deletions and changes to courses for the academic year Mitä vanhoja kursseja uusi korvaa / kommentit

Additions, deletions and changes to courses for the academic year Mitä vanhoja kursseja uusi korvaa / kommentit s, s and changes to courses for the academic year 2016 2017 Mikro ja nanotekniikan laitos Department for Micro and Nanosciences S 69, S 87, S 104, S 129, ELEC A3, ELEC C3, ELEC D3, ELEC E3, ELEC L3 T 4030

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

Suomen avoimien tietojärjestelmien keskus COSS ry

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

Lisätiedot

ZigBee-ohjaus kuorma-autolle

ZigBee-ohjaus kuorma-autolle ZigBee-ohjaus kuorma-autolle Juho Frits Petteri Koivumäki 10. helmikuuta 2010 Tavoitteet Projektityössä on tavoitteena rakentaa langaton ZigBee-ohjausverkko kaukoohjattavalle kuorma-autolle (kts. Kuva

Lisätiedot

UCOT-Sovellusprojekti. Testausraportti

UCOT-Sovellusprojekti. Testausraportti UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä

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

PC-LAITTEEN TESTAAMINEN

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

Lisätiedot

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

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

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

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

Lisätiedot

Advanced Test Automation for Complex Software-Intensive Systems

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

Lisätiedot

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

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

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

Projektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus

Projektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Projektisuunnitelma (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena

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

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

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

Lisätiedot

PRINCIPLES OF PROGRAMMING LANGUAGES - DEBUGGER

PRINCIPLES OF PROGRAMMING LANGUAGES - DEBUGGER PRINCIPLES OF PROGRAMMING LANGUAGES - DEBUGGER Group 16 Ville Laatu Henri Myllyoja - i SISÄLLYSLUETTELO 1. DEBUGGERI YLEISESTI... II 1.1 Debuggerin käyttämien... ii 1.2 Debuggerin käynnistäminen... ii

Lisätiedot

OHJ-4301 Sulautettu Ohjelmointi

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

Lisätiedot

VHDL/Verilog/SystemC. Jukka Jokelainen 20.10.2009

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

Lisätiedot

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

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit

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

Lisätiedot

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

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

Lisätiedot

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

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

Virtuoosi POS-järjestelmien joukossa

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

Lisätiedot

Testaajan eettiset periaatteet

Testaajan eettiset periaatteet Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1 T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi

Lisätiedot

Teollisuusautomaation standardit Osio 9

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

Lisätiedot

UML -mallinnus TILAKAAVIO

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

Lisätiedot

Sulautettu tietotekniikka 2007 2013 Ubiquitous Real World Real Time

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

Lisätiedot

Tableaun hyödyntäminen Toyota Rahoituksessa

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

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

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

Lisätiedot

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

Algoritmit 1. Luento 3 Ti Timo Männikkö

Algoritmit 1. Luento 3 Ti Timo Männikkö Algoritmit 1 Luento 3 Ti 17.1.2017 Timo Männikkö Luento 3 Algoritmin analysointi Rekursio Lomituslajittelu Aikavaativuus Tietorakenteet Pino Algoritmit 1 Kevät 2017 Luento 3 Ti 17.1.2017 2/27 Algoritmien

Lisätiedot

LÄÄKINTÄLAITTEEN VASTAANOTTOTARKASTUS

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

Lisätiedot

Perusopetuksen matematiikan pitkittäisarviointi 2005-2012

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

Lisätiedot

Pikaintro käyttöjärjestelmiin

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

Lisätiedot

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

Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla

Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Viimeksi muokattu 5. toukokuuta 2012 Maastotietokannan torrent-jakeluun sisältyy yli 5000 zip-arkistoa,

Lisätiedot

T SEPA - päiväkirja: Design Patterns. ETL työkalu

T SEPA - päiväkirja: Design Patterns. ETL työkalu T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty

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

Tehosta valaistustoimintaasi

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

Lisätiedot

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

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

Lisätiedot