Satsning på modellbaserad utveckling inom Saab Aerosystems sid 8. Modellering av mjukvara till obemannad helikopter sid 9

GER INSIKT I TID TEMA: MODELLBASERAD UTVECKLING I PRAKTIKEN Satsning på modellbaserad utveckling inom Saab Aerosystems sid 8 Modellering av mjukvara till obemannad helikopter sid 9 Praktiska tips för modellbaserat arbete sid 12

Stor tilltro till MBSE på Saab Training Systems sid 6 Satsning på modellbaserad utveckling inom Saab Aerosystems sid 8 Praktiska tips för modellbaserat arbete sid 12 GER INSIKT I TID TEMA: MODELLBASERAD UTVECKLING I PRAKTIKEN Redaktion Ansvarig utgivare Marie Bredberg OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknik- och samhällsutveckling. Redaktionsråd Göran Carlzon, Erichs Communications Magnus Skoog Anna Stenquist Johan Svahn Redaktör Karin Rydman, Linköping karin.rydman@combitech.se Nätvariant av OnTime www.ontime.nu Innehåll Ledare...3 Temaintroduktion...4 Stor tilltro till MBSE på Saab Training Systems...6 Satsning på modellbaserad utveckling inom Saab Aerosystems...8 Modellering av mjukvara till obemannad helikopter...9 När fel inte får förekomma modellering av säkerhetskritiska system...10 Praktiska tips för modellbaserat arbete...12 Combitech Jönköping Box 1017 551 11 Jönköping (Besöksadress: Slottsgatan 14) Linköping Teknikringen 9 583 30 Linköping Växjö Ljungadalsgatan 2 351 80 Växjö Övriga orter: Arboga, Borlänge, Enköping, Göteborg, Helsingborg, Hässleholm, Karlstad, Kista, Kristianstad, Malmö, Norrköping, Norrtälje, Trollhättan, Västerås, Örebro och Östersund. E-post info@combitech.se Hemsida www.combitech.se Produktion Erichs Communications AB, Linköping Grafisk design PO. Kommunikation AB Tryck CT Impress Combitech AB är ett av Sveriges ledande konsultföretag inom systemutveckling, systemintegration, informations- och samhällssäkerhet. Företagets verksamhetsidé är att som attraktiv partner skapa värdefulla och innovativa lösningar för våra kunder. Kunderna fi nns främst inom branscherna försvar, fordon, telekom samt statliga verk och myndigheter med ansvar för infrastrukturer i samhället. Långsiktighet och partnerskap samt närhet till våra kunder är viktigt för Combitech. Därför fi nns Combitech på 19 orter i Sverige och har ca 750 medarbetare. Combitech ingår som ett obundet konsultföretag i Saab-koncernen ett av världens ledande högteknologiska företag med huvudsaklig verksamhet inom försvar, fl yg och rymd. 2 Combitech

MODELLBASERAD UTVECKLING I PRAKTIKEN Modellen ett verktyg för konkret abstraktion Vi ser alla i vilken riktning vi är på väg: Mer funktionalitet, mer kompatibilitet, mer kommunikation, smartare interaktion, mer prestanda mer av allt. Och under allt detta förskjuts alltmer av produktens värde och funktion över till programvara. Programvaran och dess arkitektur blir alltmer central affärskritisk rentutav. Komplexiteten ökar, överskådligheten blir en allt större utmaning. Men vår mänskliga förmåga att hantera komplexitet har inte ökat. Så vi skaffar oss verktyg med allt längre skaft. Ingenjörsdriften Modellbaserad systemutveckling, det har varit vår ambition åtminstone sedan slutet av 1980-talet. Varför? Förmodligen är det en av ingenjörens hetaste inneboende drömmar att kunna åstadkomma en helt entydig och vattentät modell av funktionen som ska byggas. Exakt. Så att inga mer misstag kan göras. En längtan efter överblick och kontroll trots komplexiteten. Ingen modell garanterar att jag inte glömt eller förbisett något väsentligt fall, men vi kan ändå bli allt säkrare på att det vi faktiskt tagit med och beskrivit verkligen hänger samman. Mognad Under 1990-talet introducerades många verktyg, men de krävde mycket av användaren och organisationen. Vi gick på många minor. Verktygen har mognat väsentligt sedan dess, samtidigt som det börjar synas en alltmer enad riktning avseende de formalismer som används. De flesta verktyg förhåller sig till UML på ett eller annat sätt. Verktygens kodgeneratorer har blivit allt bättre i många fall är den automatgenererade koden lika effektiv som den handskrivna. Nu har alltfler företag upptäckt att MBSE är moget för användning, vilket vi vill visa genom artiklarna i detta nummer. Behåll nykterheten Modellbaserad systemutveckling erbjuder oss en större förmåga att hantera en ständigt ökande komplexitet, men det är ingen silver bullet som löser alla våra problem. Systemutveckling kommer alltid att vara svårt. Glöm inte bort att programvaran vi rör oss med är genuint abstrakt: viktlös, saknar utsträckning den är helt enkelt ofysikalisk. Den franske upplysningsfilosofen Denis Diderot kunde lika gärna ha vänt sig till oss när han år 1769 sa: Varje abstraktion är bara ett tecken tomt på föreställning. Grafiska modeller ger oss fantastiska möjligheter till ökad föreställning av den nyttiga funktionen, som ligger begravd i mjukvara. Men vi får inte stirra oss blinda på verktygen. Det är fortfarande människor av kött och blod som utvecklar produkter. Människor som behöver en handfast förståelse om varför produkten byggs, vems problem den löser, och som måste förstå sin egen uppgift i ett stort utvecklingsprojekt. Den avgörande kunskapen kommer aldrig att finnas lagrad i något neutralt format i några verktyg den finns i människor! Göran Backlund Business Development, Combitech Combitech 3

TEMAINTRODUKTION: MODELLBASERAD UTVECKLING I PRAKTIKEN Det kan dröja till andra eller tredje projektet innan de verkliga vinsterna syns Hur ska man gå tillväga för att införa modellbaserad utveckling i en organisation och vilka fallgropar finns det som bör undvikas? Modellbaserad utveckling har en del klara fördelar jämfört med traditionell utveckling och lär bli nästa steg inom mjukvaruutvecklingen. En fördel är att det går att höja abstraktionsnivån med modellbasering, vilket kommer att krävas i takt med att systemen blir allt mer komplexa. Andra fördelar är att modellbasering ger betydligt mer återanvändbar kod plus att det blir lättare att kommunicera mellan medlemmarna i ett projekt om man använder en modell. En bild säger mer än tusen ord. Med det sagt så finns det en del saker att tänka på för att lyckas med införandet med modellbaserad utveckling i en organisation. En viktig sak är att det gäller att få med sig hela organisationen för att övergången ska bli lyckad. Det gäller att ha en genomtänkt strategi för vad man vill åstadkomma med modellbaserad utveckling och sedan kommunicera ut det till alla berörda. De olika faserna vid införande av modellbasering En risk är att man blir överentusiastisk över möjligheterna och försöker gå för fort fram utan att verkligen förankra det man vill göra hos alla inblandade. Med en Model Maturity Model, MMM, kan man illustrera de olika faserna införandet av modellbasering kan genomgå. Första steget är hjältenivån. Här finns det några entusiaster som fastnat för modellbasering medan resten av organisationen använder traditionella metoder. De blir något av modellbaserade öar i ett hav av traditionell utveckling. Risken i det här skedet är att hela projektet dör om några av eldsjälarna slutar. Nästa nivå är att några börjar beskriva metodkedjor för arbetet och användningen av modellerna. Här kan det bli en kollision mellan det modellbaserade sättet att se på utvecklingsarbetet och det traditionella synsättet. Folk tycker om att jobba som de är vana vid och för att komma förbi det här steget krävs det mycket information om vad man vill uppnå i slutänden och varför det går bättre att uppnå det med modellbaserad utveckling. I nivå tre ska metodkedjorna ensas ihop med varandra och de processer som företaget använder för systemutveckling. Det handlar alltså om att beskriva och dokumentera det arbetssätt som ska användas inom organisationen. Här kan det bli slitningar om starka viljor börjar dra åt olika håll. Även om alla är inne på att modellbaserad utveckling är rätt väg att gå är det inte säkert att de ser exakt likadant på hur den ska användas på bästa sätt. Om man har för bråttom i det här skedet och några upplever att de blir överkörda kan det leda till stora problem, så här kan det vara läge att ta det lite lugnt och låta alla komma till tals ordentligt innan några beslut fattas. Efter det gäller det att integrera modellbaseringen med projektstyrningen och slutligen att optimera användningen av modeller genom att kombinera verktyg och metodkedjor på ett optimalt sätt vilket också kan ha sina sidor. Magnus Skoog har lång erfarenhet av projekt inom bl a försvarsoch telekomindustri. För tillfället har han ett uppdrag på Saab Aerosystems som handlar om att införa en modellbaserad process till utvecklingen av den förarlösa helikoptern Skeldar. Satsa på små iterativa steg Det krävs ett annat sätt att tänka på projektstyrning för att lyckas med modellbasering. Klassiskt bygger projektstyrning mycket på att man sätter upp olika milstolpar som ska vara klara inom en viss tid. Det kanske rör sig om en viss funktion som ska vara färdig, dokumenterad och granskad vid en viss tidpunkt. Med modellbasering förfinas modellen kontinuerligt och växer fram över tiden. Det är svårt att sätta milstolpar som ska uppnås om målet flyttas under resans gång. En metod skulle kunna vara att utveckla modellen väldigt långt innan den mer handfasta utvecklingen började, men det skulle säkert upplevas som tungt av många att jobba länge med en modell utan att få testa om den verkligen fungerade. En bättre lösning kan vara att tänka lite annorlunda och ta små, små iterativa steg och ha många små delmål som man kan stämma av mot kontinuerligt. Istället för ett fåtal stora mätpunkter inför man istället många mindre där det snabbt går att lägga till nya eller ändra på gamla delmål. Något som kan ställa högre krav på flexibilitet hos projektledningen. Välj rätt verktyg Att välja rätt verktyg att arbeta med är också mycket viktigt för att införa modellbaserad utveckling på ett bra sätt. Det man inte ska göra är att bara välja ett verktyg som verkar vara det tekniskt bästa eller mest fullständiga verktyget utan att tänka på vad det egentligen ska användas till. Det är viktigt att ställa frågor och se vad man vill åstadkomma innan man börjar titta på verktyg. Hur ska processen se ut och vilket sorts verktyg behövs för att understödja den? Man ska inte heller räkna med att ett verktyg 4 Combitech

MODELLBASERAD UTVECKLING I PRAKTIKEN kommer att fungera för allt. Det gäller att ställa sig frågan om det ska användas för analys eller kodning och så vidare. Olika verktyg har olika styrkor. Så sätt verktygen i perspektiv och tänk på att informationsflödet mellan verktygen ska bli effektivt om flera olika verktyg behöver användas. eller tredje projektet innan man ser de verkliga vinsterna med modellbaserad utveckling. Vinsterna i det här fallet är bland annat att arbetet med dokumentation och granskning minskar om man använder modellbaserad utveckling. Målet är att låta utvecklarna utveckla istället för att dokumentera. Problematik i att mäta prestanda i tid En annan sak man ska tänka på när det gäller modellbaserad utveckling är att prestandan på systemen kan bli annorlunda än om man använder traditionella metoder. Overheaden ökar med modellbasering vilket innebär att det krävs mer minne och att belastningen på processorn ökar. Det finns exempel på att system som utvecklats med modellbasering får betydligt sämre prestanda än motsvarande system som skapats med traditionell utveckling. Nu betyder inte det att det är omöjligt att få bra prestanda med modellbasering, men det gäller att vara medveten om problematiken och att mäta och uppskatta prestanda i tid. Genom att identifiera vilka delar av koden som är speciellt prestandakänsliga kan man undvika sådana här fallgropar. Dessa delar kan behöva optimeras. Prestandaoptimeringen kan göras på olika sätt genom exempelvis datastruktur, algoritmval, inline-kod, kompileringsdirektiv med mera. Detta minskar läsbarheten så det är endast lämpligt att göra vid behov. Ekonomisk vinst långsiktig Något som företagsledningen säkert är intresserad av är när man kan vänta sig att se någon utdelning av den investering det ändå är att införa modellbaserad utveckling. Här är det viktigt att inte ha några orealistiska förväntningar utan att inse att det måste få ta lite tid. Det går inte att förvänta sig att se några ekonomiska vinster redan i den första piloten. Det är först när man för ihop modellbaserad utveckling med sina systemutvecklingsprocesser så att hela informationsflödet hänger ihop som man ser de stora vinsterna. För många organisationer kan det säkert dröja till andra Det handlar om ett paradigmskifte Det gäller att inse att det hela handlar om ett paradigmskifte där organisationen måste få tid att vänja sig vid förändringarna. Det bästa man kan göra vid införandet av modellbaserad utveckling är att skynda långsamt och inte försöka stressa fram en övergång. Det kommer att krävas några projekt innan modellanvändningen är optimerad och framför allt måste det finnas ett långsiktigt mål som alla är medvetna om så de vet varför det kommer att löna sig för dem att byta arbetssätt. Reportagen visar svårigheter och framgångar De reportage som presenteras i detta nummer pekar på några konkreta erfarenheter av att införa ett modellbaserat arbetssätt. Gemensamt är drivkraften att öka utvecklingseffektiviteten, om inte initialt så på sikt, och att ledningen uttalat stödjer skiftet i utvecklingsmetodik. Trots att införandet inneburit investeringar i utbildningsaktiviteter och en viss startsträcka med de nya verktygen har slutresultat visat sig gott, både för utvecklare och produkt. Och även om inte MBSE genererar bättre designidéer, pekar exemplen på att det i längden blir effektivare och lättare att utveckla, samtidigt som svaga punkter upptäcks tidigare. Combitech 5

AV: BODIL KNUTHAMMAR Stor tilltro till MBSE på Saab Training Systems Att införa MBSE på Saab Training Systems har krävt investeringar i verktyg, utbildningsinsatser och ett nytt sätt att tänka hos systemutvecklarna. Vinsterna förväntas komma i form av bättre kvalitet, mindre mängd kod att underhålla, och ett system som är lättare att testa. Men det är krassa ekonomiska kalkyler som är huvudskälet till att Saab Training Systems valt att satsa på MBSE. Vi räknar med att öka effektiviteten i systemutvecklingen med 30 procent, säger Niclas Vilsek, chef för systemdesignavdelningen på Saab Training Systems. Saab Training Systems utvecklar militära övningssystem, alltifrån lasersimulatorer till instrumenterade stridsträningsanläggningar som populärt kan beskrivas som en avancerad variant av Laserdome. Systemet är uppbyggt kring olika typer av spelare soldat med eller utan fordon, helikopter, antitankvapen etc som förses med laserdetektorer och GPS. Varje vapen har en lasersändare. Via datorn kan man följa och analysera övningen i detalj, där övningen spelas upp på ett sätt som för tankarna till dataspelet Battlefield 2. Till varje spelartyp hör speciell programvara och olika varianter av hårdvara. För ett par år sedan startade Saab Training Systems en förstudie i syfte att ta fram hård- och mjukvara som är gemensam för samtliga spelartyper. Studien innehöll tre delar att ta fram en ny hårdvaruplattform, att se över och välja ett nytt operativsystem och drivrutiner och att införa modellbaserad utveckling med UML (Unified Modeling Language) och C++. Med vår MBSE-satsning hakar vi på den generella teknikutveckling som sker i branschen och där vi tror att vi kan få störst utväxling, säger Niclas Vilsek som är projektägare och tillika chef för systemdesignavdelningen på Saab Training Systems. Vid utvecklingen av militära övningssystem används nu modellbaserad utveckling. Anledningen är strikt ekonomisk. När resultaten kommer blir det lättare att få acceptans för MBSE, säger Niclas Vilsek. Saab AB Mentorsroll viktig En projektgrupp bestående av fem-tio utvecklare från olika avdelningar sattes samman. Combitech involverades i projektet från starten i en expert- och mentorsroll. Det var tydligt uttalat från vår sida att vi ville ha med en mentor som kunde stötta, skola in nya utvecklare och bistå oss i arkitekturfrågor, säger Niclas Vilsek. Efter den inledande förstudien var tanken att man skulle ha fortsatt med kravbearbetning och förberedelser för implementation, men en intressant order från en amerikansk kund gjorde att Saab Training Systems valde att gå in i ett skarpt projekt direkt. Vi trodde på produkten och arbetssättet och bedömde att vi skulle kunna starta direkt. Trots att det för alla inblandade blev en mycket tuffare resa än vi kunnat förutse anser vi ändå att det var rätt beslut, trots allt tal om big bang, säger Niclas Vilsek. Kunden var med rätta skeptisk till en början, då man såg en risk i att införa nya verktyg och arbetssätt. Men med facit i hand borde de vara nöjda, menar utvecklarna. Ett gott tecken är att utvecklarna ännu inte har behövt gå in och rätta någonting efter leveransen. Startsträckan kan vara lång när man ska börja arbeta med MBSE, särskilt för den 6 Combitech

MODELLBASERAD UTVECKLING I PRAKTIKEN som är van vid traditionell programmering och saknar erfarenhet av objektorientering. Projektmedlemmarna på Saab Training hade en krävande start med en rad nya verktyg att lära sig, däribland Rhapsody. Det är ju en stor investering och vår bedömning var att verktygen inte ännu var helt mogna så jag var ganska skeptisk till en början. Men man får litegrann av kokboken med sig i verktygen så att stötta utvecklarna under resan från traditionell programmering till MBSE var faktiskt ett motiv för att införa ett verktyg, menar Niclas Vilsek. Bra kan bli bättre Verktygen gör dig inte till en bättre programmerare men är man duktig i C-programmering kan man göra ett ännu bättre jobb i Rhapsody, säger systemutvecklaren Albert Hajas. Hans projektkollega Elisabeth Strandberg tycker att det nya arbetssättet har inneburit bättre kontroll. Den stora fördelen är att det är lättare att testa. Man delar upp alla delar i paket som har sina väldefinierade gränssnitt, vilket ger helt andra möjligheter när vi lämnar någonting vidare till test i nästa steg. En annan väsentlig fördel med MBSE är att allting samlas i en modell, vilket gör det lättare för den som inte är så tekniskt insatt att få grepp om systemet. Det kan underlätta för dem som skriver kraven att gå ner i designdiagrammen och visa på flödena, menar Ulf Ärlig, Combitechkonsult som varit mentor i projektet på Saab Training Systems sedan hösten 2006. En annan fördel är att det hela tiden finns en uppdaterad dokumentation. Risken att kunskapen fastnar hos ett litet antal nyckelpersoner är större med traditionell metodik. Man slipper bära med sig sin kod i ryggsäcken, som Niclas Vilsek uttrycker det. Jag har mycket bättre koll på vad mina projektkollegor håller på med nu. Faktiskt är det här ett roligare sätt att jobba på, tycker Elisabeth Strandberg. Pengar att spara Den viktigaste anledningen till att Saab Training Systems valt att satsa på MBSE är strikt ekonomisk. Man räknar med att investeringen i verktyg, utbildning och konsulttimmar ska betala sig. Efter tre år kommer vi att ha nått breakeven. Vi räknar med att öka effektiviteten i systemutvecklingen med 30 procent, säger Niklas Vilsek. Nu håller teamet som bäst på med det tredje MBSE-projektet. Det innehåller helt nya funktioner som ska levereras till kund i september. Nästa steg blir att börja foga samman de olika byggklossarna. Än så länge talar vi bara om fordonssystem, men vi har haft infanteri och antitank i åtanke i den mån vi haft chansen. Att lyfta över det till en ny spelartyp kommer att vara en stor vinst även om det inte kommer att bli smärtfritt. MBSE praktiseras än så länge bara hos programutvecklarna på Saab Training Systems, men kan också användas för kravhantering och användningsfallsmodellering. Det är när de som finns närmast kunderna börjar diskutera användningsfall med både kunder och utvecklare som vi kommer att få se de riktigt stora vinsterna med MBSE, tror Niclas Vilsek. Medlemmarna i projektgruppen är övertygade om att det modellbaserade arbetssättet har framtiden för sig på Saab Training Systems. Det krävs förstås beslut på en högre nivå att det är så här vi ska jobba. Jag tror att vi får se resultaten komma tydligare under det närmaste året och då blir det lättare att få acceptans för modellbaserad utveckling, menar Niclas Vilsek. Saab AB Combitech 7

AV: KENT OLOFSSON Satsning på modellbaserad utveckling inom Saab Aerosystems På Saab Aerosystems införs nu modellbaserad utveckling på bred front, men medan en del avdelningar använt modellbasering länge är det en nyhet för andra. Några som nyligen börjat med modellbaserad utveckling är de som jobbar med utveckling av exempelvis taktiska funktioner. En av dem som engagerat sig i införandet av modellbaserad utveckling är Anders Weitman, som deltar i ett projekt inom Saab Aerosystems där verktyget Matlab/Simulink utvärderas. Målet med projektet är att utveckla metodik för modellbaserad utveckling vilket i slutänden ska sänka kostnaderna, minska utvecklingstiden och höja kvaliteten. Projektet har inte kommit så långt än att det går att dra några långtgående slutsatser om resultatet, men hittills verkar det gå bra även om modellbaserad utveckling kanske inte ger lika stora fördelar för all sorts utveckling. Det gäller att förstå helheten och välja modelleringsspråk och verktyg utifrån de system som ska modelleras, säger Anders Weitman. idé att göra en ordentlig utvärdering av vilka verktyg som ska användas. Hur stora fördelar modellbaserad utveckling kan ge beror en hel del på vilka verktyg man har och hur väl man lyckas integrera verktygen med varandra, säger Anders Weitman. En väl fungerande verktygskedja från kravhantering till modellering/simulering, verifiering, dokumentering och inte minst versions- och konfigurationshantering kan innebära stora besparingar. Duktiga applikationsingenjörer värdefulla Sedan är det inte bara att sätta ett verktyg i händerna på utvecklarna och hoppas på det bästa. En genomtänkt metodik är avgörande för att nå bra resultat speciellt vid storskalig utveckling av säkerhetskritiska system. Det krävs förstås också en del utbildning och helst ska det finnas mentorer att vända sig till. När man inför ett nytt verktyg är det väldigt viktigt att man har riktigt duktiga applikationsingenjörer som kan vara på plats några månader för att få igång verksamheten, sammanfattar Anders Weitman. Utvärdera verktygen noggrant För den som funderar på att börja med modellbaserad utveckling kan det vara en bra 100 Mognad (%) MBSE Fel upptäcks Ej MBSE 0 Verbal definition Dokumentation Modellering Simulering Granskning Analys Prototyp Provflyg Användning Funktions/förmåge-utveckling. Mognadsgrad hos en funktion under dess framväxt. 8 Combitech

MODELLBASERAD UTVECKLING I PRAKTIKEN Modellering av mjukvara till obemannad helikopter Att skapa mjukvaran som behövs för att styra och kontrollera en obemannad helikopter är inget enkelt projekt, men på Saab Aerosystems räknar man med att kunna gå från ingenting till funktionstest på ungefär ett år utan att ge avkall på kvaliteten. En extra utmaning är att mjukvaran som skrivs inte bara ska kunna användas för att styra Skeldar, som helikoptern heter, utan den ska också fungera som kärna och ramverk i utvecklingen av andra farkoster och då inte bara helikoptrar. För att lösa uppgiften i tid använder sig Saab Aerosystems av modellbaserad utveckling. En av fördelarna med det är att det snabbt går att se om det som verkade bra i teorin också håller i verkligheten. Genom att modellera det hela i ett verktyg och få automatgenererad kod får vi snabbt fram kod och kan se om allt fungerar som vi tänkt oss betydligt snabbare än om vi suttit med penna och papper på traditionellt sätt, säger Susanne Nilsson, delprojektledare för Core Computing System och mottagare av det modellbaserade arbetssättet. För den här gruppen inom Saab Aerosystems är det första gången de arbetar med modellbaserad utveckling och till viss del får man känna sig fram till vad som fungerar under resans gång. Det mesta har fungerat bra hittills, men till en början tycke en del utvecklare att de inte riktigt kunde se en tydlig metodik bakom modellbaseringen, vilket berodde på att arbetssättet inte riktigt definierats från början. En lärdom vi kan dra är att det hade varit bra att ha ett mer genomarbetat koncept redan från början och vi kanske inte skulle ha haft så många personer inblandade till att börja med utan rullat ut det på bredare front först efter att vi utarbetat metodiken i en mindre grupp, säger Susanne Nilsson. Combitech 9

AV: KENT OLOFSSON När fel inte får förekomma modellering av säkerhetskritiska system Ett allvarligt programmeringsfel innebär för de flesta utvecklare att en klient kraschar eller att en server måste startas om, men för dem som utvecklar styrsystem på Saab Aerosystems blir konsekvenserna betydligt större. Blir det fel i programmet för styrsystemet till Gripen är resultatet inte några användare som sitter och svär framför sina datorer utan här har vi ett toppmodernt jaktplan som måste framföras med största möjliga säkerhet, vilket ställer mycket höga kvalitetskrav på styrsystemet. Med andra ord finns det inte utrymme för några misstag i koden till ett styrsystem. För att åstadkomma det har Saab Aerosystems använt modellbaserad utveckling sedan 1997 för utvecklingen av styrsystemet till Gripen. I grunden ligger verktyget MatrixX som Saab Aerosystems sedan byggde sitt eget verktyg Styrlags Design Miljö, SDM, på för att få just de funktioner och möjligheter som behövdes. Med SDM kan utvecklarna definiera funktioner och använda dem som byggblock för att skapa nya system. Två separata koder utvecklas Precis som i annan modellbaserad utveckling finns fördelar med återanvändning av Skapa modell Saab AB dok Generera dokument kod och förenklad dokumentation, men de speciella krav som ställs på styrsystem gör att modelleringen ger ännu en fördel. Det får inte finnas några fel i koden när den väl körs i flygplanet och med den här metoden får vi möjlighet att testa koden ordentligt i simuleringar först, säger Jonas Lövgren, systemingenjör på Saab Aerosystems. Under utvecklingen skapas två separata varianter av koden. Dels har vi den skarpa koden som i slutänden ska användas i flygplanet, dels har vi en referenskod som används för att testa om den skarpa koden verkligen gör det den ska. Den skarpa koden skrivs för hand för att man ska ha total kontroll över vad som sker i koden medan referenskoden automatgenereras av verktyget. Båda koderna ska göra exakt samma sak så om samma insignaler körs in i båda kodvarianterna i en simulering ska resultatet bli exakt detsamma om allt stämmer. Finns det en skillnad har något gått snett och utvecklarna får analysera vad problemet kan vara. En extra fördel är att testerna kan köras på en vanlig bordsdator istället för att testa den skarpa koden i en dyr och ofta väldigt upptagen realtidssimulator. Dokumentationen blir alltid korrekt För att effektivt kunna felsöka koden krävs det att dokumentationen stämmer till punkt Programera Generera kod 110010 100101 00100 Exekvera, Jämför Integrera skarp mjukvara Exekvera, Jämför och pricka och här kan också modellbaserad utveckling underlätta arbetet. En av de största vinsterna med modellbasering är att man alltid kan lita på att dokumentationen är rätt eftersom den bygger på modellen, säger Henric Andersson, industridoktorand inom modellbaserad utveckling hos Saab Aerosystems. Utan modellbasering lever dokumentationen ofta sitt eget liv. Eftersom den skarpa koden och referenskoden inte får skrivas av samma personer, för då förlorar vi ju hela finessen med att kunna jämföra mellan separata koder som ska utföra samma arbete, får vi med traditionella metoder också två personer som kanske dokumenterar på helt olika sätt. Dessutom smyger det sig gärna in fel i dokumentationen hur noggrann man än försöker vara när man gör det manuellt. Med modellbaserad utveckling skapas automatiskt dokumentation för all kod baserat på modellen och all dokumentation skapas på ett enhetligt sätt. Nu har vi en källa som vi utgår från och vi behöver inte längre synkronisera information från flera olika källor vilket gör att vi inte behöver lägga lika mycket tid på granskningen, säger Henric Andersson. Att den som ska granska koden har all nödvändig information samlad på ett ställe underlättar förstås mycket, men det ställer också krav som man bör vara medveten om. Det är inte bara de som står för den direkta utvecklingen som påverkas utan även de som ska granska olika dokument som beskriver systemet måste förstå modellbaserad utveckling eftersom de nu kan få dokument med invävda reglerscheman och UML-diagram och då måste alla berörda kunna förstå vad de olika pilarna betyder, säger Henric Andersson. Verifierade Komponenter Komponent DB Systemmodeller Repository Modellbaserad utveckling av säkerhetskritisk mjukvara på Saab 110010 100101 00110 Simulerings modell Mängden utbildning ska inte överdrivas Överhuvudtaget gäller det att ta med kostnaden för utbildningsinsatserna när ett företag funderar på att införa modellbaserad utveckling. Det handlar då både om att lära sig hantera verktygen som ska användas och att 10 Combitech

AV: KENT OLOFSSON få utvecklarna att tänka modellbaserat. Nu ska man emellertid inte överdriva mängden utbildning som krävs. Visst krävs det utbildning, men jag skulle säga att det räcker med några dagar för att komma in i hur man jobbar med modellbaserad utveckling, säger Jonas Lövgren. En annan sak att tänka på är att modellbaserad utveckling inte i sig kommer att ge bättre program. En dålig idé kommer inte att bli bättre bara för att någon försöker förverkliga den med hjälp av modellbaserad utveckling, men det går att upptäcka sina misstag snabbare. Du gör inte mer rätt bara för att du använder ett verktyg, men det går snabbare att upptäcka fel vilket kan spara pengar eftersom det blir billigare att åtgärda ett fel tidigt i processen än längre fram, säger Jonas Lövgren. Räkna inte med alltför snabba effekter Sedan ska man heller inte räkna med att se snabba effekter av modellbaserad utveckling när det gäller besparningar eller dramatiska ökningar av effektiviteten. Det är ett väldigt långsiktigt beslut att gå över till modellbasering och man ska inte tro att man tjänar in det på bara några månader, säger Henric Andersson. Återanvändningen till exempel gör att det går mycket snabbare för Saab Aerosystems att nu bygga styrsystem för exempelvis obemannade plan som Saabs Sharc, men det kräver då förstås att det finns modellkomponenter som kan återanvändas. Så till att börja med kommer det att bli svårt att peka på några tydliga vinster för ett företag som just startat med modellbaserad utveckling medan det i förlängningen förhoppningsvis kommer att ge stora fördelar. För att lyckas med införandet av modellbaserad utveckling är det också viktigt att det finns ett stöd från ledningen så att det finns ett ledningsbeslut på att modellbaserad utveckling ska användas. Det blir då klart för alla i organisationen att modellbaserad utveckling är viktigt och något som ska tas på allvar. Planera men inte i oändlighet När det gäller själva införandet sedan så gäller det att försöka hitta en gyllene medelväg och det kräver en del planering, men man får inte låta det hela ta för lång tid heller. Man ska inte underskatta svårigheterna och glömma att det krävs en viss utbildningsinsats Man kan lita på att dokumentationen är rätt, eftersom den och att det kan bygger på modellen, säger Henric Andersson. krävas en del arbete med att integrera verktygen, säger Henric Andersson. Å andra sidan ska man heller inte överskatta svårigheterna och utreda och utreda och försöka lösa alla tänkbara problem innan man drar igång, för då finns risken att man till slut får en för komplicerad utvecklingsmiljö. Det gäller liksom alltid att hitta rätt balanspunkt, och den balansen försöker vi på Aerosystems hålla med hjälp av VU- programmet MBSE Model Based Systems Engineering. Combitech 11

AV: MAGNUS SKOOG Praktiska tips för modellbaserat arbete MBSE (Model Based System Engineering) skiljer sig från klassisk dokumentdriven utveckling i så måtto att det inte är dokument som är informationsbärare under systemutvecklingen utan modeller. Dessa modeller kan förvisso användas för att producera dokumentation och kod, men de har också ett självändamål då modellerna kan användas i många syften. Analys/Validering. Är modellen korrekt, med avseende på syntax, fullständighet mm? Finns det inbyggda felaktigheter? Ett exempel på användning är vid formell verifiering. Man kan med hjälp av satslogik analysera om ett system uppfyller krav. Tidig simulering. Detta är mycket användbart för att hitta fel i krav och design. Det är mer effektivt och tidsbesparande att kunna simulera tidigare i utvecklingscykeln i stället för att vänta på att hela systemet blir färdigt för test. Simulering på denna högra abstraktionsnivå är dessutom mycket mera kraftfullt än normal koddebuggning. Dimensionering via protyping. Det kan t ex handla om att välja parametrar, sätta nivåer på triggers eller att välja filterparametrar. Detta är också användbart när man vill jämföra olika algoritmer. Spara dokumentation. Behovet av dokumentation kan minskas en hel del då modellen innehåller det mesta. Vid behov kan skräddarsydd dokumentation genereras, t ex vid granskning, men det är också möjligt att till mycket stor del jobba utan traditionella dokument. En Modell. En del av komplexiteten vid Systemutveckling blir lättare att hantera då det finns en gemensam syntax för att beskriva systemet. Det blir enklare att jobba i större grupper i stora projekt om man har ett ensat sätt att beskriva systemet. Då man har en ensad modell så blir det också enklare att jobba mot samma mål. Kodgenerering. De flesta MBSE-verktyg har i dag möjligheten att generera någon form av kod. Denna kod kan i sin tur användas i många syften, t ex för simulering (både av hårdvara, omvärld och av mjukvara). Den kan även i många fall användas som källkod till målplattformen. Test och Verifiering. Modeller på olika nivåer har stor användning för test och verifiering av systemet. Det finns även möjlighet att göra t ex modultesterna på modellnivå. Detta betyder att man kan spara mycket tid då modulerna redan är utprovade då de lämnar modellnivån. Systemsimulering. Om en modell av omvärlden och hårdvaran också tas fram så kan hela 12 Combitech

MODELLBASERAD UTVECKLING I PRAKTIKEN systemet simuleras. I reglerteknisk utveckling används detta ofta för att testa ett system som inte finns. Det kan vara bra i sammanhang där full provning inte är möjlig, t ex inom flyg, rymd och medicinska tillämpningar. Modeller som tagits fram på detta sätt har ofta mycket hög kvalitet då systemet redan provats ut vid simulering. Programmeringsspråk Formella Metoder Övriga Standarder Maskinkod Assembler Fortran (1950) COBOL (1960) BASIC (1964) SIMULA (1966) Lite UML historik Ursprungligen fanns två huvudspår för systemmodellering, Structured Analysis (SA) och Objektorienterad Analys (OA). Under 80-talet utvecklades en rad objektorienterade metoder. På samma sätt utvecklades objektorienterad modellering under 90-talet. De mest kända metoderna var OMT, ROOM, Booch, OOSE och SDL. Under slutet av 90-talet standardiserades UML som är en gemensam metod som innehåller komponenter från samtliga dessa metoder. UML har också påverkats av utvecklingen av JAVA och CORBA mm. Pascal (1970) Smalltalk (1972) C (1973) ADA (1980) C++ (1983) JAVA (1995) J2EE (2001) NET C# (2000) Strukturerad Programmering Objekt Orientering (80-talet) SDL (1988) MSC (1992) Booch OMT ROOM OOSE (90 talet) SDL (1992) UML 1.0 (1997) UML 2.0 (2003-2005) SysML (2006) DoDAF (2003) AUTOSAR (2006) HTML (1992) CORBA XML (1998) MDA (2001) XMI SOA / Web Services SysML SysML kan ses som en vidareutveckling av UML. UML har ibland kritiserats för att vara för mjukvaruorienterat. Det ligger nog en del i detta eftersom UML utvecklas och används mestadels av mjukvaruutvecklare. Det är nog också så att mjukvaruutvecklare har haft lättare att ta till sig objektorienterade metoder. Det är dock inte så att UML bara begränsar sig till mjukvaruutveckling, men det saknas en del för att få en helhet. SysML använder en del av UML 2.0 diagrammen, men det finns också nya diagramtyper. UML 2.0 SysML 1.0 Kravdiagram (requirement diagram) Kravdiagrammen i SysML kan därför användas för att modellera hela kravhanteringen, dvs kravskrivning, kravnedbrytning, kopplingen mot testfall, användningsfall, spårbarhets- och verifieringsmatriser. UML diagram Blockdiagram (block diagram) Blockdiagram är egentligen inget nytt i SysML. Det är en form av klassdiagram eller SysML diagram: requirements, parameterdiagram och allokeringar Gemensamma diagram: aktivitetsdiagram, block definitioner (UML2-klassdiagram), interna block (UML2-kompositstrukturer), sekvensdiagram, tillståndsdiagram, användningsfall Combitech 13

MODELLBASERAD UTVECKLING I PRAKTIKEN kompositer. Ett block är en form av klass som inkapslar data och beteende. Den kan kopplas ihop med andra block m h a serviceportar och flödesportar som egentligen bara är en form av UML 2.0 portar. Allokeringar (allocations) Under systemanalysen vill man separera struktur och funktion så att en god arkitektur kan åstadkommas. Man vill dock kunna vissa hur kraven eller ett beteende allokeras mot strukturen. Allokeringar kan modelleras med blockdefinitionsdiagram eller som allokeringstabeller. Parameterdiagram (parametric diagram) Används för att visa parametrar mellan strukturelement. Parametrarna kan begränsas och typas. Trender inom området Det finns några tydliga trender inför framtiden: UML standard UML blir mer och mer standardspråket för systemutvecklaren. Det kommer att betyda att verktygen blir mer lika varandra och att de enklare kommer att kunna utbyta information med varandra. Flerverktygsmiljöer Inget verktyg klarar helheten. Utvecklaren kommer att använda flera verktyg under systemutvecklingscykeln. Visionen för framtiden är att en gemensam modell används under hela utvecklingsprocessen. Artefakter som kod och dokumentation genereras vid behov. Övergången mellan simuleringar, exekveringar på host eller target skall vara automatiserad. Tester kan köras på modell, host eller på target. Se figur nedan. xuml UML tillhandahåller inte semantik för att beskriva hur modellerna skall föras över till applikationskod för ett specifikt språk och operativsystem. xuml (executable UML) försöker överbrygga detta. Modell Editor Krav och spårbarhets verktyg Dokument generator Dokument DoDAF / AUTOSAR DoDAF (Department of Defence Architectural Framework) är en standard för att utveckla, integrera arkitekturer utvecklade av olika försvarsföretag. Det handlar om ett få ett ramverk kring hur information ska beskrivas. AUTOSAR (Automotive Open System Architecture) är en liknande standardiserad arkitektur inom bilindustrin. Hosttmiljö Simulator CM verktyg Modell(er) Debugger Test och verifieringsverktyg Kodgenerator Källkods kompilator, länkare, laddare Källkod Targetmiljö Exekverande applikation 14 Combitech

Vi tar inte upp vanliga skolboksexempel Combitech Training Institute förmedlar verklig erfarenhet För att lösa de svåraste uppgifterna krävs det att man tänker outside the box även vid modellbaserad utveckling. Läs mer om våra tre nya MBSE-kurser på www.combitech.se Utbildare direkt från fältet med djup praktisk förankring Vi gillar inte teoretiska utbildningar som inte går att applicera i det verkliga arbetet. Därför ska inte heller våra kursdeltagare utsättas för det. Med den ena foten direkt på plats i verkliga kundprojekt och den andra stadigt förankrad i kursverksamheten kan vi kvickt snappa upp aktuella trender. Av den anledningen väljer vi också kursledare noggrant, bara våra främsta experter kan bli kursledare på CTI. Vi tar ansvar för kunskapsutvecklingen För att skapa en varaktig förändring krävs det mer än bara en kurs. Vi erbjuder långa program med uppföljningsdagar och kombinerar ofta utbildningar med mentorskap. Detta gör att våra kunder kan få skräddarsydda utbildningar precis när de behövs i projektet, samtidigt som de alltid har stöd av en expert. Unik branschbredd Med djupa kunskaper inom olika områden kan vi förmedla kompetens och erfarenhet mellan olika branscher och typer av system. Vi är samtidigt ett obundet företag, vilket innebär att vi inte har några avtal eller liknande som gör att vi måste rekommendera ett visst verktyg eller en viss teknik. Doktorer inom metodutveckling för kunskapsöverföring Vi behärskar de beprövade metoderna för kunskapsutveckling, samtidigt bedriver vi sedan många år egen forskning kring erfarenhetsbaserad kunskap. Med flera doktorer inom ämnet och mer än tio års forskningssamarbete med KTH driver vi utvecklingen i Sverige. Och forskningen kommer alltid våra kursdeltagare till del först av alla. Combitech Training Institute är en komplett partner för kompetensutveckling. Vi tar ett helhetsansvar för kurser, workshops, hela utbildningsprogram och mentorskap. Varje individ uppmuntras att utveckla sig till nya nivåer, oavsett om utgångs punkten är nybakad Nr 2 ingenjör juni 2007 eller redan erfaren Combitech chef, säger Tommy Gustavsson som är kursansvarig. För mer information skicka ett mail till tommy.gustavsson@combitech.se. 15

Avsändare: Combitech AB Box 1017, 551 11 Jönköping B Porto betalt Nytt OnTime-seminarium efter sommaren Tema: Modellbaserad systemutveckling att jobba med konkret abstraktion Vårt mål med detta seminarium är att med spännande föreläsningar ge en inblick i området samtidigt som vi förmedlar erfarenheter kring MBSE i produktutvecklingsprojekt. Seminariet vänder sig till produkt-, projektledare och personer verksamma på olika befattningar inom teknisk utveckling. Seminariet är kostnadsfritt och inleds med gemensam frukost. 08.30 09.00 Frukost, inskrivning 09.00 11.30 Seminarier Seminariet genomförs på följande orter: Linköping tisdag 4 september 2007 Collegium, Mjärdevi Västerås onsdag 5 september 2007 Elite Hotel, Stadshotellet Stockholm torsdag 6 september 2007 Polstjärnan, Sveavägen Göteborg fredag 7 september 2007 Arken Konferenscenter Malmö/Lund tisdag 11 september 2007 Scandic Star, Lund Jönköping onsdag 12 september 2007 John Bauer Hotel För mer information eller anmälan (senast 15 augusti) skicka ett mail till ontime@combitech.se. Nästa nummer av OnTime Det är när det krånglar till sig som man inser hur viktigt det är med användbarhet; när man inte förstår menysystemet på den nya dvdspelaren eller när systemet på jobbet känns ogenomträngligt. Men frågan är egentligen mycket större än så. Med system som stödjer användarens arbetsuppgifter uppnås en ökad effektivitet. Produktiviteten ökar om färre fel uppstår och fl er arbetsuppgifter kan klaras av samtidigt. Användarna blir mer nöjda och det kanske till och med blir kul att använda produkten. I en förlängning kan väldesignade program och produkter som används på rätt sätt därför bidra till att minska stress och arbetsskador. Sett ur ett säkerhetsperspektiv så minskar riskerna att användarna förstör något av misstag om handhavandet är enkelt. Att fördelarna är många är tydligt, men vad är egentligen bra användbarhet? Hur designar man ett användbart system? Hur gör man för att tjäna pengar på användbarhet? Många frågor väcks, i kommande nummer av OnTime ger vi en del av svaren.