IoT og pålidelighed
Når man for mekaniske og elektroniske produkter taler om pålidelighed eller reliability, er der en tendens til, at det bliver sidestillet med termomekaniske påvirkninger og fejl relateret til aldring og slid på produkterne. Men hvilke nye fejltyper introduceres med Internet of Things (IoT), og hvad kan der gøres for at forebygge dem?
Der er et hav af forskellige klimatiske, termiske og mekaniske tests af elektronik. Disse er stadig centrale i forbindelse med pålideligheden af produkterne, og de er velkendte hos dem, der er specialister på området, men standarddefinerede tests er ikke længere altid tilstrækkelige til at sikre en pålidelig operation af produkterne. Efterhånden som IoT og dermed trådløs kommunikation bliver mere og mere udbredt, vil IoT-specifikke tests og reviews blive mere og mere relevante. Her har vi valgt at fokusere på et par af dem: Cybersikkerhed, kommunikation og delt ansvar.
Cybersikkerhed
Så sent som i oktober 2016 blev web services såsom Twitter og Spotify ofre for et Distributed Denial of Service angreb. Det er et angreb, som benytter mange enheder til at sende falske forespørgsler til en bestemt hjemmeside. Når denne så ikke længere har kapacitet til at håndtere så mange forespørgsler, oplever de rigtige brugere, at de ikke kan få kontakt til siden. Hvad har det så med IoT og pålidelighed at gøre? To ting:
- Angrebet stammede i en stor grad fra IoT-enheder: Dette kunne ske, fordi de var inficeret af et såkaldt botnet, malware som er designet til at overtage kontrollen med en enhed.
- Sådanne angreb kan også ramme IoT-devices: Når internettet bliver belastet, er det ikke sikkert, at selv vigtig kommunikation kommer igennem.
At så mange enheder kunne blive inficeret skyldes to meget basale sikkerhedsbrister. At der ikke bliver opdateret software på mange IoTdevices, så deres sikkerhedsbrister derfor er gamle, og at der ikke ændres fra default password til et stærkt password, når de bliver installeret. Ved at have botnets der ved hjælp af bruteforce/dictionary metoden ’gætter’ det rigtige password, er de i stand til at installere programmerne på IoT-enhederne. Da en sådan malware bruger ressourcer på enheden, kan den blive langsom ligesom en PC, der reagerer langsomt på en mus eller andet input og derfor ikke fungerer som tilsigtet og derved upålideligt. Den anden risiko er selvfølgelig, at angrebet sigter efter de IoT-enheder, der er godt beskyttet, så kommunikationen ikke kommer igennem. Derfor er det vigtigt, at man, selv når enheden er beskyttet, vurderer hvilke påvirkninger, dette kunne have på produktet. En måde at teste cybersikkerhed på er derfor at udsætte IoT-enhederne for denne type af angreb og sikre, at der er procedurer for password management og software opdatering hos slutbrugeren.
Kommunikation
En anden risiko for brugerens opfattelse af pålideligheden af produkterne er den trådløse dækning for enheden. Her er der også flere typer af fejl: Enkelt pakkefejl og vedvarende fejl. Her kan vi fx benytte en case fra IBIZ TechLab projektet. Her arbejdede FORCE Technology og andre GTS-institutter på den intelligente dør, hvor der ved hjælp af forskellige sensorer kan registreres, hvornår den enkelte kunde går ind og ud af døren i en given butik. Hvis vedkommende går ind, øges det registrerede antal i butikken med én, og hvis en kunde går ud reduceres det. Hvis der her benyttes ’event baseret’ kommunikation, altså at der sendes en besked til serveren, når en person går ind eller ud, vil det kræve, at alle beskeder fra sensoren til serveren går igennem, ellers kan det registrerede antal kunder blive mere og mere forkert, hver gang der mistes en transmission. For at sikre at en sådan afvigelse bliver korrigeret, kan man sende en pakke fx hver time til at korrigere for eventuelle tabte pakker. Da denne pakke ikke sendes så ofte som de andre, kan der fx være større sikkerhed i transmissionen ved at bruge en bedre fejlrettende kodning, bedre spreading faktor i den trådløse modulation, eller flere retransmissioner. Alt sammen noget der øger overhead for kommunikationen, så den tager længere tid. Derfor kan den ikke implementeres for hver eneste kunde, da det ville dræne batteriet og bruge for meget båndbredde, men der kan godt være råd til det hver time. Effekten er, at brugeren har en oplevelse af en forringet, men ikke upålidelig ydelse.Delt ansvar og brug
Dette er ikke direkte relateret til det enkelte produkt, men opstår af grundtanken bag IoT. Når en IoT-enhed kommer på nettet, vil den levere værdi til brugeren ved at fungere sammen med IoT-enheder fra andre producenter. Som eksempel kan man tage knappen Flic fra Shortcut labs og en Phillips Hue elpære. Disse to bliver lavet helt uafhængigt af hinanden, men hvis man har sat systemet op til det, vil et tryk på knappen gennem en website som IFTTT.com tænde pæren. Men hvad nu hvis det ikke virker? Hvem har produktansvaret? Hvem skal yde support? Hvem skal beskrive, hvor længe man skal vente på, at pæren tænder, efter man har trykket? 100 millisekunder, 1 sekund, 1 time?Samtidig skal man være opmærksom på at det ikke længere er åbenlyst, hvilken applikation en IoT-enhed bliver anvendt til. For eksempel: Hvis vi anvender knappen til at styre en elpære i en bolig, vil den skulle opfylde ’residential’ krav til immunitet på 3 V/m i en indstrålet immunitetstest. Men hvis vi bruger knappen som nødstop til en stor maskine eller til at aktivere en brandalarm, skal man i stedet teste efter EN 50130-4, og denne kræver et testniveau på 10 V/m. Derved vil det være ulovligt at benytte knappen til brandalarmbrug, hvis den kun er testet til 3 V/m. Udfordringen er, at det kræver, at producenten af knappen derfor gør klart opmærksom på, i hvilke applikationer man ikke må bruge denne device, og hvilke enheder man må forbinde den til.