INDHOLD. Bedre forudsigelighed med værktøjer og modeller

Transkript

1 NR. I MARTS I 201 I N D U S T R I E L T E K N O L O G I O G S O F T W A R E Bedre forudsigelighed med værktøjer og modeller Systems Engineering, modeldrevet udvikling og agile processer giver bedre træfsikkerhed, når indlejrede systemer udvikles. Af Jesper Holst Direktør EKTOS Integration, bedre performance og øget intelligens i produkterne. Det er kravet til indlejrede systemer og det øger kompleksiteten af udviklingsprojekterne. Budgettet for et typisk projekt er mangedoblet de seneste år. I virksomhederne giver de større budgetter til de enkelte projekter naturligt et ønske om større forudsigelighed i projekterne i tid, omkostning og performance. Dansk it-forskning har i nogle år arbejdet med modelbaseret karakterisering og udvikling af systemer. Netop den modeldrevne udvikling af indlejrede systemer, i modsætning til den dokumentbaserede styring af produktets udvikling, kan være med til at sikre forudsigelighed i udviklingsprojekter. Det øger overskueligheden for projektdeltagerne, og gør det muligt at finde designfejl tidligt i projektet. Flere danske virksomheder er ved at indarbejde modelbaseret udvikling og Systems Engineering som selvfølgelige discipliner i deres udviklingsprojekter. Det sker i tæt samarbejde med universiteterne. Her i publikationen beskriver tre af de forskere, der deltager i ITOS, deres arbejde med at bruge metoder og værktøjer til modeldrevet udvikling og Systems Engineering. Samtidigt er den nystiftede danske afdeling af International Council on Systems Engineering (INCOSE) godt i gang med de første aktiviteter, der kan bidrage til at udbrede kendskabet til Systems Engineering som disciplin i produktudviklingen. Projektledelsen af udviklingsprojekterne har også stået for skud i de seneste år. De agile udviklingsprocesser er blevet tænkt ind i mange danske virksomheders udviklingssystemer, og der er sket en betydelig professionalisering af projektledelsen gennem uddannelse og certificering. Den optimale projektledelse af udviklingsprojekter er og bør stadig være et hot emne i virksomhedsledelsen. Det betydelige spænd i, hvordan virksomhederne opfatter best practise, viser at der ikke er en enkelt gylden vej til den gode ledelse af et udviklingsprojekt. Det er snarere en individuel proces under konstant ændring. I min egen virksomhed, der leverer embedded HW og SW udvikling til primært danske virksomheder, giver kravet om forudsigelighed sig udslag i en stor andel af projekter, hvor der lægges vægt på en fast pris på udviklingsprojektet. Den modtagende virksomhed ønsker sikkerhed for hele eller dele af udviklingsbudgettet, som en naturlig reaktion på at budgetterne til produktudvikling stiger kraftigt, men samtidig er det vigtigt også at kunne sikre andre parametre som tid, ydelse, kvalitet og produktionspris. En professionalisering af projektledelsen og klar tale om kravsættelsen til et nyt produkt fra både leverandør og kundes side, er væsentlige elementer for gentagen succes med dette. INDHOLD 2 Klar tale og fast hånd om ændringer gør forskellen 3 Systems Engineering giver Terma The Big Picture Seluxit analyserer konfigurerbare systemer med modeller og simulering 6 Bliv på broen 7 It s cool to be old-school 9 Brugbarhed af model baserede metoder til udvikling af systemer 11 Den gode ide er den nemme del som regel 12 Forskellige projektmodeller i Martin Professionals perspektiv 1 Designværktøjer giver hardwareudviklere konkurrencefordel 15 SysML tackler tvær faglige vanskeligheder i multidisciplinære projekter 16 efactor 201 er skudt i gang ITOS er finansieret og udvikles i samarbejde mellem Industriens Fond, DI ITEK, AAU, DTU og 12 virksomheder. ITOS løber over fire år og er åbent for alle danske virksomheder, som arbejder med embedded systemer.

2 Klar tale og fast hånd om ændringer gør forskellen Målet skal være fælles og forstået også når det ændrer sig undervejs. Her skal man nå det fælles mål på tværs af teknologier, hvilket igen stiller krav om, at målet er formuleret og forstået ens på tværs af fagdisciplinerne. Af Jørn Johansen Director, Process Improvement DELTA Mennesker kan ikke huske ret mange ting over lang tid. Derfor er det vigtigt, at krav formuleres så entydigt og klart som muligt, og at anvendelsen af kravene gøres så operationel som muligt. Det også gælder ændringer af krav. En ensartet opfattelse af kravene er nødvendigt for et sundt udviklingsprojekt. Det gør teamets evne til kravudvikling og kravstyring til en stærk del af deres kompetencer. Problemet Skal mennesker samarbejde i et team om udvikling af et nyt produkt eller en service, er det indlysende vigtigt, at de har den samme opfattelse af målet, også selvom det ændrer sig undervejs. Lige så vigtigt er kompetencen til formulering af stringente og forståelige krav ved outsourcing, hvor vi beder en partner udvikle dele af eller hele systemet. Her er den løbende styring og kommunikation af ændringer endnu vigtigere. Endvidere kan der være eksterne krav, der skal overholdes. Fx hvis produktet er medicinsk udstyr eller anvendes i miljøer med høje sikkerhedskrav. I de tilfælde kræver standarderne dokumenterede og validerede krav, hvilket stiller ufravigelige krav om sporbarhed mellem krav og testcases. Endelig er der situationen, hvor produktet består af løsninger fra flere faglige discipliner; software, hardware og mekanik. Ved manglende fælles forståelse for målet på tværs af discipliner ender resultatet med ikke-optimale løsninger og suboptimeringer. Det viser sig typisk ved, at den embedded software kommer til at løse opgaver, der meget bedre havde ligget i hardware (eller omvendt) og styringen af mekanik bliver unødig besværliggjort. Løsningen En organisations evne til at udvikle og vedligeholde produkter eller services er betinget af den professionalisme eller modenhed, den har i forhold til modenhedsmodeller som CMMI eller ISO/IEC 1550 (SPICE). Her er graden af institutionaliserede processer understøttet af metoder, værktøjer og de enkelte medarbejderes kompetencer, samt ledelsens fokus på udviklingsorganisationen og løbende forbedring af de bærende elementer. I disse modeller er kravudvikling og kravstyring centrale i forhold til mange af de øvrige processe. Product line Begrebet har fundet fodfæste indenfor automobilindustrien og er godt på vej indenfor fx mekatronik. Hovedtanken er, at dele af produktet eller systemet går igen i flere produkter. Dokumentationen og kvaliteten af de enkelte dele og interfacet mellem delene skal være stærkt styret. Begrebet er defineret i ISO/IEC Her lægges der vægt på, at krav og kravstyring, arkitektur, design, konfigurationsstyring og kvalitet er helt på plads, så genbrug på forskellige delprodukt niveauer er mulig. Sporbarhed er ikke noget man drømmer om det er en indlejret del af den procesmæssige løsning. Niveauer af features og krav Ved at dele kravene op i flere niveauer af feature og krav, på en for organisationen forståelig og operationel måde, kan ejerskabet for de forskellige niveauer placeres forskellige steder i organisationen, produkter og produktvarianter kan konfigureres ud fra features og krav linkes til løsninger og testcases. Flere værktøjer tilbyder en samlet løsning til hele kæden. Standarder Nedenfor er nævnt et udpluk af standarder, der handler om krav. Det kan anbefales at medtage disse standarder, om ikke andet så til inspiration. Herudover kan det være nyttigt at se på CMMI og ISO/IEC 1550 (SPICE). ISO/IEC 2918 Systems and software engineering Life cycle processes - Requirements engineering IEEE 1233 Guide for Developing System Requirements Specification ISO/IEC Serie af standarder om Product quality ISO/IEC TR 2766 Guide for requirements engineering tool capabilities Defining requirements to pladser tilbage Vi holder masterclass i defining requirements om dynamiske metoder til at styre og definere krav. Successen fra sidste års masterclass med Delta gentager vi med de erfaringer indarbejdet, som den første masterclass gav os. Den holdes marts 201 og april 201 på Fyn. Tilmeld og læs mere om Defining Requirements her ITOS/Masterclasses/ Pages/Masterclassikravsspecifikation.aspx 2

3 Systems Engineering giver Terma The Big Picture Fokus på System Engineering intensiveres med nyt dansk chapter af den internationale System Engineering organisation INCOSE. Af Mikkel Vestergaard Hansen Director, Systems Engineering, Defense & Security, Terma A/S Systems Engineering er en interdisciplinær tilgang til succesfuldt at kunne realisere komplekse systemer. Der fokuseres på tidligt at få identificeret de rigtige krav, få dem dokumenteret, skabe det rigtige design, og sikre at systemet efterfølgende overholder alle krav, samtidig med, at helheden holdes for øje. Nogenlunde sådan kan Systems Engineering defineres. Værdi for Terma Terma A/S har oplevet en stor værdi i at have medarbejdere, der mestrer det brede perspektiv. Især i produkter med høj kompleksitet indeholdende elementer fra flere forskellige fagdiscipliner (software, elektronik, mekanik), som f.eks. radarsystemer eller selvbeskyttelsessystemer til fly. Ofte kan forskellige krav løses både i software, hardware eller i en kombination deraf, men udviklingsomkostningerne vil ofte variere meget afhængigt af den valgte løsning. Der vil også ofte være elementer i brugerens anvendelse af produktet, der gør, at den ene løsning er at foretrække frem for den anden, men at identificere dette kræver en god forståelse for brugerens behov og et godt overblik over helheden. Tværfaglig Derfor er vi I Terma A/S ved formelt at indføre en Systems Engineering proces, baseret på ISO/IEC 15288, der sikrer en struktureret tilgang til disciplinen. Processen er blevet skrevet af en arbejdsgruppe bestående af udøvende systemingeniører, på tværs af flere forretningsområder, og er løbende blevet reviewet af interes- senter fra andre procesområder (forretningsudvikling, udviklingsingeniører, product managers), da Systems Engineering processen udfylder en central rolle. Efter processen er formelt godkendt venter arbejdet med at træne medarbejderne i processen. Dette gælder både for systemingeniørerne selv, men også de andre medarbejdere som processen har indflydelse på. Krav til identificering Det at have en proces for Systems Engineering fordrer, at vi får identificeret de rigtige krav fra de relevante interessenter tidligt, får valgt den rigtige arkitektur, får implementeret løsningen, for derefter at sikre, at løsningen lever op til de krav, der var udgangspunktet, så kunden bliver tilfreds med produktet. Denne proces har naturligvis også fundet sted tidligere men i en mindre struktureret form. INCOSE Selve det at arbejde professionelt med Systems Engineering er ikke nogen nyhed på internationalt plan. Organisationen International Council on Systems Engineering (INCOSE) har gjort det siden INCOSE har sit udspring i aerospace industrien i USA, men er siden kommet til at dække meget bredt. Det er en not-forprofit organisation, der har til formål at hæve niveauet for, og udbrede kendskabet til, Systems Engineering på tværs af industri, uddannelsesmiljø og den offentlige sektor. Dansk chapter INCOSE har mange forskellige aktiviteter som årlige konferencer, video-web sessioner omkring relevante emner og mange arrangementer afholdt af de nationale afdelinger. INCOSE vedligeholder også en Systems Engineering Handbook, baseret på ISO/IEC standarden og tilbyder muligheden for at blive certificeret efter denne. Under en workshop sidste år, blev det besluttet at forsøge at starte et dansk chapter. Det blev en realitet i slutningen af 2013, og det danske chapter er nu begyndt at arbejde for at udbrede kendskabet til Systems Engineering i Danmark. Det er tanken at gøre det blandt andet gennem workshops og foredrag omkring emnet Nordic Systems Engineering Tour i København 21. maj 201 Heldagsarrangement med danske og internationale talere, der alle relaterer sig til Systems Engineering. For yderligere information og tilmelding se 3

4 Seluxit analyserer konfigurerbare systemer med modeller og simulering Af Thomas Pedersenn Institut for Datalogi, Aalborg Universitet og ITOS projektet Når man udvikler konfigurerbare systemer er konfigurationen af den endelige installation ukendt. Det gør det svært at forudsige samspillet mellem komponenterne og om de resulterer i uønskede konflikter. I sådanne situationer hjælper værktøjer til modellering, simulering og verifikation. Det ser et nyt forskningsprojekt på. Et intelligent hjem er et eksempel på et konfigurerbart system. Det består af en række forskellige apparater og enheder, som kommunikerer og samarbejder på kryds og tværs. Nexus er den protokol, som virksomheden Seluxit bruger til at understøtte denne kommunikation. Deres produkt giver også muligheden for at eksekvere kontrolsystemer, der udnytter protokollen. Et kontrolsystem er en eller flere tilstandsmaskiner, der modtager og sender simple værdier over lokalnetværket. Da vi har et system, bestående af flere kontrolsystemer der kommunikerer, og endda over et forsinket netværk, har vi de klassiske problemer, der også kan opstå i flertrådede programmer. Da disse problemer generelt er svære at forudsige og finde manuelt, ser vi i projektet på muligheden for at analysere kontrolsystemerne med automatiserede værktøjer. En bevægelsessensor der styrer lyset Unplugged c < = LAN_DELAY mmotionsensor_motion == == 1 exec_motion_detected! NoMotion motionsensor_timeout m eout == 1 exec_motion_notdetected! Modellering i UPPAAL UPPAAL 1 er et værktøj til modellering, simulering og verifikation af realtidssystemer, udviklet i et samarbejde mellem Uppsala og Aalborg Universitet. I UPPAAL modelleres et system grafisk som kommunikerende tilstandsmaskiner, hvor tilstanden indeholder almindelige variable som kendt fra programmering, samt ure (eng: clocks). Ud fra en sådan model er UPPAAL i stand til at analysere egenskaber ved modellen, f.eks. om systemet kan nå en given tilstand eller om en bestemt sammenhæng mellem tid og tilstand er opfyldt. Når vi skal modellere et kontrolsystem, baseret på Nexus, i UPPAAL er det en blanding af modeller, der laves ud fra kontrolsystemet, generiske modeller, og modeller der skal designes fra bunden. mmotionsensor_motion == 1 exec_m exec_motion_continues! otion_continues! Motion Motion Modellen af selve kontrolsystemet skabes ved at modellere tilstandsmaskinerne direkte i UPPAAL. Et eksempel med et simpelt kontrolsystem til en bevægelsessensor ses i figuren nedenfor. Denne kunne for eksempel styre en lampe. Efter den er blevet tilsluttet har den basalt set to tilstande, én for når der er bevægelse i rummet og én for når der ikke er. For at undgå for hurtige tilstandsskift, slukkes lampen først når en timer udløber. Netværk og timemodel De generiske modeller indeholder en netværksmodel og en timermodel. Netværksmodellen kommer ind i billedet, fordi vi ønsker at afdække problemer, der opstår ved kommunikationen, og den beskriver hvordan en netværkspakke bliver forsinket når den transporteres fra én enhed til en anden. En timer er et konkret element i Seluxit s system, der bruges i tilstandsmaskinerne til at lave forsinkede handlinger. Begge modeller er generiske fordi de ikke afhænger af det konkrete system og kan genbruges i andre. Miljøet med i modellen Når vi analyserer et kontrolsystem er det ikke tilstrækkeligt med en model af selve systemet, vi skal også kende det miljø som systemet indgår i. Disse modeller beskriver enhederne i omverdenen. Hvilke data de modtager fra kontrolsystemer og hvad disse modtager fra sensorer. De afhænger meget af, hvad man ønsker at analysere og kan spænde fra helt simple til meget komplekse beskrivelser af enheder. Da dette ikke er en del af kontrolsystemet, er det nødvendigt at designe disse fra bunden. 1 UPPAAL:

5 Fordele ved modeller Hele idéen med at skabe en model af et system er, at vi ved brug af forespørgsler i UPPAAL, kan verificere at egenskaberne er opfyldt. Dette kan være helt basale egenskaber, f.eks. som at systemet hverken har deadlocks eller livelocks. Det kan også være mere specifikke egenskaber. For eksempel er det rart at vide, at lyset altid bliver tændt, når røgdetektoren måler røg i rummet, selvom bevægelsessensoren ikke måler bevægelse, eller at termostaten ikke åbner for radiatoren, når vinduessensoren har lukket den. Simulerer kontrol Udover at finde fejl kan UPPAAL også kan assistere i selve udviklingsprocessen af kontrolsystemet. For det første har de grafiske værktøjer potentiale til at give større overblik, end de rene tekstuelle beskrivelse som Seluxit bruger i dag. For det andet kan UPPAAL også bruges til at simulere et kontrolsystem trin for trin, hvilket øger forståelsen for hvordan det modellerede system agerer. Denne simulering kombineret med at værktøjet kan svare med en sekvens der viser hvorfor en egenskab ikke er overholdt, der, gør det effektivt at finde og rette fejl. Videre muligheder Verifikation af modeller kan lyde som den hellige gral inden for udvikling af systemer, men det er vigtig at kende dens begrænsninger. For det første bliver verifikationen udført ved fuldstændig udforskning af tilstandsrummet. Selvom denne er optimeret vil nogle modeller stadig være for store og komplekse til at de kan analyseres inden for rimelig tid. Til dem og til stokastiske kontrolsystemer, kan den stokastiske udgave af UPPAAL hjælpe. Den finder sandsynligheden for et svar ved hjælp af intelligent simulering i stedet for den fuldstændige udforskning. Elegant løsning Et andet problem i udvikling og analyse af modeller, er at analysen kun kan blive så god som modellen. Hvis det endelige system ikke er programmeret, så det svarer til modellen, er der ingen garantier for om systemet har de samme egenskaber. Her kan man overveje at bruge automatiserede testværktøjer, der bruger modellen til at genererer test med, men i vores tilfælde er der en mere elegant løsning. Udover at finde en måde at modellere Seluxit s systemer, har vi også formelt beskrevet en tovejs oversættelse mellem system og model. Herved kan eksisterende systemer let analyseres med automatiserede værktøjer og modeller udviklet i UPPAAL kan oversættes til konkrete systemer hurtigt og uden at risikere de fejl der opstår ved manuel oversættelse. Den automatiserede oversættelse kan dog ikke skabe modeller for enhederne, da de ikke er kontrolsystemer. Men modeller kan importeres så de svarer til dem der er i et givet miljø. Seluxit s system er langt fra det eneste konfigurerbart system der vil kunne analyseres på denne måde. Andre eksempler kunne være Z-wave og Zigbee, inden for hjemmeautomation, eller mere generelt, modul-baserede systemer hvor det endelige system først er kendt på installationstidspunktet. Den automatiserede oversættelse kan også videreudvikles og tilpasses andre omgivelser. Vi har for eksempel tidligere også vist at kontrolsystemer beskrevet i UPPAAL kan eksekveres direkte med egenudviklet software. I dette tilfælde sendte kontrolsystemerne beskederne gennem HomePort en grænseflade der tilbyder en simple XML-baseret webservice indgang til apparaterne i et intelligent hjem. 5

6 Bliv på broen Senior Project Manager R&D, Executive Manager Knud Jørgen Poulsen Jan Aagaard Projekt lederen er manden på broen med det store overblik. Det er ikke klogt at stikke ned i maskinrummet eller over i messen og give en hånd med undervejs. Den vigtigste rolle er at sikre, at hele besætningen holder fælles kurs. I teknologivirksomheden DEIF, med hovedsæde i Skive og datterselskaber i 15 nøglemarkeder, er innovation en grundsten, der sikrer virksomhedens indtjening og fortsatte værditilvækst. Cirka 20% af firmaets 500 medarbejdere er beskæftiget med R&D. Ledelse... I DEIF s udviklingsafdeling i Skive, tror vi mere på mennesker end systemer. Hvor DEIF tidligere fokuserede på systemer i udviklingsprocessen, viser vores erfaringer i dag, at succes i projekter skyldes 80% ledelser og 20% systemer. Det ved vi fra projektevalueringer, hvor vi beder medarbejderne tage stilling til, hvad der kan gøres bedre eller anderledes næste gang. Svarene er mange, men hovedindtrykket er, at systemer ikke kan forebygge klassiske problemer i udviklingsprojekter. Det kan derimod en agil styring af en kompetent og visionær projektleder, der evner at uddelegere ejerskab og styrke et arbejdsmiljø, hvor samarbejdet glider frit mellem driftsfunktionerne. Erkendelsen er, at gode medarbejdere og gode holdninger hænger tæt sammen med god ledelse. Den kreative projektleder Udviklingsprojekter, der indeholder ny teknologi, er relativt uforudsigelige. Disse projekter er en kreativ proces, hvor man realiserer en vision eller en idé i form af et produkt. Specielt i opstarten af udviklingsprojekterne er idéstormen, den krøllede kreativitet og de vilde nye tanker i højsædet. 6 For at sikre at alle har den samme opfattelse af, hvad slutproduktet er, og hvad det kan, er det vigtigt i specifikationsfasen at fokusere på resultatet. At se udefra og ind ; at se det med kundebrillerne på og beskrive og visualisere det vha. modeller og udkast til f.eks. brochure, service og salgsmateriale. Det giver en langt højere grad af forståelse og identifikation på tværs af funktioner end en tyk teknisk specifikation fyldt med komplekse ingeniørtermer, der ikke nødvendigvis kan omsættes til brugbare resultater indenfor det enkelte område. Der skal skues langt ud i fremtiden, og man skal kunne se om hjørner for at udvikle den teknologi, som vil blive nøglen til eksempelvis større forretning eller bedre kvalitet. Begynd med slutningen På DEIF har vi et mantra, der hedder Begynd med slutningen og gør det vigtigste

7 først. Udover mellemregningerne på vejen derhen, er det er først og fremmest den vision, den gode projektleder skal sikre sig, at projektgruppen har for øje. Fokus på resultater, ikke metode Den tilgang er et opgør med en traditionel rolle, hvor projektlederen opfattes som en, der skal vide og koordinere alt, og derved tit sidder med fingrene langt nede i teknikken og risikerer at miste overblikket over hele projektet. Det kan være farligt at være at spillende træner. Ofte vil det nemlig føre til en prioritering af eget område. Hvis projektlederen f.eks. har baggrund i Udviklingsafdelingen, er det nemt at komme til at give større fokus på sit gamle arbejdsområde på bekostning af andre. Det kan betyde dårligere resultater fra øvrige grupper, mindre ejerskab og commitment til projektet og slutproduktet. For at sikre, at produktet får den maksimale værdiskabelse for virksomheden, er det nødvendigt gennem hele forløbet at sikre, at det har den helt rigtige pasning til virksomheden i hele værdikæden og i alle dens led. Den gode projektleder skal derfor kunne beherske og skifte lederstil flere gange gennem et forløb, hvad enten der skal gøres en indsats for kreativitet, leverancer eller driftsfunktioner. Ved at blive på broen og lede projektet overordnet vha. projektdrivere med delansvar, bevarer projektlederen overblikket over alle leverancer og sikrer, at delresultater og prioriteringer holder. Hele opgaver til hele mennesker Det er afgørende, at virksomhedens forskellige kompetencer bidrager med deres ekspertviden, så projektet når de bedste resultater på den korteste tid. Når projektlederen tildeler en opgave til en medarbejder, gør han det i tillid til, at kollegaen kan løse den. Kreativiteten og ejerskabet overgår til projektmedarbejderen i en ansvarsoverdragelse og forståelse mellem de to, der giver plads til det hele menneske. At efterleve det ideal kræver omstilling og holdningsændringer i hele organisationen. Når det lykkes, kan projektlederen med fuld sindsro holde sig fra maskinrummet, blive på broen og styre skibet sikkert i havn. It s cool to be old-school Individualitet er stadig et hit, når der skal innoveres. Af Christopher Meisner RTX Med den megen fokus på udviklingsprocesser, understøttende tools og nye teknologiske trends og platforme, er det let at glemme, at det stadig er de individuelle kompetencer og hard-core software udviklingstools, som i sidste ende skaber løsningerne. Ikke, at det første ikke er vigtigt men klassiske softwarediscipliner, kompetencer og tools er stadig lige så vigtige for at få frembragt innovative løsninger af høj kvalitet. Realtids software RTX A/S ( er en børsnoteret nordjysk virksomhed, der udvikler trådløst kommunikationsudstyr til en række forskellige applikationer og markedssegmenter og på en række teknologi platforme. Paletten af applikationer dækker over alt fra telemetri-udstyr til medico applikationer, home automation, professionelt trådløst audio udstyr, lavenergi løsninger til trådløse sensorer over til trådløst telefoni og professionelt kommunikations udstyr m.m. Fællesnævner for alle disse løsninger er, at de indeholder embedded realtids software systemer. Sideløbende følger software udvikling på PC platforme: drivere; løsninger til integration af det trådløse udstyr; samt udviking af tools og test automatiseringsløsninger. Stærke kompetencer indenfor disse områder er i høj grad det, der har været medvirkende til, at der er skabt modulære og portable software platforme og tilhørende tools. Det danner grundlaget for, at RTX effektivt kan udvikle innovative trådløse løsninger af høj kvalitet. Framework Figuren nedenfor illustrerer, hvorledes forskellige teknologiplatforme, som RTX opererer med, alle er bygget med de samme basale byggesten. Konceptet med standard frameworks og platforme er selvsagt ikke nyt eller specielt innovativt, men det er stadig vanskeligt at implementere korrekt. Det er lykkedes for RTX at konstruere det således, at det grundlæggende udviklingsframework er ens på tværs af teknologier og platforme. Den grundlæggende software er standardiseret således at operativsystem, håndtering af persistent data, debug/trace interfaces, test interfaces til bl.a udvikling og 7

8 produktionstest, etc. er ens på tværs af platforme. Det gør, at udviklingsmiljø er ens, at tools kan genbruges og at software komponenter relativt enkelt kan genbruges og deles på tværs af teknologi platforme. Samtidig kender og forstår alle udviklere den generelle udviklingsplatform på tværs af teknologier og domæner. Killer feature RTX har udviklet egen suite af udviklingstools. Ikke fordi det er vores kerneforetning at udvikle tools, men fordi det har været nødvendigt. RTX har bl.a. udviklet egen In-Circuit-Debugger. Der fandtes ikke nogen brugbar løsning til de Systemon-Chips (SoC), der udgør en væsentlig komponent i vores forretning, så derfor måtte RTX udvikle en selv. Det har siden vist sig at være et enormt stærkt værktøj. Tæt integration med SoC en og med det grundlæggende software framework gør, at bl.a. chip og systemtilstande kan monitoreres i real time en killer feature i et kommunikationssystem. Værktøjet er så innovativt at det er blevet et produkt i sig selv, og har vist sig så værdifuldt, at det er blevet udvidet med support for bl.a ARM platforme, hvor der ellers er kommercielle 3. parts alternativer. De to ovenstående eksempler på løsninger var aldrig lykkedes uden meget dygtige individuelle kompentencer. Disse kompetencer bygger dels på talent og god uddannelse, men i høj grad også på en stærk Nordjysk erfaring med embedded kommunikationssystemer. RTX forretningen bygger på specialist kompetencer inden for radio, kommunikations prokoller og netværks stakke, signalbehandling etc., samt domæne erfaring inden for de produktsegmenter vi opererer. Spørger vi vores kunder er det uden tvivl vores kompetencer og vores erfaring, der tilfører dem værdi, og som i sidste ende er vores berettigelse. Værdi af kompetencerne Software domænet for RTX er som nævnt primært embedded software. Dette domæne er selvfølgelig på mange måder forskelligt fra system software på PC, server, database eller web platforme. Men grundlæggende er det den enkelte medarbejders kompetencer og innovation, som i sidste ende skaber en særlig værdi i løsningen. I software konstruktion er mange af de nødvendige kompetencer klassiske hard core tekniske kompetencer. Selvfølgelig spiller samspillet mellem individer, team organisation, processor og proces-understøttende værktøjer en stor rolle. I den forstand er det både cool at være oldschool og new-school. Det er lykkedes for RTX både at opbygge stærke individuelle kompetencer og erfaring og at få disse til at spille sammen som organisation. Det har stadig værdi at forstå maskinarkitekturer og at være skrap til bits og bytes og softwareudvikling kræver stadig først og fremmest gode programmører og arkitekter med stærke old-school kompetencer. 8

9 Overblik: Brugbarhed af modelbaserede metoder til udvikling af systemer Adskillige modelleringsteknologiers anvendelighed er undersøgt i et kandidatprojekt mellem DTU og GN Resound. Projektet blev belønnet med ITOS embedded award Arbejdet fortsætter nu i et erhvervs PhD projekt mellem GN Resound og DTU, og er en del af ITOS. Af Allan Munck ErhvervsPhD studerende, DTU og GN Resound Kundernes forventninger til produkternes funktionalitet og brugervenlighed har gjort de indlejrede systemer stadigt mere komplekse. Forventninger om problemfri kommunikation med omgivende systemer har i høj grad bidraget til forøget kompleksitet. En forstærkning af disse tendenser kan forventes i de kommende år. Der er derfor behov for en massiv indsat for at sikre konkurrenceevnen og for at udnytte mulighederne i et kraftigt ekspanderende marked. Fejl koster De fleste virksomheder har med varierende succes udviklet indlejrede systemer ved hjælp af dokumentbaserede metoder, hvor systemerne beskrives successivt i form af dokumenter vedrørende krav, design, implementering, integration, verifikation, validering, produktion og ibrugtagning. For alle disse faser er der risiko for at indføre fejl, der kan få afgørende indflydelse på systems kvalitet og pålidelighed. Jo senere fejlene opdages jo større omkostninger og forsinkelser vil det medføre. I enkelte tilfælde vil det blive nødvendigt at opgive en lancering af produktet. Modeller finder fejl Indførelse af modelbaserede metoder hævdes at kunne løse mange af de problemer, der gælder for dokumentbaserede metoder. Den modelbaserede metode er karakteriseret ved, at systemspecifikationen opbygges som modeller frem for dokumenter. Modellerne kan benyttes til automatiserede og interaktive analyser og simuleringer. Det bliver derfor muligt at finde designfejl, før de fysiske prototyper fremstilles. Metoden gør det således muligt at lave grundige specifikationer af selv meget komplekse systemer, hvorfor det er attraktivt for virksomheder at indføre modelbaserede metoder til udvikling af indlejrede systemer. Overgangen fra dokumentbaserede metoder til modelbaserede metoder kræver dog grundige overvejelser og en betydelig indsats. Formålet med kandidatprojektet mellem DTU og GN Resound har været at undersøge forskellige modelbaserede metoder, modelleringssprog, værktøjer og processer med henblik på at finde en mere optimal måde at udvikle komplekse indlejrede systemer på. Det gennemførte studie er således baseret på en industriel case fra GN Resound, hvor der modelleres et komplekst system, hvori høreapparater udgør en central part. Kandidatafhandlingen kan rekvireres ved henvendelse til GN Resound R&D. Livscyklus og modellering De fleste bøger og artikler om modellering beskriver kun, hvorledes der laves modeller af systemer i regulær drift. Men alle faser af produktets livscyklus må medtages, så man sikrer, at systemet kan implementeres, produceres, vedligeholdes og endelig bortskaffes efter endt service. Projektet startede med en analyse af de forskellige fasers indflydelse på sy- 9

10 ITOS stemet og modellerne heraf. For hver fase identificeres en række interessenter, således at en række krav og begrænsninger for systemet kan identificeres og efterfølgende modelleres. Modelleringsmetoder Projektet indledte med at kigge på en metode, der har været brugt med succes til udvikling af aeronautiske systemer. Denne metode, Embedded Computer System Analysis Model (ECSAM), er dog af ældre dato og åbenbart ikke særlig udbredt. Derfor blev det besluttet også at kigge på Object Oriented Systems Engineering Methodology (OOSEM), som er af nyere dato og tilsyneladende ganske udbredt. Både ECSAM og OOSEM indeholder mange gode og sunde principper. Projektet er resulteret i en unik metodologi med elementer fra både ECSAM og OOSEM, men som i højere grad tager hensyn til systems livscyklus. Modelleringssprog og værktøjer En række modelleringssprog har været undersøgt i projektet, herunder ECSAM, SysML, UML, xtuml, SystemC, Matlab/ Simulink/Stateflow, Labview og QM. Sprogene blev vurderet ud fra en række parametre, herunder deres evne til at beskrive indlejrede systemer med stor udtryksfuldhed, fravær af unødig kompleksitet, ambiguiteter og implicitte relationer. Et godt værktøj er afgørende for succesfuld modellering. Projektet omfattede derfor en undersøgelse af mere end 20 forskellige værktøjer fra simple kontorprogrammer (særligt tegneprogrammer og regneark) til avancerede modelleringsværktøjer med modelcheck mm. Formålet med undersøgelserne var ikke at kåre en testvinder, men at finde den optimale kombination af sprog og værktøj for de individuelle modelleringsopgaver. Modelleringsproces Den unikke modelleringsmetode beskriver en systematisk proces, hvor følgende delmodeller udfærdiges efter behov: Reverse Engineering Model (REM), Business Domain Model (BDM), Problem Domain Model (PDM), Solution Domain Model (SDM), Implementation Domain Model (IDM), Software Model (SWM), Hardware Model (HWM) og Hardware Software Interface (HSI). Guiden beskriver ligeledes hvordan følgende dokumenter genereres ud fra modellerne: Product Description (PD), Test System Description (TSD) og Verification & Testing Requirements (VTR). Specifikationen dækker altså både selve systemet under udvikling samt eventuelle testsystemer og -procedurer. Eksekverbare modeller på vej Projektet viste, at endog modellering uden eksekvering eller uden simulering giver et stort udbytte. Fuldt udbytte opnås dog først, når modellerne kan eksekveres. Næste fase består derfor i at opbygge eksekverbare modeller og lave troværdige simuleringer til forudsigelse af et systems funktionalitet, ydelse, pålidelighed mm.. Et erhvervs-phd projekt er startet med henblik på at gennemføre dette videre arbejde. Erfaringerne fra dette projekt vil indgå i et fremtidigt ITOS framework for modelbaseret udvikling af indlejrede systemer. SysML blev fundet bedst til beskrivende modeller, der ikke kræver analyser eller simuleringer. SystemC blev foretrukket til simuleringsmodeller med lav grad af ambiguitet. Kombinationen af Matlab, Simulink og Stateflow blev foretrukket til lave simuleringsmodeller, når systemet består af flere forskellige domæner fx. analog og digital hardware, system software, DSP algoritmer, mm. Andre kombinationer af modelleringssprog og -værktøjer blev fundet mindre optimale. 10

11 Direktør, 3D Visionlab ITOS Den gode ide er den nemme del... som regel Af Rune Domsten Radikal innovation foregår konstant i næsten alle kroge af virksomheder og samfundet. Udfordringen er som regel at få tænkt alle detaljer igennem, bygget, produceret og allermest udfordrende at få skabt et marked inden ideen er forældet eller andre er kommet foran. Mange virksomheder har brændt fingrene med at lave produkter, som er meget forskellige fra det, de plejer. Det har ofte været ramt af lang udviklingstid og kunder, der ikke var parate til at tage imod det nye produkt. Det kan sagtens være fordi, det var for meget på forkant. Så den sikre vej er at lave et nyt evolutionært produkt. Med tidens stigende kompleksitet i produkter og løsninger samtidig med en fortsat hurtig teknologisk udvikling, bliver de almindelige processer for produktinnovation også sat voldsomt under pres. Minimal smidighed Fra en ide er fostret, til alle nødvendige specifikationer og detaljer er på plads, skal der laves meget tænke og papirarbejde. Her er skreven specifikationer en stigende udfordring både i ressourceforbrug og i kalender tid. Samtidigt er smidigheden minimal, og det gør, at justeringer og innovationer undervejs i et forløb ikke kommer med. Med andre ord sættes innovation og produktinput nærmest på hold, så snart konceptarbejdet et slut. Det er problematisk, at et team kun må være iderige og opfindsomme i den første fase af et projekt. Retænkning Det er derfor nødvendigt at gentænke processer, værktøjer og beskrivelser, når der skal tænkes i produkter, der skal møde et marked, som forandrer sig potentielt meget under et udviklingsforløb. Man kunne fristes til at skille et produkt mere ad i udviklingsforløb. F.eks. at hardware fryses tidligt og har overkapacitet og tænkes genbrugt i flere produkt generationer og varianter. At funktioner altid frigives i en basis version, og der er tænkt flere releases ind med reel fornyelse (ganske som det sker i smartphones, og som det skete med PC er i gennem årtier). Nu er tiden blot kommet til mere almindelige produkter, ikke mindst industriprodukter. Det er blevet en udfordring for industrien, at den er vant til at et produkt skal holde i min 10 år, og at der ikke skal komme nye opgrades og interfaces, men industrien er nødt til at se mulighederne i den nye verden ellers bliver den ramt af dem, der gør det. Crowdfunding I øjeblikket kommer en del af de radikale innovationer fra små nystartede virksomheder via crowfunding fra f.eks Kickstarter og Indigogo. Her bliver produkter præsenteret i en tidlig fase og potentielle kunder kan lægge præ-ordrer ind og kommentere på definitionen. Det udfordrer den gamle venture kapital i måden at skaffe kapital på, da de interesssante projekter bliver finansieret af risikovillige kunder, der præ-ordrer. Samtidigt, kan et team præsentere en ambitiøs ide uden det sædvanlige forarbejde og undersøgelser, som en etableret virksomhed ville gøre. Samlet er metoden med at anvende crowdfunding med til at reducere time-to-market og risikoen, da de første mange kunder allerede har lagt de første ordrer. Danske eksempler Det er p.t to gode danske eksempler på virksomheder Airtame og The Dash der får rykket markedet og kommer i gang, også selvom der i begge tilfælde er tale om meget kort eller kort udviklingsforløb og tekniske udfordringer, som ikke på forhånd er løst helt eller blot tilnærmelsesvist. Det bliver spændende at se, hvornår etablerede virksomheder begynder at benytte crowdfunding og co-creation, når de skal lave radikale innovationer til en ny eller etableret kundekreds. 11

12 Forskellige projektmodeller i Martin Professionals perspektiv Fremgangsmåden for projekter har stor betydning for resultaterne. Projektchef Martin Professional ApS Af Niels Jørgen Lange En virksomheds projektmodel handler om kommunikation og samarbejde; om hvilke forventninger virksomheden stiller i forhold til at indfri fælles mål og hvilke konkrete handlinger eller processer, der kan eller skal gennemføres for at indfri disse forventninger. For Martin Professional er projektmodellen én af de vigtigste forretningsprocesser, og derfor bruger vi også meget tid på at forstå og formidle indholdet. Integreret produktudvikling Det er mange år siden, at samarbejdet i en virksomhed byggede på overlevering fra én funktion til en anden, med lodrette skodder og silotænkning. I dag arbejder langt de fleste moderne virksomheder med Integreret Produkt Udvikling; en samarbejdsmodel, hvor fagdisciplinerne sidder omkring det samme bord og drøfter behov og løsning igennem hele projektet, og evaluerer resultaterne i fællesskab undervejs. Derved får man en bedre kommunikation på tværs af faggrupperne, og derved får man mulighed for at korrigere, hvis man er på afveje, inden det går galt. En udviklingsmodel skal: Være effektfuld, dvs. lede frem til et brugbart resultat på kort tid Være effektiv, dvs. udnytte de mulige ressourcer optimalt Sikre kvaliteten af projektleverancen Være fleksibel så evt. ændringer kan indføres undervejs Fremme innovation, så man kan kapitalisere nye og banebrydende idéer Kvalitet i processen De mest udbredte typer af projektmodeller tager forskellige udgangspunkter, og derfor har de også vægten, lagt på forskellige af ovenstående elementer. En fælles parameter er dog, at de alle vægter at kvaliteten i et produkt først og fremmest fremkommer ved at have kvalitet i processen, der frembringer det. Træfsikkerhed i højsædet Hos Martin Professional har vi sat træfsikkerheden i højsædet for vores projektgennemførelse. Samtidig arbejder vi både målrettet og hurtigt frem til markedsintroduktionen. Projektplanlægning, risikohåndtering, review, og statusrapportering er blot nogle få af de naturlige virkemidler, vi bruger til at sikre, at leverancerne vil kunne indfri målene inden for rammerne, der er givet af ledelsen. Fleksibel stage-gate Vi arbejder efter en fleksibel stage-gate model, hvor der stilles forventninger til projektteamets resultater i de forskellige faser. Samtidig har virksomhedens øverste ledelse mulighed for ved hver gate at tjekke om produktet stadigvæk vil have den forventede effekt og potentiale på markedet, om projektet stadigvæk har en sund økonomi, om projektet leverer den rigtige performance og stadigvæk er det rigtige projekt at køre videre med i porteføljen af projekter. PRINCE2 og PMBOK er eksempler på modeller, der beskriver både det operationelt udførende og det taktiske ledelsesniveau. De kræver samtidig en del administrativ tid til at sikre, at man overholder kravene fra modellen. Ved valg af model skal man derfor nøje overveje, om værdien af de formelle krav står mål med den samlede indsats og økonomi i udviklingsprojektet. Arbejder man f.eks. på et stort it projekt med mange aktører, stort budget og formelle (kunde-) krav til processen, er de nævnte modeller ganske anvendelige, og de har efterhånden også vundet en generel anerkendelse og udbredelse i it branchen. SCRUM Modeller der er mere agile og mindre formelle mht. formen, men fokuserer på indholdet, holder samtidig også det administrative overhead på et lavere niveau. SCRUM er en metode, der understøtter det agile og er målrettet det operationelle niveau for udviklingen af software i et projekt. Formen i arbejdet er ganske vist fastlagt formelt, men fokus er på resultaterne og hurtigt visuelt overblik, frem for rapporter og meget dokumentation. SCRUM er målrettet softwareudvikling, der har den fordel, at softwareproduktet er færdigt, når softwaren er kodet og testen verificerer at kravene er opfyldte. Der er hurtig respons fra oplægget til det færdige resultat. Hardware og mekaniske konstruktioner kan ikke på samme måde levere hurtige håndterbare resultater, alene af den grund at der er et produktionsled imellem tegning til færdigt produkt. Derfor har SCRUM principperne ikke fundet samme udbredelse uden for software miljøet, så agiliteten skal bygges ind på en anden måde. 12

13 Selvom det umiddelbart kan opleves som kontraster, kan stage-gate modeller på det taktisk/operationelle niveau give god mening for mange virksomheder, kombineret med f.eks. SCRUM og rapid prototyping på det operationelle niveau. Agilitet ikke en modsætning Agilitet er derfor ikke en modsætning til stage-gate modeller. En god projektmodel sætter rammen for arbejdet, men i sidste ende er det ikke projektmodellen der gør arbejdet. Den reelle værdi ligger i, hvordan det udføres i praksis. Rapid prototyping af mekaniske konstruktioner kan lade sig gøre med f.eks. SLA modeller, en teknologi der har udviklet sig meget inden for de seneste år. Efterhånden kan man skabe selv relativt komplekse konstruktioner og med forskellige materialer på meget kort tid, og på den måde konkretisere en teknisk løsning. Der er endnu ikke udviklet samme type af teknologi til elektroniske kredsløb. En del simuleringsværktøjer har været tilgængelige i mange år, men rapid prototyping af elektronik kræver fortsat, at man kører produktdesignet igennem en normal fremstillingsproces. Er dette arbejde en del af den kritiske vej i et projekt, er en hurtig prototype proces naturligvis vigtig. Find din egen model På det udførende niveau må det anbefales at bruge den faglige model, der bedst muligt sikrer fornuftig fremdrift, synkronisering og afklaring med de øvrige faglige områder. SCRUM inden for indlejret software giver derfor fortsat god mening, mens de øvrige fagområder arbejder efter en anden agil systematik. Der er næppe en metode, der er så generisk anvendelig, at den kan bruges på alle typer af projekter, uden tilpasning til den organisation og den type af produkt, der skal frembringes. Store formelle krav til form og dokumentation kan være lige så giftigt for fremdriften i et lille projekt, som løs styring og lav dokumentationsgrad kan være for økonomien i et stort projekt. Man må finde det rigtige leje, der passer til projektets karakter og virksomhedens prioriteringer. Hos Martin Professional arbejder vi efter en udviklingsmodel, der kombinerer alle faggrupper og relevante funktioner i et integreret produktudviklingsforløb, sådan at den samlede værdikæde optimeres fra idé til færdig produktleverance til kunden. Vi har taget ved lære af mange af teorierne og kombinerer de brugbare elementer med vores egen empiriske viden, og samlet det hele i en livscyklus model, der vil virke i Martins kontekst. Hæm ikke ideerne Martin Professional lever af show business, og vi skal være meget fokuseret for at definere nye kreative lysprodukter, som vil appellere til markedet. Vores produkt road map indeholder mange produktidéer, der er fremkommet fra mange kilder, der ikke altid lader sig beskrive i en model. Det vigtige er, at der samles op på processen, så man kan få en meget konkret markedsmæssig effekt af det produktprogram, der vælges ud til realisering. Har produktet, vi ønsker at udvikle,ikke det rigtige indhold, er det ligegyldigt, hvor effektive vi er i den efterfølgende realisering af produktet. Udviklingsmodellen er reelt en af de vigtigste forretningsprocesser i virksomheden, da en meget stor del af den samlede omsætning kommer fra produkter, der er udviklet få år forinden. Der sker meget inden for lysbranchen, og de lys og kreative effekter man kan levere i dag, er old school om 3-5 år. Vi har derfor ikke tid til at arbejde med produkter, der ikke vil slå igennem på markedet, men vi har tid til at lege med lys og generere idéer til nye produkter, for det er dér den reelle værdi funderes. 13

14 Når vi de seneste år har set danske virksomheder flytte udviklingen tilbage til Europa skal baggrunden blandt andet findes i det faktum, at danske/europæiske teknikere og ingeniører i højere grad har evnen til at sætte sig ind i designprocessen. De er skrappe til at justere undervejs, så der løbende kan inkorporeres nye specifikationer i designet. Udflytningen gav ikke de ønskede besparelser og fordele og i en del tilfælde det stik modsatte: Fordyrelser og forsinkelser. Forudsigelighed Skal man være konkurrencedygtige på markedet i fremtiden, kræver det, at man er i stand til at styre sin udvikling mht. omkostninger og tid. Det vil i den forbindelse være tvingende nødvendigt bl.a. at reducere antallet af prototyper. Vi vil derfor se en væsentligt større anvendelse af avanceret EDA-teknologi, da kravene til print i produkter som f.eks. telefoner, tablets og andre håndholdte produkter konstant øges mht. funktionalitet, størrelse og strømforbrug. Går vi bare nogle få år tilbage i tiden, så verden ganske anderledes ud, hvad angik komponent- og design kompleksitet man kunne i vid udstrækning klare sig med nogle få tommelfingerregler og gammeldags tegne- og printteknologi. Vi står ikke stille I dag indeholder næsten alle elektroniske produkter avancerede kredse samt interfaces, der bruger industri standard protokoller. F.eks. DDR2/3/ til hukommelse, SATA til lagring, PCI-e og USB ITOS Designværktøjer giver hardwareudviklere konkurrencefordel Fremtiden for virksomheder og hardwaredesignere er at bevare og udvikle sin viden og værktøjer til Electronic Design Automation (EDA). Optimizing design costs and processes 2/3 til kommunikation med eksterne enheder. Vi må formode, at udviklingen ikke står stille, og at vi hastigt bevæger os mod endnu større kompleksitet. Udfordringen er, at designernes kompetencer løbende skal opdateres og kombineres med moderne EDA-værktøjer for at fortsætte det høje niveau indenfor elektronikudvikling i Danmark. Designeren skal kontinuerligt opdatere sin viden. Selv garvede hardware designerne kan komme til kort, når det gælder om at udnytte de moderne værktøjer bedst muligt. Derfor er det også vigtigt at have adgang til løbende efteruddannelse og kvalificeret support. Integration er afgørende Det kræver på den anden side også, at EDA-leverandøren kontinuerligt opdaterer sine værktøjer, så de matcher den nye teknologi. Udviklingen stiller stadig stigende krav til værktøjerne, som bl.a. skal lette design processen og interaktionen mellem designerne ved at automatisere og effektivisere planlægning, kontrollere designforløb, foretage avancerede simuleringer, overskue store mængder af data, udpege egnede og tilgængelige komponenter samt sikre, at printet bliver designet uden fejlmuligheder. EDA-værktøjernes integration, både internt mellem de forskellige discipliner Preventing manufacturing delays from component procurement errors Optimizing power consumption and power efficiency Maximize electrical performance Af Arvid Thorndahl som diagramtegning, simulering, FPGA design, PCB design, mv. og eksternt mod mekanik og produktion, er afgørende for at kunne lette design processen og koordinere forskellige designeres intentioner. Fremtidens EDA-værktøjer vil bl.a. omfatte diagramtegnesystemer med funktionalitet, der kombinerer forskellige metoder til design entry (traditionel diagramtegning kombineret med tabeldrevet, scripting, højniveau sprog mv.), så fremtidens design kan håndteres effektivt. Simulatorer Der vil også være stigende behov for simulatorer f.eks. til PCB signal integritets analyse, hvor man medtager både power og signal integritet i samme analyse, så man kan undersøge hotspots på printet. Dermed behøver man ikke vente på at kontrollere hotspots med f.eks. et termiske kamera, til den første prototype er færdigmonteret med komponenter. Integration of electronics and mechanical enclosure Andre simulatorer kan kontrollere kritiske signaler på design med lavt strømforbrugende kredse, hvor det ellers kan være umuligt fysisk at måle på signalerne på en prototype, Minimize power driven thermal issues Optimize integration of key IP into the overall board system Direktør Nordcad Systems A/S fordi oscilloskopet påvirker signalerne. Viden og udvikling Nøglen til den fremtidige succes for designere og virksomheder, ligger i at kunne bevare den opbyggede viden i virksomheden, brug af avancerede værktøjer, løbende efteruddannelse samt adgang til højt kvalificeret support ellers bliver det ikke muligt at følge med den teknologiske udvikling. 1

15 SysML tackler tvær faglige vanskeligheder i multidisciplinære projekter Af Sune Wolff Erhvervsforsker ved Institut for Ingeniørvidenskab, Århus Universitet og Terma A/S Som regel mangler mekanik og software folkene et fælles sprog, når de udvikler nye indlejrede systemer sammen. Modelleringssproget SysML er udviklet til at tackle problemerne ved at forbedre den tværfaglige kommunikation. For at undgå mange af de problemer, der opstår ved udvikling af løsninger med både it, elektronik og mekanik, er der brug for et mere holistisk overblik over systemet, så tværfaglige udfordringer kan diskuteres langt tidligere. Håndtere krav SysML (Systems Modeling Language) er baseret på UML (Unified Modeling Language), men kompleksiteten er mindsket og mere abstrakte modelleringskomponenter er tilføjet. Det sikrer, at man kan beskrive andet end rene software systemer. SysML er lavet specielt til at håndtere krav, linke tests til krav, nedbryde systemer til mindre komponenter og allokere krav til de ansvarlige komponenter. Semantikken er udvidet til understøttelse af kravsmodellering samt performanceanalyse, som er to essentielle systemingeniør aktiviteter. Teknologier som SysML er nødvendige for at bevæge sig væk fra dokumentbaset udvikling af indlejrede systemer, til en modelbaseret tilgang. Fire SysML diagramtyper i aktion SysML er inddelt i fire diagramtyper: krav, struktur, adfærd og parametriske diagrammer. Diagrammerne dækker forskellige elementer af udviklingsprocessen og er lavet så de giver alternative men komplimentære overblik over systemet. Under et forskningsprojekt udført på Terma A/S blev de forskellige SysML diagramtyper anvendt til at specificere en simulator af elektronisk krigsførelse. Usecase diagrammer blev anvendt til at beskrive den overordnede anvendelse af simulatoren, mens kravsdiagrammer modellerede de mere tekniske krav. Blokken Et grundlæggende modelleringselement i SysML er blokken, der kan repræsentere alt lige fra software og hardware til mekanik og processer. Terma brugte et blokdefinitionsdiagram til at nedbryde simulatoren i mindre blokke og beskrive deres indbyrdes hierarkiske opdeling. Interne blokdiagrammer blev brugt til at beskrive interfaces og sammenhænge internt i disse blokke. Disse to diagramtyper bruges altså til at modellere strukturen af systemet. Terma benyttede tilstandsmaskiner til at beskrive det fjendtlige missils adfærd, mens sekvensdiagrammer blev brugt til at beskrive interaktionen mellem flyets selvbeskyttelsessystem og sensorer. Jagerfly Et jagerfly beskytter sig mod missiler ved at skyde såkaldte flares ud, som afleder missilet. Til at beskrive de fysiske egenskaber af de flares, selvbeskyttelsessystemet affyrer, blev parametriske diagrammer benyttet. De gjorde det muligt at beskrive en flares bevægelse over tid vha. differentialligninger. Fordele ved SysML For systemingeniører der vil forbedre præcision og effektivitet i kommunikationen med andre tekniske og ikke-tekniske interessenter, er SysML et glimrende valg som modelleringssprog, da SysML formår at beskrive hele systemer på tværs af de involverede fagdiscipliner. Overvåge lufthavn Ved at modellere hele systemet får man langt tidligere en kommunikationsplatform til at drøfte tværfaglige udfordringer med til at sikre, at problemer bliver synliggjort længe før den kritiske integrationsfase, hvilket klart mindsker udgiften for at rette disse fejl. Under det beskrevne forskningsprojekt på Terma gav brugen af SysML gode resultater. Især var det værdifuldt at kunne koble elementer fra de forskellige diagramtyper sammen for at opnå en mere holistisk beskrivelse af systemet. F.eks. var det værdifuldt, at man i én og samme model kunne beskrive kravhierarkier, allokering af krav og test cases til validering af krav. Det gjorde det nemmere at spore krav igennem systemet. Der er planlagt yderligere brug af SysML hos Terma til at beskrive et kommercielt produkt til overvågning af lufthavne. Her vil fokus være på interface beskrivelser mellem de del-systemer, der skal interagere i dette system. LÆR MERE Der er flere muligheder for at lære mere om dette spændende modelleringssprog. Aarhus Universitet holder kurser i systemingeniør disciplinen både på bachelor og kandidat niveau. I disse kurser er SysML et centralt element. ITOS tilbyder en Master Class til systemingeniører, hvor der er afsat en hel dag til undervisning i SysML. 15

16 Finale 5. april i Industrien Hus Kom og deltag! efactor 201 er skudt i gang Luften var fyldt med spænding og forventning, da efactor 201 Bringing embedded systems to life rullede i gang. Af Birthe Ritter Projektleder efaktor, DI ITEK 0 repræsentanter fra alle de kvalificerede hold var mødt frem for at deltage i launchen og få udleveret det Arduino-kit, som de har de næste 8 uger til at udvikle deres vinderprojekt med. Startskuddet blev givet ved en videokonference 7. februar mellem deltagerne fra AAU, AU, DTU og ITU styret af Edward Todirica fra DTU med assistance fra Ulrik Nyman i Aalborg og Sune Wolff i Aarhus. 1 spændende projekter 1 teams med i alt 9 studerende er kvalificeret til efactor 201, heraf 3 teams fra Aalborg, teams fra Aarhus, teams fra DTU, 1 team fra ITU og 2 blandede teams fra DTU/ITU. På videokonferencen præsenterede alle holdene sig selv, deres baggrund og erfaring med embedded systems. De fortalte også, hvad deres projekt drejer sig om, men da der var lutter konkurrenter tilstede, blev der ikke afsløret for mange detaljer. Undertegnede kan dog berette, at vi kommer til at se spændende løsninger der bl.a. sigter på at løse problemstillinger indenfor trafiksikkerhed, arbejdsmiljø, fysisk og psykisk velbefindende. Finale i Industriens hus De næste 8 uger fordyber de 1 teams sig i at udvikle deres løsning, og der er lagt op til en særdeles spændende slutspurt, når vinderne af efactor 201 findes på finaledagen lørdag d. 5. april i Industriens Hus. Her præsenterer og demonstrerer alle team deres projekt for et dommerpanel bestående af medlemmer af ITOS styregruppe og udvalgte eksperter indenfor embedded systems. Åben for publikum Finaledagen er åben for publikum. Her kan man se, høre om og måske prøve de spændende løsninger. Publikum har også noget at skulle have sagt. Der kan stemmes om, hvilket projekt man som publikum synes bedst om og finder mest forståeligt og brugbart. Der er kr. til 1. prisen og kr. til hhv. innovationsprisen og publikumsprisen. 16