Få succes med at udvikle IoT-produkter i prædefinerede IoT-økosystemer

Af Jeppe Pilgaard Bjerre

I en verden hvor antallet af IoT-produkter er i eksplosiv vækst, er det vigtigt, at man som produktudvikler vælger komponenter, der har den rette funktionalitet, til ens IoT-produkt. Desuden skal man være forvisset om, at ens IoT-løsning kan fungere sammen med eksisterende IoT-systemer.

Udvikling af IoT-produkter indebær en række udfordringer for både teknikken, processen og økonomien. Risikoen for forsinkelser og ekstraudgifter i produktudviklingen er bestemt tilstede. Derfor er det vigtig, at man allerede i designfasen af en IoT-løsning baserer den på afprøvede og testede metoder, så man ved, at produktet fungerer optimalt, når det rulles ud.

Kravspecifikationen er et centralt redskab

I udviklingsprocessen er kravsspecifikationen nok det vigtigste redskab. Hos FORCE Technology ser vi en lang række produkter, der fejler i godkendelsesforløbet. Ofte skyldes det fejl og mangler i kravsspecifikationen, fx krav der er misforstået i udviklingsforløbet, eller krav der ikke er defineret i kravspecifikationen.

Men hvordan sikrer man, at man får alle de vigtige krav med i kravspecifikationen?

Brug standarder til at definere nye IoT-produkter

Man kan opnå en systematisk gennemgang af funktionelle krav og interoperabilitetskrav til et IoT-produkt ved at bruge standarder, fx ISO/IEC 30141 Internet of Things – Reference Architecture, til af definere nye IoT-produkter. Standarden indeholder værktøjer til at definere elementer så som sensortyper, identifikation, brugere, og standarden er opdelt i domæner som funktionalitet, kommunikation og brug.

Ved at benytte en standard til at definere nye produkter sikrer man også, at alle involverede ’taler samme sprog’. Derved mindskes risici for misforståelser i fortolkningen af krav.

Prototypen skal fungere i realistisk brugsmiljø

Når man udruller et nyt IoT-produkt som et delelement ind i et IoT-økosystem, skal man være sikker på, at det performer korrekt. Selv om prototypen har opfyldt kravene, vil udrulningen betyde introduktion af nye variable, såsom installationsmiljø og co-eksistens, som i værste tilfælde kan have en så dramatisk forringelse af performance, at produktet er helt ubrugeligt. Derfor er det vigtigt at lave en test af IoT-produktet, der afspejler et realistisk brugsscenarie.

Hvilket miljø skal IoT-produktet installeres i?

Laver man trådløse systemer, er det fx vigtigt at overveje hvor stor margin, der er behov for i et linkbudget, da der er stor forskel på dæmpning for et system, der sidder på et hustag, og et system der sidder i en kælder i et industrielt miljø.

Desuden bør man opstille krav til produktets modstandsdygtighed overfor klimatiske påvirkninger (fx temperatur og fugt) i hele produktets levetid.

Ændres scoopet eller funktionaliteten i IoT-produktet undervejs i udviklingsprocessen, skal man huske at revurdere, hvad det betyder for pålidelighedskravene.

Hvordan skal data håndteres?

Når man opbygger et IoT-netværk med mange - måske flere tusinde - enheder, kan der potentielt genereres enorme mængder data. Derfor bør man udarbejde veldefinerede metoder for datalagring i systemet, hvordan data tilgås fra egne systemer, samt for hvordan man kan åbne op for, at andre systemer kan tilgå de data, som ens system generer, så solide og sikre data-infrastrukturer opbygges.

Fælles forståelse betaler sig

Helt generelt er udvikling af IoT-produkter en øvelse i samarbejde på tværs af discipliner, organisationer og brancher. Det er kritisk at kunne kommunikere dele af et IoT-system, så man sammen opnår en fælles forståelse og forventning til, hvad man er ved at udvikle. Så resultatet modsvarer det ønskede, og man undgår at skulle lave om i designet, fordi et krav blev glemt eller misforstået.

Omkostningerne forbundet med at ændre et produkt i testfasen er op mod 1000 gange dyrere end ved kravspecificeringen. Konsekvensen kan være, at et projekt helt skal kasseres, fordi det ikke kan betale sig at lave et nyt design. Derfor kan det godt betale sig at bruge ressourcer på at få lavet en god og gennemarbejdet kravspecifikation tidligt i udviklingsforløbet.


Ovenstående er et uddrag af en artikel bragt i Elektronik & Data, august 2019.