ITOS FIELDBOOK

Dine fremtidige kunder kræver mere af dig end i dag. De forventer smarte produkter. Kan du levere?

Denne tekst henvender sig til dig, der er i en virksomhed, som står på tærsklen til eller allerede er i gang med at udvikle smarte produkter.

Hvis din virksomhed ikke er den første til at levere et smart produkt kan nogle andre tage hele markedet ved at være dem, der kommer først.

Smarte produkter spænder lige fra at tilføje den simpleste sensor til jeres nuværende produkt, til de mest komplekse løsninger. En enkelt sensor kan tilføje masser af værdi til et klassisk produkt.

Her fi nder du løsninger, konkrete råd og vejleding. Du bliver guidet gennem de første trin og får anvisninger til, hvor du kan fi nde mere information og vejledning.

Du får inspiration om følgende:

– Technology roadmaps, Systems Engineering, modellering

– Konkrete cases fra danske virksomheder

Med andre ord: Forståelse for udvikling af embedded systemer og smarte produkter i praksis.

F I E L D B O O K

&UDVIKLING AF

EMBEDDEDSYSTEMER

SMARTE PRODUKTER I PRAKSIS

Lav din virksomheds eget roadmap

IT S IT S

FIE

LDB

OO

K - U

DV

IKLIN

G A

F E

MB

ED

DE

D S

YS

TE

ME

R &

SM

AR

TE

PR

OD

UK

TE

R I P

RA

KS

IS

Udgivet af DI ITEK

H.C. Andersens Boulevard 18

1787 København V.

Telefon 3377 3377

itek.di.dk

itek@di.dk

Redaktion slut 10.10.2015

Layout: fru nielsens tegnestue

Tryk: Dystan & Rosenberg

ISBN: 978-87-7144-065-2

500.10.15

ITOS

FORORD

Mange industrielle produkter baserer sig i dag på avancerede teknologier. Samspillet mellem det fysiske, det digitale og det elektroniske griber om sig og grænsefladerne viskes ud. Vi ser ind i en fremtid, hvor industriens pro-dukter er online, kommunikerer, bliver selvstyrende, selvlærende og forud-seende. En fremtid, der ligger lige rundt om hjørnet – og i nogle tilfælde al-lerede er her.

Ambitionen er, at den fremtid skal danske virksomheder forme og præge. En stærk konkurrenceevne kræver, at man som dansk virksomhed mestrer det digitale univers på samme høje niveau, som man i dag mestrer produk-tionens univers – og at man er i stand til at få universerne til at smelte sam-men.

Nærværende fieldbook udspringer af projektet Industrielle Teknologier og Software (ITOS). Bogen præsenterer en samlet ramme af metoder, proces-ser og teknikker til, hvordan virksomheder i praksis bevæger sig fra indu-strielle produkter til smarte produkter ved at styrke kompetencerne inden for udvikling af embedded systems.

Projektet er et samarbejde mellem 14 virksomheder, Aarhus Universitet, Aalborg Universitet, Danmarks Tekniske Universitet, DI ITEK og Industri-ens Fond. Projektet har kørt i fire år og formålet har været, at danske virk-somheder får ny viden, nye kompetencer og nye ingeniører, der kan styrke dem i konkurrencen på det globale marked både nu og i fremtiden.

Håbet er, at denne fieldbook kan være med til at sætte embedded systems og nye teknologiske muligheder på agendaen, og at projektets resultater bidrager til, at samarbejdet på tværs af virksomheder, uddannelsesinstitu-tioner og forskningsenheder bliver prioriteret og værdsat yderligere af alle parter i og omkring dansk erhvervsliv.

Mads Lebech Adm. direktør Industriens Fond

FOTO: TERMA A/S

ITOSIND

HO

LD

4 EXECUTIVE SUMMARY

5 INTRODUKTION TIL FIELDBOOKEN

7 1. TAG UDFORDRINGEN MED SMARTE PRODUKTER OP 7 1.1 FRA INDUSTRIELT TIL SMART PRODUKT

8 1.2 FRA TANKE TIL HANDLING – DET KAN DU BRUGE FIELDBOOKEN TIL

15 2. GØR DIN VIRKSOMHED KLAR TIL SMARTE PRODUKTER 15 2.1 HVOR MEGET UDVIKLER SKAL VIRKSOMHEDEN VÆRE

18 2.2 SMART, SMARTERE, AUTONOM

23 3. LÆG TEKNOLOGISTRATEGIEN FOR DINE SMARTE PRODUKTER23 3.1 FÅ GREB OM TEKNOLOGI-GAP’ET

24 3.2 TEKNOLOGIOVERVÅGNING

25 3.3 TEKNOLOGIROADMAPPING

26 3.4 TEKNOLOGIMODNING

28 3.5 DET KORTE AF DET LANGE

31 4. BRUG DE RETTE METODER31 4.1 MÅL OG OPGAVER

32 4.2 ROLLER OG ANSVAR

33 4.3 SYSTEMS ENGINEERING I TERMA A/S

34 4.4 SYSTEM ENGINEERING PROCES

36 4.5 SYSTEMS ENGINEERING VÆRKTØJER

37 4.6 KORT OG GODT

39 5. VÆLG DEN RETTE PROCES39 5.1 ITERATIVE OG AGILE PROCESSER

43 6. BRUG DE RETTE TEKNIKKER43 6.1 MODELLER – LIDT AD GANGEN

48 6.2 REQUIREMENT ENGINEERING ELLER KRAVSTYRING

51 6.3 SIKKERHED FOR SMARTE PRODUKTER

53 OPSUMMERING KAPITEL 4-653 VIRKSOMHEDENS KOMPETENCEROADMAP

57 7. GÅ I GANG MED SMARTE PRODUKTER57 7.1 HOVEDPOINTER FOR AT KOMME FRA INDUSTRIELT TIL SMART PRODUKT

58 7.2 HER FINDER DU MERE INFORMATION

63 8. ITOS CASES64 8.1 GN RESOUND – SMART PHONE STYRET HØREAPPARAT

67 8.2 SELUXIT – DET AUTONOME HUS

71 8.3 TERMA – BESKYTTELSE AF KRITISK INFRASTRUKTUR

74 8.4 MAN DIESEL & TURBO – MERE RENE OG EFFEKTIVE DIESELMOTORER

80 REFERENCER

ITOS

DEN HELT KORTE VERSIONI denne fieldbook kan du læse om, hvad der skal gøres, når du vil gå fra industrielt til smart produkt.

Fieldbooken giver dig grundlag for at tegne dit eget roadmap for din virksomheds udvikling af smarte produkter og embedded systemer. Det handler om jeres:

¤ Udfordring med at udvikle smarte produkter til kunder og markeder

¤ Ambition – hvilken udvikler I skal være og hvor smarte jeres produkter skal være

¤ Teknologiske strategi

¤ Kompetencer I skal beherske

¤ Next step og inspiration fra andre

Fieldbooken giver således et overblik og ram-me for at fastlægge, hvad din virksomhed skal beherske for at få succes med at udvikle smar-te produkter – og hvordan du løfter din organi-sation til opgaven.

Fieldbooken baserer sig på en stor gruppe dan-ske virksomheder og universiteters fælles ar-bejde og deres anbefalinger om, hvad der skal til for at udvikle smarte produkter. Der berøres, hvordan du bruger technology road maps, Sy-stems Engineering og modeller og kommer vi-dere fra klassiske udviklingsdyder som stage gate og krav. Det krydres med cases og best practices baseret på gennemgående forsk-ningscases fra GN ReSound A/S, MAN Diesel & Turbo A/S, Terma A/S og Seluxit ApS.

Fieldbooken formidler best practice for udvik-ling af smarte produkter baseret på erfaringer fra danske virksomheder og universiteter.

Fieldbooken giver konkrete input til den inge-niørmæssige realisering af smarte produkter. Den er skrevet til dig, der gør dig overvejelser om, hvordan din virksomhed kommer i gang el-ler videre med embedded systemer, og som sø-ger inspiration til at øge jeres kompetencer.

EXECUTIVE SUMMARY

Forfattere Henrik Valentin Jensen (red.), DI ITEK

Mads Kronborg Agesen, CISS, AAU

Ulrik Nyman, AAU

Sune Wolff, AU, Terma A/S

Bidragsydere Allan Munck, DTU, GN ReSound

Martin Løkke – Terma A/S

Jørn Johansen – Whitebox A/S

Nicolai Pedersen – DTU, MAN Turbo & Diesel

Brian Boyles, Seluxit Aps

Henning Mortensen, DI ITEK

ITOS

Samfundets stærkeste forandringskraft er digitaliseringen. Den påvirker måden, vi udveksler information med hinanden, hvordan vi arbejder, vores produkter, apparater og udstyr, og hvordan virksomheder fungerer og kon-kurrerer.

Det har stor politisk og kommerciel betydning, at danske virksomheder er i stand til at realisere de muligheder, som digitaliseringen giver.

Konkret betyder digitaliseringen, at produkterne skal kunne langt mere. Produkter inden for stort set alle områder kommer til at få teknologier ind-bygget til at overvåge, måle og styre produktet og til at kommunikere og ud-veksle data.

De kaldes under et embedded eller indlejrede teknologier og systemer. De omfatter eksempelvis sensorer, software, netværk og trådløs teknologi, og er kernen i digitaliseringen af produkter. Det tegner lovende perspektiver for danske virksomheder og kræver samtidig, at en lang række nye metoder skal tilegnes og beherskes.

Denne fieldbook opstiller et grundlag for, hvordan virksomheder kan gøre brug af embedded teknologi og at udvikle produkter med smarte og intel-ligente funktioner. Fieldbooken bygger på praktiske erfaringer fra en række virksomheder om den måde, de arbejder med at udvikle smarte produkter til deres kunder.

Fieldbooken er bygget op, så den kan bidrage til ledelsens proces og plan-lægning af udviklingsarbejdet. Den lægger op til, at ledelsen kan få beskre-vet et roadmap over den udviklingsaktivitet, virksomheden skal igennem, og hvilke betingelser der skal til. Den introducerer metoder og værktøjer - tech-nology roadmap, systems engineering og modellering.

Det er centrale kompetencer til at tage de teknologiske udfordringer og mu-ligheder op og omsætte dem til nye avancerede danske løsninger. Det arbej-de skal fieldbooken stimulere til. Hermed er bolden til det givet op.

Adam LebechBranchedirektørDI ITEK

INTRODUKTION TIL FIELDBOOKEN

ITOS

61

7

ITOS

Virksomheder udvikler smarte produkter for at give deres kunder flere og bedre funktionaliteter. Det sker ved at sammensætte flere hardware- og software-teknologier. Vejen dertil går gennem at opgradere sin organisa-tion med kompetencer, metoder og teknikker til udvikling af embedded sy-stemer.

1.1 FRA INDUSTRIELT TIL SMART PRODUKTKampen på de industrielle produktmarkeder bliver fremover ført ud fra hvor smarte de enkelte produkter er, altså hvor meget intelligens og kommuni-kation, der bygges ind i produkterne. Kommunikation og intelligens bygges ind gennem embedded systemer.

Smarte produkters embedded systemer forbedrer kvaliteten og giver helt nye muligheder. Det gælder for f.eks brugerne af høreapparater, som kan bruge en smartphone til at regulere lydstyrke. Embedded systemer kan sty-re apparaterne i vores private hjem automatisk. De gør motorerne i han-delsskibe mere miljøvenlige og de kan øge sikkerheden af kritisk infrastruk-tur i eksempelvis lufthavne.

Nye smarte funktioner er noget de fleste professionelle kunder og forbruge-re forventer som en naturlig del af nye produkter. Når en funktion findes på en smart phone eller tablet, ønsker kunderne de samme typer funktioner og apps føjet til deres professionelle og private udstyr. Det virker enkelt og li-getil, når vi får adgang til en hel række af funktioner uden, at vi som brugere behøver at vide eller kende noget til den underliggende kode.

Teknisk og produktmæssigt er det imidlertid en meget stor mundfuld at tage fat på for de fleste danske industrivirksomheder og deres udviklere. Kundernes nye krav og forventninger stiller ethvert branche- og produktom-råde overfor en række nye tekniske krav, og for en del af virksomhederne er der tale om nyt og ukendt land.

Udover flere funktioner og bedre styring af produkterne stiller brugeren krav om realtidsovervågning og monitorering, for mere præcist og bedre at kunne følge med i, hvordan vigtige parametre, udvikler sig. Kunderne stil-ler også krav om, at produkterne skal kunne styres på afstand, en forvent-ning om trådløs kommunikation, og at produkterne kan håndtere samspil-let med andre smarte produkter.

For udviklerne rejser det en række udfordringer, og de skal afgøre hvilken stak af teknologier, der bedst opfylder kravene. Det gælder fra både en mar-kedsmæssig, teknisk og økonomisk vinkel. Samtidig skal udviklerne und-gå at blokere for de nye landvindinger, vi venter de kommende år med ikke mindst big data og Internet of Things.

Embedded systemer udgør grundlaget i alle nye smarte produkter. Uden embedded systermer ville der f.eks ikke være computerstyring af tog og bi-ler. Big data, cloud teknologi og netværk har alle embedded systemer ind-

1. TAG UDFORDRINGEN MED SMARTE PRODUKTER OP

Kampen på de industrielle produktmarkeder bliver frem-over ført ud fra, hvor meget intelligens og kommunikation, der bygges ind i produkterne

Kundernes nye krav og forvent-ninger stiller ethvert branche- og produktområde overfor en række nye tekniske krav

8

ITOS

bygget. De omfatter sensorer, visionsystemer, wireless og regnekraften til at styre forskelligt udstyr og systemer på afstand, og gør dem i stand til at kon-trollere sig selv. Internet of Things, IoT, hvor alt fremover kan kommunikere og styres via nettet, kommer til at præge alle og brancher fremover. I praksis kommer ingen produkter til at gå fri – og i mange brancher vil de smarte pro-dukter, og de services der følger med, også bane vejen for omvæltning med nye stærke konkurrenter og forretningsmodeller.

Teknisk, skal vi derfor alle fremover beherske embedded systemer, som bli-ver en game changer på de industrielle markeder.

1.2 FRA TANKE TIL HANDLING – DET KAN DU BRUGE FIELDBOOKEN TIL Fieldbooken giver et praktisk grundlag for at give sig i kast med de udfor-dringer, der følger af at udvikle smarte produkter. Fieldbooken giver konkre-te anvisninger på, hvordan udfordringen kan tages op. Den er udarbejdet, drøftet og skrevet i et langvarigt samarbejde mellem praktikere og forskere.

TIL FORSKELLIGE TYPER VIRKSOMHEDER

I fieldbooken bestræber vi os på at give et grundlag for, hvordan virksom-heder med forskellig baggrund og vilkår for at udvikle smarte produkter og embedded systemer, kan gribe opgaven an. Fieldbooken er bygget op ud fra ledelsens udfordring, og giver input til centrale spørgsmål, ledergruppen kan drøfte. Figur 1 illustrerer den overordnede ramme, som kan bruges til at bygge virksomhedens eget roadmap for udviklingsarbejdet.

FIELDBOOKENS RAMME TIL ET ROADMAP FOR UDVIKLING AF EMBEDDED SYSTEMER

KAPITEL 1 KAPITEL 2 KAPITEL 3 KAPITEL 4-6 KAPITEL 7-8

UDFORDRINGEN VI SKAL TAGE OP

AMBITION:DEN UDVIKLER VI SKAL VÆRE

SÅ SMARTE SKAL VORES

PRODUKTER VÆRE

VORES TEKNOLOGI-

STRATEGI

TEKNOLOGI ROADMAP

DE RETTE METODER

DE RETTEPROCESSER

DE RETTETEKNIKKER

GÅ VIDEREFÅ NY

INSPIRATION

C E N T R A L E S P Ø R G S M Å L

HVAD MENER VI NÅR VI SIGER EMBEDDED SYSTEMER?

SMARTE PRODUKTER?

HVAD ER VORES ERFARINGER MED

AT UDVIKLE OG KOMME FRA IDE TIL PRODUKT?

HVOR SMARTE SKAL VORES PRODUKTER

VÆRE?

HVOR SKAL INTELLIGENSEN

PLACERES?

HVAD SKAL VI MESTRE?

HVAD SKAL VI TAGE FAT PÅ?

HVAD ER DET NÆSTE AFGØRENDE

SKRIDT FOR OS?

HVAD KAN VI LÆRE AF

ANDRE?

FIGUR 1

Fieldbooken giver et praktisk grundlag for at give

sig i kast med at udvikle smarte produkter

9

ITOS

LÆR FRA FIELDBOOKENS FIRE INDUSTRICASESFieldbooken er resultatet af ITOS, der er et projekt, hvor 14 danske virksom-heder sammen med tre universiteter i samarbejde med Industriens Fond og med DI ITEK som projektleder, har været fælles om at udvikle og afprøve nye arbejdsmetoder til at udvikle smarte produkter. I fire virksomheder – GN ReSound A/S; MAN Diesel & Turbo A/S; Terma A/S og Seluxit Aps – er der gennemført forskningsprojekter om udviklingen af embedded systemer sammen med AU, AAU og DTU.

De fire industricases er gennemgående cases i fieldbooken, og er suppleret med andre eksempler fra danske virksomheder. De fire industricases præ-senteres kort på de følgende sider og uddybes hver især i kapitel 8.

VIRKSOMHEDER OG DELTAGERE I ITOS

FIGUR 2

Deltagerne i projektet har været:

Bruël og Kjær Sound Vibration A/S

Danfoss A/S

EKTOS A/S

GN ReSound A/S

Grundfos A/S

MAN Diesel & Turbo

Mjølner Informatics A/S

RTX A/S

Seluxit ApS

Servodan A/S

Terma A/S

Triax A/S

3D Visionlab ApS

Xtel A/S

Danmarks Tekniske Universitet, Aalborg Universitet og Aarhus universitet.

DI ITEK har været projektleder for ITOS

Projektet er gennemført i samarbejde med og støtte fra Industriens Fond. Industriens Fond er en privat filantropisk fond. Fonden støtter og udvikler nyskabende projekter, som styrker konkurrenceevnen for dansk industri og erhvervsliv generelt.

Læs mere om fonden på www.industriensfond.dk

ITOS styregruppe:

Rune Domsten, 3D Vision Lab Aps

Lars Lindqvist, GN ReSound A/S

Martin Løkke, Terma A/S

Kim G. Larsen, AAU

Jan Madsen, DTU

Adam Lebech, DI ITEK

Henrik Valentin Jensen, DI ITEK

10

ITOS

GN RESOUNDULTIMATIV BEDRE SYSTEMS ENGINEERING

GN ReSound finder, at testdrevet udvikling giver bedre kode; færre fejl, ge-nerelt højere kvalitet og en øget produktivitet.

Øget kompleksitet og en forventning om at høre-apparater i nær fremtid forventes at kunne mere og kommunikere med omkringliggende apparater og services, har fået GN ReSound til at afsøge om kombinationen af testdrevet modelbaserede me-toder generelt resulterer i kortere Time-To-Market og et bedre slutprodukt.

GN ReSound arbejder med en grundlæggende ide om at bevæge sig fra dokument drevne processer til testdrevet og modelbaseret systemudvikling.

Forsker: Allan Munck, erhvervs Phd. stip., DTU

MAN DIESEL & TURBOSIMULERING AF TERMODYNAMIK OG MOTORKONTROL

Åbenlys samspil mellem mekanik, termodynamik og motorkontrolsystemet giver blod på tanden i forhold til at simulere hele molevitten, såkaldt co-si-mulering for bl.a. at lette integration af delkomponenter.

MAN Diesel & Turbo’s eksperter i forbrænding, mekanik, motorkontrol og termodynamik anven-der avancerede modelbaserede design- og simu-leringsværktøjer. MAN Diesel & Turbo arbejder ud fra ideologien om at vælge den rigtige hammer til den givne opgave. Hvis MAN skal gøre dét på en smart måde, integreres de enkelte ingeniører og udvikleres værktøjer i ét simuleringsmiljø.

MAN Diesel & Turbo udvikler avancerede distribu-erede kontrolsystemer og tager skridtet videre og indfører et abstraktionsniveau mellem enhederne i deres Cyber Physical System, således at co-simu-lering af forskellige modeller og fysiske enheder er muligt.

Forsker: Nicolai Pedersen, Phd. stip., DTU

CASE 1

CASE 2

”Vi får indsigt i styrker og svagheder ved forskellige metoder og tools. Ultimativt skulle vi gerne få input til at opdatere vores systems engine-ering approach

Lars Lindqvist, VP, Research & Development at GN ReSound

” Modellering og simulering er en hjørne-sten i udviklingen af vores store to-takts motorer. Idet der efterhånden kun ordres elektronisk styrede motorer øges behovet for at modellere og simulere kontrolsystemet sammen med modeller af motoren

Henrik Rechnagel Olesen, Head of Control & Monitoring, MAN Diesel & Turbo

11

ITOS

SELUXIT INTERNET OF THINGS KRÆVER MODELLERING

IoT-softwarevirksomheden Seluxit udvikler platforme og services, der åbner for kommunikation på tværs af hverdagens apparater og fremtidens smarte produkter. Udfordringerne opstår, når apparaterne der kommunikerer med hinanden, har hver deres agenda og til tider modarbejder hinanden. Det for-søges løst med avancerede værktøjer til analyse af modeller af apparaternes opførsel og brugernes krav.

Kommunikation på tværs af protokoller smi-diggøres hos Seluxit ved brug af arkitek-turmæssige abstraktioner, der tillige tjener formålet at kunne verificere den ønskede systemopførsel, og bevare et stabilt og funk-tionel system til trods for mange interessen-ter.

Stigende efterspørgsel og stadig stigende grad af kompleksitet gør, at Seluxit afsøger mulighederne for run-time at verificere på forhånd ukendte konfigurationer af deres IOT-platform.

Forsker: Thomas Pedersen, Phd. stip., AAU

TERMASIMULERING AF IDÉEN DER BLEV TIL VIRKELIGHED HOS TERMA

Et nyt forretningsområde for forsvars- og sikkerhedshedsvirksomheden, benhårde produktkrav og ukendt teknologi, fik Terma til at implementere en model af idéen, før den blev virkelig.

Terma udvikler avancerede systemer med banebrydende teknologi, hvor én af de store udfordringer er at gennemskue konsekvenser og muligheder ved de designvalg der foretages i udviklingsfasen.

Anvendelsen af modeller i samspil med sy-stemingeniør disciplinen, til at verificere øn-sket funktionalitet og visualisere systemop-førsel, har gjort Terma i stand til hurtigt at afgøre modenheden af ny teknologi og der-med accelerere produktudviklingen.

En kombination, der giver agil produktudvik-ling, øget funktionalitet, færre fejl, en bedre kommunikation internt såvel som eksternt og hurtigere Time-to-Market.

Forsker: Sune Wolff, erhvervs-post doc., AU

CASE 3

CASE 4

”Selv om de enkelte enheder er simple, gør sam-spillet mellem konfigurerbare enheder at systemet hurtigt bliver uoverskuelig. Uoverskueligheden gør at vi har brug for værktøjer og metoder til både at teste systemkonfigurationer inden de bliver anvendt, men også til at analysere systemer hvor det trods gode intentioner alligevel gik galt.

Daniel Lux, CEO, Seluxit

” Anvendelsen af en modelbaseret tilgang til ud-vikling af produktet T.react CIP, til beskyttelse af kritisk in-frastruktur, har bidraget til at sænke den overordnede risiko i udviklingsprojektet. Ved først at lave en fokuseret model til evaluering af ny teknologi inden den nye teknologi introduce-res i produktet har vi opnået et modent og optimeret produkt langt hurtigere end uden modellen.

Martin Løkke, Vice President, Programs & Products, Terma A/S

12

ITOS

LIDT MERE OM HVAD EMBEDDED SYSTEMER ER

EMBEDDED SYSTEMER GEMMER SIG UNDER KØLERHJELMEN

Et blik på det, der er sket siden de første dampkøretøjer til den moderne bil i dag, viser den større og større rolle, som embedded systemer, også kaldet indlejrede systemer, spiller.

Biler er blevet langt mere behagelige at køre i siden dampmaskinen, vores sikkerhed er betragteligt forbedret og brændstoføkonomisk sker der i disse år markante fremskridt. Alt sammen gjort mulig af de embedded systemer.

Udviklingen af biler, som figur 3 illustrerer, er at embedded systemer med-fører en række fordele, ved at de:

¤ Tilføjer nye og bedre funktioner til produkter f.eks navigati-onsudstyr, sensorer til parkering og sikkerhedsudstyr

¤ Øger robustheden og effektiviteten af produkterne

¤ Gør vores produkter smartere og mere konkurrencedygtige

Det embedded system er populært sagt alt det hardware og software, der gemmer sig under kølerhjelmen. Som brugere af et produkt, har vi fuld ad-gang til at bruge den funktionalitet, de embedded systemer tilfører produk-tet, uden overhovedet at kende eller have adgang til koden.

Funktionalitet

Teknologi

Fremdrift+ Hastighed+ Komfort

+ Radio+ Lys+ Komfort

+ Hastighed+ Komfort+

+ Radio+ Lys+ Komfort

+ Sikkerhed+ Komfort

+ Sikkerhed+ Navigation+ Komfort

+ Hastighed+ Komfort+

DampMekanik

BrændstofMekanik

IndustrielproduktionElekricitetMekanik og elektricitet

Elektrisk indsprøjtningMekanik og elektricitet

ECU, etc.Mekanik og elektronik

Intern Kommuni-kationMekanik og elektronik

Mekanik, elektronikog software

Mekanik, elektronikog software...?

FIGUR 3

Eksempler på elementer, i embedded systemer:DSP, Electronic Control Unit, Embedded operating systems, Embedded software, Firmware, FPGA, Information appliance, Microprocessor/Microcontroller, Real-time operating system.

Eksempler på teknikker og metoder til at udvikle embedded systemer: Programming languages, Software engineering, Domain Specific Language.

Synonymer for embedded systemer: Cyber-physical systems, indlejrede systemer.

13

ITOS

HVAD MENER VI, NÅR VI SIGER:

¤ Smarte produkter, Embedded Systemer?

¤ I hvilken grad, vil vi kalde vores produkter for smarte produkter?

¤ Hvilken vej går markedet og kundernes ønsker

¤ Hvilke teknologier består vores produkter af? Hvilke skal vi have mere af? Mindre af?

ç LEDELSENS DRØFTELSE

2

15

ITOS

2. GØR DIN VIRKSOMHED KLAR TIL SMARTE PRODUKTER

FASTLÆG DIN VIRKSOMHEDS AMBITION For de fleste virksomheder betyder det at gå fra industrielt til smart produkt, at der til hardwaren skal lægges mere software end hidtil. For nogle har der ikke tidligere været software knyttet til produktet, for andre er det at gå end-nu et skridt videre ad den vej, man er slået ind på. Ambitionen vil være for-skellig afhængig af, hvor langt fremme man er i denne proces og hvad der passer til ens organisation. I dette kapitel ser vi først på, hvad betydningen er ud fra hvor professionaliseret man vil gøre sin udviklingsfunktion. Der-næst ser vi på betydningen af, hvor ambitiøs man vil være med teknologien. Altså hvor meget udvikler skal virksomheden være og hvor smart skal dens produkt være.

Det kan man som virksomhed bruge til at fastlægge sin ambition for, at ud-vikle smarte produkter.

2.1 HVOR MEGET UDVIKLER SKAL VIRKSOMHEDEN VÆREEt gennemgående træk for måden ITOS virksomhederne arbejder med ud-vikling er, at de alle ser på, hvordan de produkter de udvikler, passer ind i et større billede. Samtidig bruger de en eller anden form for beskrivelse el-ler model af det, de skal udvikle, før de starter. Fremgangsmåden omfatter derudover en beskrivelse af de krav, produktet skal opfylde, et design for løsningen, der realiseres med varierende grad af standardmoduler og egen udvikling.

Figur 4 beskriver forskellige niveauer for, hvordan udviklingsopgaven løses fra det meget basale til det meget avancerede. Figuren kan bruges til at fastlægge ambitionen for virksomhedens udvikling.2

For de fleste betyder det at gå fra industrielt til smart produkt, at der til hardwaren skal lægges mere software

FOTO: GN RESOUND A/S

16

ITOS

KOMPETENCEMODEL

Systems Engineering ser vi i ITOS som toppen af arbejdet – den overord-nede tværgående tilgang, der binder alle områderne sammen, medens mo-delleringskompetencer er fundamentet for at udvikle løsninger.

Krav, Design, Realisering og Test & validering er de fire søjler i arbejdet med at udvikle. Baseline beskriver det niveau der oftest vil være i en uer-faren virksomhed og niveau 4 det mest systematiske og højeste niveau for, hvordan man griber udviklingen an.

Hvilket niveau virksomheden skal ligge på, afhænger af den betydning det at udvikle smarte produkter med embedded systemer har for virksomhe-dens nuværende og kommende produktprogram.

Alle behøver ikke at have ambitionen om at nå til det, vi definerer som ni-veau 4. Det væsentlige er, at man som virksomhed identificerer, hvor man er og hvilket indsatsområde, der vil give den største forbedring. Generelt vil vi anbefale, at man arbejder mod at nå niveau 2 i alle kolonner. Herefter af-hænger udbyttet af at bevæge sig op i niveauer af størrelsen på den enkelte virksomhed og typen af de produkter, virksomheden udvikler.

Figuren berører ikke, den konkrete metode for, hvordan processen i arbej-det udføres – om man bruger en Stage Gate model, hvor der tages beslut-ning om at fastfryse bestemte dele af produktets design ved på forhånd be-sluttede milepæle, eller man arbejder agilt med flere parallelle forløb og inddrager brugerne løbende. Det berører vi i kapitel 5.

S Y S T E M S E N G I N E E R I N G K O M P E T E N C E R F O R E M B E D D E D S Y S T E M E R

Krav til produktet Design Realisering Test & validering

M O D E L L E R I N G S K O M P E T E N C E R

Uspecificeret

Skriftlig formuleret

Kravhierarkier

Formelle specifikationer

Modeller af krav

Baseline

1

2

3

4

Enkeltløsnings-orienteret

Diagrammer af visse aspekter

Arkitektur beskrivelseog beskrivelse afhovedfunktioner

Simulering af deleaf designet

Model-drevet design

Udelukkende standardmoduler

Standard moduler + egne moduler

Håndkodet og manuel hardware realisering

Auto-generering af dele af systemet

Chip design & kode generering fra modeller

Ved levering

Løbende feedback

Funktionel test

Automatiseret test

Modelbaseret

FIGUR 4

Beskrivelse af forskel lige komptenceniveauer til

udvikling

Krav, Design, Realisering og Test &

validering er de fire søjler i arbejdet

17

ITOS

SYSTEMS ENGINEERING Når et udviklingsprojekt går på tværs af flere forskellige discipliner såsom mekanik, elektronik og software stiger kompleksiteten i projektet dramatisk. Det er derfor nødvendigt at styre interaktionen mellem de parallelle udviklingsforløb for at undgå kostbare fejl i et udviklingsprojekt.

Systems engineering inddrager alle aspekter af udviklingsprocessen. Et væsentligt forhold for at udvikle velfungerende smarte produkter er, at følge en defineret udviklingsproces. Hvis ikke dette er tilfældet er det stort set umuligt at foretage ændringer i udviklingsforløbet eller at lære til næste udviklingsforløb. At have styr på udviklingsprocessen og projektstyringen er det område, hvor man som virksomhed først og fremmest skal sætte ind, hvis der er manglende kompetencer. Se kapitel 4 for en uddybning af systems engineering.

KRAV TIL PRODUKTET (REQUIREMENT ENGINEERING)For at kunne udvikle det rigtige produkt er det nødvendigt klart at kunne udtrykke krav og ønsker til dets systemiske opbygning med funktionelle og ikke-funktionelle egenskaber. Første trin i bedre at kunne til-passe sine produkter til de krav, de egentlig bør opfylde, er at være fuldt ud bevidst om, hvad disse krav er. Krav kan både være krav direkte fra enkelte kunder, men også fremtiden for det marked, virksomheden opererer i.

Jo højere niveau af kravstyring, jo lettere bliver det at vurdere effekten af ændrede krav og den indbyrdes relation mellem de enkelte krav. I vores kompetencemodel viser vi hvorledes der via en mere systematisk tilgang til beskrivelsen af krav kan opnås en bedre og mere kompetent styring af systemkrav. Se afsnit 6.2 for en uddybning af kravstyring.

DESIGNI Design kolonnen på figur 4 beskrives udviklingen fra at fokusere på det enkelte produkt til at have et modeldrevet framework, der giver mulighed for at konfigurere allerede eksisterende komponenter til nye produkter.

Imellem disse ligger flere niveauer hvor man i før-ste omgang benytter diagrammer eller modeller til at beskrive de overordnede moduler som produk-tet består af og de indbyrdes relationer og afhæn-gigheder imellem de enkelte moduler.

TEST & VALIDERINGI Test og Validering er det vigitigt at fokusere både på:1. Er kundens krav opfyldt?2. Er de tekniske design krav opfyldt?

Opfylder man kun det første, risikerer man at op-bygge en ”teknisk gæld” i sit system.

Opfylder man derimod kun nummer 2, har man et system som virker til specifikation, men ikke løser kundens krav/behov.

REALISERINGRealisering i vores model omfatter både soft-ware og hardware udvikling. Hvis en virksomhed kommer med stærke kompetencer på det ene, men ikke på det andet område er det meget vig-tigt at være opmærksom på, at det kan kræve en helt ny tilgang til et projekt, når det pludseligt både inkluderer software og hardware. For man-ge virksomheder vil der også være mekaniske eller andre produktionsmæssige aspekter som de skal kunne mestre for at fremstille kvalitets-produkter.

MODELLERINGModellering, bør bruges der, hvor det hjælper med at øge abstraktionen fra realiseringen.

Tilstandsmaskiner og kontrol/regulering er gode områder at starte med at anvende modeller.

18

ITOS

2.2 SMART, SMARTERE, AUTONOM Hvor smart et produkt skal være, handler om, hvor meget intelligens og kommunikation, der bygges ind i det. Generelt er det et spørgsmål om, hvor meget regnekraft produktet har til at overvåge og have kontrol over forskel-ligt udstyr, optimere og gøre dem i stand til på egen hånd at udføre opgaver. Denne evne til at udføre opgaver betegnes som en kapabilitet.

En måde at opdele kapabiliteten efter er vist i figuren nedenfor, som går fra monitorering til autonomi. Jo mere smart, desto flere opgaver kan produk-tet udføre og jo mere autonomt fungerer det.

FIRE NIVEAUER AF PRODUKTKAPABILITETER FOR SMARTE PRODUKTERFIGUR 5

AUTONOMI

OPTIMERING

KONTROL

MONITORERING

Sensorer og eksterne data-kilder giver mulighed for overvågning af:– Produktets tilstand– Produktets omgivelser– Produktets brug

Embedded software i produktet eller i tilknyttet cloud giver mulighed for:– Kontrol af produktets funktioner– Personalisering af produktet

Monitorering og kontrolgiver mulighed for algo-ritmer, der optimererproduktets funktion og brug for at:– Forbedre produktets performance– Give mulighed for forudseende system diagnose, service og reparation

Kombinationen af monito-rering, kontrol og optime-ring giver mulighed for:– Autonome produkter– Autonom konfiguration og koordinering med andre systemer– Autonom produkt forbedring og personalisering– Selvdiagnosticering

Kilde: Porter, HBR nov. 2014

CASEMAN Diesel & Turbo ønsker at udvikle mere opti-male skibsmotorer for at forbedre brændstoføko-nomien og levetiden af de samlede systemer de le-verer. En del af deres løsningsstrategi består i øget brug af modeller. De kobler allerede eksisterende modeller af de fysiske processer i en forbrændings-

motorer med modeller af kontrolsoftwaren for at kunne simulere det samlede system. Dette giver mulighed for at kunne eksperimentere med flere systemkonfigurationer, og gør det lettere at udvikle mere dynamiske systemer.

19

ITOS

For hver af de fire kapabiliteter definerer figur 5, den generelle funktionalitet den giver grundlag for. Hvad det betyder for det enkelte produkt, illustrerer eksempler fra de fire gennem gående industricases:

Hvis et produkt giver mulighed for monitorering vil den næste naturlige til-føjelse være kontrol. Dette giver mulighed for både at fjernstyre produktets funktionalitet og at personalisere produktet til den enkelte bruger af syste-met.

Næste trin i tilføjelsen af værdi er optimering, hvor performance af produk-tet kan forbedres gennem optimerede algoritmer og de indsamlede data kan bruges til at forudsige og undgå systemnedbrud.

Det sidste trin i klassificeringen er autonomi. Autonome produkter, der selv er i stand til at undersøge deres nuværende tilstand og deres eget behov for vedligeholdelse. Autonome produkter kan også være i stand til selv at for-handle med andre autonome indlejrede systemer om samarbejde i løsnin-gen af en opgave hvorved de bliver selvkonfigurerende.

En vigtig pointe er, at arbejdet med et niveau i produktet fordrer, at man me-strer de underliggende niveauer.

MONITORERING Hvor stor belastning har skibsmotoren kørt med minut for minut over de sidste 24 timer? MAN Diesel & Turbo casen

KONTROL Via en tilhørende app er det muligt at skifte til det lyd-filter, der skal være aktivt i ens eget høreapparat. GN Resound casen

OPTIMERING Data fra systemet bruges til at forbedre sensor-fusion algoritmerne for at opnå mere præcise estimater af personers bevægelse. Terma casen

AUTONOMI Klimasystemet og indbrudsalarmen snakker selv sammen så åbningen af et vindue ikke aktiverer alarmen. Seluxit casen

FIGUR 6

EKSEMPLER FRA CASENE

20

ITOS

FRA IDÉ TIL SMART PRODUKT Ideér, der realiseres med eksisterende og velkendt teknologi og værk-tøjer giver umiddelbart anledning til at trække i arbejdstøjet og komme hurtigst muligt på markedet. Men i processen fra idé til smart produkt, hvor nye teknologier skal i spil, opleves det som regel, at ens hidtidige fremgangsmåde kommer til kort. Med afsæt i dette kapitel kan ledelsen overveje:

1. HVOR DYGTIGE SKAL VI VÆRE TIL AT UDVIKLE?

Brug figur 4 til at besvare følgende:

¤ På hvilket niveau er vores viden og erfaring med at udvikle smarte produkter?

¤ Er vi på baseline? Niveau 1 eller 2 …?

¤ Hvordan udformer vi vores krav i dag? Designer vi ud fra diagrammer, en arkitekturbeskrivelse, del-simulering eller en model?

¤ Hvad er vores ambition for vores niveau for udvikling? Kræver det, at vi tilegner os nye kompetencer?

2. HVOR SMARTE SKAL VORES PRODUKTER VÆRE?Brug figur 5 til at besvare følgende:

¤ Hvad er kundens behov for funktionalitet? Er det at få målinger over produktets tilstand og brug?

¤ Skal kunderne kunne styre nogle eller alle funktioner? Skal brugerne kunne sætte det op til sig selv? Skal produktet kunne selv-optimere? Have autonom styring af sine funktioner?

¤ Hvad kan vores produkter i dag i forhold til kundernes behov? Kan vi levere det med vores nuværende organisations teknologikompetencer?

è LEDELSENS DRØFTELSE

ITOS

FOTO: SELUXIT APS

3

23

ITOS

3. LÆG TEKNOLOGISTRATEGIEN FOR DINE SMARTE PRODUKTER

Udviklingen af teknologier til smarte produkter sker i et tempo, som hele ti-den giver mulighed for flere varianter og løsninger til kunderne. Det udfor-drer virksomheder, hvor teknologi udgør kernen i deres forretning. For dem gælder det hele tiden om at holde sig ajour med den teknologiudvikling, som har betydning for deres egne produkter. En metode til det er at bruge et teknologi roadmap.

3.1 FÅ GREB OM TEKNOLOGI-GAP’ETEt produkt eller systems performance afhænger af de enkelte delsystemer og samspillet mellem dem. Det indbyrdes samspil bliver mere omfattende jo flere teknologier, der skal spille sammen, og jo flere funktionaliteter vi kræver produktet skal have. Det rejser nye krav til komponentsiden og an-dre nye krav til konstruktionen af systemerne. Det rejser også et spørgsmål om beregningskraften skal ligge i produktet eller i skyen og hvilket netværk produktet skal være koblet på.

Selvom virksomhedens udviklingsmiljø principielt skal kende og kunne ope-rere ud fra alle de muligheder og rammer, teknologiudviklingen giver, er in-gen virksomhed i stand til at overskue teknologierne i sin helhed. Det er derfor nødvendigt at finde en måde at arbejde med det teknologigap, der er mellem virksomhedens egen teknologividen og den teknologi, der hele ti-den er i gang på markedet.

Der skal træffes nogle valg og fravalg af teknologi, og vælges hvordan gap’et lukkes. Overordnet kan det ske ved at se på, hvad virksomhedens teknolo-giniveau er i dag, og hvad det skal skal være inden for en given tidsramme. Altså, at lægge virksomhedens teknologistrategi.

Fastlæggelsen af målet og ansvaret for at få det gennemført hviler på ledel-sens skuldre. Målet kan f.eks. være at give kunder mulighed for at udnyt-te teknologiforbedringer gennem løbende opdateringer. Roadmappet kan f.eks bruges til at tage stilling til hvilke af de mest lovende nye teknologier, man vil arbejde videre med og til at beskrive den vej man vil gå, forudsæt-ninger og barrierer, og til at få listet de opgaver, der kommer ud af det. Le-delse af teknologi omfatter overordnet set tre lag.

¤ Teknologiovervågning

¤ Teknologi roadmapping

¤ Teknologimodning3 Der skal træffes nogle valg og fravalg af teknologi, og vælges hvordan gap’et lukkes

24

ITOS

Overvågning og indsamling af produktrelevant teknologividen er en løben-de proces. Det kan f.eks være at holde skarpt øje, med de forhold, der sæt-ter takten for virksomhedens udvikling, såsom udvikling af nye chip hos chipleverandørerne.

Roadmapping giver et overordnet billede af teknologier og trends og for-ventninger om teknologi, markeder og kunder som virksomhedens kompe-tencer skal matche.

Teknologimodning handler om at vurdere, hvor fremskreden – teknologipa-rat – en given teknologi er i forhold til virksomhedens behov og på baggrund heraf vælge, hvad der skal udvikles på.

3.2 TEKNOLOGIOVERVÅGNINGDer er mange måder at skaffe sig viden om ny teknologi på. Oplagte måder er at deltage i branchens netværk, dialog med ens leverandører, samarbej-de med universiteter, rettigheds- eller patentanalyse og f.eks. gennem mes-ser og konferencer.

Nye metoder er f.eks datamining, big data og webcrawling, hvor der sam-les information ind fra et sociale medier og websider, der kombineres med forskellige databaser.

Embedded systemer giver i sig selv adgang til en lang række data om hvor-dan produkter og systemer virker, de påvirkninger de er udsat for, driftbe-lastninger og produktivitet og f.eks energiforbrug.

” Vi ser ikke kun i produktkataloger, men har dialog med leverandørerne om, hvad de nye chip-sæt kan om 2-3 år. Roadmapping af udviklingen i nye produkter er vigtig for os, og hvordan markedet bevæger sig i vores branche.

Claus Omann, adm. direktør Triax

Der er mange måder at skaffe sig viden

om ny teknologi på

TEKNOLOGI MODNING

TEKNOLOGI ROADMAPPING

TEKNOLOGI OVERVÅGNING

Lag af teknologiledelseFIGUR 7

25

ITOS

Overvågningen skal give viden om muligheder og trusler for ens produkter. Det bør ske systematisk, så der bliver skabt et dækkende billede, og man så vidt mulig bliver opmærksom på relevante teknologier, så der satses på de rigtige.

3.3 TEKNOLOGIROADMAPPINGTeknologiroadmap er et meget anvendt værktøj til teknologiledelse. Det ta-ger afsæt i virksomhedens strategi, således at beslutningerne om teknologi og produktudvikling går hånd-i-hånd. Overordnet set er et teknologiroad-map et værktøj til teknologiplanlægning som:

¤ Linker teknologier til produkter og derpå til kundebehov

¤ Viser gap mellem de ønskede produkter og teknologierne bag dem

¤ Giver bedre forudsigeligheden i produktudviklingen

Som regel er der flere lag af roadmap involveret – et for den overordnede markedsudvikling og forretning som linker til de produkter og services virk-somheden sælger som igen linker til teknologibehovet som så skal omsæt-tes i konkrete handlinger for teknologiudvikling. Figuren herunder er inspi-reret af Danfoss’ roadmap.

Kilde: Jesper Søbygaard Nielsen, Danfoss

Time

MARKET

PRODUCT

PLATFORM

M1 M2 M3

P1

T1

C1 C2 C3

T2 T3 T4 T5

PL1 PL2 PL3

P2 P3 P4

”PULL” ”PUSH”

TECHNOLOGY

COMPETENCE

Sammenhængende roadmap – med teknologi ”pull” og ”push” FIGUR 8

Målet er at få opstillet et sam-menhængende roadmap, som viser hvilke nye teknologier og kompetencer, der skal til

Målet er at få opstillet et sammenhængende roadmap, som viser hvilke nye teknologier og kompetencer, der skal til for at kunne udvikle produkter og produktplatforme til sine markeder. Det er således vigtigt at få identificeret afhængighederne i det ”pull” af nye teknologier og kompetencer, der hidrø-rer fra produktroadmappet.

Helt nye teknologiideer, f.eks fra virksomhedens egen innovation, eller nye aktører, skal også inkluderes i teknologiroadmappet. Hvis der ikke er et ek-sisterende produkt i roadmappet, som umiddelbart kræver en sådan ny

26

ITOS

teknologi, kan det ofte være sværere at retfærdiggøre, at der skal bruges tid og penge på modning af den pågældende teknologi, idet der måske ikke ek-sisterer en forretningsplan for dette fremtidige produkt. Disse ”push” tek-nologier kan dog også være vigtige at få modnet, da de nogle gange giver anledning til nye og banebrydende produkter.

Slutresultatet er et teknologi roadmap, der indeholder de teknologier (pla-ceret på en tidsakse), som ønskes og forventes at blive modnet inden for den tidsmæssige horisont for roadmappet. Prioriteringerne af teknologival-gene og modningen af disse sker således gennem markederne og forret-ningsplanen for de enkelte produkter.

En anerkendt metode indenfor teknologi roadmapping er T-plan, der er ud-viklet af Cambridge University i samarbejde med forskellige virksomheder. Virksomhederne Danfoss A/S og Terma A/S har baseret deres roadmap proces på T-plan.

T-plan omfatter en forretningsproces for udvikling af nye produkter, som skaber en dynamisk kobling mellem det tekniske perspektiv og det kom-mercielle perspektiv. Koblingen sker ved at føre nye produkter på marke-det. Det giver ny viden som flyder tilbage til den tekniske organisation og bliver en videnressource, når nye produkter bliver udviklet (Phal mfl.)

3.4 TEKNOLOGIMODNINGTeknologiske risici kan ikke undgås – det er et konstant vilkår, der altid skal arbejdes med. Man kan sænke risikoen ved at anvende relativt modne tek-nologier navnlig dem man selv har erfaring med. I bedømmelsen af moden-hed er det ikke nok, at andre er kommet langt med en teknologi. Den sam-menhæng en relevant applikation skal indgå i kan være helt anderledes. F.eks. kan brugermiljøet den skal leve i være hårdere og kræve mere robust-hed eller der kan være skrappere certificeringskrav.

Modning af ny teknologi sker derfor ofte gennem et teknologiprojekt, som tidsmæssigt ligger inden det egentlige udviklingsprojekt. I et teknologipro-jekt kender man ikke nødvendigvis slutresultatet. Teknologiprojektet skal derfor køres langt mere fleksibelt end et udviklingsprojekt, som har helt fa-ste rammer for både scope, cost og schedule.

Mange virksomheder har implementeret en form for StageGate model (Ro-bert G. Cooper) for at styre de forskellige faser af en produktudvikling og dermed også modningen af teknologierne.

Som et mål for forskellige teknologiers modenhed kan man anvende en op-deling i Technology Readiness Level – TRL. Det beskriver hvor meget en teknologi er undersøgt og testet.

Oversigten neden for lister modenhedniveauer. De går fra grundlæggende forskning i de første niveauer til proof of concept. Her er man så at sige sta-dig i laboratoriet. De midterste niveauer er der, hvor der foretages, simule-ringer hvor modellering f.eks kan være et nyttigt første skridt og forskellige prototypeafprøvning. I de sidste tre niveauer pilottester man og bruger tek-nologien i det miljø og under de forhold, den skal fungere i.

www.ifm.eng.cam.ac.uk/ resources/techmanworkbooks/

t-plan/

27

ITOS

HVOR SKAL VI PLACERE INTELLIGENSENEr væsentligt spørgsmål er, hvor meget funktionalitet og hardware, der skal placeres i selve produktet og hvor meget der skal placeres i skyen.

Jo mere fleksibelt og kraftigt hardware, der placeres i det enkelte pro-dukt, desto mere kan produktet fremtidssikres gennem softwareopdaterin-ger. Det øger selvfølgelig også produktionsprisen for det enkelte produkt, jo kraftigere hardware der skal bygges ind i produktet. Alt afhængig af det marked produktet er tiltænkt kan der være vidt forskellige forhold, der af-gør hvad der er mest optimalt. Der er også en afvejning mellem brug af stan-dard processorer og specialudviklet hardware. Specialudviklet hardware i form af f.eks FPGA’er kan opnå meget bedre performance, men har højre-re udviklingstid.

En anden overvejelse der skal gøres i forbindelse med fordelingen af funkti-onalitet mellem det fysiske produkt og skyen er, om der skal benyttes stan-dard eller egenudviklede protokoller for kommunikationen. At følge stan-darder kan give fordele i forhold til hastigheden, hvormed nye løsninger og produkter kan udvikles.

TECHNOLOGY READINESS LEVELS

TRL 0: Idea. Unproven concept, no testing has been performed

TRL 1: Basic reseach. Principles postulated and observed but no experimental proof available.

TRL 2: Technology formulation. Concept and application have been formulated.

TRL 3: Applied research. First laboratory tests completed; proof of concepts.

TRL 4: Small scale prototype built in a laboratory environment (”ugly” prototype).

TRL 5: Large scale prototype tested in intended environment.

TRL 6: Prototype system tested in intended environment close to expected performance.

TRL 7: Demonstration system operating in operational environment at pre-commercial scale.

TRL 8: First of a kind commercial system. Manufacturing issues solved.

TRL 9: Full commercial application, technology available for consumers.Kilde: EU-kommissionen

28

ITOS

EKSEMPEL FRA GN RESOUND CASENI forbindelse med udviklingen af nye høreapparater der skulle kunne mod-tage lyd via en WiFi forbindelse udviklede GN ReSound en specialdesig-net protokol til at at kommunikere mellem høreapparaterne og en telefon. Et af formålene med denne protokol var at lave mindst mulig af lydproces-sering i selve høreapparaterne da disse har meget begrænset beregnings-kraft. Herved kunne GN ReSound lave et unikt produkt som ingen andre på markedet havde.

FIGUR 9

5 grader

Høreapparat med App

App

speech produktspecial chip

Vejrstationsimpel chip

Fuldt system medstandard chip

og skærm

Cloud Funktionaliteti Cloud

Smart køleskab

3.5 DET KORTE AF DET LANGESørg for identificering, udvælgelse og modning af de ”rigtige” teknologier for jeres produkter. Ledelse af teknologi omfatter tre områder, (i) teknologi efterretninger, (ii) teknologi roadmapping og (iii) teknologi modning, som alle bør forholde sig til og lægge et passende ambitionsniveau for i sin virk-somhed – teknologistrategien.

Arbejdet med teknologiledelse klares ikke af en lille gruppe af mennesker, som sidder isoleret og laver teknologi roadmaps, men kræver derimod en stor koordination og aktiv udveksling af viden om markeder, produkter, teknologier mv. Denne koordination på tværs af organisationer og geografi er afgørende for, hvor succesfuld og effektiv teknologiledelsen bliver.

29

ITOS

CASE

ç LEDELSENS DRØFTELSEI forhold til de produkter din virksomhed udvikler, hvor skal intelligen-

sen placeres? Skal det være i produktet eller clouden?

¤ Hvilke teknologiske forhold taler for en cloud løsning – hvilke taler for at lægge den i produktet?

¤ Hvad er de markedsmæssige argumenter for den ene el-ler anden løsning? Hvilken værdi giver de kunderne? Hvad er prisen hhv. omkostningerne ved den ene frem for den anden løsning?

¤ Hvilke kompetencer kræver løsningerne – har vi dem selv, kan vi opbygge dem in-house eller kan vi skaffe os dem på en anden måde?

CASE: TECHNO-MATIC – HVORDAN SKAL VI LAVE EN CLOUD-LØSNING?

Techno-matic er en af mange mindre virksomhe-der, som står overfor opgaven at modernisere deres produkter. Virksomheden udvikler og producerer bl.a. avanceret styreelektronik til skovmaskiner og hydrauliske lifte. Traditionelt set, har der ikke været behov for et rigt applikationslag med mobil apps, webinterface og avancerede brugergrænseflader. Virksomheden står derfor i dag overfor at skulle træffe en række valg. Valg der alle kendetegnes ved en vægtning af kost vs. funktioner og præget af stor usikkerhed omkring det fremtidige marked og dets krav.

De to yderpunkter for Techno-Matik’s overvejelser er;

¤ Bibeholde eksisterende Atmel MCU styring og tilbyde Cloud connectivity gennem en add-on med seriel/CAN kommunikation til MCU

¤ Udvikle én samlet platform for alle deres pro-dukter med udgangspunkt i en multiprocessor løsning, hvoraf én varetager det øvre applika-tionslag, dvs. GUI, Cloud, IoT, etc. gennem et operativ system som f.eks Linux

De to yderpunkter er fra et Cloud perspektiv lige gode, da remote monitorering og kontrol kan opnås i begge tilfælde. Krav om øget offline funktionalitet trækker i retningen af en større platform da skyen ikke altid er tilgængelig, mens BOM-prisen trækker i retningen af et add-on som tilkøb.

Med InnoBooster programmet, får virksomheden i samarbejde med CISS ved Aalborg Universitet (se mere på www.ciss.dk) sparring omkring valg og fravalg for sidenhen i fællesskab at tage fat på et egentligt prototypisk design af deres Cloud-løsning.

InnoBooster programmet udbydes af Innovations-fonden.

Læs mere om mulighederne for små og store inno-vationsprojekter på www.innovationsfonden.dk

4

31

ITOS

4. BRUG DE RETTE METODER

SYSTEMS ENGINEERINGDen tværfaglige natur af systemerne ligger bag de fleste af de udfordrin-ger man bliver stillet overfor under udviklingen af embedded systemer. Pro-dukterne bliver stadigt mere komplekse og med indhold af både mekanik, elektronik og software. Den øgede kompleksitet i produkterne betyder, at risikoen for at begå kostbare fejl i udviklingsfasen stiger markant. Det er baggrunden for, at danske virksomheder har taget systemingeniør discipli-nen op, da den bidrager til at alle tekniske aspekter afvejes på lige vilkår med de projektplansmæssige aspekter.

En af de danske virksomheder, der gør udstrakt brug af system enginee-ring, er Terma A/S med hovedkontor i Lystrup ved Århus. Terma udvikler avancerede systemer til forsvar, fly, rumfart og sikkerhed og har indført Sy-stems Engineering som en mere systematisk tilgang til de tværfaglige tek-niske aspekter i produktudvikling og projektarbejde.

4.1 MÅL OG OPGAVERSystems Engineering som metode tilstræber at favne alle aspekter af et ud-viklingsforløb. Det grundlæggende formål er at opnå en bedre integration i hele produktets livscyklus, dvs. integration af teknologi, teknik, forretning, projekt- og produktledelse fra ide til kunde. Systems Engineering har i langt højere grad fokus på samspillet mellem de enkelte søjler frem for at foku-sere på f.eks. et bestemt aspekt af teknologiudvikling. Opgaverne går på

Produkterne bliver stadig mere komplekse og indholder både mekanik, elektronik og software

FOTO: TERMA A/S

32

ITOS

tværs af virksomhedens forskellige afdelinger; salg, udvikling og ledelse. Relationer mellem afdelinger opbygges som en egentlig Systems Engine-ering proces ved at styrke virksomhedens evne til at til at tænke helheds-orienteret.

Systems Engineering integrerer traditionel projektledelse og teknisk om-tanke for systemets helhed. I praksis forankres Systems Engineering med fordel hos en eller flere teknisk kompetente medarbejdere i organisationen med stort overblik. Systems Engineering går på tværs af de traditionelle fag-discipliner og sikrer således helheden i produktudviklingen. Med kla-re tekniske ansvarsområder er det systemmæssige ansvar forankret på lige fod med projektledelse. Resultatet er tættere sparring afdelinger i mellem, hurtigere intern feedback og ofte smartere produkter der er udviklet med helheden for øje.

4.2 ROLLER OG ANSVARRollerne i Systems Engineering omfatter udover projektlederen en rolle med ansvar for at varetage ledelse af et projekts tekniske aspekter, forstået således at der er fokus på, at produktet i sidste ende har den ønskede kva-litet og lever op til de tekniske krav. Det er med andre ord en modvægt til projektlederens fokus på tidsplan, leveringstid, budget og omkostninger.

Rollen med ansvar for System Engineering ligger tæt op ad projektleder-rollen PM, og der kan være tale om at have en egentlig systemingeniør SE til varetagelse af ansvaret. De to roller deler såledesdet samlede ansvar for produktudvikling og har visse opgaver af samme karakter. Det er vist i fi-gur 10.

BEHOVSANALYSE

KRAVSDEFINITIONKRAVSSTYRING

ARKITEKTURDESIGN

TRADEOFF ANALYSE

INTEGRATION

OMKOSTNINGSHÅNDTERING

PERFORMANCEOVERVÅGNING

RESSOURCEPLANLÆGNING

PROJEKTKOORDINERING

PROJEKTRAPPORTERING

OUR JOB!

PROJEKTPLANLÆGNING

VERIFIKATION & VALIDERING

OPERATIONVEDLIGHOLD

KOMMUNIKATION

FORHANDLING

RISIKOHÅNDTERING

KONFIGURATIONSSTYRING

ESTIMERING

SYSTEMAFGRÆNSNING

PMSE

FIGUR 10

Kilde: TERMA A/S ud fra PMI-INCOSE Community of Practice on Lean in Program Management

33

ITOS

Systemingeniørens ansvar omfatter de klassiske tekniske processer i udvik-lingsforløb som kravdefinition og kravstyring, arkitekturdesign, verifikation og validering osv. Systemingeniøren vil typisk også have ansvar for behovs-analyse og brugerinvolvering, herunder også at inddrage de dele af organisa-tionen der forestår drift og vedligehold af det færdige produkt.

Projektlederen har fokus på projektplanlægningen, ressourcer og omkost-ninger. Herudover er der nogle processer, som begge roller beskæftiger sig med, og som ofte er mere delt mellem projektlederen og systemingeniøren.I praksis aftales en ansvarsfordeling upfront for produktudviklingen mellem projektleder og systemingeniør.

4.3 SYSTEMS ENGINEERING I TERMA A/STerma har stor værdi af at have medarbejdere, der mestrer det brede tvær-faglige perspektiv kombineret med domæneviden og procesviden indenfor Systems Engineering. Det gælder især produkter med høj kompleksitet der indeholder elementer fra flere forskellige fagdiscipliner (software, elektro-nik, mekanik), som f.eks. radarsystemer eller selvbeskyttelsessystemer til fly og helikoptere. Ofte kan forskellige krav løses både i software, hardware eller i en kombination deraf, men udviklingsomkostningerne vil som regel variere afhængig af den valgte løsning. Der vil som regel også være elementer i bru-gerens anvendelse af produktet, der gør, at én løsning er at foretrække frem for en anden. Det kræver en god forståelse for brugerens behov og et godt overblik over systemet i sin helhed at opfylde det. Det er her Systems Engi-neering for alvor giver værdi for Terma.

Termas strategi fokuserer på forudsigelighed og effektiv gennemførsel af produktudvikling gennem hele produktets livscyklus. Terma har praktise-ret Systems Engineering i mere end 10 år, men det er først med indførelsen af systemingeniør processen, at Terma har formaliseret og nedskrevet hvor-dan, det praktiseres.

Terma får med Systems Engineering identificeret krav fra de relevante inte-ressenter tidligt, får valgt den rigtige arkitektur, får implementeret løsningen og sikret, at løsningen lever op til de krav, der var udgangspunktet. Denne proces har naturligvis også fundet sted tidligere i Terma inden den formel-le systemingeniørproces, men i en mindre struktureret og systematisk form.

Processen er blevet skrevet af en arbejdsgruppe bestående af blandt andet systemingeniører, på tværs af flere forretningsområder, og er løbende ble-vet reviewet af interessenter fra andre procesområder (forretningsudvikling, udviklingsingeniører, product managers), da systemingeniørprocessen ud-fylder en central rolle med kontaktflader til alle disse.

” I vores branche oplever vi, at behovet for tekniske kompetencer, som evner at overskue og specificere store og komplekse systemer, er stadigt stigende. Kun herved sikres, at et større udviklingsteam arbejder i samme retning og at de enkelte delsystemer fungerer optimalt, når de integreres.

Martin Løkke, Vice President, Programs & Products, Terma a/s

34

ITOS

Arbejdet med at skrive en fælles systemingeniørproces på tværs af forret-ningsområder og domæner var værdifuld for Terma. Det lykkedes at kombi-nere de forskellige erfaringer med Systems Engineering i organisationen til ét fælles optimum for produktudvikling dækkende både de civile og militæ-re segmenter. Indførelsen af systemingeniør processen gav anledning til, at nogle af udviklingsprojekterne skulle have et andet og større fokus på Sy-stems Engineering end det var tilfældet.

4.4 SYSTEM ENGINEERING PROCESSystems Engineering handler om at transformere markedets behov til et system, som opfylder dette behov. Behovet for denne transformationen er langt fra ny, og bør ikke foregå tilfældigt, men gennem en systematisk og styret proces, som sikrer, at det går godt hver gang. Opgaverne er således ej heller ikke nye, og ansvaret for opgaverne forankres med System Engine-ering gennem konkrete metoder og processer i organisationen på lige fod med projektledelse.

Der findes flere Systems Engineering metoder. Terma baserer sin proces på den civile standard, ISO/IEC 15288. I bund og grund er Systems Enginee-ring et udtryk for det gamle håndværkerudtryk: ”Measure twice, cut once”. Hvis vi har gode veldefinerede krav og en klar plan for den tekniske gen-nemførsel, er der væsentligt mindre risiko for, at vi skal lave noget om, efter vi har bygget det. Det betyder at indførelsen af system engineering flytter mere arbejde til de tidligere faser af en produktudvikling, så man sikrer, at fundamentet i form af veldefinerede krav og en god arkitektur er på plads.

Sådan kan man komme i gang med Systems Engineering baseret på IEC 15288

1. Identificer en eller flere af de, i IEC 15288 definerede, over-ordnede indsatsområder (Life Cycle Processes)

2. Nedsæt en arbejdsgruppe for hvert indsatsområde

3. Involver personer tværfagligt og på tværs af forretningsom-råder

4. Definer en proces, gerne med udgangspunkt i IEC 15288, en proces der tager hele systemets livscyklus (System Life Cycle) i betragtning.

Sådan kan man komme i gang med

Systems Engineering

Systems Engineering handler om at transformere

markedets behov til et system, som opfylder

dette behov

FOTO: MAN DIESEL & TURBO

36

ITOS

4.5 SYSTEMS ENGINEERING VÆRKTØJERModelleringssprog som f.eks. SysML er udviklet til at give systemingeniører en måde at tackle udfordringerne med tværfaglige kommunikation. Gene-relt mangler elektronik- og software ingeniører et fælles sprog, når de ud-vikler nye indlejrede systemer sammen.

SysML (Systems Modeling Language) er baseret på UML (Unified Mode-ling Language), men kompleksiteten er mindsket og mere abstrakte mo-dellerings komponenter er blevet tilføjet. På den måde kan andet end rene software systemer beskrives. SysML er lavet specielt til at kunne håndtere krav, linke test til krav, nedbryde systemer til mindre komponenter og allo-kere krav til de ansvarlige komponenter. Semantikken er udvidet til under-støttelse af kravmodellering samt performance analyse, som er to essen-tielle systemingeniør aktiviteter.

Teknologier som SysML er nødvendige for at bevæge sig fra traditionel do-kumentbaseret systemudvikling, til en modelbaseret tilgang. Modellerings-sprog SysML bør være i enhver systemingeniørs værktøjskasse.

SysML er inddelt i fire diagramtyper: krav, struktur, adfærd og parametri-ske diagrammer. De forskellige diagrammer dækker forskellige elementer af udviklingsprocessen og er lavet så de giver alternative men komplemen-tære overblik over systemet. Det er ikke nødvendigt for en virksomhed at introducere brugen af alle disse diagrammer. En gradvis introduktion kan anbefales, hvor der i første omgang fokuseres på nedbrydelse af systemet til delsystemer, og først senere beskrives adfærd og performance modeller.

SysML formår at beskrive hele systemer på tværs af de involverede fagdi-scipliner. For systemingeniører, der gerne vil forbedre præcisionen og effek-tiviteten i deres kommunikation med andre tekniske og ikke-tekniske inte-ressenter, er SysML et glimrende valg som modelleringssprog.

Systems Engineering er ... at forstå markedets behov og transformere disse til et system som opfylder behovene

Det er også:

... et PERSPEKTIV –anvender en system-tankegang til helesystemer, deresenkeltdele og interaktion til det eksterne miljø

... En PROFESSION –interdisciplinært fag som

integrerer multidisciplinærekompetencer

... En iterative teknisk ledelses PROCES

SE

Proces

Perspektiv Profession

FIGUR 11

SysML (Systems Modeling Language)

er inddelt i fire diagram-typer: krav, struktur,

adfærd og parametriske diagrammer

Kilde: TERMA A/S

37

ITOS

Ved at modellere hele systemet får man på et langt tidligere tidspunkt en kommunikationsplatform, hvor tværfaglige udfordringer kan diskuteres. Det kan være med til, at problemer bliver synliggjort længe før den kritiske integrationsfase, og mindske udgiften til at rette fejl.

4.6 KORT OG GODTSystems Engineering handler om:

¤ Evnen til at specificere et komplekst system for at sikre at et større (internationalt) tværfagligt udviklingsteam arbejder i samme retning og at de enkelte delsystemer kan integreres efterfølgende

¤ At kunne overskue en øget kompleksitet ved på en struktureret måde, at nedbryde et system i delsystemer og håndtérbare størrelser (System-of-Systems)

¤ Evnen til at modellere komplekse systemer og dermed forudsige og optimere systemernes opførsel

¤ At være helhedstænkende og favne hele produktets livscyklus – fra undfangelse til afvikling

¤ Forstå markedet og dets behov ved at se produktet fra brugerens synspunkt.

Et godt modelleringsværktøj at starte med er SysML og ISO/IEC 15288. Det kan bruges som inspiration til at fastlægge en virksomheds Systems Engineering proces.

5

39

ITOS

Forskellige modeller til at opdele sine udviklingsaktiviteter efter, tjener det formål at få en systematik og et overblik over de forskellige komponenter og delsystemer som udvikles, og sikkerhed for at de nødvendige processer bliver gennemført.

I dag taler vi mest om iterative og agile processer. Den tidligste anvendte procesmodel for udviklingen af software er vandfaldsmodellen. I dag bru-ges den metode mest som en referencemodel for de forskellige konceptu-elle faser, en softwareudviklingsproces består af.

5.1 ITERATIVE OG AGILE PROCESSERIterative og agile udviklingsmodeller er ikke nye. De strækker sig tilbage til de allerførste softwareprojekter og vandt udbredelse og popularitet i løbet af 1990’erne. Blandt de mest kendte kan nævnes udviklingsprocesserne Unified process (UP) og extreme programming (XP) samt projektstyrings-modellen SCRUM.

Hovedelementet i en iterativ procesmodel er, at alle faserne gennemløbes gentagne gange indtil systemet er færdigudviklet.

ITERAKTIV PROCES

Agile modeller er en fællesbetegnelse for en lang række af udviklingspro-cesser, der alle er iterative og lægger stor vægt på brugerinddragelse. Det engelske ord agile kan bedst oversættes med adræt eller smidig i denne sammenhæng.

Hovedlementet i agile modeller er, at brugeren bliver tættere involveret i udviklingen af systemet. Det skal bidrage til, at det for hver eneste iterati-on bliver valideret ikke bare om systemet er korrekt udviklet, men også om det system, der bliver udviklet, svarer overens med de kommende brugeres faktiske forventninger og behov. Agile modeller lægger derudover generelt større vægt på virkende software end på dokumentation.

5. VÆLG DEN RETTE PROCES

5 REALISERING

DESIGN

KRAVANALYSE

VALIDERING OG TEST

DRIFT OG VEDLIGEHOLD

FIGUR 12

Forskellige modeller til at opdele sine udviklings-aktiviteter efter

40

ITOS

Agile procesmodeller har efterhånden vundet stor indpas i organisationer, der udvikler ikke sikkerhedskritisk systemer. En model der bliver brugt for at kombinere de klare faser fra en sekventiel proces med den iterative udvik-ling og validering fra agile modeller, er en såkaldt Stage-Gate model.

I de enkelte stages kan den enkelte udviklingsafdeling vælge at benytte agile og iterative processer og derved prioritere virkende software højt. Men ved de enkelte Gates, når processen skifter type, vil der være krav til dokumen-tation og til at der træffes beslutning om, produktet skal fortsætte eller ej til næste fase.

De første trin i at mestre sin udviklingsproces består i at få styring over udviklingsprocesserne og dernæst klart at definere den proces, der bliver brugt. Den letteste vej til at opnå disse forbedringer er at anvende allerede standardiserede processer som udgangspunkt. De højeste niveauer kan kun opnås gennem vedvarende at arbejde med at forbedre processen og tilpasse den til virksomheden og de specifikke typer af produkter.

AGILITET I PRAKSIS

STAGE-GATE MODEL

Idé Forundersøgelse

G1:Screening

G2:Anden

Screening

G3:Business

case

G4:Review af

Udviklingsforløb

G6:Business

review

G7:Produktions

review

Detaljeret undersøgelse

Udvikling Test ogValidering

Produktion Produktionsstop

SELUXIT OG GN RESOUNDVirksomhedstørrelse, segment og historie har indflydelse på, hvordan det er muligt at agere agilt. Virksomhederne Seluxit og GN ReSound er eksem-pler på en mindre og en stor virksomhed

UDVIKLINGSPROCES OG PROJEKT MODELStore virksomheder har oftest et større procesapparat. Hos Gn ReSound anvendes en traditionel Stage-gate model og stor grad af agilitet ses oftest i de midterste faser, dvs. omkring design og realisering, medens krav- og te-starbejde udføres mere stringent. Seluxit arbejder i projekter typisk med hyppige demonstrationer af funkti-onalitet, hurtig feedback fra kunden. Projekters fremdrift måles ikke som frembringelse af dokumenter ved en gate, men funktionalitet der demon-streres for kunden ved enden af et sprint. Til styrring af "processen" anven-des scrum med bl.a daglige stand-up møder.

FIGUR 13

Agile procesmodeller har efterhånden vundet stor indpas i organisationer,

der udvikler ikke sikkerheds-kritisk systemer

41

ITOS

INTERESSENTINVOLVERINGGN ReSound udvikler produkter, der er underlagt strenge certificerings-krav, hvorfor kravspecifikation foregår tidligt, mens test og validering fore-går sent i et projektforløb. Eksterne interessenter involveres derfor mest kun i de to faser.

Seluxit derimod, har frihed til at involvere interessenter under hele projekt-forløbet. Skulle projektet tage en uventet drejning, involveres nye interes-senter ad-hoc.

LEVERANCER OG DEADLINESSeluxit's meget agile måde at arbejde på, gør at funktionelle leverancer for-fines gradvist gennem et projektforløb, mens dokumentation færdiggøres ved endelig levering. Bevidst holder Seluxit et skarpt øje med scope creep, som kan være en hindring for at nå deadlines. GN ReSound har en veldefineret proces at følge – hele vejen i mål. Udvikle-re har frihed til at gennemføre agile sprints på delleverancer mellem Gates. Endelig levering af såvel dokumentation, funktionalitet og produkt følger en stringent tråd. Scope creep håndteres gennem kravspecifikation, mens deadlines for det meste kun trues af mangel på ressourcer.

6

43

ITOS

6. BRUG DE RETTE TEKNIKKER MODELLER, REQUIREMENTS ENGINEERING OG SIKKERHED

6.1 MODELLER – LIDT AD GANGENFRA SMÅ MODELLER TIL FULD MODEL-BASERET UDVIKLING AF EMBEDDED SYSTEMER

Holdningen blandt ITOS virksomhederne er, at anvendelse af modeller er vigtig – men alt med måde! Forsøg ikke at løfte virksomheden flere niveauer ad gangen, da læringskurven er stejl. I praksis er det klogt at bruge tid på at finde og vælge et specifikt felt, hvor modeller ser ud til at kunne tilføre vær-di til den nuværende arbejdsproces. Derpå laves en målrettet plan for, hvor-dan modellerne bliver indført.

I udviklingsprocesser lærer man hele tiden og finder bedre løsninger. Hurtig tilpasning hele vejen rundt til nye krav er kritisk for at være agil, og er et na-turligt vilkår for kravstyring i dag.

FIND DET RETTE SÆT MODELLER Modellering skal have et formål – vi modellerer ikke blot fordi vi kan. Formå-let for vores modellering bestemmes af en række forskellige parametre og hensyn. Samtidig er valgmulighederne for modeller meget stort, så spørgs-målet er hvilken model, der svarer bedst til behovet. Hos GN Resound har man fundet en metode til at systematisere processen med at finde et brug-bart sæt af modelleringsteknologier, se figur 14. 6

Alt med måde!Forsøg ikke at løfte virksomheden flere niveauer ad gangen. Læringskurven er stejl

FIGUR 14Metode til at finde den rigtige modelleringsteknologi

Types og Systems

ModelingDisciplines

IdentifyModeling

Needs

AvailableTechnologies

Controlo flowData flow

IdentifyPotential

Technologies

CorrelateNeeds &

Technologies

IdentifyOptimalTech.set

ImplementModeling

Setup

Set of modeling

methodologies, languagesand tools

Prioritized Needs vsModeling Disciplines and

Technology Rating

44

ITOS

Enterprise Modeling (EM)

Integrated Engineering (IE) Andre aktiviteteri virksomhedenCoherent Modeling (CM) Andre

udviklings-aktiviteterABCM ABCM

BSM AAM … BSM" AAM"

Fundamental Modeling (FM)

FIGUR 15

Først undersøges hvilke modelleringsdiscipliner, man kan have glæde af, idet virksomhedens nuværende og fremtidige behov kortlægges i forhold til disse discipliner. Derefter undersøges, hvilke teknologier, som opfylder de forskellige behov. Det sidste trin i denne udvælgelsesproces består i at identificere det bedste (minimale) sæt af modelleringsteknologier, som til-sammen dækker behovene. Når værktøjerne skal indføres i virksomheden anbefales det at gøre det gradvist og gå efter de lavt hængende frugter.

Projektet har identificeret følgende modelleringskategorier

¤ Basic modeling (BM)

¤ Behavioral simulation modeling (BSM)

¤ Architectural analysis modeling (AAM)

¤ Behavior/architecture co-modeling

¤ Coherent modeling (CM)

¤ Integrated engineering (IE)

¤ Enterprise modeling (EM)

¤ Artifact beyond modeling

For at kunne bruge metoden er det nødvendigt med et grundlæggende kendskab til forskellige typer af modellering. Figur 15 viser en mulig indde-ling af modelleringsdiscipliner

Figuren skal læses nedefra og op og er et slags kort, der mapper de forskel-lige typer modellering, og hvad de især kan benyttes til.

MODELLERINGSDISCIPLINERFundamental Modeling (FM) benyttes en struktureret kommunikation mellem alle parter, der er involveret i udviklingen af et embedded system. FM kan inkludere modeller af projektfaser, interessenter, krav, brugersce-narier, systemfunktioner, -struktur og -data, testcases, mm. Simulering er ikke en del af FM. Man kan derfor starte med at bruge gængse kontor-værktøjer til at lave diagrammer, tekstbeskrivelser, tabeller, etc. Et egent-

BSM = Behavioral Simulation ModelingAAM = Architectural Analysis Modeling ABCM = Architecture/behavior co-modeling

Fundamental Modeling (FM)

45

ITOS

ligt modelleringsværktøj baseret på f.eks. SysML vil dog normalt være at foretrække, fordi et godt værktøjer gør det nemmere at vedlige holde store komplekse modeller.

Behavioral Simulation Modeling (BSM) benyttes, når der er behov for at forudsige, hvordan et system vil opføre sig i forskellige situationer. Inter-aktive simulering kan bruges til undersøge forskellige aspekter af system uden modellere komplicerede test cases. Automatiserede simuleringer kræver lidt mere at modellere, men gør det til gengæld lettere at gentage verifikationen, når modellerne af systemet eller omgivelserne ændres. Der findes en lang række modelleringssprog og -værktøjer, der er velegnet til BSM. System- og softwaresimulering vil kunne laves med SysML, UML, Si-mulink, SystemC, VDM, Ptoleymy-II, mm. Til hardwaresimulering bruges oftest VHDL, Verilog, SystemC, SPICE, Modelica, mm. Til sikkerhedskriti-ske systemer vil man ofte benytte mere stringente modeller og formel ma-tematisk verifikation med værktøjer som SPIN, UPPAAL, etc.

Architectural Analyses Modeling (AAM) benyttes, når der er behov for at analysere og optimere systemets arkitektur og egenskaber for at opnå den ønskede ydeevne, stabilitet, pålidelighed, brugbarhed osv. Relationerne mellem de forskellige egenskaber beskrives typisk ved hjælp af matemati-ske ligninger eller komplekse funktion (f.eks. termodynamiske ligninger). Simulering af disse ligninger vil ofte kunne laves med de værktøjer, som er beskrevet for BSM ovenfor. Modelleringssproget AADL muliggør andre automatiserede analyser som f.eks. FMEA, fejlspredning, osv.

Architecture/Behavior Co-Modeling (ABCM) benyttes til at analysere og simulerer systemer, hvor der er stærk vekselvirkning mellem systems arki-tektur og opførsel. Dette er tilfælde, når systemet eller brugerne kan (de-) aktivere delsystemer, eller når systemet kan (de-) aktivere forskellige funk-tioner i forskellige situationer (f.eks. når det bliver for varmt). Mange af de værktøjer som bruges til BSM og AAM vil også kunne bruges til ABCM, men det kræver større omhu og stringens at modellere til ABCM. En vel-struktureret model vil også muliggøre automatisk generering af software fra modellerne.

Coherent Modeling (CM) benyttes, når der er behov for at hægte model-ler i forskellige modelleringssprog og -værktøjer sammen. Når man har for-skellige modeller til forskellige analyser er der stor risiko for inkonsistens, når der laves ændringer. Med CM kan man forebygge dette problem ved at lave af (semi-) automatiske model¬transformationer, således at ændrin-ger fra en model overføres til de andre modeller efter et fastlagt skema. CM kræver en betydelig indsats, som kun i sjældne tilfælde vil kunne ret-færdiggøres.

Integrated Engineering (IE) har til formål at integrere de forskellige ingeniør¬discipliner inklusive modellering. Med et godt Product Lifecycle Management (PLM) værktøj kan man integrerer forskellige modeller og sikre fuld sporbarhed til andre artefakter såsom hardware, software, bru-germanualer, dokumentation, osv. IE er nok enklere at indføre end CM, men er dog for den modelleringsmæssige modne virksomhed.

Enterprise Modeling (EM) bruges til at modellere alle virksomhedens ak-tiviteter med at analysere, designe, implementere, fremstille, udbyde, sæl-ge, operere, servicere og vedligeholde produkter og systemer. EM kræver en betydelig indsats og er nok kun for de helt store virksomheder.

Behavioral Simulation Modeling (BSM)

Architectural Analyses Modeling (AAM)

Architecture/Behavior Co-Modeling (ABCM)

Coherent Modeling (CM)

Integrated Engineering (IE)

Enterprise Modeling (EM)

46

ITOS

IDENTIFIKATION AF MODELLERINGSBEHOVUd fra oversigten over de forskellige modelleringsdiscipliner kan vi identi-ficere modelleringsbehovet. Først identificeres vigtige interessenter. Deref-ter forbereder vi passende spørgeskemaer og laver interviews. En analyse af svarene vil resultere i en prioriteret liste af behov (grupperet efter mo-delleringsdiscipliner). Det er vigtigt også at inkludere fremtidige behov, så man ikke risikerer at investere i et setup, som ikke rækker fremover.

IDENTIFIKATION AF POTENTIELLE TEKNOLOGIERMarkedet for modelleringsværktøjer er i rivende udvikling, og potentiel-le modelleringsteknologier kan findes ved at lade sig inspirere af ”Survey of Model-Based Systems Engineering (MBSE) Methodologies ” af Jeff A. Estefan eller ” Popular SysML Modeling Tools” af Tim Weilkiens og ved at søge på nettet.

MAP BEHOV OG TEKNOLOGIERMed listerne over behov og potentielle teknologier kan analysen fortsættes ved at lave en tabel, hvor rækkerne angiver behovene, mens teknologierne skrives i kolonnerne. I felterne angiver vi en karakter for, hvor godt behovet er dækket af teknologien.

IDENTIFICER MULIGE SÆT AF TEKNOLOGIERDet ideelle værktøj findes ikke. Kun i meget få tilfælde kan man nøjes med et enkelt værktøj. Oftest må man benytte et sæt af flere værktøjer for at kunne alle behov. Mappingen mellem behov og teknologier er udgangs-punktet for at finde den bedste kombination. En grundig metode til at finde et godt sæt er vist i figur 16. Her benyttes matematiske metoder, som be-skrevet i ” Identification and implementation of feasible modeling setups” af Allan Munck og Jan Madsen . Det korte af det lange er at sørge for, at alle vigtige behov er dækket med så få værktøjer som muligt. Man kan dog væl-ge en anden strategi, hvor man vælger lidt flere værktøjer, hvis man derved kan få andre fordele – f.eks. bedre brugervenlighed.

FIGUR 16 Mapping mellem behov og teknologier (eksempel, uddrag)

Disciplines and needs Technology rating

Need SysML AADL UPPAAL SystemC PLM Plugins Priority Tool #1 Osate2 + SMC +TLM/AMS Tool#2 4Tool #1

Behavioral simulation modeling Interactive simulations Yes ••• ••• •••• •• NA NAAutomated simulations Yes ••• ••• ••••• ••• NA NAFormal verification Yes • •• ••••• • NA NA

47

ITOS

TAG DET VALGTE SETUP I BRUGNår et godt sæt af modelleringsteknologier er fundet, skal de implemente-res. Det kan gøres på mange måder, da man kan variere antallet af modelle-ringsfeatures og udviklingsprojekter. Figur 18 viser fire ekstremer.

Hver måde har sine fordele og ulemper. Ved at benytte pilotprojekter ri-sikerer man, at setupet ikke kan skalleres op. Omvendt er det en stor or-ganisatorisk udfordring at starte på mange udviklingsprojekter samtidig. Tilsvarende kan det være en stor teknisk udfordring at indføre hele model-leringspaletten på én gang. I praksis vil man nok vælge en fremgangsmåde, der ligger mellem disse fire ekstremer.

I PRAKSISHos GN Resound har man fået en god indsigt i de forskellige modellerings-discipliner og virksomhedens behov. GN Resound har således på en syste-matisk måde identificeret en passende værktøjskasse, der tilfredsstiller både nuværende og fremtidige modelleringsbehov. SysML, SystemC, Sim-Java2 og andre modelleringsteknologier bliver gradvist indført i virksomhe-den, efterhånden som der bliver behov for dem.

FIGUR 17Metode til identifikation af mulige sæt af teknologier

INPUTSTechnology

ratingvs needs

andmodeling disciplines

OUTPUTSSet of

modelingmethodologies,

languagesand tools

Identifyrequired set for

each need

Combine requiredset for

each need

Reduce combined

set

Identifyminimal solution

Chooseamongegually

goodchoices

TechnicallyChallenging Confident

Cautious OrganizationallyChallenging

Feat

ures

Projects

FIGUR 18Implementering af modelleringssetup

48

ITOS

OUTSOURCING

Et solidt og vedligeholdt kravhierarki er en del af grundlaget for succes med outsourcing. Kan en organisation ikke formulere det, den ønsker sig med præcision over for outsourcing partneren, bliver leverancen tilsvarende upræcis. Det gælder også valideringen af leverancen.

6.2 REQUIREMENT ENGINEERING ELLER KRAVSTYRINGTraditionel kravstyring har stadig sin berettigelse, da specifikation af krav spiller en central rolle i kommunikation i og omkring udvikling af produkter og services. I takt med generelt hurtigere markedsmekanismer kan kravene i dag ændre sig markant hurtigere.

MÅLET SKAL VÆRE KLART OG FORSTÅET – OGSÅ NÅR DET ÆNDRER SIG UNDERVEJS

Den menneskelige hukommelse er ikke langtidsholdbar, og den kan ikke huske ret mange ting i detaljen. Til gengæld har mennesker en god fantasi og en levende evne til fortolkning. Derfor er det selvsagt nødvendigt, at vi i et samarbejde er nødt til at formulere og enes om målet.

Problemet med at formulere og fastholde et fælles mål gælder alle udvik-lingsprojekter, og problemets størrelse øges jo flere, der har indflydelse på og skal anvende det fælles mål. Derfor skal de vigtigste krav formuleres så entydigt og fyldestgørende og på en form, der gør det muligt at eftervise at kravene er opfyldt.

For mange produkter består løsningen af integrerede resultater fra flere faglige discipliner; software, hardware og mekanik. Her skal det fælles mål formuleres på tværs af teknologier og fagområder, hvilket igen stiller krav om, at målet er forstået på samme måde på tværs af fagdisciplinerne.Mangler den fælles forståelse af målet på tværs af discipliner, så ender re-sultatet med suboptimering. Det viser sig typisk ved, at den embedded software kommer til at løse opgaver, der havde ligget meget bedre i hard-ware (eller omvendt) og styringen af mekanik bliver gjort unødig besværlig.

Mennesker er pr. definition utålmodige – lad os nu komme i gang. Der-for glemmes centrale krav, for så at komme forstyrrende ind senere i for-løbet med omarbejde til følge. Det kan f.eks være centrale eksterne krav fra standarder, der skal overholdes, for at produktet i sidste ende kan mar-kedsføres. For at leve op til standarder, er det hovedreglen, at alle krav er dokumenterede og validerede. Det stiller så igen ufravigelige krav om spor-barhed mellem f.eks krav og testcases.

” Ofte fejler produkter i testfasen ene og alene fordi, det ikke er ordentligt beskre-vet, hvordan kravet skal testes. Nogle går så vidt, at uden sporbarhed, kan produktet ikke valideres i henhold til standarden.

Jørn Johansen, Partner & Director – Whitebox

49

ITOS

Der er mange penge i at specificere krav og styre dem under udviklingsforløbet.

UNDGÅ PENGESPILDDer er mange penge i at blive bedre til at specificere krav og styre dem un-der udviklingsforløbet. Gøres arbejdet ikke godt nok, kommer der udgifter til fejlretning – i værste fald tilbagekaldelse, når produktet er på markedet.

Årsagen til fejlenes opståen i forbindelse med kravspecifikation og æn-dringsstyring kan f.eks være manglende krav, forkerte krav, tvetydige krav, ikke realiserede krav, mistolkede krav, ikke registrerede ændringer af krav, osv. Der er gennemført flere undersøgelser af, hvor fejl i et udviklingsforløb opstår, og hvad det betyder for den samlede udviklingsomkostning

Figur 19, viser, at langt de fleste fejl på slutproduktet ved udvikling af soft-ware opstår i forbindelse med kravspecifikation og styring af kravændrin-ger. Undersøgelsen viste, at 56% af alle fejl ligger i kravspecifikationen.

Der er i øvrigt stort sammenfald med en dansk EU støttet undersøgelse Her er fejlene hidrørende fra krav 51%. (Vinter)

LØSNINGEN

Ovenstående beskrivelse af problemet med at skabe, formulere og vedlige-holde et entydigt og fyldestgørende mål giver en del af svaret på løsningen af problemet. Hvis flere teams skal arbejde sammen om udvikling af et nyt produkt eller en service, er det nødvendigt med fælles viden og arbejdsfor-mer for at kunne opbygge og vedligeholde det kravhierarki:

¤ dem der skal sikre en solid opbygning af de overordnede krav (eller features),

¤ dem der sikrer den løbende udvikling af produkt eller service kravene,

¤ dem der sikrer, at ændringer i kravhierarkiet styres og dokumenteres.

50

ITOS

UDVIKLING AF KRAVHIERARKI

Første aktivitet er, at få indsamlet alle de vigtigste ønsker, ideer og krav. Her er det centralt, at få så mange interessenter som muligt involveret fra starten. Denne involvering anvender gerne f.eks use cases, demonstrati-oner, interviews, brugerundersøgelser, forretningsanalyser og prototyper i anvendelse. Heri skal også huskes krav fra standarder og interne generelle produkt- og produktionskrav.

Interessentkravene beskrives som krav, kunden eller brugeren i den sid-ste ende kan validere. Denne aktivitet afklarer uoverensstemmelser mel-lem krav eller ønsker fra interessenter, og de krav, der skal prioriteres og ende med at blive realiseret.

Næste aktivitet er specificeringen af kunde- og brugerkrav i produkt og komponentkrav – med sporbarhed gennem hierarkiet både oppefra-og-ned og nedefra-og-op. I denne fase af udviklingen af krav er det vigtigt at få grænsefladekrav mellem komponenterne identificeret og dokumenteret. De er vigtige for at kunne definere en fyldestgørende test. I denne aktivitet deles kravene op i fagdiscipliner, som krav til elektronik, mekanik og soft-ware.

Derefter analyseres kravene for at sikre, at den ønskede funktionalitet med den rette kvalitet kan udvikles. Det kan f.eks ske ved konceptdemonstratio-ner, brug af scenarier og prototyper.

Det er vigtigt, at analysen af kravhierarkiet er sammenhængende og at kra-venes indflydelse på de samlede udviklingsomkostninger afdækkes. Sam-tidig identificeres:

¤ de mest risikable krav

¤ verificerbarheden af de enkelte krav

¤ validerbarheden af de overordnede kunde- og brugerkrav.

DESIGN 27 pct.

ANDET 10 pct.

ÅRSAG TIL FEJL OMKOSTNINGER

IMPL. 7 pct.

KRAV 56 pct.

DESIGN 13 pct.

IMPL. 1 pct.

KRAV 82 pct.

ANDET 4 pct.

FIGUR 19 Undersøgelse af hvor fejl op-står og andelen af omkost-ninger til fejlrettelser.

Kilde: Vinter

Indsaml de vigtigste ønsker, ideer og krav

Specificér bruger- kravene i produkt- og

komponentkrav

51

ITOS

Analysen skal give den nødvendige tryghed for, at produktet eller systemet kan realiseres med de midler, den teknologi og de kompetencer, der er til-gængelig.

Udviklingen af kravhierarkiet forløber parallelt – og skal ikke være en se-kventiel øvelse. Kravene skal fra starten registreres på det rette niveau for at undgå redundant information ned gennem hierarkiet. Her udvikler og æn-dringsstyres hele kravhierarkiet undervejs i forløbet.

6.3 SIKKERHED FOR SMARTE PRODUKTER Når man gør sine produkter smarte og indbygger embedded systemer, der kan kommunikere med omverdenen, skal virksomheden også have fokus på sikkerheden. Der findes en række eksempler på, at smarte produkter er blevet hacket, og ondsindede personer har taget kontrol over produktet el-ler de data, som kommunikeres fra produktet. Der findes også en række ek-sempler på, at forskere har hacket et produkt og efterfølgende orienteret virksomheden om det, således at den kunne rette fejlen inden den blev of-fentliggjort. Begge dele kan komme til at koste betydelige summer på bund-linjen eller tabt renomme.

Typisk opstår fejl i programmeringen, fordi der i udviklingsforløbet under-vejs ikke har været inddraget relevante kendte sikkerhedsovervejelser, el-ler at man forsøger at bygge for mange intelligente ting sammen i systemet. Derfor bør man gå til arbejdet med smarte systemer, som man ville gå til enhver anden udviklingsopgave: Man skal kortlægge og håndtere sine risici og beskytte de mest kritiske dele bedst. Man skal teste sin kode for fejl og eventuelt få nogen til at angribe koden, som om de var hackere med ond-sindede hensigter.

Man skal sørge for, at koden kan opdateres, når der opdages nye sårbarhe-der i produktet eller i tilknytning til produktet. Endelig skal man overveje, om der er tekniske sikkerhedsforanstaltninger, man bør bygge ind i sit pro-dukt fra starten.

Vær også opmærksom på eventuelle lovgivningskrav. I det omfang det smarte produkt behandler personoplysninger, gælder der særlige regler. Reglerne er under revision, men på nuværende tidspunkt kan vi fastslå, at det bødemæssigt bliver meget dyrt ikke at overholde disse regler. Noget af det, man især skal være opmærksom på i den forbindelse, er hvem der har adgang til at se data, om den person data vedrører, har givet samtykke til at videreformidle data og at data kun bruges til det formål, de indsamles til.

Det er ledelsen, som har ansvaret for, at sikkerheden i de smarte produk-ter er på plads. Derfor bør ledelsen sikre, at der er udpeget en sikkerheds-ansvarlig og eventuelt er en sikkerhedsorganisation på plads. Ledelsen skal også sikre, at der er sikkerhedspolitikker og -procedurer på plads. Ledelsen skal sikre, at produktet efterlever relevante standarder og lovgivning. Ende-lig skal ledelsen sikre, at produktet er testet, og ledelsen skal godkende den restrisiko, som det smarte produkt måtte have.

Smarte produkter bør være sikre produkter, for at undgå uforudsete ekstra regninger til virksomheden.

Vær opmærksom på lovgivningskrav. For person oplysninger, er der særlige regler

FOTO: SELUXIT FOTO: GN RESOUND A/S

53

ITOS

OPSUMMERING KAPITEL 4-6

FIGUR 20

Kompetenceniveauerne er beskrevet i figur 4 side 16

VIRKSOMHEDENS KOMPETENCEROADMAP

LØFT DIN VIRKSOMHEDS KOMPETENCER

I de foregående kapitler har vi peget på centrale metoder, processer og tek-nikker til at udvikle smarte produkter og embedded systemer.

I kapitel 2 introducerede vi en model til at beskrive forskellige ambitioner for det kompetenceniveau, man vil ligge på som udvikler. Desuden fire be-greber til at angive produktets kapabiliteter, dvs. hvor smart det skal være – monitorering, kontrol, optimering og autonomi.

I kapitel 3 gav vi et overblik over, hvordan virksomheden kan lægge sin tek-nologistrategi for sine smarte produkter gennem et teknologi roadmap. Det vil sige hvilke teknologier man skal satse på og hvilke markedsforventninger ens produkt teknisk skal kunne leve op til.

I kapitel 4-6 blev der peget på de operationelle kompetencer, der skal be-herskes for at kunne realisere produktet

¤ Systems engineering som overordnet metode og en fast orga-nisatorisk rolle til at integrere de forskellige fagdiscipliner og de markedsmæssige, tekniske og økonomiske perspektiver

¤ Agile og iterative processer som systematik til at opdele og sty-re de forskellige dele af udviklingsaktiviteterne

¤ Modellering og valg af forskellige modelteknikker passet til udviklingsopgaven.

Det udgør de forskellige byggesten i ledelsens fastlæggelse af vejen frem for virksomheden til at gøre sine industrielle produkter smartere, dvs. in-deholde mere intelligens og kommunikation. Det har vi sammenfattet i fi-gur 20.

Kompetenceniveauer for at udvikle produkter med forskellige kapabiliteter Anbefalede kompetence niveauer

Kapabilitet Krav til produktet Design Realisering Test & Validering

Monitorering

Kontrol

Optimering

Autonomi

Niveau 2Niveau 1

Niveau 2

Niveau 3

Niveau 3Niveau 4

S Y S T E M S E N G I N E E R I N G K O M P E T E N C E R F O R E M B E D D E D S Y S T E M E R

Krav til produktet Design Realisering Test & validering

M O D E L L E R I N G S K O M P E T E N C E R

Uspecificeret

Skriftlig formuleret

Kravhierarkier

Formelle specifikationer

Modeller af krav

Baseline

1

2

3

4

Enkeltløsnings-orienteret

Diagrammer af visse aspekter

Arkitektur beskrivelseog beskrivelse afhovedfunktioner

Simulering af deleaf designet

Model-drevet design

Udelukkende standardmoduler

Standard moduler + egne moduler

Håndkodet og manuel hardware realisering

Auto-generering af dele af systemet

Chip design & kode generering fra modeller

Ved levering

Løbende feedback

Funktionel test

Automatiseret test

Modelbaseret

FOTO: GN RESOUND A/S

54

ITOS

Figur 20 viser at det kun er nødvendigt, at befinde sig på de første niveau-er for at udvikle produkter, der understøtter monitorering og kontrol. Udvik-lingsopgaven kan i store træk løses ved at anvende standardmoduler og i et vist omfang egne moduler. For den der hidtil har udviklet et rent industrielt produkt er første skridt mod et smart produkt med andre ord overkommeligt. Vi anbefaler at man stræber mod niveau 2 i figur 4.

Det betyder ikke, det er den rene skovtur. Det er udvikling aldrig, og der vil også være stor forskel på om virksomheden allerede har udviklet succesful-de produkter med f.eks monitorering og kontrol eller man starter fra bunden. Pointen er, at de tekniske kompetencer er inden for rækkevidde. På dette trin kan virksomheden arbejde med at opbygge erfaringer med systems engine-ering f.eks for at optimere produktets værdi for kunden ved at have forskellig vægt på discipliner som f.eks elektronik, software og mekanik. Virksomheden kan samtidig begynde at indarbejde agile processer i sine udviklingsaktivite-ter.

Er ambitionen, at produkterne skal kunne lave optimering til specifikke situ-ationer eller enkelte kunder, bliver det nødvendigt at have en mere styret og modelbaseret proces. For at kunne foretage sådanne tilpasninger er det nød-vendigt at have indarbejdet metoder til Systems Engineering for at overskue, hvilke dele af det samlede system, der bliver påvirket af ændringer i det en-kelte krav og at kunne arbejde agilt hermed.

Specielt produkter med autonomi vil være svære at udvikle uden at have for-melle modeller for produkternes opførsel. Sådanne modeller vil muliggøre si-mulering af verifikation af produktets opførsel i et utal af mulige fremtidige scenarier.

Når ambitionen er lagt fast, kan man stille sig spørgsmålet om hvem man har i organisationen, der kan stå for opgaven og hvilke ressourcer og kompeten-cer, de har til rådighed. Afhængigt af de kompetencer virksomheden har, kan man overveje at skaffe sig eventuelle nye ved at deltage i udviklingsnetværk, efteruddannelse, nyansættelser, udvikle sammen med sine leverandører, uni-versiteter eller teknologiske konsulenter.

SELUXIT CASENSeluxIT der er en lille og relativt ny virk-somhed (stiftet i 2006) har helt fra starten arbejdet med produkter der indebærer monitorering, kontrol og trådløs kom-munikation. Målet for deres produkter til fremtidens intelligente hjem er automa-tisk konfigurering og en stor grad af auto-nomi for det enkelte delsystem. Derfor har de gennem et fortsat samarbejde med Aalborg Universitet sørget for at tilegne sig kompetencer i inden for formelle mo-deller og system verifikation.

TERMA CASENI Terma casen er der blevet anvendt modeller til udvik-ling af prototyper af nye produkter. Dette har givet indsigt i nye teknologier og en hurtigere vej til produkt-modning af nye sensor-fu-sion teknologier. Brugen af modeller har været et godt værktøj til at mildne risi-ci ved introduktion af nye teknologier.

GN RESOUND CASENI GN ReSound casen bli-ver der aktivt arbejdet med betydningen af mo-deller på tværs af alle processer i udviklingen af embedded produkter og med formaliseringen af en ny udviklings pro-ces baseret på kombi-nationen af modeller og testdrevet udvikling.

CASE

S Y S T E M S E N G I N E E R I N G K O M P E T E N C E R F O R E M B E D D E D S Y S T E M E R

Krav til produktet Design Realisering Test & validering

M O D E L L E R I N G S K O M P E T E N C E R

Uspecificeret

Skriftlig formuleret

Kravhierarkier

Formelle specifikationer

Modeller af krav

Baseline

1

2

3

4

Enkeltløsnings-orienteret

Diagrammer af visse aspekter

Arkitektur beskrivelseog beskrivelse afhovedfunktioner

Simulering af deleaf designet

Model-drevet design

Udelukkende standardmoduler

Standard moduler + egne moduler

Håndkodet og manuel hardware realisering

Auto-generering af dele af systemet

Chip design & kode generering fra modeller

Ved levering

Løbende feedback

Funktionel test

Automatiseret test

Modelbaseret

55

ITOS

Spørgsmål til ledelsens drøftelse af sit kompetence roadmap

¤ Hvilke kapabiliteter har vores produkter nu, og hvilke ønsker vi, de skal have?

¤ Ud fra vores teknologi road map eller strategi, hvilke tekniske gap skal vi så lukke?

¤ Kan vi lukke gap’et med det kompetenceniveau vi har, eller skal vi opgradere vores kompetencer (indenfor f.eks systems enginee-ring, agile metoder, modellering, kravstyring, sikkerhed)?

¤ Hvordan opgraderer og skaffer vi os de kompetencer?

ç LEDELSENS DRØFTELSE

FOTO: GN RESOUND A/S

7

57

ITOS

7. GÅ I GANG MED SMARTE PRODUKTER NOGLE TOMMELFINGERREGLER OG HVOR DU FINDER MERE INFORMATION

7.1 HOVEDPOINTER FOR AT KOMME FRA INDUSTRIELT TIL SMART PRODUKTUdvikling af smarte produkter handler om at kunne sammensætte flere tek-nologier og lægge dem ind på en måde, så kunderne opnår bedre og flere funktionaliteter. Vigtige discipliner for den ingeniørmæssige realisering er:

¤ Technology Roadmapping

¤ Systems Engineering

¤ Modellering

Projektledere og udviklere oplever det at være på forkant med teknologier-ne som alt andet end en triviel opgave.Technology Roadmapping er en es-sentiel og farbar vej hertil, og bør foregå sideløbende med udviklingsaktivi-teten.

Traditionel projektledelse anbefales suppleret med systems engineering di-sciplinen, der giver fod på teknologi og kompetencer og gør organisationen i stand til at overskue udviklingen af det komplette system.

Jo smartere produkt, desto flere teknologier og forretningsmæssige per-spektiver skal drejes mod hinanden og desto flere trade offs opstår der. Be-hovet for at kunne simulere og modellere stiger således, jo mere kapabilitet, der lægges ind i produktet.

ITOS projektet har løbende drøftet best practice – en række tommelfinger-regler – for den praktiske brug af de forskellige processer, metoder og tek-nikker. Det, er der samlet op på i boksen:

Udvikling af smarte produkter handler om at kunderne opnår bedre og flere funk tionaliteter

7 ITOS BEST PRACTICES De vigtigste praktiske pointer i udviklingsarbejdet med at bruge de metoder, processer og teknikker fra denne fieldbook blev drøftet af deltagerne på et seminar i ITOS projektet. Det, er der kommet denne liste ud af:

¤ Brug technology roadmaps strategisk til at identificere fremtidige produkter og teknologier.

¤ Afsøg og anvend moden teknologi

¤ Basér ny-udvikling på eksisterende platforme for hardware og software

¤ Håndter aspekter, der går på tværs af forskellige discipliner med en Systems Engineering tilgang

¤ Brug agile modeller i udviklingsfasen – og skab en systematik for kravarbejdet

¤ Hav som mål at øge forståelse og integritet ved brug af modeller i alle led af jeres planlægning og udvikling. Introducer nye modeltyper gradvist, hvor der er besparelser at hente

¤Det ultimative modelværktøj findes ikke – behersk flere

58

ITOS

DET ULTIMATIVE MODELVÆRKTØJ FINDES IKKEGN ReSounds erfaring er, at der ikke findes ét modelværktøj, der alene løf-ter opgaven at udvikle smarte produkter. Hver delopgave kræver speciali-serede værktøjer og der er behov for en sammenkobling af alle organisati-onens værktøjer.

ITOS’ anbefaling er at finde den vifte af modelværktøjer, der tilsammen har den rette funktionalitet og sikre sig, at værktøjerne kan arbejde sammen. Man skal ikke lede efter et værktøj, der kan det hele, det findes ikke.

Understøttelse af 3. part integration indsnævrer udvalget af værktøjer. Sammenkobling af værktøjer for f.eks kravstyring, software- og mekanik- design og dokumentation stiller krav til åbne api’er eller mulighed for data import og eksport mellem software.

7.2 HER FINDER DU MERE INFORMATIONITOS projektet har udgivet seks publikationer om en række væsentlige te-maer. De er skrevet af praktigere og forskere i form af artikler. Vægten er på praktiske efaring og cases.

WWW. itek.di.dk/ Indsatsomraader/

Innovationiteknologi- erhvervet/ITOS

Kort til den indlejrede fremtid Fokus er på teknologi trends og teknologi roadmap

Værktøjer og modeller Vigtige metoder og modeller til at udvikle embedded systemer

Internet of Things og Industri 4.0 To store drivkræfter for teknologiudviklingen

Wireless Teknologi Fokus er på betydnin-gen af wireless teknologi i smarte produkter

Innovation for samfundet Embedded systemer set i et bredere teknologisk udviklingsperspektiv

Roadmap til embedded systemer (dec 2015) Ledelsens arbejde med at udvikle smarte produkter

59

ITOS

TECHNOLOGY ROADMAPEn god kilde til mere information om Technology Roadmaps er den hjem-meside der også bliver refereret til i afsnittet: http://www.ifm.eng.cam.ac.uk/resources/techmanworkbooks/t-plan/ Her bliver der også henvist til følgende bog: ”T-Plan: Technology Road Mapping” (University of Cam-bridge, 2001) som grundig beskrivelse af processen.

En anden mulig kilde er: ”From Business Strategy to Information Technolo-gy Roadmap” (Tiffany Pham, 2013).

SYSTEMS ENGINEERINGOrganisationen International Council on Systems Engineering (INCOSE) har gjort det siden 1990. INCOSE har sit udspring i flyindustrien i USA, men er siden kommet til at dække meget bredt. Det er en non-profit organisa-tion, der har til formål at hæve niveauet for, og udbrede kendskabet til, Sy-stems Engineering på tværs af industri, uddannelsesmiljø og den offentlige sektor. INCOSE har mange forskellige aktiviteter som årlige konferencer, video-web sessioner omkring relevante emner og arrangementer afholdt af de nationale afdelinger.

INCOSE vedligeholder også en Systems Engineering håndbog, baseret på ISO/IEC 15288 standarden. Denne håndbog er en operationel tilgang til Systems Engineering. Håndbogen kan enten købes gennem INCOSE eller downloades som medlem af INCOSE. INCOSE tilbyder også muligheden for at blive certificeret systemingeniør på flere niveauer efter denne stan-dard.

I slutningen af 2013 blev en dansk afdeling af INCOSE etableret , som ar-bejder for at udbrede kendskabet til Systems Engineering i Danmark. Dette gøres blandt andet gennem workshops og foredrag om emnet.

AGILE METODER

HTTP://DIGITALISER.DK/ RESOURCE/454065/ARTEFACT/ VEJLEDNING+OM+ AGIL+UDVIKLING.PDF

Agile metoder prioriterer (oversat fra agilemanifesto.org)

¤ Personer og interaktioner over processer og værktøjer

¤ Virkende produkter over fyldestgørende dokumentation

¤ Samarbejde med kunden over kontraktforhandling

¤ Reaktion på forandringer over at følge planen

60

ITOS

MODELLERDer er mange muligheder for at finde mere information om brugen af mo-deller i udviklings processer. Som det bliver understreget i afsnit 6.1 er der mange forskellige typer af modeller og det er vigtigt at starte med at finde den rigtige type af modeller at finde mere information om.

En god introduktion på dansk til basal modellering af systemer, med UML som udgangspunkt, kan fås i bogen ”Objekt orienteret analyse og design” (Mathiassen, 2001).

De inspirationskilder der blev foreslået i kapitel 6 om modeller er: ”Survey of Model-Based Systems Engineering (MBSE) Methodologies ” af Jeff A. Estefan eller ” Popular SysML Modeling Tools” af Tim Weilkiens.

REQUIREMENT ENGINEERINGEn organisations evne til at udvikle og vedligeholde produkter eller services er betinget af den professionalisme (modenhed) den har. Professionalis-men måles som modenhed med en såkaldt modenhedsmodel som f.eks CMMI® eller ISO/IEC 15504 (SPICE). Her analyseres graden af anvend-te processer, understøttet af metoder, værktøjer og udtrykte kompetencer, samt ledelsens fokus på udviklingsorganisationen. I disse modeller er krav-udvikling og kravstyring centrale i forhold til mange af de øvrige processer, der er en del af udviklingsprocessen.

ØVRIGEInnobooster er et program under Innovationsfonden, hvor små og store virksomheder kan søge tilskud til et samarbejde med universiteterne – se www.innovationsfonden.dk

FOTO: TERMA A/S

8

63

ITOS

88. ITOS CASES

INDUSTRICASESFÆLLES TRÆK TRODS STORE FORSKELLE ITOS’ resultater bygger på fire industricases, udover det brede virksom-hedssamarbejde. De fire cases er gennemført som forskningsprojekter i samarbejde med AU, AAU og DTU. Hver har de en historie om, hvordan de med embedded systemer tackler vidt forskellige udfordringer fra kunderne og teknologisk. Det er historier som på den ene side er meget teknisk beto-nede, og på den anden side handler om temaer, vi alle kender.

F.eks hvordan smartphonen kan bruges til at styre et høreapparats funk-tioner. At undgå nogen vi ikke bryder os om, trænger ind på havne og fly-vepladser. At vi selv har kontrollen og ikke de teknologier vi får ind i vores hjem. At store handelsskibe får mere rene og effektive dieselmotorer.

De tekniske overvejelser og aktiviteter fra de fire industricases er beskrevet udførligt i dette kapitel.

I alle fire cases sker der en sammensmeltning af hardware og software. De bruger modeller til at lette integrationen mellem delkomponenter og til at simulere og validere hele systemer. Modeller er med til at give; bedre aftest-ning, tidligere prototyper og mere robuste produkter.

Selv om de fysiske aspekter af de systemer, der bliver udviklet i de fire cases er meget forskellige og de også er meget forskellige i størrelse, er der store ligheder på de softwaremæssige sider af systemerne. Høreapparater og die-selmotorer til skibe er begge relativt lukkede systemer med få interfaces til omgivende systemer. Home automation og beskyttelsessystemer er mere åbne systemer der opererer i samarbejde med mange eksterne systemer.

Alle fire cases jagter færre fejl, hurtigere gennemløb, agilitet og hurtigere læring.

Selv om fagområderne er vidt forskellige i de fire industricases, er udfordrin-gerne og formålet de samme. Derfor er nogle af de værktøjer og tilgange man kan tage hul på nogle af de samme på tværs af de fire cases. Der er en tendens til at anvende mere formelle modeller for at opnå bedre processer og bedre produkter. Det er i høj grad simuleringsbehovet som er den faktor der driver udviklingen.

I forhold til model i Figur 4 befinder casevirksomhederne sig kompetence-mæssigt på niveau 3 på langt de fleste aspekter. Nogle arbejder nu på at nå niveau 4 for nogle delaspekter.

Alle fire cases mestrer monitorering og kontrol, og arbejder med optime-ringsaspekter.

Fire cases er gennemført som forsknings projekter i samarbejde med AU, AAU og DTU

Alle fire cases jagter færre fejl, hurtigere gennemløb, agilitet og hurtigere læring

De mestrer monitorering og kontrol og arbejder med optimering

S Y S T E M S E N G I N E E R I N G K O M P E T E N C E R F O R E M B E D D E D S Y S T E M E R

Krav til produktet Design Realisering Test & validering

M O D E L L E R I N G S K O M P E T E N C E R

Uspecificeret

Skriftlig formuleret

Kravhierarkier

Formelle specifikationer

Modeller af krav

Baseline

1

2

3

4

Enkeltløsnings-orienteret

Diagrammer af visse aspekter

Arkitektur beskrivelseog beskrivelse afhovedfunktioner

Simulering af deleaf designet

Model-drevet design

Udelukkende standardmoduler

Standard moduler + egne moduler

Håndkodet og manuel hardware realisering

Auto-generering af dele af systemet

Chip design & kode generering fra modeller

Ved levering

Løbende feedback

Funktionel test

Automatiseret test

Modelbaseret

64

ITOS

8.1 GN RESOUND – SMART PHONE STYRET HØREAPPARATSiden lanceringen af GN ReSound’s første høreapparat DANAVOX i 1947, har GN ReSound gentagne gange taget ny teknologi i brug for at optime-re deres kerneprodukt, høreapparatet; Digital lydprocessering i 1992, Soft-ware baseret lydprocessering i 1996, Surround Sound i 2009. Alle mar-kante teknologiskifte som optimerede funktionalitet og medførte bedre produkter for kunden.

I 2010 lancerede GN ReSound det første høreapparat med indbygget tråd-løs kommunikation, der gjorde brug af 2.4 GHz båndet, som vi alle kender fra WiFi til vores mobiltelefon, tablet og bærbare computer.

Det nye produkt markerer i GN ReSounds historie ikke kun et teknologiskif-te, men et paradigmeskifte. Hvor udviklingsafdelingens fokus før 2010 var optimering af produktet, er fokus nu i høj grad rettet ud af produktet. I 2012 kommunikerede højre øre med venstre øre baseret på 2.4 GHz teknologi og i 2014 markedsførte GN ReSound verdens første høreapparat der uden vi-dere streamer lyd trådløst fra en iPhone.

De høreapparater som for få år siden var stand-alone produkter, kommu-nikerer nu med hinanden og andre produkter. GN ReSound udvikler nu ud-over desktop applikationer til trådløs kalibrering af høreapparatet hos øre-lægen også Apps til iPhone, Android og Windows Phone så deres kunder kan konfigurere deres høreapparat. Det er kun et spørgsmål om tid før apps udviklet af 3. part ser dagens lys.

GN Resound – Smart Phones genopfandt trådløs overførsel af lyd og revolutionerede markedetTrådløs overførsel af lyd til høreapparater har eksiste-ret i mange år i form af såkaldte teleslynger, der fun-gerer vha. af elektromagnetisme. GN ReSound satsede benhårdt på at være først på markedet med WiFi direkte til apparatet. Det gav dem en markedsmæssig fordel, et væld af ny funktio-nalitet og en række nye udfordringer;

¤ Design af radio og audio-protokol til plads- og ressourcebegrænset miljø

¤ Godkendelse som medicoudstyr af WiFi-enabled apparat

¤ Kompatibilitet med 3. parts produkter og services

FIGUR 21

Forsker: Allan Munck,

erhvervs Phd. stip., DTU

65

ITOS

Skriv tests før der udvikles noget

Ikke alene mulighederne med ny teknologi er uendelige, nye udfordringer melder sig også på banen. Fra at udvikle produkter, der er uvidende om en verden udenfor deres indpakning, til at udvikle produkter som automa-tisk opdaterer firmware over Internettet, håndterer sameksistens af multi-ple apparater på samme netværk og desuden beror sig på 3. part software og apparater kræver et nyt tankesæt.

GN ReSound har derfor erkendt at den ellers succesfulde tilgang til Systems Engineering med stor sandsynlighed skal opdateres – det store spørgsmål er bare hvordan.

PROCES, PROCES OG TEST-DREVET MODELBASERET SYSTEMS ENGINEETestdrevet udvikling af software, såkaldt Test Driven Development (TDD) har hos GN ReSound, og mange andre virksomheder, betydet en markant forøgelse af produktivitet, færre fejl og generelt bedre kode. Det har fået GN ReSound til at udfordre hele organisationens interne processer.

Det overordnede ønske hos GN ReSound er at erstatte den traditionelle do-kumentdrevne process med en modelbaseret tilgang til Systems Enginee-ring. Forventningen om, at høreapparater i nær fremtid forventes at kun-ne mere og kommunikere med omkringliggende apparater og services, har fået GN ReSound til at afsøge om kombinationen af testdrevet modelbase-rede metoder generelt resulterer i kortere Time-To-Market og bedre slut-produkter.

Det udviklede koncept kaldes Test-Driven Models-Based System Engine-ering (TD-MBSE) og GN ReSounds fokus er således på samspillet mellem System Engineering, Modeller, Processer og slutprodukternes kvalitet.

Principielt ønskes en test-drevet tilgang til alle former for modellering, dvs. for modeller af systemernes interessenter, kontekst, brugere, omgivelser, systemfunktioner, arkitektur, mm.

Benyt tests kontinuerligt under hele udviklingsfor-løbet

FOTO

: GN

RESO

UN

D A

/S

66

ITOS

I casen har GN ReSound udviklet en me-tode til test-drevet udvikling af embedded systemer. Metoden er baseret på formel verifikation, så der er garanti for resul-taterne. I praksis har GN ReSound brugt værktøjet UPPAAL, da dette har en række unikke features, der letter arbejdet. Først indsamles kravene til systemet. Funktio-nelle krav modelleres som test cases ud-trykt som tilstandsmaskiner. Andre krav udtrykkes som invarianter og andre ”que-ries”, som UPPAAL bruger til den formelle analyse. Derefter køres den nye test case, hvilket gerne skulle resultere i en fejl. Her laver UPPAAL et trace, som benyttes til at ”finde fejlen” og indføre de modelele-menter i systemet, der skal til for at pas-sere testen. Dette gentages, indtil all tests passeres. Der afsluttes eventuelt med at rydde op i modellen, inden man går videre med næste krav.

Varianter laves ligeledes test-drevet ef-ter en metode, som GN ReSound kal-der Test-Driven Design Space Explorati-on (TD-DSE). Her lavet varianter ud fra en basismodel, der er lavet efter TD-MBSE metoden. For at identificeret rummet for de parametre, der ønskes varieret, benyt-tes såkaldt Property Estimation og Pro-perty Simulation. Når udfaldsrummet er identificeret vælges nogle værdier, hvor-efter løsningerne udsættes for formel og statistisk verifikation for vurdere effekten på funktionalitet og performance. Meto-den er illustreret i figur 22. I praksis er TD-MBSE og TD-DSE meto-derne blev brugt til at udvikle og analysere modeller et system, hvor tre subsystemer

konkurrerer om adgangen til at fælles data/control bus. Der blev udviklet to varianter, hvoraf denne ene gav den bedste udnyttelse af bussens kapaci-tet, mens den anden sikrede den hurtigste turn-around tid på et kritisk sce-narie. Begge løsninger levede op til kravene.

Den udviklede metode egner sig bedst til relativt små systemer, da det valg-te værktøj har nogle begrænsninger, som ikke umiddelbart kan omgås. Hos GN ReSound arbejdes der derfor på en metode til modellering af store sy-stemer, der er karakteriseret af bland andet omfattende og kompleks ud-veksling af information mellem mange subsystemer.

En anden væsentlig del af ITOS casen hos GN ReSound er at identificere forskellige niveauer af modellering. De identificerede modelleringsniveauer tjener dels formålet at kategorisere værktøjer og dels begrebsliggøre et nyt komplekst proces apparat hos GN ReSound. Metoden til at vælge de rigtige værktøjer er omtalt i afsnit 6.1.

Obtain andspecify

behavioral orarchitecturalrequirement

Refinerequirement

Model behavioral scenario or

architecturaltest case

Create ormodify system

behavior /system

architecture

Run allbehavioral &architectural

test cases

Clean upmodel

Run newtest case

Interactivesimlation

Executiontraces

Repeat

Alle tests pass

Tests fails

Some test(s) fails

Tests pass

TD-MBSE for modellering embedded systemer

FIGUR 22TD-MBSE for modellering embedded systemer

67

ITOS

8.2 SELUXIT – DET AUTONOME HUSKøber man 10 forskellige ‘smart home’ produkter lavet af forskellige produ-center, følger der med stor sandsynlighed 10 forskellige apps med. Det gør i sidste ende livet mere vanskeligt for forbrugeren end tilsigtet. Forbruge-ren ønsker et orkestreret system, hvor man ikke alene har en central bru-gergrænseflade, men hvor der også automatisk løses potentielle problemer hvis produkterne modarbejder hinanden, og hvor der desuden præsenteres nye muligheder, når forskellige systemer kan noget smart i samspil.

Seluxit, der bl.a. udvikler home automation løsninger på vegne af sine er-hvervskunder, er i høj grad optaget af præcis denne problemstilling og mu-lighed, og gør brug af sofistikerede modelleringsmetoder, for at sikre opbyg-ning af optimale autonome systemer. Udvikling af enhver home automation løsning er en opgave i systemintegration, hvis ikke systemet blot skal være en serie fragmenterede (og potentielt modsigende) kontrolsystemer, uden mulighed for overordnet optimering eller autonomi.

Seluxits industricase, drejer sig om hvordan Seluxit anvender modeller til udvikling af deres egen platform for IoT systemintegration. Produktet er et generaliseret framework system, der er i stand til at takle uforudsete pro-blemstillinger og muligheder til en række brugsscenarier.

INDBRUDSALARMEN OG KLIMASYSTEMETDet er rimeligt at forvente, at et alarmsystem har en funktion, hvor man kan angive om man er til stede eller ej, dvs. om indbrudsalarmen bør være tændt. I bedst fald, sker det automatisk og pålideligt via information ind-samlet fra sensorer i ejendommen. Der kan også forventes, at et alarmsy-stem vil kunne genkende indbrud baseret på en række parametre fra data indhentet fra en række sensorer, hvor i bedste fald husets kat fritages fra at være mistænkt som indbrudstyv. Det er også forventeligt, at åbning af døre og vinduer (dog ikke kattelemmen) vil kunne udløse alarm, hvis alarmsy-stemet er aktivt. Kort sagt kan det forventes, at alarmsystemet har en kva-litet og en konsistens som gør, at det kan beskrives som velfungerende.

TD-BMBSE

FunctionalityImpact

PerformanceImpact

TD-MBSE

AlternativeDesigns

OtainingEstimates

PropertyEstimations

PropertySimulations

Base Design

Formal Verfication

Test-drevet Design Space ExplorationFIGURE 23Test-drevet Design Space Exploration

Forsker: Thomas Pedersen, Phd. stip., AAU

Til 10 forskellige ‘smart home’ produkter, følger der med stor sandsynlighed 10 forskellige apps

68

ITOS

Men hvad sker der hvis man introducerer et klimasystem til det overordne-de home automation system, velfungerende for sin vis, der har automatisk åbning af vinduer som feature med det formål at regulere luftkvalitet? Alar-men udløses, hvis aktiv ved klimasystemets vinduesåbning, på trods af, at det er imod vores ønsker. Der skal altså en udvidelse af systemet til, for at løse problemet.

Det er et enkelt eksempel på en feature interaktion med et uventet resultat. Udviklerne af alarmsystemet har tænkt på katten, men ikke på klimasyste-met. Og det vil være urimeligt at forvente at udvikler af diverse systemer bør tage højde for alle scenarier. I stedet, bør vores overordnede system kun-ne identificere hvor der er en konflikt, og ideelt selv være i stand til at ska-be en løsning.

Det vil være upraktisk og omkostningsfuld at prøve sig frem under selve im-plementeringen/integrationen af systemer, især i takt med at antallet og kompleksitet af feature interaktioner øges. I stedet, er det ønskeligt at mo-dellere det overordnede home automation system for at identificere kon-fliktområder såvel som muligheder for gavnlige interaktioner, inden der in-tegreres.

For at kunne identificere og gøre muligt at håndtere disse konflikter og mu-lighederne for gavnligt forøgelse af systemet, kræves der to ting: model-lering og tilhørende verificeringsanalyse, som vil beskrive den forventede optræden af systemet, og at rammesystemet er i stand til at tilpasse sig ba-seret på disse modeller. Seluxit har sidstnævnte: en abstraktion i deres IoT platforms arkitektur, som gør systemet ikke alene er i stand til at håndtere mange forskellige brugsscenarier, men som desuden også gør det lettere at anvende modelverificering. Men Seluxit har brug for en samarbejde for at kunne modellere systemadfærd, inden der implementeres en løsning.

TIMED AUTOMATA OG UPPAAL MODELVERIFICERINGDer er mange mulige måder, hvorpå man kan modellere og verificere den forventede virkning af et home automation system. Det indledende model-leringsarbejde indebærer at man systematisk noterer enheder i systemet, deres funktioner og mulige tilstande (både ønsket og sekundært), hvilke variabler der påvirker enhedernes funktion, og hvordan miljøet er med til at påvirke disse variable. Der er en sammenhæng mellem alle disse aspekter i en ejendom, og en for-analyse har som formål at lave en udførlig liste af dis-se aspekter for hver enhed og miljømæssig påvirkning.

F.eks. kan et køleskab, med primær funktion at holde mad kølig, være tændt, slukket og samtidig i én af adskillige funktionsprogrammer. Køle-skabet har som sekundær effekt, at øge varmen i lokalet, hvor det står. Kø-leskabets funktion, og dermed energi forbrug, er påvirket af temperaturind-stillingsværdi, valgt program, temperaturen i lokalet samt, hvor tit døren bliver åbnet, og hvor lang tid døren står åben hver gang.

I visse tilfælde, kan en sådan forhåndsanalyse afsløre potentielle problem-områder og synergieffekter, og dermed være tilstrækkeligt for mindre kræ-vende opgaver. Med en formel matematisk modelverificering herfra vil sik-re, at der er styr på sagerne, inden man går videre.

Med en systematisk analyse af elementer, der er på spil i en ejendom, er der adskillige valgmuligheder for formel opbygning og verificering af model-

Der er mange mulige måder, at modellere og

verificere den forventede virkning af et home automation system

69

ITOS

ler. For Seluxit, sker identificering af potentielle problemområder i systemin-tegration igennem et tæt samarbejde med Aalborg Universitet og brug af metoder og værktøjer delvist udviklet af Aalborg Universitet. Aalborg Uni-versitet har i samarbejde med Uppsala Universitet udviklet et redskab, der hedder UPPAAL, som bruges til at verificere modeller. De formelle model-ler, der bruges for at beskrive bl.a. home automation er såkaldte timed auto-mata.

Timed automata er en formel fremstilling i familien af såkaldte finite state machines eller tilstandsmaskiner. De var konceptualiseret igennem automa-ta teori, udviklet i det 20. århundred som en væsentligt grundlæggende del af dataologi. Igennem modellering af automata, kunne dataloger klarlægge hvad der kunne beregnes af en computer. Automata teori og relaterede stu-dier har altså haft enorm teoretisk vigtighed og praktisk applikation igennem overordnet udvikling af computer hardware og software.

Et home automation system kan modelleres ved reduktion til en række ti-med automata, som beskriver de mulige tilstande af et systemelement, og betingelser for at ændre tilstand. Idet vi har med et real-time system at gøre, inkluderes tid som element i de anvendte automata modeller. Derved kan vi resonere omkring realtidsaspektet.

For at forstå konceptet bag denne type modeller, kan man betragte en re-lativ simpel lampe med tre tilstande for lysintensiteten: slukket, lav og høj. For at opnå høj lysintensitet, skal man trykke på knappen to gange hurtigt, ellers slukker man lyset. I første omgang, er lampen slukket, indikeret med en dobbeltcirkel. En ‘press’ handling påkalder en transition, som tager os fra ‘off’ til ‘low’. I den transition, bliver timeren ‘t’ også nulstillet. Denne timer er brugt for at måle tiden siden transitionen fra ‘off’ til ‘low’. Når endnu en ‘press’ handling er påkaldt, én af to mulige transitioner sker. Hvis timeren ‘t’ er mindre end eller lige med to enheder af tid (i modellen angivet som 2000 millisekunder), er transition til ‘high’ valgt. Ellers kommer man tilbage til til-standen ‘off’.

Timed automata som illustreret i dette enkle eksempel kan også anvendes til at beskrive vores aktuelle scenarie med alarmsystem og klimasystem. Op-lysningerne fra forhåndsanalyse er struktureret i en række timed automata med en udførlig matematisk notation, som vi ikke vil beskrive nærmere her. De formelle modeller er derfra brugt som input til UPPAAL, som indikerer konflikten i dets output som et falsk resultat, i vores tilfælde hvor alarmen er udløst selvom der ikke er indbrud.

FIGUR 24

Lamp Controller

Kilde: Thomas Pedersen et al

70

ITOS

FRA ABSTRAKTION TIL HANDLINGSeluxit har en platform som kan iværksætte handlinger baseret på indstil-linger af enheder samt miljømæssige vilkår såsom værdier, regler, timere, beregninger og tilstandsmaskiner, og dermed realisere komplekse feature interaktioner. Dette kan forgå via en gateway enhed, som fungerer som sy-stemets hjerne og fortolker, hvis der er tale om forskellige leverandører med hver deres applikation og evt. kommunikation protokol. I bedste fald vil en-heder kunne snakke direkte sammen, såfremt enhederne udvikles i samspil med Seluxit for at tage fuld udnytte platformens funktionalitet. Seluxit ar-bejder aktivt som nøglespiller med at drive nye standarder som understøt-ter deres vision af dynamisk konfigurerbare enheder som kan interageres på meningsfuld vis.

Seluxits teknologi er speciel fordi det tilvejebringer et abstraktionslag hvor-med eksekverbare tilstandsmaskiner og timers i et Seluxit home auto-mation system bekvemt kan være oversat fra de formelle UPPAAL timed automata modeller. Ud over modelverificering, åbner det også op for mu-ligheden at implementere intelligente applikationer hvor der kan være tale om distribueret intelligens, hvor ejendommens forskellige interaktioner eksponeres for de enkelte delsystemer, præcis som synapse i en hjerne sør-ger for kontaktfladen mellem nerveceller.

Tilbage til vores eksempel med klimasystemets automatiske vinduesåb-ning, der udløser alarmen, har vi set, at brug af modeller kan forudse po-tentielle problemer som en systemudvikler kan agere på, gjort muligt igen-nem Seluxits IoT platform. Seluxit’s samarbejde med Aalborg Universitet tilstræber de løsninger, hvor systemet selv er i stand til at finde og løse pro-blemer automatisk, og med en passende brugerinteraktion. Derudover er det ønskeligt, at systemet selv kan identificere situationer, hvor operatio-ner kan optimeres og egentlige valg træffes, såsom områder hvor anven-delse af dublerede af funktioner optimeres (f.eks at vælge mellem flere en-heder med afkølingsfunktion med variable energiomkostninger afhængig af situationen).

Idéen er egentlig at man som bruger sætter reglerne og krav, og at syste-met syntetiserer koden, som gør det til virkelighed. Med Seluxits IoT plat-form sammen med verificering fra UPPAAL er mekanismer på plads. Men det er stadigt et åbent spørgsmål, om der kan adopteres en standard in-denfor home automation og generelt indenfor IoT, som vil kunne gøre ba-nen klar for denne slags effektivisering og orkestrering i systemopbyggelse, i overensstemmelse med brugerens ønsker og krav, som velbyggede auto-nome systemer vil medføre.

Når man tænker på home automation som en del af den bredere kontekst af the Internet of Things, står det klart, at potentialet af dette nye felt først for alvor realiseres, når vi er i stand til at skabe intelligente autonome sy-stemer.

” Filmindustriens historie vrimler med billeder af fremtidens fuldautomatiserede hus, hvor husejerens vilje er nærmest telepatisk. Andre gange ganske komisk trumfer husets uvilje husejeren.

Brian Boyles, Seluxit

71

ITOS

8.3 TERMA – BESKYTTELSE AF KRITISK INFRASTRUKTURAngrebene på World Trade Center og Pentagon i 2001 og efterfølgende ter-rorhandlinger, har øget fokus på beskyttelsen af den kritiske infrastruktur, som er en af hjørnestenene i et moderne vestligt samfund. Lufthavne, bro-er, kraftværker og kommunikationskanaler spiller en utrolig vigtig rolle – skulle bare én af disse blive sat ud af drift, vil det have alvorlige konsekven-ser på tværs af andre sektorer og påvirke byer, landsdele eller hele lande.

Terma så muligheden for at anvende sine eksisterende produkter på et nyt marked for overvågning af kritisk infrastruktur. Eksisterende overvågnings-systemer bliver typisk opereret manuelt og har fokus på at overvåge peri-meteren af et givent område. Terma har udviklet et system – T.react CIP – der ved hjælp af radarer muliggør overvågning af hele områder, og auto-matisk kamera kontrol, der mindsker behovet for manuel styring, og sæn-ker derved risikoen for fejl.

T.REACT CIP

Med T.react CIP fokuserer Terma på at erstatte manuel overvågning med et automatiseret system der benytter radar tracking teknologi til at identifice-re personers færden over tid.

I software systemet definerer kontrolløren geografiske zoner og opsætter regler for disse zoner. Et eksempel på en sådan regel kunne være at der skal gives alarm hver gang en person bevæger sig ind i zonen. Et andet ek-sempel kunne være at give alarm hvis en person eller et køretøj overstiger en given hastighed inde i zonen. Ved hjælp af en robust regel-motor er det muligt at opstille komplekse regler, og derved styre hvornår systemet ud-steder alarmer.

Når en alarm bliver udstedt, notificeres kontrolløren og mindst ét kamera bliver automatisk rettet mod personen, og følger denne baseret på input fra radaren. For at sikre at kontrolløren kan identificere hvilken person der har brudt reglen og se hvad denne foretager sig, er det vigtigt at kameraet kan zoome tilstrækkeligt ind på personen – målet er at systemet kan følge en person rundt på hele området med tilstrækkeligt zoom til at personen fyl-der 50% af skærmhøjden.

UDFORDRINGEN

Når software udvikles til at automatisere menneskelige handlinger, er det vigtigt ikke blot af have fokus på handlingerne, men også den bagvedlig-gende menneskelige beslutningsprocess og den tankevirksomhed, der lig-ger til grund for de udførte handlinger, da det oftest er den, det er sværest at efterligne. Ved manuelt styrede overvågningssystemer, anvender operatø-ren sine sanser (øjne) og intuition til at estimere hvor et objekt af interesse befinder sig, hvorefter kameraet manuelt justeres mod objektet.

Det er ikke muligt for en radar at give en eksakt position af personer, der bevæget sig rundt – den vil altid kun kunne give et estimat. Afhængigt af radarantennes dimensioner, samt radarens frekvensområde og processor-kraft vil estimatet være mere eller mindre eksakt. En radar vil for hvert track levere en position der er dens bedste estimat hvor personen er, samt en Gausisk fordelt sandsynligheds-tætheds-funktion, der for nemheds skyld

Angrebene på World Trade Center og Pentagon i 2001 og efterfølgende terror handlinger, har øget fokus på beskyttelsen af den kritiske infra-struktur

Forsker: Sune Wolff erhvervs-post doc., AU

72

ITOS

bliver visualiseret som en ellipse i det følgende. Samlet set fortæller rada-ren dens bedste estimat af hvor personen er, samt et område (ellipsen) in-denfor hvilken den er 99% sikker på at personen befinder sig.

Den radar der benyttes i T.react CIP er en lille og forholdsvis billig landba-seret 2D radar – hvilket gør at der er en betydelig usikkerhed i estimatet af personens position. For at sikre at et kamera rent faktisk har indsigt på per-sonen der har brudt en regel, må det aldrig zoome længere ind end at det har hele radarens elliptiske usikkerhed indenfor kameraet synsfelt. Dette er vist i figur 25 – radaren giver sit bedste estimat af hvor personen befinder sig (den blå prik) samt en usikkerhed indenfor hvilken den er 99% sikker på at personen befinder sig (den delvist transparente ellipse). Det er i figur 25 tydeligt, at kameraet ikke kan zoome særlig langt ind, hvis det skal bibehol-de hele usikkerhedsellipsen inden for dens synsfelt.

Som det ses i figur 25 er radaren langt mere usikker omkring personens po-sition i vinkeludbredelse end den er i afstand – det ses på den meget lang-strakte ellipse. Årsagen er, at den lille antenne, der benyttes i radaren, gør at strålebredden bliver ret bred – der er altså tale om en afstands-afhængig usikkerhed. Den bølgelængde, der benyttes i radaren gør usikkerheden om personens afstand til radaren konstant uanset afstand til personen – altså en afstands-uafhængig usikkerhed.

EFTERLIGNINGEN AF DEN MENNESKELIGE INTUITIONFor at opnå en højere præcision i systemets estimat af personers position kombineres estimaterne fra individuelle radarer – en såkaldt sensor-fusi-on. Denne teknik sikrer at usikkerheder fra individuelle sensorer reduceres samlet set – dette er vist i figur 26.

KAMERARADAR

PERSON

Maximalt zoom kameraet kan foretage hvis hele radarens usikkerhed skal være indenfor kameraets synsfelt.

FIGUR 25

73

ITOS

Hver af radarerne i figur 26 har en større usikkerhed i vinkeludbredelse end afstand hvilket kan ses i den elliptiske repræsentation af deres estimater. Ved at kombinere estimaterne fra radarerne kan man udnytte den store for-skel i usikkerhed i vinkeludbredelse og afstand fra de to radarer. Resulta-tet af denne sensor-fusion kan ses som den lille sorte ellipse i figur 26. Det mere præcise estimat af personens position gør det muligt for kameraet at zoome væsentligt længere ind og sikre nemmere identifikation af personen.

Teorien bag den anvendte sensor-fusion er baseret på matematiske model-ler af systemets opførsel og usikkerheder. I dette tilfælde er der tale om fu-sion af radareres egne usikkerheder ved hjælp af overskuelige trigonometri-ske betragtninger.

SIMULERING AF DEN NYE TEKNOLOGIFor Terma var sensor-fusion teknologien et uprøvet kapitel i et overvåg-ningssystem, og udviklerne på dette projekt havde kun begrænset erfaring med sensor-fusion baseret på kombinationen af Gausiske multivariate el-ler Kalman Filtre1. Terma lavede derfor en model af systemet for at afprøve sensor-fusion inden det blev endelig implementeret i T.react CIP.

Én af de vigtigste grunde til at lave en model er, at man kan tillade sig at ab-strahere væk fra detaljer, der ikke er vigtige for den analyse, man gerne vil foretage. I den udviklede model blev der abstraheret væk fra geografiske zo-ner, regler og en masse andre af de ting, der gør T.react CIP til et smart pro-dukt. På den måde fokuserer modellen på de dele af systemet, der er væ-sentlige for at vurdere værdien og kompleksiteten af sensor-fusion.

Modellen kan ændre, hvor hurtigt de individuelle radarer roterer, for at si-mulere asynkront indkomne radar tracks. Derudover indeholder modellen en lang række justerbare parametre for at muliggøre analyse af, hvordan disse påvirker det fusionerede track. Endeligt har Terma sørget for at gøre

KAMERARADAR 1

PERSON

RADAR 2

Ved at kombinere estimaterne fra to radarer kan man opnå et me-get mere præcist estimat af hvor en person er – og derved kunne zoome længere ind på personen.

FIGUR 26

Teorien bag den anvendte sensor-fusion er baseret på matematiske modeller af systemets opførsel og usikkerheder

74

ITOS

det muligt at anvende rigtig data optaget fra radarerne i modellen, for der-ved at kunne genskabe situationer set i virkeligheden.

Der er altså brugt megen tid på at beslutte, hvilke dele af systemet man kunne abstrahere helt væk fra (f.eks zoner og regler), hvilke dele man kun-ne nøjes med en abstrakt repræsentation af (f.eks radaren), og hvilke dele der skulle modelleres meget præcist (f.eks selve sensor-fusion funktionali-teten samt interfacet til radarerne).

8.4 MAN DIESEL & TURBO – MERE RENE OG EFFEKTIVE DIESELMOTORERMAN Diesel & Turbo står overfor tekniske udfordringer med nye krav fra kunder og lovgivning om øget effektivitet, mindre forurening og understøt-telse af alternative brændstoffer. Løsningen medfører et stigende antallet distribuerede kontrol enheder og supplerende systemer. Udviklingen af dis-se nye systemer kræver omfattende viden og indsigt i sammen spillet mel-lem hver af de distribuerede enheder og det fysiske system, en to takts die-sel motor.

Modellering og simulering er afgørende værktøjer for at kunne udvikle op-timalt stabile og pålidelige kontrol systemer, samt at estimere performan-ce og udvælge en korrekt udlægning af motoren. Tidligere har simplificeret modeller af kontrol systemets påvirkning på motor dynamikken været til-strækkelige, under performance simuleringer, og forenklede termodynami-ske modeller af motoren blevet brugt til udvikling af kontrol algoritmer. Med nye systemer som EGR (Exhaust Gas Recirculation), SCR (Selective cataly-tic reduction) og Tacho over ethernet, er kravene til kontrol softwaren og ud-lægningen af fysiske komponenter mere kompliceret, og gabet mellem kon-trol modellering og de fysiske modeller blevet mindre. Der er derfor brug for bedre simulerings miljøer, der kan forbinde kontrol softwaren med termo-dynamikken samt netværket der forbinder enheder.

Især for de tids kritiske dele af motor reguleringen (f.eks Indsprøjtnings ti-ming) er netværket vigtigt. Enhver dynamisk forstyrrelse fra undersystemer kan divergere og påvirke andre enheder. Det er derfor vigtigt at kunne esti-mere, ikke blot opførelsen af de enkelte undersystemer, men hele systems som én enhed.

Komplekse komponenter kræver dedikeret værktøjer for at blive modelleret optimalt, hvilket medfører et markant antal forskellige værktøjer, der varie-re i både sprog, solvere og tids opfattelser. Det er derfor ikke trivielt at kom-binere disse modeller i et enkelt udviklings miljø. Det har ikke været muligt at finde et enkelt værktøj som kan håndtere alle de ønsker man har til et si-mulering miljø, og man ønsker derfor et standardiseret framework for simu-lering, der kan kombinere solvere , koordinere tids eksekveringer og mo-dellere forskellig netværks opførsel, en såkaldt co-simulering med netværk.

Functional Mock-up Interface (FMI) er blevet valgt som co-simulerings standard og SystemC Network Simulation Library (SCNSL) som netværks simulator.

CYBER-PHYSICAL SYSTEM

En standard MAN Diesel & Turbo motor, med sit tilhørende kontrol system og HMI, er illustreret i figur 27. Kontrol systemet består af et antal indlej-rede kontrollere, bestående af et strøm modul, I/O kabinet DC/DC konver-ter og en FPGA. Alle kontrollere er identiske, men softwaren der bliver lagt

Modellering og simulering er afgørende værktøjer for at

kunne udvikle optimalt stabile og pålidelige kontrol systemer

Modellering og simulering er afgørende værktøjer for at

kunne udvikle optimalt stabile og pålidelige kontrol systemer

Forsker: Nicolai Pedersen

Phd. stip., DTU

75

ITOS

på FPGA’en definere kontrol formålet. At have identisk hardware har man-ge fordele, så som variationen og mængden af reserve kontrollere der er nødvendige at have med på skibet, men medføre også en strenget struktur i softwaren som besværliggøre simuler.

Motoren kombineret med kontrol systemet klassificeres som et Cyber-Phy-sical System, og er på figur 27 opdelt i tre dele. Den fysiske del af systemet består af alle de mekaniske dele, med sensorer of aktuatorer som interface til resten af systemet. Top laget er hvor udviklings og test senarier bliver de-fineret og derved påvirker systemet. FMI er illustreret som det grå områ-

FIGUR 27

TEST & DEVELOPMENT

SCNSL

CYBER CYBER

Cylinder Model Crankshaft Model

Different abstraction

levels and Modeling

environments

Simulation Scenario:

Algorithm verificationFault injection

Temporal verificationDesign space exploration

Cylinder Control

Unit

Switch Model Protecols PriorityBandwith Delay

Engine Control

Unit

Tacho Interface

Unit

XXX Control/ Interface

Units

ThermodynamicModelse

PHYSICAL

76

ITOS

de, der forbinder det fysiske lag med cyber laget. Med FMI er det mulig at samle fysiske modeller med kontrol software, i en complet co-simulering. Koblingen mellem indgange og udgange er gjort overskuelig ved hjælp af et XML skema, der beskriver de variable hver del komponent stiller til rådig-hed for omverden. Når alle ind- og udgange er forbundet er det muligt at foretage deterministiske simuleringer. En deterministisk simulering er me-get anvendelig til at verificere modeller, og fortage regressions test af påli-delige dele af systemet.

For Cyber-Physical systemer, især realtids kontrol systemer har kommuni-kationen stor indflydelse. Netværks kommunikation er ofte LAN eller WAN baseret, hvor determinisme ikke er garanteret. Det kan medføre uhensigts-mæssige påvirkninger på systemet grundet assertion og tids forsinkelser på tids kritiske signaler. Disse udfordringer, kan som oftest overkommes ved at sikre sig en markant overhead på processor belastningen, og korrekt sy-stemopførsel verificeret gennem omfattende test på rigtige hardware. Selv-om denne tilgang umiddelbart er tilstrækkeligt, er det ikke en særlig effek-tiv tilgang, og overhead alene sikrer ikke korrekt eksekvering.

Samtidig bliver kun få fejl fanget under hardware test. Der ønskes en mere pålidelig metode til at undersøge og verificere netværket. Derfor er en net-værksmodel introduceret, der tidligt i udviklingen, gør det muligt at simule-re netværket, med ventetid, forsinkelse og alternative protokoller. Det igen muliggør, at man tidligere kan vælge den rigtige netværks opsætning og op-timale overhead på udregning enheder. SCNSL er blevet brugt til at lave net-værks modellen, der forbinder kontrollerne. Med SCNSL er det nemt at im-plementere og erstatte protokoller, samtidig kan forbindelserne mellem enheder konfigureres ved sende hastighed, forsinkelse og prioritet. Ved brug a SCNSLs simulering kernel er det nemt for testere og udviklere at opsætte simuleringsforløb med fejl og forstyrrelser, som kan teste systemets grænser.

Kombinationen af SCNSL med FMI gør det muligt at simulere kontrol soft-waren med enhver abstraktion af motor model og det dertilhørende netværk.

FUNCTIONAL MOCK-UP INTERFACEFMI er et standardiseret interface til at simulere dynamisk koblede pro-blem stilling, bestående af et antal distribuerede delsystemer, uafhængigt af simulering værktøjer. Interfacet kan opsættes enten ved at have en lokal solver, som løser delsystemernes individuelle modeller (Model Exchange), eller distribuerede solvere, som løser modellerne lokalt i delsystemet (Co-Simulation), se figur 28.

Co-Simulation

FMU

FMIProcess

Executable

Model Exchange

MASTERSLAVE

Model Solver

FMU

FMIProcess

Executable

MASTER SLAVE

ModelSolver

FIGUR 28

77

ITOS

FIGUR 29Engine Control Room

Engine Room

MOP(Main Operation Panal)

SCNSL Node:Switch protocol design

SCNSL Node:Input/Output Controller

Netword interupt:Packet recived(b_transport)

Amount of CCU units corresponds to the amount ofCylinders (4-12)

CCU1(Cylinder Control Unit) CCU2 CCU(n)

ACU(Auxillary Control

Unit)

ECU(Engine Control

Unit)

TIU(Tacho Interface

Unit)

SCU(Scavenge AirControl Unit)

EICU(Engine Interface

Control Unit))

EthernetCables

SCNSL Channel:adjustable bitrateand transmission

delay

Switch:

IEEE 802.3, store-and-forward-

switching

IEEE 802.1 D/Ppriority

SCNSLCommunicator:priority protecol

EthernetSwitch 2

EthernetSwitch 1

78

ITOS

I dette projekt er vi kun interesseret i Co-simulerings versionen af FMI. FMI blev udviklet under MODELISAR, som var del af det Europæiske projekt ITEA2 indledt af Daimler AG. Målet var at optimere mulighederne for at ud-veksle simulerings modeller mellem underleverandører og internt i udvik-lingen. FMI består i sin enkelthed blot af et XML-skema og tre c-header fi-ler, som definerer applikationsinterfacet med typer og metoder, som skal implementeres for at få en uniform måde at simulere på.

Et delsystem under FMI kaldes en Functional Mockup Unit (FMU). Det er et arkiv, der minimum består af XML-skemaet og applikationen pakket som et dynamisk loadet bibliotek (Win=DLL,Unix=SO).

NETVÆRKS MODEL

SystemC Network Simulation Library (SCNSL) er en udvidelse af SystemC, som gør det muligt at simulere Hardware sammen med Software og Net-værk i en enkelt simulering. Netværket på en MAN Diesel & Turbo motor er vist i figur 29:

¤ Kernel: Ansvarlig for at eksekvere events i korrekt tidsorden. SCNSL benytter SystemC scheduleren ved at mappe netværk events som standard SystemC events.

¤ Node: Er det aktive element i netværket som producere og anvender overført data. En node er afkoblet fra resten af systemet og kan derfor manipuleres af designere til et specifikt test scenarie.

¤ Packet: En pakke på netværket som udveksles mellem noder. I SCNSL er pakken internt og det er optil designeren af definere formatet og protokollen.

¤ Channel: En kanal er det fysiske medium der forbinder to noder, enten point-to-point eller shared-medium. Understøttede formater er Unidirectional, Half/Full-Duplex and shared.

¤ Port: Hver node anvender port til at sende og modtage pakker.

FOTO: SELUXIT APS

79

ITOS

ECS SWShared Library

ECS SWShared Library

ThermodynamicModel

Shared LibraryC++/DSE/MATLAB...

ZIP

XMLParser

Zip/Load

Thread

Thread

Thread

Channel:Bitrate/Delay

Channel:Bitrate/Delay

Channel:Bitrate/Delay

DLLloader

FMI Appwrapper

FMI Lib

FMU WrapperFMI application

functionsXML Schema

FMU WrapperFMI application

functionsXML Schema

FMU WrapperFMI application

functionsXML Schema

SCNSL: ECS Node

Inpul/Output Controller

Network interrupt

SimulationManager

FMI/SCNSL

SCNSL: ECS Node

Inpul/Output Controller

Network interrupt

Zip/Load

Zip/Load

SCNSL: Switch Node

Protocol/packagedesign

Channel:Bitrate/Delay

Channel:Bitrate/Delay

FIGUR 30

SIMULERING MASTERDen samlede løsning med FMI og SCNSL kan ses på figur 30. Yderst til ven-stre er de modeller og software der skal simuleres. ECS software er pakket som et shared library og wrappet i en FMU. Termodynamiske modeller er ligeledes wrappet i en FMU og pakket som et shared library udviklet i f.eks MATLAB, DSE (MANs interne tool) eller ren C++. Hver FMU får en dedike-ret tråd og håndteres gennem et FMI-lib leveret af MODELON. FMI-lib har nogle basale funktioner til at arkivere, læse XML, loade DLL’er og kalde FMI applikations metoder.

Simulerings manageren står for tidslig eksekvering af hver FMU og håndte-ring af netværks modellen. Når en netværks Proxy er blevet opdateret arki-veres output kontrollen på SCNSL noden og sende gennem switch model-len til den relevante nodes input kontroller. Med denne opsætning er det mulig at simulere kontrol software sammen med enhver form for termody-namisk model og samtidig udforske netværkets indflydelse på eksekverin-gen.

80

ITOS

REFERENCERModel-Driven Software Engineering in Practice, 2012 Marco Brambilla, Jordi Cabot & Manuel Wimmer ISBN: 978-1608458820

Objekt orienteret analyse og design, 2001Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen & Jan Stage ISBN: 978-8777511530

T-plan: The Fast Start to Technology Roadmapping. Planning Your Route to Success, 2001 University of CambridgeISBN: 9781902546094

From Business Strategy to Information Technology Roadmap: A Practical Guide for Executives and Board Members, 2013 Tiffany Pham, David K. Pham & Andrew Pham ISBN: 978-1466585027

How smart Connected Products are transforming comptitiveness, Harvard Business Review, nov. 2014. Michael E. Porter and James E. Heppelmann. Danfoss Power Electronics vej fra spæde teknologier til eksekvering i praksis, ITOS nr. 2, 2013, Trends og Visioner, Jesper Søbygaard Nielsen, Danfoss

Technology readiness levels (TRL), 2014, HORIZON 2020 – WORK PROGRAMME 2014-2015, EU Kommissionen

Technology Roadmapping: Linking technology resources to business objectivesRobert Phaal, Clare Farrukh and David ProbertCentre for Technology Management, University of Cambridge, 2001

TERMA A/S ud fra The Guide to Lean Enablers for Managing Engineering Programs, Joint PMI-INCOSE Community of Practice on Lean in Program Management, May 2012

Work in Progress: Allan Munck og Jan Madsen: ”Identification and implementation of feasible modeling setups”, 2015.

Kravsspecifikationer, IBC EUROFORUM, 2004, Otto Vinter, Delta

”Model-Based Controllers for Home Automation”, Thomas Pedersen et. al

Udgivet af DI ITEK

H.C. Andersens Boulevard 18

1787 København V.

Telefon 3377 3377

itek.di.dk

itek@di.dk

Redaktion slut 10.10.2015

Layout: fru nielsens tegnestue

Tryk: Dystan & Rosenberg

ISBN: 978-87-7144-065-2

500.10.15

ITOS FIELDBOOK

Dine fremtidige kunder kræver mere af dig end i dag. De forventer smarte produkter. Kan du levere?

Denne tekst henvender sig til dig, der er i en virksomhed, som står på tærsklen til eller allerede er i gang med at udvikle smarte produkter.

Hvis din virksomhed ikke er den første til at levere et smart produkt kan nogle andre tage hele markedet ved at være dem, der kommer først.

Smarte produkter spænder lige fra at tilføje den simpleste sensor til jeres nuværende produkt, til de mest komplekse løsninger. En enkelt sensor kan tilføje masser af værdi til et klassisk produkt.

Her fi nder du løsninger, konkrete råd og vejleding. Du bliver guidet gennem de første trin og får anvisninger til, hvor du kan fi nde mere information og vejledning.

Du får inspiration om følgende:

– Technology roadmaps, Systems Engineering, modellering

– Konkrete cases fra danske virksomheder

Med andre ord: Forståelse for udvikling af embedded systemer og smarte produkter i praksis.

F I E L D B O O K

&UDVIKLING AF

EMBEDDEDSYSTEMER

SMARTE PRODUKTER I PRAKSIS

Lav din virksomheds eget roadmap

IT S IT S

FIE

LDB

OO

K - U

DV

IKLIN

G A

F E

MB

ED

DE

D S

YS

TE

ME

R &

SM

AR

TE

PR

OD

UK

TE

R I P

RA

KS

IS