Et produkt, der står ude hos kunder, skal kunne rettes. Kan det kun ske ved at nogen kører ud til hver enkelt enhed, bliver enhver rettelse til en udkørsel, og enhver sikkerhedsopdatering bliver udskudt til det passer ind i kalenderen.
KitOS er det grundlag, vi har bygget for at slippe for det. Det er et embedded Linux-system med containere ovenpå, som håndterer provisionering af enheder, afvikling af software og fjernstyret opdatering, så en enhed i drift kan få ny funktionalitet uden at nogen skal ud og røre den. Vi bruger det både som analyseværktøj i udviklingsforløb og som driftsgrundlag i kundernes produkter.
Genkender I noget af det her?
Så findes der en måde at gøre det på, som mange ikke ved eksisterer. Her er forskellen, når en rettelse skal ud til enheder der står ude hos kunder.
Sådan gør de fleste
Resultatet: opdateringer bliver udskudt
Sådan kan det gøres
Resultatet: opdatering er en rutine
Det er ikke et spørgsmål om at have dygtige folk. Det er et spørgsmål om grundlaget under produktet. Kan en enhed ikke opdateres på afstand, bliver enhver rettelse til en udkørsel, og enhver sikkerhedsopdatering udskudt.
Derfor findes det
En industriel løsning består af meget mere end den funktion, brugeren møder. Under brugerfladen ligger operativsystem, drivere, protokoller, databehandling, netværk, sikkerhed, opdateringer og overvågning. Skal alle de lag bygges forfra i hvert projekt, vokser både omfanget og risikoen hurtigt.
KitOS samler dem. Det betyder at vi ikke skal udvikle provisionering, applikationsdrift, datakommunikation, netværksstyring og opdateringsmekanismer forfra, hver gang vi går i gang.
Vi kan i stedet koncentrere udviklingen om det, der gør netop jeres løsning særlig. Det forkorter vejen, sænker den tekniske risiko og gør projektet billigere, end hvis grundlaget skulle bygges med.
KitOS er ikke en standardløsning, som opgaven skal presses ned i. Det er et fundament, vi konfigurerer og bygger videre på, hvad enten det ender som en kompakt styreenhed med HMI, en industriel gateway, lokal databehandling eller en løsning fordelt på flere enheder.
Grundlaget under produktet
Kernen er at software på en embedded enhed pakkes som versionerede containere. Det betyder at en opdatering kan sendes ud til enheder der allerede kører, at det er entydigt hvilken version der sidder hvor, og at man kan rulle tilbage hvis noget ikke opfører sig som forventet.
Applikationerne er adskilt, men taler sammen. Hver applikation kører i sin egen container og er isoleret fra de øvrige, så en ændring ét sted ikke behøver at påvirke resten. Samtidig publicerer de data på en intern databus og abonnerer på hinandens. På NORDIC er det tre applikationer på samme bus: to henter data fra hver sit måleudstyr, og en tredje omsætter det til et webbaseret HMI. Ingen af dem kender de andre.
Realtid ligger i kernen. Linux-kernen er kompileret med realtidsfunktioner, så tidskritiske processer kan prioriteres og systemet reagere forudsigeligt. Realtid er dermed ikke et spørgsmål om hvor hurtigt en brugerflade opdaterer, men en egenskab i fundamentet under applikationerne. De konkrete krav til latency og determinisme dimensioneres til den enkelte løsning.
Rækkevidden i snitflader er Linux egen. Har kernen en driver, kan vi bruge den, og det gælder fieldbus, PLC, HMI, Modbus, CAN, SDR og RF, GPIO og en del mere. Bruger udstyret proprietære eller udokumenterede protokoller, udvikler vi selv integrationen. Det betyder at velfungerende udstyr ikke nødvendigvis skal udskiftes for at komme med i et nyt system.
Nederst de snitflader, Linux har drivere til, altså fieldbus, PLC, Modbus, CAN og en del mere. Derover KitOS med provisionering, containere, opdatering og netværk, plus KitFleet til at se flåden. Øverst de to måder vi bruger det på: til analyse og til drift. Det er det samme grundlag begge steder.
To slags opdateringer
Applikationen skiftes ved at rulle en ny container ud. Det kan ske ofte, det kræver ingen genstart, og der kan rulles tilbage til den forrige version.
Systemet skiftes sjældnere og på en anden måde. Enheden har to partitioner, og den nye version skrives til den, enheden ikke kører på. Derefter genstarter enheden over på den. Virker den ikke, starter enheden tilbage på den forrige. En fejlet opdatering efterlader altså ikke en død enhed.
Begge dele er signeret. Enheden tager kun imod software, der er signeret af os.
Enheden har to partitioner. Den nye version skrives til den, enheden ikke kører på. Derefter genstarter den over på den nye. Virker den ikke, starter enheden tilbage på den forrige af sig selv. Der er altså altid en vej tilbage, og ingen skal køre ud for at finde den.
Lukket udefra, styret indefra og ud
Kun de porte, en container udtrykkeligt åbner, kan nås direkte. Angrebsfladen er dermed præcis det, I selv har valgt at åbne i jeres egen applikation, og ikke mere.
Styringen går den modsatte vej af hvad man skulle tro. Enheden åbner selv en krypteret forbindelse udad til vores centrale driftsopsætning, og containere, netværk og opdateringer løber retur i den samme forbindelse. Der skal ikke åbnes porte ind mod enheden, og jeres firewall skal ikke laves om.
Fjernlogin, administrationsflader og portscanning bliver afvist, fordi der ikke er noget at nå. Det eneste, der kan nås direkte på enheden, er en port I selv har åbnet i jeres egen container. Angrebsfladen er dermed præcis så stor, som I har valgt at gøre den.
Enheden åbner selv forbindelsen udad til vores gateway, og styringen løber retur i den samme forbindelse. KitFleet og jeres egne folk kommer ind den vej. Der skal ikke åbnes porte ind mod enheden, og jeres firewall skal ikke laves om.
Enheden kører videre uforstyrret, hvis forbindelsen til centralen ryger. Lokal databehandling og styring afhænger ikke af en permanent forbindelse. Det, der venter, er styring og opdatering.
Skal flere enheder indgå i den samme løsning, kan databussen brokobles mellem dem gennem en indbygget Pub/Sub-bro. Det er samme mekanisme som inde i den enkelte enhed, bare strakt ud over flere. Derfra kan enheder konfigureres i en failover-topologi, hvor funktioner overtages et andet sted, hvis en enhed falder ud.
Den centrale opsætning består af flere redundante hubs, og kunder med særlige krav til driften kan aftale at køre deres egen kopi af gatewayen. Gatewayen har et defineret API, så administrationen kan lægges ind i de systemer, I allerede bruger, i stedet for kun at ligge i vores.
I drift hos kunder
KitOS ligger under blandt andet:
Det er den samme platform under en offshorerig, et screeningsapparat hos optikere, et læringssystem i folkeskolen, en eventinstallation og tre kommunale sensorsystemer. Det er ikke otte løsninger, der ligner hinanden. Det er otte steder, hvor det samme driftsgrundlag holder.
Et embedded produkt lever i årevis, ofte på steder hvor et servicebesøg er dyrt eller upraktisk. Det er en del af grunden til at vi kan blive på et projekt i mange år. Læs mere om service, drift og support, eller om vores arbejde med IoT og sensorsystemer og dataløsninger og kommunikation i realtid.
KitOS giver typisk mening, når en løsning skal:
KitOS kan følge en løsning fra den første prototype hele vejen til drift, hosting og videreudvikling, og kan leveres både som del af et projekt og som selvstændigt værktøj. Der følger dokumentation, vejledning og support med.
Kontakt os
Daniel Frederiksen
CTO | Teknisk direktør