embedded systemer smarte produkter - DI Digital
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 finder du løsninger, konkrete råd og vejleding. Du bliver guidet gennem de første trin og får anvisninger til, hvor du kan finde 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. FIE LD BOOK - UDV IK LING A F E MBEDDED SYSTEMER & SMARTE PRODUKTER I PR AKSIS ITOS FIELDBOOK UDVIKLING AF & EMBEDDED SYSTEMER SMARTE PRODUKTER I PRAKSIS Lav din virksomheds eget roadmap IT S IT S Udgivet af DI ITEK H.C. Andersens Boulevard 18 1787 København V. Telefon 3377 3377 itek.di.dk [email protected] 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 produkter er online, kommunikerer, bliver selvstyrende, selvlærende og forudseende. En fremtid, der ligger lige rundt om hjørnet – og i nogle tilfælde allerede 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 produktionens univers – og at man er i stand til at få universerne til at smelte sammen. Nærværende fieldbook udspringer af projektet Industrielle Teknologier og Software (ITOS). Bogen præsenterer en samlet ramme af metoder, processer og teknikker til, hvordan virksomheder i praksis bevæger sig fra industrielle 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 Industriens Fond. Projektet har kørt i fire år og formålet har været, at danske virksomheder 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, uddannelsesinstitutioner 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 INDHOLD ITOS 4 EXECUTIVE SUMMARY 5 INTRODUKTION TIL FIELDBOOKEN 7 TAG UDFORDRINGEN MED SMARTE PRODUKTER OP 1. 7 1.1 FRA INDUSTRIELT TIL SMART PRODUKT 8 1.2 FRA TANKE TIL HANDLING – DET KAN DU BRUGE FIELDBOOKEN TIL 15 GØR DIN VIRKSOMHED KLAR TIL SMARTE PRODUKTER 2. 152.1 HVOR MEGET UDVIKLER SKAL VIRKSOMHEDEN VÆRE 182.2 SMART, SMARTERE, AUTONOM 23 LÆG TEKNOLOGISTRATEGIEN FOR DINE SMARTE PRODUKTER 3. 233.1 FÅ GREB OM TEKNOLOGI-GAP’ET 243.2 TEKNOLOGIOVERVÅGNING 253.3 TEKNOLOGIROADMAPPING 263.4 TEKNOLOGIMODNING 283.5 DET KORTE AF DET LANGE 31 BRUG DE RETTE METODER 4. 314.1 MÅL OG OPGAVER 324.2 ROLLER OG ANSVAR 334.3 SYSTEMS ENGINEERING I TERMA A/S 344.4 SYSTEM ENGINEERING PROCES 364.5 SYSTEMS ENGINEERING VÆRKTØJER 374.6 KORT OG GODT 39 VÆLG DEN RETTE PROCES 5. 395.1 ITERATIVE OG AGILE PROCESSER 43 BRUG DE RETTE TEKNIKKER 6. 436.1 MODELLER – LIDT AD GANGEN 486.2 REQUIREMENT ENGINEERING ELLER KRAVSTYRING 516.3 SIKKERHED FOR SMARTE PRODUKTER 53 OPSUMMERING KAPITEL 4-6 53 VIRKSOMHEDENS KOMPETENCEROADMAP 57 GÅ I GANG MED SMARTE PRODUKTER 7. 577.1 HOVEDPOINTER FOR AT KOMME FRA INDUSTRIELT TIL SMART PRODUKT 587.2 HER FINDER DU MERE INFORMATION 63 ITOS CASES 8. 648.1 GN RESOUND – SMART PHONE STYRET HØREAPPARAT 678.2 SELUXIT – DET AUTONOME HUS 718.3 TERMA – BESKYTTELSE AF KRITISK INFRASTRUKTUR 748.4 MAN DIESEL & TURBO – MERE RENE OG EFFEKTIVE DIESELMOTORER 80 REFERENCER ITOS EXECUTIVE SUMMARY DEN HELT KORTE VERSION I 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 ramme for at fastlægge, hvad din virksomhed skal beherske for at få succes med at udvikle smarte produkter – og hvordan du løfter din organisation til opgaven. Fieldbooken baserer sig på en stor gruppe danske virksomheder og universiteters fælles arbejde og deres anbefalinger om, hvad der skal til for at udvikle smarte produkter. Der berøres, hvordan du bruger technology road maps, Systems Engineering og modeller og kommer videre fra klassiske udviklingsdyder som stage gate og krav. Det krydres med cases og best practices baseret på gennemgående forskningscases fra GN ReSound A/S, MAN Diesel & Turbo A/S, Terma A/S og Seluxit ApS. Fieldbooken formidler best practice for udvikling af smarte produkter baseret på erfaringer fra danske virksomheder og universiteter. Fieldbooken giver konkrete input til den ingeniørmæssige realisering af smarte produkter. Den er skrevet til dig, der gør dig overvejelser om, hvordan din virksomhed kommer i gang eller videre med embedded systemer, og som søger inspiration til at øge jeres kompetencer. Forfattere Bidragsydere Henrik Valentin Jensen (red.), DI ITEK Allan Munck, DTU, GN ReSound Mads Kronborg Agesen, CISS, AAU Martin Løkke – Terma A/S Ulrik Nyman, AAU Jørn Johansen – Whitebox A/S Sune Wolff, AU, Terma A/S Nicolai Pedersen – DTU, MAN Turbo & Diesel Brian Boyles, Seluxit Aps Henning Mortensen, DI ITEK ITOS INTRODUKTION TIL FIELDBOOKEN 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 konkurrerer. 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 indbygget til at overvåge, måle og styre produktet og til at kommunikere og udveksle 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 intelligente 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 planlægning af udviklingsarbejdet. Den lægger op til, at ledelsen kan få beskrevet et roadmap over den udviklingsaktivitet, virksomheden skal igennem, og hvilke betingelser der skal til. Den introducerer metoder og værktøjer - technology roadmap, systems engineering og modellering. Det er centrale kompetencer til at tage de teknologiske udfordringer og muligheder op og omsætte dem til nye avancerede danske løsninger. Det arbejde skal fieldbooken stimulere til. Hermed er bolden til det givet op. Adam Lebech Branchedirektør DI ITEK ITOS 6 ITOS 1. TAG UDFORDRINGEN MED SMARTE PRODUKTER OP 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 organisation med kompetencer, metoder og teknikker til udvikling af embedded systemer. 1.1 FRA INDUSTRIELT TIL SMART PRODUKT Kampen på de industrielle produktmarkeder bliver fremover ført ud fra hvor smarte de enkelte produkter er, altså hvor meget intelligens og kommunikation, der bygges ind i produkterne. Kommunikation og intelligens bygges ind gennem embedded systemer. Kampen på de industrielle produktmarkeder bliver fremover ført ud fra, hvor meget intelligens og kommunikation, der bygges ind i produkterne 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 styre apparaterne i vores private hjem automatisk. De gør motorerne i handelsskibe mere miljøvenlige og de kan øge sikkerheden af kritisk infrastruktur i eksempelvis lufthavne. Nye smarte funktioner er noget de fleste professionelle kunder og forbrugere 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 ligetil, 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 produktområde overfor en række nye tekniske krav, og for en del af virksomhederne er der tale om nyt og ukendt land. Kundernes nye krav og forventninger stiller ethvert brancheog produktområde overfor en række nye tekniske krav 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 stiller også krav om, at produkterne skal kunne styres på afstand, en forventning om trådløs kommunikation, og at produkterne kan håndtere samspillet 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 markedsmæssig, teknisk og økonomisk vinkel. Samtidig skal udviklerne undgå 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 biler. Big data, cloud teknologi og netværk har alle embedded systemer ind7 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 kontrollere 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 produkter, 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 bliver 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 udfordringer, der følger af at udvikle smarte produkter. Fieldbooken giver konkrete anvisninger på, hvordan udfordringen kan tages op. Den er udarbejdet, drøftet og skrevet i et langvarigt samarbejde mellem praktikere og forskere. Fieldbooken giver et praktisk grundlag for at give sig i kast med at udvikle smarte produkter TIL FORSKELLIGE TYPER VIRKSOMHEDER I fieldbooken bestræber vi os på at give et grundlag for, hvordan virksomheder 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 FIGUR 1 KAPITEL 1 KAPITEL 2 KAPITEL 3 KAPITEL 4-6 KAPITEL 7-8 UDFORDRINGEN VI SKAL TAGE OP AMBITION: DEN UDVIKLER VI SKAL VÆRE VORES TEKNOLOGISTRATEGI DE RETTE METODER GÅ VIDERE FÅ NY INSPIRATION SÅ SMARTE SKAL VORES PRODUKTER VÆRE TEKNOLOGI ROADMAP DE RETTE TEKNIKKER C E NT R A L E HVAD MENER VI NÅR VI SIGER EMBEDDED SYSTEMER? HVAD ER VORES ERFARINGER MED AT UDVIKLE OG KOMME FRA IDE TIL PRODUKT? S PØ RG S M Å L HVOR SMARTE SKAL VORES PRODUKTER VÆRE? HVOR SKAL INTELLIGENSEN PLACERES? SMARTE PRODUKTER? 8 DE RETTE PROCESSER 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? ITOS LÆR FRA FIELDBOOKENS FIRE INDUSTRICASES Fieldbooken er resultatet af ITOS, der er et projekt, hvor 14 danske virksomheder 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: DI ITEK har været projektleder for ITOS Bruël og Kjær Sound Vibration A/S 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. 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. 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 9 ITOS CASE 1 GN RESOUND ULTIMATIV BEDRE SYSTEMS ENGINEERING GN ReSound finder, at testdrevet udvikling giver bedre kode; færre fejl, generelt højere kvalitet og en øget produktivitet. ” Øget kompleksitet og en forventning om at høreapparater 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 metoder generelt resulterer i kortere Time-To-Market og et bedre slutprodukt. Lars Lindqvist, VP, Research & Development at GN ReSound GN ReSound arbejder med en grundlæggende ide om at bevæge sig fra dokument drevne processer til testdrevet og modelbaseret systemudvikling. Vi får indsigt i styrker og svagheder ved forskellige metoder og tools. Ultimativt skulle vi gerne få input til at opdatere vores systems engineering approach Forsker: Allan Munck, erhvervs Phd. stip., DTU CASE 2 MAN DIESEL & TURBO SIMULERING 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-simulering for bl.a. at lette integration af delkomponenter. ” MAN Diesel & Turbo’s eksperter i forbrænding, mekanik, motorkontrol og termodynamik anvender avancerede modelbaserede design- og simuleringsvæ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ø. Henrik Rechnagel Olesen, Head of Control & Monitoring, MAN Diesel & Turbo MAN Diesel & Turbo udvikler avancerede distribuerede kontrolsystemer og tager skridtet videre og indfører et abstraktionsniveau mellem enhederne i deres Cyber Physical System, således at co-simulering af forskellige modeller og fysiske enheder er muligt. Modellering og simulering er en hjørnesten 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 Forsker: Nicolai Pedersen, Phd. stip., DTU 10 ITOS CASE 3 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 forsø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 smidiggøres hos Seluxit ved brug af arkitekturmæssige abstraktioner, der tillige tjener formålet at kunne verificere den ønskede systemopførsel, og bevare et stabilt og funktionel system til trods for mange interessenter. 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. ” Selv om de enkelte enheder er simple, gør samspillet 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 Forsker: Thomas Pedersen, Phd. stip., AAU CASE 4 TERMA SIMULERING 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 systemingeniør disciplinen, til at verificere ønsket funktionalitet og visualisere systemopførsel, har gjort Terma i stand til hurtigt at afgøre modenheden af ny teknologi og dermed accelerere produktudviklingen. En kombination, der giver agil produktudvikling, ø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 ” Anvendelsen af en modelbaseret tilgang til udvikling af produktet T.react CIP, til beskyttelse af kritisk infrastruktur, 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 introduceres 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 11 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. FIGUR 3 Funktionalitet Fremdrift + Hastighed + Komfort Damp Mekanik Brændstof Mekanik Teknologi + Radio + Lys + Komfort + Hastighed + Komfort + + Radio + Lys + Komfort Industriel produktion Elekricitet Mekanik og elektricitet Elektrisk indsprøjtning Mekanik og elektricitet ECU, etc. Mekanik og elektronik + Sikkerhed + Komfort Intern Kommunikation Mekanik og elektronik + Sikkerhed + Navigation + Komfort + Hastighed + Komfort + Mekanik, elektronik og software Mekanik, elektronik og software ...? 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 medfører en række fordele, ved at de: ¤ Tilføjer nye og bedre funktioner til produkter f.eks navigationsudstyr, 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 adgang til at bruge den funktionalitet, de embedded systemer tilfører produktet, uden overhovedet at kende eller have adgang til koden. 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. 12 ITOS LEDELSENS ç DRØFTELSE 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? 13 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å endnu et skridt videre ad den vej, man er slået ind på. Ambitionen vil være forskellig 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. Dernæ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. For de fleste betyder det at gå fra industrielt til smart produkt, at der til hardwaren skal lægges mere software Det kan man som virksomhed bruge til at fastlægge sin ambition for, at udvikle smarte produkter. 2.1 HVOR MEGET UDVIKLER SKAL VIRKSOMHEDEN VÆRE Et gennemgående træk for måden ITOS virksomhederne arbejder med udvikling 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 eller 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. FOTO: GN RESOUND A/S 15 ITOS KOMPETENCEMODEL Beskrivelse af forskellige komptenceniveauer til udvikling SYSTEMS ENGINEERING KOMPETENCER FOR EMBEDDED SYSTEMER Krav til produktet Design Baseline Uspecificeret Enkeltløsningsorienteret Udelukkende standard moduler Ved levering 1 Skriftlig formuleret Diagrammer af visse aspekter Standard moduler + egne moduler Løbende feedback Kravhierarkier Arkitektur beskrivelse og beskrivelse af hovedfunktioner Håndkodet og manuel hardware realisering Formelle specifikationer Simulering af dele af designet Auto-generering af dele af systemet Automatiseret test Modeller af krav Model-drevet design Chip design & kode generering fra modeller Modelbaseret 2 3 4 Realisering Test & validering Funktionel test MODELLERINGSKOMPETENCER FIGUR 4 Systems Engineering ser vi i ITOS som toppen af arbejdet – den overordnede tværgående tilgang, der binder alle områderne sammen, medens modelleringskompetencer 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 uerfaren virksomhed og niveau 4 det mest systematiske og højeste niveau for, hvordan man griber udviklingen an. Krav, Design, Realisering og Test & validering er de fire søjler i arbejdet Hvilket niveau virksomheden skal ligge på, afhænger af den betydning det at udvikle smarte produkter med embedded systemer har for virksomhedens nuværende og kommende produktprogram. Alle behøver ikke at have ambitionen om at nå til det, vi definerer som niveau 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 afhæ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 arbejdet udføres – om man bruger en Stage Gate model, hvor der tages beslutning om at fastfryse bestemte dele af produktets design ved på forhånd besluttede milepæle, eller man arbejder agilt med flere parallelle forløb og inddrager brugerne løbende. Det berører vi i kapitel 5. 16 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 tilpasse 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. DESIGN REALISERING I 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ørste omgang benytter diagrammer eller modeller til at beskrive de overordnede moduler som produktet består af og de indbyrdes relationer og afhængigheder imellem de enkelte moduler. Realisering i vores model omfatter både software og hardware udvikling. Hvis en virksomhed kommer med stærke kompetencer på det ene, men ikke på det andet område er det meget vigtigt 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 mange virksomheder vil der også være mekaniske eller andre produktionsmæssige aspekter som de skal kunne mestre for at fremstille kvalitetsprodukter. TEST & VALIDERING MODELLERING I Test og Validering er det vigitigt at fokusere både på: 1. Er kundens krav opfyldt? 2. Er de tekniske design krav opfyldt? Modellering, 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. Opfylder man kun det første, risikerer man at opbygge 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. 17 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 forskelligt 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 produktet udføre og jo mere autonomt fungerer det. FIRE NIVEAUER AF PRODUKTKAPABILITETER FOR SMARTE PRODUKTER FIGUR 5 AUTONOMI OPTIMERING KONTROL MONITORERING Sensorer og eksterne datakilder 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 Kilde: Porter, HBR nov. 2014 Monitorering og kontrol giver mulighed for algoritmer, der optimerer produktets funktion og brug for at: – Forbedre produktets performance – Give mulighed for forudseende system diagnose, service og reparation Kombinationen af monitorering, kontrol og optimering giver mulighed for: – Autonome produkter – Autonom konfiguration og koordinering med andre systemer – Autonom produkt forbedring og personalisering – Selvdiagnosticering CASE MAN Diesel & Turbo ønsker at udvikle mere optimale skibsmotorer for at forbedre brændstoføkonomien og levetiden af de samlede systemer de leverer. 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- 18 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. 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 gennemgående industricases: FIGUR 6 EKSEMPLER FRA CASENE MONITORERING KONTROL OPTIMERING AUTONOMI Hvor stor belastning har skibsmotoren kørt med minut for minut over de sidste 24 timer? MAN Diesel & Turbo casen 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 Data fra systemet bruges til at forbedre sensor-fusion algoritmerne for at opnå mere præcise estimater af personers bevægelse. Terma casen Klimasystemet og indbrudsalarmen snakker selv sammen så åbningen af et vindue ikke aktiverer alarmen. Seluxit casen Hvis et produkt giver mulighed for monitorering vil den næste naturlige tilføjelse være kontrol. Dette giver mulighed for både at fjernstyre produktets funktionalitet og at personalisere produktet til den enkelte bruger af systemet. Næste trin i tilføjelsen af værdi er optimering, hvor performance af produktet 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 forhandle med andre autonome indlejrede systemer om samarbejde i løsningen af en opgave hvorved de bliver selvkonfigurerende. En vigtig pointe er, at arbejdet med et niveau i produktet fordrer, at man mestrer de underliggende niveauer. 19 ITOS FRA IDÉ TIL SMART PRODUKT Ideér, der realiseres med eksisterende og velkendt teknologi og værktø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: LEDELSENS è DRØFTELSE 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? 20 ITOS FOTO: SELUXIT APS ITOS 3. LÆG TEKNOLOGISTRATEGIEN FOR DINE SMARTE PRODUKTER Udviklingen af teknologier til smarte produkter sker i et tempo, som hele tiden giver mulighed for flere varianter og løsninger til kunderne. Det udfordrer 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’ET Et 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 andre 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 operere ud fra alle de muligheder og rammer, teknologiudviklingen giver, er ingen 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 tiden 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 teknologiniveau er i dag, og hvad det skal skal være inden for en given tidsramme. Altså, at lægge virksomhedens teknologistrategi. Der skal træffes nogle valg og fravalg af teknologi, og vælges hvordan gap’et lukkes Fastlæggelsen af målet og ansvaret for at få det gennemført hviler på ledelsens skuldre. Målet kan f.eks. være at give kunder mulighed for at udnytte 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ætninger og barrierer, og til at få listet de opgaver, der kommer ud af det. Ledelse af teknologi omfatter overordnet set tre lag. ¤ Teknologiovervågning ¤ Teknologi roadmapping ¤ Teknologimodning 23 ITOS FIGUR 7 Lag af teknologiledelse TEKNOLOGI OVERVÅGNING TEKNOLOGI ROADMAPPING TEKNOLOGI MODNING Overvågning og indsamling af produktrelevant teknologividen er en løbende proces. Det kan f.eks være at holde skarpt øje, med de forhold, der sætter takten for virksomhedens udvikling, såsom udvikling af nye chip hos chipleverandørerne. Roadmapping giver et overordnet billede af teknologier og trends og forventninger om teknologi, markeder og kunder som virksomhedens kompetencer skal matche. Teknologimodning handler om at vurdere, hvor fremskreden – teknologiparat – en given teknologi er i forhold til virksomhedens behov og på baggrund heraf vælge, hvad der skal udvikles på. 3.2 TEKNOLOGIOVERVÅGNING Der 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, samarbejde med universiteter, rettigheds- eller patentanalyse og f.eks. gennem messer og konferencer. Der er mange måder at skaffe sig viden om ny teknologi på Nye metoder er f.eks datamining, big data og webcrawling, hvor der samles 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 hvordan produkter og systemer virker, de påvirkninger de er udsat for, driftbelastninger 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 24 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 TEKNOLOGIROADMAPPING Teknologiroadmap er et meget anvendt værktøj til teknologiledelse. Det tager afsæt i virksomhedens strategi, således at beslutningerne om teknologi og produktudvikling går hånd-i-hånd. Overordnet set er et teknologiroadmap 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 virksomheden sælger som igen linker til teknologibehovet som så skal omsættes i konkrete handlinger for teknologiudvikling. Figuren herunder er inspireret af Danfoss’ roadmap. Sammenhængende roadmap – med teknologi ”pull” og ”push” M1 MARKET P1 PRODUCT P2 PL1 PLATFORM M2 P3 PL2 T1 COMPETENCE C1 T2 C2 T3 Time P4 PL3 ”PUSH” ”PULL” TECHNOLOGY M3 FIGUR 8 T4 T5 C3 Kilde: Jesper Søbygaard Nielsen, Danfoss 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. Målet er at få opstillet et sammenhængende roadmap, som viser hvilke nye teknologier og kompetencer, der skal til Helt nye teknologiideer, f.eks fra virksomhedens egen innovation, eller nye aktører, skal også inkluderes i teknologiroadmappet. Hvis der ikke er et eksisterende produkt i roadmappet, som umiddelbart kræver en sådan ny 25 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 eksisterer en forretningsplan for dette fremtidige produkt. Disse ”push” teknologier 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 (placeret på en tidsakse), som ønskes og forventes at blive modnet inden for den tidsmæssige horisont for roadmappet. Prioriteringerne af teknologivalgene og modningen af disse sker således gennem markederne og forretningsplanen for de enkelte produkter. www.ifm.eng.cam.ac.uk/ resources/techmanworkbooks/ t-plan/ En anerkendt metode indenfor teknologi roadmapping er T-plan, der er udviklet 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 kommercielle perspektiv. Koblingen sker ved at føre nye produkter på markedet. 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 TEKNOLOGIMODNING Teknologiske 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 teknologier navnlig dem man selv har erfaring med. I bedømmelsen af modenhed er det ikke nok, at andre er kommet langt med en teknologi. Den sammenhæ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 robusthed 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 teknologiprojekt kender man ikke nødvendigvis slutresultatet. Teknologiprojektet skal derfor køres langt mere fleksibelt end et udviklingsprojekt, som har helt faste rammer for både scope, cost og schedule. Mange virksomheder har implementeret en form for StageGate model (Robert 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 opdeling 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 stadig i laboratoriet. De midterste niveauer er der, hvor der foretages, simuleringer 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 teknologien i det miljø og under de forhold, den skal fungere i. 26 ITOS 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 HVOR SKAL VI PLACERE INTELLIGENSEN Er 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 produkt, desto mere kan produktet fremtidssikres gennem softwareopdateringer. 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 afgør hvad der er mest optimalt. Der er også en afvejning mellem brug af standard processorer og specialudviklet hardware. Specialudviklet hardware i form af f.eks FPGA’er kan opnå meget bedre performance, men har højrere udviklingstid. En anden overvejelse der skal gøres i forbindelse med fordelingen af funktionalitet mellem det fysiske produkt og skyen er, om der skal benyttes standard eller egenudviklede protokoller for kommunikationen. At følge standarder kan give fordele i forhold til hastigheden, hvormed nye løsninger og produkter kan udvikles. 27 ITOS EKSEMPEL FRA GN RESOUND CASEN I forbindelse med udviklingen af nye høreapparater der skulle kunne modtage lyd via en WiFi forbindelse udviklede GN ReSound en specialdesignet protokol til at at kommunikere mellem høreapparaterne og en telefon. Et af formålene med denne protokol var at lave mindst mulig af lydprocessering i selve høreapparaterne da disse har meget begrænset beregningskraft. Herved kunne GN ReSound lave et unikt produkt som ingen andre på markedet havde. FIGUR 9 Høreapparat med App speech produkt special chip Vejrstation simpel chip Fuldt system med standard chip og skærm Cloud Funktionalitet i Cloud Smart køleskab 5 grader App 3.5 DET KORTE AF DET LANGE Sø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 virksomhed – 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. 28 ITOS CASE: TECHNO-MATIC – HVORDAN SKAL VI LAVE EN CLOUD-LØSNING? Techno-matic er en af mange mindre virksomheder, 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 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. De to yderpunkter for Techno-Matik’s overvejelser er; InnoBooster programmet udbydes af Innovationsfonden. ¤ Bibeholde eksisterende Atmel MCU styring og tilbyde Cloud connectivity gennem en add-on med seriel/CAN kommunikation til MCU Læs mere om mulighederne for små og store innovationsprojekter på www.innovationsfonden.dk 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. ¤ Udvikle én samlet platform for alle deres produkter med udgangspunkt i en multiprocessor løsning, hvoraf én varetager det øvre applikationslag, dvs. GUI, Cloud, IoT, etc. gennem et operativ system som f.eks Linux CASE LEDELSENS ç DRØFTELSE I forhold til de produkter din virksomhed udvikler, hvor skal intelligensen 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 eller 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? 29 4 ITOS 4. BRUG DE RETTE METODER SYSTEMS ENGINEERING Den tværfaglige natur af systemerne ligger bag de fleste af de udfordringer man bliver stillet overfor under udviklingen af embedded systemer. Produkterne 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 disciplinen op, da den bidrager til at alle tekniske aspekter afvejes på lige vilkår med de projektplansmæssige aspekter. Produkterne bliver stadig mere komplekse og indholder både mekanik, elektronik og software En af de danske virksomheder, der gør udstrakt brug af system engineering, er Terma A/S med hovedkontor i Lystrup ved Århus. Terma udvikler avancerede systemer til forsvar, fly, rumfart og sikkerhed og har indført Systems Engineering som en mere systematisk tilgang til de tværfaglige tekniske aspekter i produktudvikling og projektarbejde. 4.1 MÅL OG OPGAVER Systems Engineering som metode tilstræber at favne alle aspekter af et udviklingsforlø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 fokusere på f.eks. et bestemt aspekt af teknologiudvikling. Opgaverne går på FOTO: TERMA A/S 31 ITOS BEHOVSANALYSE SYSTEMAFGRÆNSNING PROJEKTPLANLÆGNING KOMMUNIKATION KRAVSDEFINITION OMKOSTNINGSHÅNDTERING FORHANDLING KRAVSSTYRING ARKITEKTURDESIGN TRADEOFF ANALYSE KONFIGURATIONSSTYRING INTEGRATION VERIFIKATION & VALIDERING OPERATION PERFORMANCEOVERVÅGNING RISIKOHÅNDTERING ESTIMERING PROJEKTKOORDINERING PROJEKTRAPPORTERING VEDLIGHOLD SE RESSOURCEPLANLÆGNING OUR JOB! PM Kilde: TERMA A/S ud fra PMI-INCOSE Community of Practice on Lean in Program Management FIGUR 10 tværs af virksomhedens forskellige afdelinger; salg, udvikling og ledelse. Relationer mellem afdelinger opbygges som en egentlig Systems Engineering proces ved at styrke virksomhedens evne til at til at tænke helhedsorienteret. Systems Engineering integrerer traditionel projektledelse og teknisk omtanke 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 klare 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 ANSVAR Rollerne 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 kvalitet 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 projektlederrollen 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 figur 10. 32 ITOS Systemingeniørens ansvar omfatter de klassiske tekniske processer i udviklingsforløb som kravdefinition og kravstyring, arkitekturdesign, verifikation og validering osv. Systemingeniøren vil typisk også have ansvar for behovsanalyse og brugerinvolvering, herunder også at inddrage de dele af organisationen der forestår drift og vedligehold af det færdige produkt. Projektlederen har fokus på projektplanlægningen, ressourcer og omkostninger. 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/S Terma har stor værdi af at have medarbejdere, der mestrer det brede tværfaglige 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, elektronik, 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 brugerens 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 Engineering for alvor giver værdi for Terma. Termas strategi fokuserer på forudsigelighed og effektiv gennemførsel af produktudvikling gennem hele produktets livscyklus. Terma har praktiseret 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 hvordan, det praktiseres. Terma får med Systems Engineering identificeret krav fra de relevante interessenter 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 formelle 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 blevet reviewet af interessenter fra andre procesområder (forretningsudvikling, udviklingsingeniører, product managers), da systemingeniørprocessen udfylder 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 33 ITOS Arbejdet med at skrive en fælles systemingeniørproces på tværs af forretningsområder og domæner var værdifuld for Terma. Det lykkedes at kombinere 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å Systems Engineering end det var tilfældet. Sådan kan man komme i gang med Systems Engineering 4.4 SYSTEM ENGINEERING PROCES Systems 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 Engineering gennem konkrete metoder og processer i organisationen på lige fod med projektledelse. Systems Engineering handler om at transformere markedets behov til et system, som opfylder dette behov Der findes flere Systems Engineering metoder. Terma baserer sin proces på den civile standard, ISO/IEC 15288. I bund og grund er Systems Engineering 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 gennemfø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, overordnede indsatsområder (Life Cycle Processes) 2. Nedsæt en arbejdsgruppe for hvert indsatsområde 3. Involver personer tværfagligt og på tværs af forretningsområder 4. Definer en proces, gerne med udgangspunkt i IEC 15288, en proces der tager hele systemets livscyklus (System Life Cycle) i betragtning. 34 FOTO: MAN DIESEL & TURBO ITOS Systems Engineering er ... at forstå markedets behov og transformere disse til et system som opfylder behovene Det er også: SE ... et PERSPEKTIV – anvender en systemtankegang til hele systemer, deres enkeltdele og interaktion til det eksterne miljø ... En PROFESSION – interdisciplinært fag som integrerer multidisciplinære kompetencer Proces Perspektiv Profession ... En iterative teknisk ledelses PROCES Kilde: TERMA A/S FIGUR 11 4.5 SYSTEMS ENGINEERING VÆRKTØJER Modelleringssprog som f.eks. SysML er udviklet til at give systemingeniører en måde at tackle udfordringerne med tværfaglige kommunikation. Generelt mangler elektronik- og software ingeniører et fælles sprog, når de udvikler nye indlejrede systemer sammen. SysML (Systems Modeling Language) er baseret på UML (Unified Modeling Language), men kompleksiteten er mindsket og mere abstrakte modellerings 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 allokere krav til de ansvarlige komponenter. Semantikken er udvidet til understøttelse af kravmodellering samt performance analyse, som er to essentielle systemingeniør aktiviteter. SysML (Systems Modeling Language) er inddelt i fire diagram typer: krav, struktur, adfærd og parametriske diagrammer Teknologier som SysML er nødvendige for at bevæge sig fra traditionel dokumentbaseret systemudvikling, til en modelbaseret tilgang. Modelleringssprog SysML bør være i enhver systemingeniørs værktøjskasse. SysML er inddelt i fire diagramtyper: krav, struktur, adfærd og parametriske diagrammer. De forskellige diagrammer dækker forskellige elementer af udviklingsprocessen og er lavet så de giver alternative men komplementæ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 fagdiscipliner. For systemingeniører, der gerne vil forbedre præcisionen og effektiviteten i deres kommunikation med andre tekniske og ikke-tekniske interessenter, er SysML et glimrende valg som modelleringssprog. 36 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 GODT Systems 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. 37 ITOS 5. VÆLG DEN RETTE PROCES 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. Forskellige modeller til at opdele sine udviklings aktiviteter efter I dag taler vi mest om iterative og agile processer. Den tidligste anvendte procesmodel for udviklingen af software er vandfaldsmodellen. I dag bruges den metode mest som en referencemodel for de forskellige konceptuelle faser, en softwareudviklingsproces består af. 5.1 ITERATIVE OG AGILE PROCESSER Iterative 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 projektstyringsmodellen SCRUM. Hovedelementet i en iterativ procesmodel er, at alle faserne gennemløbes gentagne gange indtil systemet er færdigudviklet. ITERAKTIV PROCES FIGUR 12 KRAVANALYSE VALIDERING OG TEST DESIGN DRIFT OG VEDLIGEHOLD REALISERING Agile modeller er en fællesbetegnelse for en lang række af udviklingsprocesser, 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 iteration 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. 39 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 udvikling og validering fra agile modeller, er en såkaldt Stage-Gate model. Agile procesmodeller har efterhånden vundet stor indpas i organisationer, der udvikler ikke sikkerhedskritisk systemer 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 dokumentation 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 FIGUR 13 STAGE-GATE MODEL Idé Forundersøgelse G1: Screening Detaljeret undersøgelse G2: Anden Screening Udvikling G3: Business case Test og Validering G4: Review af Udviklingsforløb Produktion G6: Business review Produktions stop G7: Produktions review SELUXIT OG GN RESOUND Virksomhedstørrelse, segment og historie har indflydelse på, hvordan det er muligt at agere agilt. Virksomhederne Seluxit og GN ReSound er eksempler på en mindre og en stor virksomhed UDVIKLINGSPROCES OG PROJEKT MODEL Store 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 testarbejde udføres mere stringent. Seluxit arbejder i projekter typisk med hyppige demonstrationer af funktionalitet, hurtig feedback fra kunden. Projekters fremdrift måles ikke som frembringelse af dokumenter ved en gate, men funktionalitet der demonstreres for kunden ved enden af et sprint. Til styrring af "processen" anvendes scrum med bl.a daglige stand-up møder. 40 ITOS INTERESSENTINVOLVERING GN ReSound udvikler produkter, der er underlagt strenge certificeringskrav, hvorfor kravspecifikation foregår tidligt, mens test og validering foregå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 projektforløbet. Skulle projektet tage en uventet drejning, involveres nye interessenter ad-hoc. LEVERANCER OG DEADLINES Seluxit's meget agile måde at arbejde på, gør at funktionelle leverancer forfines 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. Udviklere 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. 41 ITOS 6. BRUG DE RETTE TEKNIKKER MODELLER, REQUIREMENTS ENGINEERING OG SIKKERHED 6.1 MODELLER – LIDT AD GANGEN FRA 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ærdi til den nuværende arbejdsproces. Derpå laves en målrettet plan for, hvordan modellerne bliver indført. Alt med måde! Forsøg ikke at løfte virksomheden flere niveauer ad gangen. Læringskurven er stejl 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 naturligt 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ørgsmå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 brugbart sæt af modelleringsteknologier, se figur 14. Types og Systems Modeling Disciplines Available Technologies Identify Modeling Needs Identify Potential Technologies FIGUR 14 Metode til at finde den rigtige modelleringsteknologi Controlo flow Data flow Correlate Needs & Technologies Identify Optimal Tech.set Implement Modeling Setup Set of modeling methodologies, languages and tools Prioritized Needs vs Modeling Disciplines and Technology Rating 43 ITOS 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 tilsammen 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 inddeling af modelleringsdiscipliner Figuren skal læses nedefra og op og er et slags kort, der mapper de forskellige typer modellering, og hvad de især kan benyttes til. FIGUR 15 Enterprise Modeling (EM) Integrated Engineering (IE) Coherent Modeling (CM) ABCM BSM Andre udviklingsaktiviteter ABCM AAM … BSM" Andre aktiviteter i virksomheden AAM" Fundamental Modeling (FM) BSM = Behavioral Simulation Modeling AAM = Architectural Analysis Modeling ABCM = Architecture/behavior co-modeling MODELLERINGSDISCIPLINER Fundamental Modeling (FM) Fundamental 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, brugerscenarier, systemfunktioner, -struktur og -data, testcases, mm. Simulering er ikke en del af FM. Man kan derfor starte med at bruge gængse kontorværktøjer til at lave diagrammer, tekstbeskrivelser, tabeller, etc. Et egent- 44 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. Interaktive 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, Simulink, SystemC, VDM, Ptoleymy-II, mm. Til hardwaresimulering bruges oftest VHDL, Verilog, SystemC, SPICE, Modelica, mm. Til sikkerhedskritiske systemer vil man ofte benytte mere stringente modeller og formel matematisk verifikation med værktøjer som SPIN, UPPAAL, etc. Behavioral Simulation Modeling (BSM) 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 matematiske 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. Architectural Analyses Modeling (AAM) Architecture/Behavior Co-Modeling (ABCM) benyttes til at analysere og simulerer systemer, hvor der er stærk vekselvirkning mellem systems arkitektur og opførsel. Dette er tilfælde, når systemet eller brugerne kan (de-) aktivere delsystemer, eller når systemet kan (de-) aktivere forskellige funktioner 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 velstruktureret model vil også muliggøre automatisk generering af software fra modellerne. Architecture/Behavior Co-Modeling (ABCM) Coherent Modeling (CM) Coherent Modeling (CM) benyttes, når der er behov for at hægte modeller i forskellige modelleringssprog og -værktøjer sammen. Når man har forskellige 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 ændringer 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 retfæ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, brugermanualer, dokumentation, osv. IE er nok enklere at indføre end CM, men er dog for den modelleringsmæssige modne virksomhed. Integrated Engineering (IE) Enterprise Modeling (EM) bruges til at modellere alle virksomhedens aktiviteter med at analysere, designe, implementere, fremstille, udbyde, sælge, operere, servicere og vedligeholde produkter og systemer. EM kræver en betydelig indsats og er nok kun for de helt store virksomheder. Enterprise Modeling (EM) 45 ITOS IDENTIFIKATION AF MODELLERINGSBEHOV Ud fra oversigten over de forskellige modelleringsdiscipliner kan vi identificere modelleringsbehovet. Først identificeres vigtige interessenter. Derefter forbereder vi passende spørgeskemaer og laver interviews. En analyse af svarene vil resultere i en prioriteret liste af behov (grupperet efter modelleringsdiscipliner). 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 TEKNOLOGIER Markedet for modelleringsværktøjer er i rivende udvikling, og potentielle 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 TEKNOLOGIER Med 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. FIGUR 16 Mapping mellem behov og teknologier (eksempel, uddrag) Disciplines and needs Technology rating Behavioral simulation modeling Interactive simulations Automated simulations Formal verification Need Priority SysML Tool #1 AADL Osate2 Yes Yes Yes ••• ••• • ••• ••• •• UPPAAL SystemC PLM + SMC +TLM/AMS Tool#2 •••• ••••• ••••• •• ••• • NA NA NA Plugins 4Tool #1 NA NA NA IDENTIFICER MULIGE SÆT AF TEKNOLOGIER Det 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 udgangspunktet 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 beskrevet 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ælge en anden strategi, hvor man vælger lidt flere værktøjer, hvis man derved kan få andre fordele – f.eks. bedre brugervenlighed. 46 ITOS INPUTS Technology rating vs needs and modeling disciplines Identify required set for each need Combine required set for each need Reduce combined set Identify minimal solution Choose among egually good choices OUTPUTS Set of modeling methodologies, languages and tools FIGUR 17 Metode til identifikation af mulige sæt af teknologier TAG DET VALGTE SETUP I BRUG Når et godt sæt af modelleringsteknologier er fundet, skal de implementeres. Det kan gøres på mange måder, da man kan variere antallet af modelleringsfeatures og udviklingsprojekter. Figur 18 viser fire ekstremer. Hver måde har sine fordele og ulemper. Ved at benytte pilotprojekter risikerer man, at setupet ikke kan skalleres op. Omvendt er det en stor organisatorisk udfordring at starte på mange udviklingsprojekter samtidig. Tilsvarende kan det være en stor teknisk udfordring at indføre hele modelleringspaletten på én gang. I praksis vil man nok vælge en fremgangsmåde, der ligger mellem disse fire ekstremer. FIGUR 18 Features Implementering af modelleringssetup Technically Challenging Cautious Confident Organizationally Challenging Projects I PRAKSIS Hos GN Resound har man fået en god indsigt i de forskellige modelleringsdiscipliner og virksomhedens behov. GN Resound har således på en systematisk måde identificeret en passende værktøjskasse, der tilfredsstiller både nuværende og fremtidige modelleringsbehov. SysML, SystemC, SimJava2 og andre modelleringsteknologier bliver gradvist indført i virksomheden, efterhånden som der bliver behov for dem. 47 ITOS 6.2 REQUIREMENT ENGINEERING ELLER KRAVSTYRING Traditionel 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 udviklingsprojekter, 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 resultatet med suboptimering. Det viser sig typisk ved, at den embedded software kommer til at løse opgaver, der havde ligget meget bedre i hardware (eller omvendt) og styringen af mekanik bliver gjort unødig besværlig. Mennesker er pr. definition utålmodige – lad os nu komme i gang. Derfor glemmes centrale krav, for så at komme forstyrrende ind senere i forlø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 markedsføres. For at leve op til standarder, er det hovedreglen, at alle krav er dokumenterede og validerede. Det stiller så igen ufravigelige krav om sporbarhed mellem f.eks krav og testcases. ” Ofte fejler produkter i testfasen ene og alene fordi, det ikke er ordentligt beskrevet, 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 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. 48 ITOS UNDGÅ PENGESPILD Der er mange penge i at blive bedre til at specificere krav og styre dem under udviklingsforløbet. Gøres arbejdet ikke godt nok, kommer der udgifter til fejlretning – i værste fald tilbagekaldelse, når produktet er på markedet. Der er mange penge i at specificere krav og styre dem under udviklingsforløbet. Årsagen til fejlenes opståen i forbindelse med kravspecifikation og ændringsstyring 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 software opstår i forbindelse med kravspecifikation og styring af kravændringer. 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 vedligeholde 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 arbejdsformer 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. 49 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, demonstrationer, interviews, brugerundersøgelser, forretningsanalyser og prototyper i anvendelse. Heri skal også huskes krav fra standarder og interne generelle produkt- og produktionskrav. Indsaml de vigtigste ønsker, ideer og krav Interessentkravene beskrives som krav, kunden eller brugeren i den sidste ende kan validere. Denne aktivitet afklarer uoverensstemmelser mellem 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-ogned 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 software. Specificér brugerkravene i produkt- og komponentkrav Derefter analyseres kravene for at sikre, at den ønskede funktionalitet med den rette kvalitet kan udvikles. Det kan f.eks ske ved konceptdemonstrationer, brug af scenarier og prototyper. Det er vigtigt, at analysen af kravhierarkiet er sammenhængende og at kravenes indflydelse på de samlede udviklingsomkostninger afdækkes. Samtidig identificeres: ¤ de mest risikable krav ¤ verificerbarheden af de enkelte krav ¤ validerbarheden af de overordnede kunde- og brugerkrav. FIGUR 19 Undersøgelse af hvor fejl opstår og andelen af omkostninger til fejlrettelser. OMKOSTNINGER ÅRSAG TIL FEJL ANDET 10 pct. IMPL. 7 pct. ANDET 4 pct. IMPL. 1 pct. DESIGN 27 pct. DESIGN 13 pct. KRAV 56 pct. KRAV 82 pct. Kilde: Vinter 50 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 tilgængelig. Udviklingen af kravhierarkiet forløber parallelt – og skal ikke være en sekventiel øvelse. Kravene skal fra starten registreres på det rette niveau for at undgå redundant information ned gennem hierarkiet. Her udvikler og ændringsstyres 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 eller de data, som kommunikeres fra produktet. Der findes også en række eksempler på, at forskere har hacket et produkt og efterfølgende orienteret virksomheden om det, således at den kunne rette fejlen inden den blev offentliggjort. Begge dele kan komme til at koste betydelige summer på bundlinjen eller tabt renomme. Typisk opstår fejl i programmeringen, fordi der i udviklingsforløbet undervejs ikke har været inddraget relevante kendte sikkerhedsovervejelser, eller 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 ondsindede hensigter. Man skal sørge for, at koden kan opdateres, når der opdages nye sårbarheder i produktet eller i tilknytning til produktet. Endelig skal man overveje, om der er tekniske sikkerhedsforanstaltninger, man bør bygge ind i sit produkt 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. Vær opmærksom på lovgivningskrav. For personoplysninger, er der særlige regler Det er ledelsen, som har ansvaret for, at sikkerheden i de smarte produkter er på plads. Derfor bør ledelsen sikre, at der er udpeget en sikkerhedsansvarlig 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. Endelig 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. 51 FOTO: SELUXIT FOTO: GN RESOUND A/S ITOS OPSUMMERING KAPITEL 4-6 VIRKSOMHEDENS KOMPETENCEROADMAP LØFT DIN VIRKSOMHEDS KOMPETENCER I de foregående kapitler har vi peget på centrale metoder, processer og teknikker 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 begreber 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 teknologistrategi 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 beherskes for at kunne realisere produktet ¤ Systems engineering som overordnet metode og en fast organisatorisk 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 styre de forskellige dele af udviklingsaktiviteterne ¤ Modellering og valg af forskellige modelteknikker passet til udviklingsopgaven. SYSTEMS ENGINEERING KOMPETENCER FOR EMBEDDED SYSTEMER Krav til produktet Det udgør de forskellige byggesten i ledelsens fastlæggelse af vejen frem for virksomheden til at gøre sine industrielle produkter smartere, dvs. indeholde mere intelligens og kommunikation. Det har vi sammenfattet i figur 20. Design Realisering Test & validering Baseline Uspecificeret Enkeltløsningsorienteret Udelukkende standard moduler Ved levering 1 Skriftlig formuleret Diagrammer af visse aspekter Standard moduler + egne moduler Løbende feedback 2 3 Kravhierarkier Arkitektur beskrivelse og beskrivelse af hovedfunktioner Håndkodet og manuel hardware realisering Formelle specifikationer Simulering af dele af designet Auto-generering af dele af systemet Automatiseret test Modeller af krav Model-drevet design Chip design & kode generering fra modeller Modelbaseret 4 Funktionel test MODELLERINGSKOMPETENCER Kompetenceniveauerne er beskrevet i figur 4 side 16 Kompetenceniveauer for at udvikle produkter med forskellige kapabiliteter Anbefalede kompetence niveauer Kapabilitet Krav til produktet Design Realisering Niveau 1 Monitorering Kontrol Niveau 2 Optimering Niveau 3 Autonomi Test & Validering Niveau 4 Niveau 2 Niveau 3 FIGUR 20 53 ITOS Figur 20 viser at det kun er nødvendigt, at befinde sig på de første niveauer for at udvikle produkter, der understøtter monitorering og kontrol. Udviklingsopgaven 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. SYSTEMS ENGINEERING KOMPETENCER FOR EMBEDDED SYSTEMER Krav til produktet Design Baseline Uspecificeret Enkeltløsningsorienteret 1 Skriftlig formuleret Kravhierarkier Formelle specifikationer Simulering af dele af designet Auto-generering af dele af systemet Automatiseret test Modeller af krav Model-drevet design Chip design & kode generering fra modeller Modelbaseret 2 3 Realisering Test & validering Udelukkende standard moduler Ved levering Diagrammer af visse aspekter Standard moduler + egne moduler Løbende feedback Arkitektur beskrivelse og beskrivelse af hovedfunktioner Håndkodet og manuel hardware realisering 4 Funktionel test MODELLERINGSKOMPETENCER 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 succesfulde 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 engineering 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 udviklingsaktiviteter. Er ambitionen, at produkterne skal kunne lave optimering til specifikke situationer 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ødvendigt at have indarbejdet metoder til Systems Engineering for at overskue, hvilke dele af det samlede system, der bliver påvirket af ændringer i det enkelte krav og at kunne arbejde agilt hermed. CASE SELUXIT CASEN TERMA CASEN SeluxIT der er en lille og relativt ny virksomhed (stiftet i 2006) har helt fra starten arbejdet med produkter der indebærer monitorering, kontrol og trådløs kommunikation. Målet for deres produkter til fremtidens intelligente hjem er automatisk konfigurering og en stor grad af autonomi 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 modeller og system verifikation. I Terma casen er der blevet anvendt modeller til udvikling af prototyper af nye produkter. Dette har givet indsigt i nye teknologier og en hurtigere vej til produktmodning af nye sensor-fusion teknologier. Brugen af modeller har været et godt værktøj til at mildne risici ved introduktion af nye teknologier. GN RESOUND CASEN I GN ReSound casen bliver der aktivt arbejdet med betydningen af modeller på tværs af alle processer i udviklingen af embedded produkter og med formaliseringen af en ny udviklings proces baseret på kombinationen af modeller og testdrevet udvikling. Specielt produkter med autonomi vil være svære at udvikle uden at have formelle modeller for produkternes opførsel. Sådanne modeller vil muliggøre simulering 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 kompetencer, 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, universiteter eller teknologiske konsulenter. 54 ITOS LEDELSENS ç DRØFTELSE 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 engineering, agile metoder, modellering, kravstyring, sikkerhed)? ¤ Hvordan opgraderer og skaffer vi os de kompetencer? FOTO: GN RESOUND A/S 55 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 PRODUKT Udvikling af smarte produkter handler om at kunne sammensætte flere teknologier 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 Udvikling af smarte produkter handler om at kunderne opnår bedre og flere funktionaliteter Projektledere og udviklere oplever det at være på forkant med teknologierne som alt andet end en triviel opgave.Technology Roadmapping er en essentiel og farbar vej hertil, og bør foregå sideløbende med udviklingsaktiviteten. Traditionel projektledelse anbefales suppleret med systems engineering disciplinen, 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 perspektiver skal drejes mod hinanden og desto flere trade offs opstår der. Behovet 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 tommelfingerregler – for den praktiske brug af de forskellige processer, metoder og teknikker. Det, er der samlet op på i boksen: 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 57 ITOS DET ULTIMATIVE MODELVÆRKTØJ FINDES IKKE GN ReSounds erfaring er, at der ikke findes ét modelværktøj, der alene løfter opgaven at udvikle smarte produkter. Hver delopgave kræver specialiserede værktøjer og der er behov for en sammenkobling af alle organisationens 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 mekanikdesign og dokumentation stiller krav til åbne api’er eller mulighed for data import og eksport mellem software. 7.2 HER FINDER DU MERE INFORMATION WWW. itek.di.dk/ Indsatsomraader/ Innovationiteknologierhvervet/ITOS ITOS projektet har udgivet seks publikationer om en række væsentlige temaer. De er skrevet af praktigere og forskere i form af artikler. Vægten er på praktiske efaring og cases. Kort til den indlejrede fremtid Fokus er på teknologi trends og teknologi roadmap Wireless Teknologi Fokus er på betydningen af wireless teknologi i smarte produkter Værktøjer og modeller Vigtige metoder og modeller til at udvikle embedded systemer Innovation for samfundet Embedded systemer set i et bredere teknologisk udviklingsperspektiv Internet of Things og Industri 4.0 To store drivkræfter for teknologiudviklingen 58 Roadmap til embedded systemer (dec 2015) Ledelsens arbejde med at udvikle smarte produkter ITOS TECHNOLOGY ROADMAP En god kilde til mere information om Technology Roadmaps er den hjemmeside 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 Cambridge, 2001) som grundig beskrivelse af processen. En anden mulig kilde er: ”From Business Strategy to Information Technology Roadmap” (Tiffany Pham, 2013). SYSTEMS ENGINEERING Organisationen 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 organisation, der har til formål at hæve niveauet for, og udbrede kendskabet til, Systems Engineering på tværs af industri, uddannelsesmiljø og den offentlige sektor. 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 standard. I slutningen af 2013 blev en dansk afdeling af INCOSE etableret , som arbejder for at udbrede kendskabet til Systems Engineering i Danmark. Dette gøres blandt andet gennem workshops og foredrag om emnet. AGILE METODER 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 HTTP://DIGITALISER.DK/ RESOURCE/454065/ARTEFACT/ VEJLEDNING+OM+ AGIL+UDVIKLING.PDF 59 ITOS MODELLER Der er mange muligheder for at finde mere information om brugen af modeller 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 ENGINEERING En organisations evne til at udvikle og vedligeholde produkter eller services er betinget af den professionalisme (modenhed) den har. Professionalismen måles som modenhed med en såkaldt modenhedsmodel som f.eks CMMI® eller ISO/IEC 15504 (SPICE). Her analyseres graden af anvendte processer, understøttet af metoder, værktøjer og udtrykte kompetencer, samt ledelsens fokus på udviklingsorganisationen. I disse modeller er kravudvikling og kravstyring centrale i forhold til mange af de øvrige processer, der er en del af udviklingsprocessen. ØVRIGE Innobooster er et program under Innovationsfonden, hvor små og store virksomheder kan søge tilskud til et samarbejde med universiteterne – se www.innovationsfonden.dk 60 FOTO: TERMA A/S ITOS 8. ITOS CASES INDUSTRICASES FÆLLES TRÆK TRODS STORE FORSKELLE ITOS’ resultater bygger på fire industricases, udover det brede virksomhedssamarbejde. 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 betonede, og på den anden side handler om temaer, vi alle kender. Fire cases er gennemført som forskningsprojekter i samarbejde med AU, AAU og DTU F.eks hvordan smartphonen kan bruges til at styre et høreapparats funktioner. At undgå nogen vi ikke bryder os om, trænger ind på havne og flyvepladser. 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 aftestning, 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 dieselmotorer 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. 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 udfordringerne 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. SYSTEMS ENGINEERING KOMPETENCER FOR EMBEDDED SYSTEMER Krav til produktet I forhold til model i Figur 4 befinder casevirksomhederne sig kompetencemæssigt på niveau 3 på langt de fleste aspekter. Nogle arbejder nu på at nå niveau 4 for nogle delaspekter. Design Realisering Test & validering Baseline Uspecificeret Enkeltløsningsorienteret Udelukkende standard moduler Ved levering 1 Skriftlig formuleret Diagrammer af visse aspekter Standard moduler + egne moduler Løbende feedback 2 3 4 Kravhierarkier Arkitektur beskrivelse og beskrivelse af hovedfunktioner Håndkodet og manuel hardware realisering Formelle specifikationer Simulering af dele af designet Auto-generering af dele af systemet Automatiseret test Modeller af krav Model-drevet design Chip design & kode generering fra modeller Modelbaseret Funktionel test MODELLERINGSKOMPETENCER Alle fire cases mestrer monitorering og kontrol, og arbejder med optimeringsaspekter. De mestrer monitorering og kontrol og arbejder med optimering 63 ITOS Forsker: Allan Munck, erhvervs Phd. stip., DTU 8.1 GN RESOUND – SMART PHONE STYRET HØREAPPARAT Siden lanceringen af GN ReSound’s første høreapparat DANAVOX i 1947, har GN ReSound gentagne gange taget ny teknologi i brug for at optimere deres kerneprodukt, høreapparatet; Digital lydprocessering i 1992, Software baseret lydprocessering i 1996, Surround Sound i 2009. Alle markante teknologiskifte som optimerede funktionalitet og medførte bedre produkter for kunden. I 2010 lancerede GN ReSound det første høreapparat med indbygget trådlø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 teknologiskifte, 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 videre streamer lyd trådløst fra en iPhone. De høreapparater som for få år siden var stand-alone produkter, kommunikerer nu med hinanden og andre produkter. GN ReSound udvikler nu udover desktop applikationer til trådløs kalibrering af høreapparatet hos ørelæ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. FIGUR 21 GN Resound – Smart Phones genopfandt trådløs overførsel af lyd og revolutionerede markedet Trådløs overførsel af lyd til høreapparater har eksisteret i mange år i form af såkaldte teleslynger, der fungerer 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 funktionalitet og en række nye udfordringer; 64 ¤ Design af radio og audio-protokol til pladsog ressourcebegrænset miljø ¤ Godkendelse som medicoudstyr af WiFi-enabled apparat ¤ Kompatibilitet med 3. parts produkter og services ITOS 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 automatisk opdaterer firmware over Internettet, håndterer sameksistens af multiple apparater på samme netværk og desuden beror sig på 3. part software og apparater kræver et nyt tankesæt. Skriv tests før der udvikles noget 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 ENGINEE Testdrevet 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. Benyt tests kontinuerligt under hele udviklingsforløbet Det overordnede ønske hos GN ReSound er at erstatte den traditionelle dokumentdrevne process med en modelbaseret tilgang til Systems Engineering. Forventningen om, at høreapparater 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 metoder generelt resulterer i kortere Time-To-Market og bedre slutprodukter. Det udviklede koncept kaldes Test-Driven Models-Based System Engineering (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. FOTO: GN RESOUND A/S 65 ITOS TD-MBSE for modellering embedded systemer Obtain and specify behavioral or architectural requirement Model behavioral scenario or architectural test case Refine requirement Run new test case Tests pass Tests fails Execution traces Interactive simlation Create or modify system behavior / system architecture Some test(s) fails Run all behavioral & architectural test cases Alle tests pass Repeat Clean up model I casen har GN ReSound udviklet en metode til test-drevet udvikling af embedded systemer. Metoden er baseret på formel verifikation, så der er garanti for resultaterne. 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. Funktionelle krav modelleres som test cases udtrykt som tilstandsmaskiner. Andre krav udtrykkes som invarianter og andre ”queries”, 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 modelelementer i systemet, der skal til for at passere 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 efter en metode, som GN ReSound kalder Test-Driven Design Space Exploration (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, benyttes såkaldt Property Estimation og Property Simulation. Når udfaldsrummet er identificeret vælges nogle værdier, hvorefter løsningerne udsættes for formel og statistisk verifikation for vurdere effekten på funktionalitet og performance. Metoden er illustreret i figur 22. I praksis er TD-MBSE og TD-DSE metoderne 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 kapacitet, mens den anden sikrede den hurtigste turn-around tid på et kritisk scenarie. Begge løsninger levede op til kravene. FIGUR 22 TD-MBSE for modellering embedded systemer Den udviklede metode egner sig bedst til relativt små systemer, da det valgte 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 systemer, der er karakteriseret af bland andet omfattende og kompleks udveksling 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. 66 ITOS FIGURE 23 Test-drevet Design Space Exploration Test-drevet Design Space Exploration Base Design TD-BMBSE Alternative Designs Formal Verfication Otaining Estimates Property Estimations Property Simulations Functionality Impact Performance Impact TD-MBSE Forsker: Thomas Pedersen, Phd. stip., AAU 8.2 SELUXIT – DET AUTONOME HUS Køber man 10 forskellige ‘smart home’ produkter lavet af forskellige producenter, følger der med stor sandsynlighed 10 forskellige apps med. Det gør i sidste ende livet mere vanskeligt for forbrugeren end tilsigtet. Forbrugeren ønsker et orkestreret system, hvor man ikke alene har en central brugergræ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. Til 10 forskellige ‘smart home’ produkter, følger der med stor sandsynlighed 10 forskellige apps Seluxit, der bl.a. udvikler home automation løsninger på vegne af sine erhvervskunder, er i høj grad optaget af præcis denne problemstilling og mulighed, og gør brug af sofistikerede modelleringsmetoder, for at sikre opbygning 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 problemstillinger og muligheder til en række brugsscenarier. INDBRUDSALARMEN OG KLIMASYSTEMET Det 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 indsamlet fra sensorer i ejendommen. Der kan også forventes, at et alarmsystem 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 alarmsystemet er aktivt. Kort sagt kan det forventes, at alarmsystemet har en kvalitet og en konsistens som gør, at det kan beskrives som velfungerende. 67 ITOS Men hvad sker der hvis man introducerer et klimasystem til det overordnede home automation system, velfungerende for sin vis, der har automatisk åbning af vinduer som feature med det formål at regulere luftkvalitet? Alarmen 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å klimasystemet. 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 kunne identificere hvor der er en konflikt, og ideelt selv være i stand til at skabe en løsning. Det vil være upraktisk og omkostningsfuld at prøve sig frem under selve implementeringen/integrationen af systemer, især i takt med at antallet og kompleksitet af feature interaktioner øges. I stedet, er det ønskeligt at modellere det overordnede home automation system for at identificere konfliktområder såvel som muligheder for gavnlige interaktioner, inden der integreres. For at kunne identificere og gøre muligt at håndtere disse konflikter og mulighederne for gavnligt forøgelse af systemet, kræves der to ting: modellering og tilhørende verificeringsanalyse, som vil beskrive den forventede optræden af systemet, og at rammesystemet er i stand til at tilpasse sig baseret 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 MODELVERIFICERING Der er mange mulige måder, hvorpå man kan modellere og verificere den forventede virkning af et home automation system. Det indledende modelleringsarbejde 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 disse aspekter for hver enhed og miljømæssig påvirkning. Der er mange mulige måder, at modellere og verificere den forventede virkning af et home automation system 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øleskabet 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 temperaturindstillingsvæ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 problemområder og synergieffekter, og dermed være tilstrækkeligt for mindre krævende opgaver. Med en formel matematisk modelverificering herfra vil sikre, 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- 68 ITOS ler. For Seluxit, sker identificering af potentielle problemområder i systemintegration igennem et tæt samarbejde med Aalborg Universitet og brug af metoder og værktøjer delvist udviklet af Aalborg Universitet. Aalborg Universitet har i samarbejde med Uppsala Universitet udviklet et redskab, der hedder UPPAAL, som bruges til at verificere modeller. De formelle modeller, der bruges for at beskrive bl.a. home automation er såkaldte timed automata. Timed automata er en formel fremstilling i familien af såkaldte finite state machines eller tilstandsmaskiner. De var konceptualiseret igennem automata 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 studier 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 timed 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 relativ 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 tilstanden ‘off’. FIGUR 24 Lamp Controller Kilde: Thomas Pedersen et al Timed automata som illustreret i dette enkle eksempel kan også anvendes til at beskrive vores aktuelle scenarie med alarmsystem og klimasystem. Oplysningerne 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. 69 ITOS FRA ABSTRAKTION TIL HANDLING Seluxit har en platform som kan iværksætte handlinger baseret på indstillinger 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 systemets hjerne og fortolker, hvis der er tale om forskellige leverandører med hver deres applikation og evt. kommunikation protokol. I bedste fald vil enheder kunne snakke direkte sammen, såfremt enhederne udvikles i samspil med Seluxit for at tage fuld udnytte platformens funktionalitet. Seluxit arbejder aktivt som nøglespiller med at drive nye standarder som understøtter deres vision af dynamisk konfigurerbare enheder som kan interageres på meningsfuld vis. Seluxits teknologi er speciel fordi det tilvejebringer et abstraktionslag hvormed eksekverbare tilstandsmaskiner og timers i et Seluxit home automation system bekvemt kan være oversat fra de formelle UPPAAL timed automata modeller. Ud over modelverificering, åbner det også op for muligheden 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ørger for kontaktfladen mellem nerveceller. Tilbage til vores eksempel med klimasystemets automatiske vinduesåbning, der udløser alarmen, har vi set, at brug af modeller kan forudse potentielle problemer som en systemudvikler kan agere på, gjort muligt igennem 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 problemer automatisk, og med en passende brugerinteraktion. Derudover er det ønskeligt, at systemet selv kan identificere situationer, hvor operationer kan optimeres og egentlige valg træffes, såsom områder hvor anvendelse af dublerede af funktioner optimeres (f.eks at vælge mellem flere enheder 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 systemet syntetiserer koden, som gør det til virkelighed. Med Seluxits IoT platform sammen med verificering fra UPPAAL er mekanismer på plads. Men det er stadigt et åbent spørgsmål, om der kan adopteres en standard indenfor home automation og generelt indenfor IoT, som vil kunne gøre banen klar for denne slags effektivisering og orkestrering i systemopbyggelse, i overensstemmelse med brugerens ønsker og krav, som velbyggede autonome 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 systemer. ” 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 70 ITOS Forsker: Sune Wolff erhvervs-post doc., AU 8.3 TERMA – BESKYTTELSE AF KRITISK INFRASTRUKTUR Angrebene på World Trade Center og Pentagon i 2001 og efterfølgende terrorhandlinger, har øget fokus på beskyttelsen af den kritiske infrastruktur, som er en af hjørnestenene i et moderne vestligt samfund. Lufthavne, broer, kraftværker og kommunikationskanaler spiller en utrolig vigtig rolle – skulle bare én af disse blive sat ud af drift, vil det have alvorlige konsekvenser på tværs af andre sektorer og påvirke byer, landsdele eller hele lande. Angrebene på World Trade Center og Pentagon i 2001 og efterfølgende terrorhandlinger, har øget fokus på beskyttelsen af den kritiske infrastruktur Terma så muligheden for at anvende sine eksisterende produkter på et nyt marked for overvågning af kritisk infrastruktur. Eksisterende overvågningssystemer bliver typisk opereret manuelt og har fokus på at overvåge perimeteren 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 automatisk kamera kontrol, der mindsker behovet for manuel styring, og sænker 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 identificere 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 eksempel 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 udsteder 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 fylder 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 bagvedliggende menneskelige beslutningsprocess og den tankevirksomhed, der ligger 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 processorkraft 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 71 ITOS PERSON Maximalt zoom kameraet kan foretage hvis hele radarens usikkerhed skal være indenfor kameraets synsfelt. RADAR KAMERA FIGUR 25 bliver visualiseret som en ellipse i det følgende. Samlet set fortæller radaren dens bedste estimat af hvor personen er, samt et område (ellipsen) indenfor hvilken den er 99% sikker på at personen befinder sig. Den radar der benyttes i T.react CIP er en lille og forholdsvis billig landbaseret 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å personen 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 bibeholde hele usikkerhedsellipsen inden for dens synsfelt. Som det ses i figur 25 er radaren langt mere usikker omkring personens position i vinkeludbredelse end den er i afstand – det ses på den meget langstrakte 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 INTUITION For at opnå en højere præcision i systemets estimat af personers position kombineres estimaterne fra individuelle radarer – en såkaldt sensor-fusion. Denne teknik sikrer at usikkerheder fra individuelle sensorer reduceres samlet set – dette er vist i figur 26. 72 ITOS PERSON RADAR 2 Ved at kombinere estimaterne fra to radarer kan man opnå et meget mere præcist estimat af hvor en person er – og derved kunne zoome længere ind på personen. KAMERA RADAR 1 FIGUR 26 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 forskel i usikkerhed i vinkeludbredelse og afstand fra de to radarer. Resultatet 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 modeller af systemets opførsel og usikkerheder. I dette tilfælde er der tale om fusion af radareres egne usikkerheder ved hjælp af overskuelige trigonometriske betragtninger. Teorien bag den anvendte sensor-fusion er baseret på matematiske modeller af systemets opførsel og usikkerheder SIMULERING AF DEN NYE TEKNOLOGI For Terma var sensor-fusion teknologien et uprøvet kapitel i et overvågningssystem, og udviklerne på dette projekt havde kun begrænset erfaring med sensor-fusion baseret på kombinationen af Gausiske multivariate eller 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 abstrahere 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 zoner, regler og en masse andre af de ting, der gør T.react CIP til et smart produkt. 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 simulere 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 73 ITOS det muligt at anvende rigtig data optaget fra radarerne i modellen, for derved 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 kunne 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 funktionaliteten samt interfacet til radarerne). 8.4 MAN DIESEL & TURBO – MERE RENE OG EFFEKTIVE DIESELMOTORER Forsker: Nicolai Pedersen Phd. stip., DTU MAN Diesel & Turbo står overfor tekniske udfordringer med nye krav fra kunder og lovgivning om øget effektivitet, mindre forurening og understøttelse af alternative brændstoffer. Løsningen medfører et stigende antallet distribuerede kontrol enheder og supplerende systemer. Udviklingen af disse nye systemer kræver omfattende viden og indsigt i sammen spillet mellem hver af de distribuerede enheder og det fysiske system, en to takts diesel motor. Modellering og simulering er afgørende værktøjer for at kunne udvikle optimalt stabile og pålidelige kontrol systemer, samt at estimere performance og udvælge en korrekt udlægning af motoren. Tidligere har simplificeret modeller af kontrol systemets påvirkning på motor dynamikken været tilstrækkelige, under performance simuleringer, og forenklede termodynamiske modeller af motoren blevet brugt til udvikling af kontrol algoritmer. Med nye systemer som EGR (Exhaust Gas Recirculation), SCR (Selective catalytic reduction) og Tacho over ethernet, er kravene til kontrol softwaren og udlægningen af fysiske komponenter mere kompliceret, og gabet mellem kontrol modellering og de fysiske modeller blevet mindre. Der er derfor brug for bedre simulerings miljøer, der kan forbinde kontrol softwaren med termodynamikken samt netværket der forbinder enheder. Modellering og simulering er afgørende værktøjer for at kunne udvikle optimalt stabile og pålidelige kontrol systemer Især for de tids kritiske dele af motor reguleringen (f.eks Indsprøjtnings timing) er netværket vigtigt. Enhver dynamisk forstyrrelse fra undersystemer kan divergere og påvirke andre enheder. Det er derfor vigtigt at kunne estimere, 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 variere i både sprog, solvere og tids opfattelser. Det er derfor ikke trivielt at kombinere 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 simulering miljø, og man ønsker derfor et standardiseret framework for simulering, der kan kombinere solvere , koordinere tids eksekveringer og modellere 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 indlejrede kontrollere, bestående af et strøm modul, I/O kabinet DC/DC konverter 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 74 ITOS TEST & DEVELOPMENT Simulation Scenario: Algorithm verification Fault injection Temporal verification Design space exploration CYBER SCNSL Switch Model Bandwith Delay Protecols Priority XXX Control/ Interface Units Cylinder Control Unit Engine Control Unit Tacho Interface Unit PHYSICAL Different abstraction levels and Modeling environments Cylinder Model Crankshaft Model Thermodynamic Modelse FIGUR 27 på FPGA’en definere kontrol formålet. At have identisk hardware har mange 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-Physical 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 defineret og derved påvirker systemet. FMI er illustreret som det grå områ75 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ådighed for omverden. Når alle ind- og udgange er forbundet er det muligt at foretage deterministiske simuleringer. En deterministisk simulering er meget anvendelig til at verificere modeller, og fortage regressions test af pålidelige dele af systemet. For Cyber-Physical systemer, især realtids kontrol systemer har kommunikationen stor indflydelse. Netværks kommunikation er ofte LAN eller WAN baseret, hvor determinisme ikke er garanteret. Det kan medføre uhensigtsmæ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 systemopførsel verificeret gennem omfattende test på rigtige hardware. Selvom denne tilgang umiddelbart er tilstrækkeligt, er det ikke en særlig effektiv 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 netværksmodel introduceret, der tidligt i udviklingen, gør det muligt at simulere 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 optimale overhead på udregning enheder. SCNSL er blevet brugt til at lave netværks modellen, der forbinder kontrollerne. Med SCNSL er det nemt at implementere 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 softwaren med enhver abstraktion af motor model og det dertilhørende netværk. FUNCTIONAL MOCK-UP INTERFACE FMI er et standardiseret interface til at simulere dynamisk koblede problem 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 (CoSimulation), se figur 28. FIGUR 28 Co-Simulation Model Exchange FMU Executable SLAVE MASTER FMI Process Model MASTER Solver Solver Process 76 FMU Executable SLAVE FMI Model ITOS FIGUR 29 Engine Control Room EICU (Engine Interface Control Unit)) MOP (Main Operation Panal) Switch: Ethernet Cables IEEE 802.3, store-and-forwardswitching SCNSL Channel: adjustable bitrate and transmission delay Ethernet Switch 1 IEEE 802.1 D/P priority SCNSL Communicator: priority protecol ACU (Auxillary Control Unit) ECU (Engine Control Unit) SCNSL Node: Switch protocol design Ethernet Switch 2 CCU1 (Cylinder Control Unit) CCU2 SCNSL Node: Input/Output Controller Netword interupt: Packet recived (b_transport) TIU (Tacho Interface Unit) SCU (Scavenge Air Control Unit) CCU(n) Amount of CCU units corresponds to the amount of Cylinders (4-12) Engine Room 77 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 udveksle simulerings modeller mellem underleverandører og internt i udviklingen. FMI består i sin enkelthed blot af et XML-skema og tre c-header filer, 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 Netvæ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 78 ITOS ECS SW Shared Library Zip/Load FMU Wrapper FMI application functions XML Schema SCNSL: ECS Node ZIP Channel: Bitrate/Delay Inpul/Output Controller Network interrupt XML Parser Channel: Bitrate/Delay FMU Wrapper ECS SW Shared Library Zip/Load FMI application functions XML Schema Thread FMI Lib Thread Thread Simulation Manager FMI/SCNSL Channel: Bitrate/Delay Protocol/package design Channel: Bitrate/Delay DLL loader Thermodynamic FMU Wrapper Model Zip/Load FMI application Shared Library functions C++/DSE/MATLAB... XML Schema SCNSL: Switch Node SCNSL: ECS Node FMI App wrapper Channel: Bitrate/Delay FIGUR 30 SIMULERING MASTER Den samlede løsning med FMI og SCNSL kan ses på figur 30. Yderst til venstre 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 dedikeret 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åndtering af netværks modellen. Når en netværks Proxy er blevet opdateret arkiveres output kontrollen på SCNSL noden og sende gennem switch modellen til den relevante nodes input kontroller. Med denne opsætning er det mulig at simulere kontrol software sammen med enhver form for termodynamisk model og samtidig udforske netværkets indflydelse på eksekveringen. 79 Inpul/Output Controller Network interrupt ITOS REFERENCER Model-Driven Software Engineering in Practice, 2012 Marco Brambilla, Jordi Cabot & Manuel Wimmer ISBN: 978-1608458820 Objekt orienteret analyse og design, 2001 Lars 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 Cambridge ISBN: 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 objectives Robert Phaal, Clare Farrukh and David Probert Centre 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 80 Udgivet af DI ITEK H.C. Andersens Boulevard 18 1787 København V. Telefon 3377 3377 itek.di.dk [email protected] Redaktion slut 10.10.2015 Layout: fru nielsens tegnestue Tryk: Dystan & Rosenberg ISBN: 978-87-7144-065-2 500.10.15 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 finder du løsninger, konkrete råd og vejleding. Du bliver guidet gennem de første trin og får anvisninger til, hvor du kan finde 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. FIE LD BOOK - UDV IK LING A F E MBEDDED SYSTEMER & SMARTE PRODUKTER I PR AKSIS ITOS FIELDBOOK UDVIKLING AF & EMBEDDED SYSTEMER SMARTE PRODUKTER I PRAKSIS Lav din virksomheds eget roadmap IT S IT S
© Copyright 2024