Harsh Joshi
Co-founder & Technical Director
En praktisk ramme til vurdering af en outsourcingpartner inden for udvikling af indlejrede systemer og IoT, der omfatter hardware, firmware, tilslutningsmuligheder, sikkerhed, certificering og beskyttelse af immaterielle rettigheder.
En hardware-iværksætter med en fungerende prototype og en produktionsfrist står over for ét afgørende spørgsmål, inden han underskriver en udviklingskontrakt: Kan dette team rent faktisk føre et forbundet produkt fra et eksperimentbræt til en certificeret enhed, der er klar til levering? En ingeniørchef, der skal integrere IoT-sensorer i en eksisterende maskine, stiller sig en mere afgrænset version af det samme spørgsmål, nemlig om partneren har forståelse for både den fysiske hardware og den cloud-platform, som dataene i sidste ende ender på.
Udvikling af indlejrede systemer og IoT befinder sig i krydsfeltet mellem flere tekniske discipliner på én gang: hardwaredesign, firmware, trådløs forbindelse, cloud-infrastruktur og ofte mekanisk indkapsling. At vurdere en partner til denne type arbejde indebærer at kontrollere, om der er reel, verificerbar ekspertise på tværs af hele denne stack – ikke blot en portefølje af logoer. Denne guide gennemgår, hvad udvikling af indlejrede systemer og IoT egentlig indebærer, de specifikke kriterier, der adskiller en kompetent partner fra en risikabel, samt de spørgsmål, det er værd at stille, inden man forpligter sig til at afsætte et budget og en produktkøreplan til et eksternt team. Monarch Innovation samarbejder med hardware- og produktteams på tværs af netop denne type tværfaglig ingeniørarbejde, hvilket er det perspektiv, denne guide er bygget op omkring.
Hvad udvikling af indlejrede systemer og IoT egentlig omfatter
Udvikling af indlejrede systemer indebærer at designe og programmere den software, der kører direkte på et stykke hardware og styrer, hvordan en enhed registrerer, behandler og reagerer i realtid. Det adskiller sig fra almindelig applikationsudvikling, fordi det skal fungere inden for faste begrænsninger med hensyn til hukommelse, strømforbrug og processorkraft, og fordi fejl kan påvirke den fysiske adfærd i stedet for blot at vise sig på en skærm.
IoT-udvikling udvider netop dette indlejrede arbejde udad ved at forbinde en enhed til et netværk, så den kan sende data til skyen, modtage kommandoer og interagere med andre systemer. Et komplet IoT-produkt består typisk af fire lag: selve hardwaren, den firmware, der kører på den, forbindelseslaget, der sender data til og fra enheden, samt skyen eller backend-platformen, der lagrer, behandler og viser disse data.
En partner, der er stærk inden for ét område, er ikke automatisk stærk inden for alle fire. Mange virksomheder, der udvikler indlejret software, skriver fremragende firmware, men udliciterer hardwareudviklingen til andre, og mange cloud-fokuserede IoT-leverandører har overhovedet kun begrænset intern hardwareekspertise. Monarch Innovations produktudviklingsydelser dækker hardware- og elektrisk design, indlejrede systemer og IoT-udvikling som sammenhængende discipliner snarere end separate opgaver, hvilket er en af de første ting, det er værd at undersøge hos enhver partner, du vurderer.
Hvorfor virksomheder outsourcer udvikling af indlejrede systemer og IoT
En række tilbagevendende udfordringer får hardware- og produktteams til at vælge en ekstern udviklingspartner frem for at udvikle hvert enkelt lag internt.
- Tværfaglige kompetencegab: Et »software-first«-team, der udvikler et forbundet produkt, har ofte stærke kompetencer inden for firmware eller cloud, men ingen intern erfaring med hardware eller PCB-design, og det omvendte er lige så almindeligt for »hardware-first«-teams.
- Specialiseret, kortvarig ekspertise: Et enkelt produkt kan kræve en specifik trådløs protokol, en bestemt mikrocontrollerfamilie eller en certificeringsproces, som det interne team aldrig har arbejdet med før og ikke vil få brug for igen i årevis.
- Hurtig implementering: Det kan tage længere tid at ansætte og opbygge et komplet team med ekspertise inden for indlejrede systemer og IoT internt, end produktkøreplanen tillader, især når hardware og firmware skal udvikles sideløbende.
- Krav til certificering og overholdelse af standarder: For at få en tilsluttet enhed godkendt gennem FCC-, CE- eller UL-test kræves det, at designbeslutninger træffes tidligt i forløbet, og en partner, der har været igennem denne proces før, kan undgå dyre omdesigninger sent i projektforløbet.
Ulempen er, at det er sværere at afvikle projekter inden for indlejret software og IoT end ved almindelig software-outsourcing. En firmware-kodebase, der er bundet til specifik hardware, eller en cloud-arkitektur, der er bygget op omkring en partners standarder, kan være dyr at overdrage til et andet team, hvis det første ikke fungerer. Derfor har valg af partner større betydning her end i mindre hardwareafhængigt udviklingsarbejde.
Hvad man skal kigge efter hos en udviklingspartner inden for indlejrede systemer og IoT
Når du ved, hvilke lag dit produkt har brug for, bør du vurdere en potentiel samarbejdspartner ud fra konkrete, målbare kriterier frem for et generelt indtryk fra en salgssamtale.
Tværfaglig dækning: Spørg direkte, om ingeniører inden for hardware, firmware, tilslutningsmuligheder og cloud arbejder sammen om det samme projekt, eller om de hyres ind som underleverandører hver for sig. Et team, der i fællesskab designer printkortet og skriver firmwaren, har en tendens til at opdage integrationsproblemer – f.eks. en sensor, der trækker mere strøm, end kortet er designet til – inden de når frem til en prototype.
Protokol og forbindelsesdybde: Sørg for, at partneren har konkret, navngiven erfaring med netop den trådløse teknologi, dit produkt kræver – uanset om det drejer sig om Bluetooth Low Energy til et batteridrevet bærbart produkt, LoRaWAN eller mobilnet til industrielle sensorer med lang rækkevidde eller Wi-Fi og Zigbee til smarthjem-enheder. Hver protokol indebærer forskellige afvejninger mellem strømforbrug, rækkevidde og omkostninger, og en partner bør kunne forklare, hvorfor én protokol passer bedre til din anvendelse end en anden, i stedet for blot at falde tilbage på det, de kender bedst.
Sikkerhedspraksis for forbundne enheder: Et forbundet produkt er også en endeenhed i netværket, og svag enhedssikkerhed kan udsætte en hel enhedspark for angreb. National Institute of Standards and Technology’s vejledning om cybersikkerhed inden for IoT skitserer de grundlæggende praksis, som producenter bør indarbejde i en enhed allerede fra designfasen, herunder sikker identifikation, databeskyttelse og opdateringsmekanismer. Spørg en potentiel partner, hvordan de håndterer sikker opstart, krypteret kommunikation og signering af trådløse opdateringer – ikke blot om de »tager sikkerhed alvorligt«.
Støtte til certificering og overholdelse af krav: Enheder, der sender radiosignaler, skal som regel have FCC-certificering i USA og CE-mærkning i Europa, og for mange produktkategorier kræves der desuden UL-sikkerhedstest. En partner med direkte erfaring inden for pre-compliance-test kan påpege designproblemer, såsom et problem med antenneplacering eller et uafskærmet højhastighedsspor, måneder før en kostbar certificeringsfejl ellers ville komme til syne.
Komponentindkøb og bevidsthed om udgåede komponenter: Leveringstider for halvledere og udgåede komponenter kan forsinke et hardwareprojekt længe efter, at selve designet er færdigt. En partner, der tager højde for komponenter fra alternative leverandører og realistiske leveringstider allerede under designfasen – og ikke først, når der opstår mangel – reducerer denne risiko betydeligt.
Erfaring med integration af cloud og backend: Hvis produktet kræver et dashboard, analyseværktøjer eller flådestyring, skal du sikre dig, at partneren har konkret erfaring med at forbinde indbyggede enheder til en cloud-platform, herunder konfiguration af enheder i stor skala og smidig håndtering af periodiske forbindelsesproblemer, i stedet for blot at udvikle enhedssiden og betragte cloud-delen som et problem, der skal løses af andre.
Bemandingsmodel og navngivne ingeniører: Spørg specifikt, hvem der skal arbejde på projektet, og om disse ingeniører forbliver tilknyttet projektet gennem alle faser – hardware, firmware og konnektivitet. Kontinuitet er vigtigere i indlejret udvikling end i de fleste softwareprojekter, da et skifte mellem ingeniører midt i projektet ofte betyder, at man skal lære både hardwarebegrænsningerne og firmwarearkitekturen forfra. Monarch Innovations tidligere vejledning om personaleudvidelse kontra et dedikeret ingeniørteam behandler dette spørgsmål om bemanding mere indgående for teams, der overvejer, hvilken model der passer bedst til et igangværende hardwareprogram.
Beskyttelse af intellektuel ejendomsret: Indlejrede produkter og IoT-produkter rummer ofte en reel konkurrencemæssig værdi i deres firmware og systemarkitektur. Spørg konkret, hvordan partneren håndterer ejerskabet til kildekoden, adgangskontrol og fortrolighed, og sørg for at få vilkårene for overdragelse af intellektuel ejendomsret på skrift, inden designarbejdet påbegyndes.
Dokumentation og overdragelsespraksis: Sørg for at få bekræftet, hvad du modtager ved projektets afslutning: skemaer, PCB-layoutfiler, firmware-kildekode med kommentarer, testrapporter og certificeringsdokumentation. En samarbejdspartner, der ikke klart kan beskrive sin overdragelsesproces, er en samarbejdspartner, som du senere kan få svært ved at bryde med, selvom selve det tekniske arbejde er i orden.
Tjekliste til evaluering af partnere inden for indlejrede systemer og IoT
| Evalueringsfaktor | Hvad man skal tjekke | Hvorfor det er vigtigt |
|---|---|---|
| Dækning af discipliner | Hardware, firmware, tilslutningsmuligheder og cloud i ét team | Mindsker integrationsfejl mellem lagene |
| Erfaring med protokollen | Projekter, der er opkaldt efter din specifikke trådløse teknologi | Bekræfter reel indsigt, ikke blot overfladisk kendskab |
| Sikkerhedspraksis | Sikker opstart, krypteret kommunikation, signering af OTA-opdateringer | Beskytter enheden og det større netværk, den er tilsluttet |
| Certificeringshistorik | Test forud for overensstemmelse med FCC-, CE- eller UL-krav | Undgår omprojekteringer i de sidste faser og overskredne lanceringsdatoer |
| Komponentstrategi | Planlægning med alternative leverandører, realistiske leveringstider | Mindsker risikoen for produktionsforsinkelser som følge af mangler |
| Cloud-integration | Konfiguration af enheder, flådestyring, håndtering af forbindelser | Bekræfter, at partneren dækker hele IoT-stakken |
| Kontinuitet i personalet | Navngivne ingeniører, der gennemfører hele programmet | Bevarer den tekniske kontekst gennem alle projektfaser |
| IP-beskyttelse | Ejerskab af kildekode, adgangskontrol, skriftlige vilkår | Bevarer produktets konkurrencefordel |
| Leverancer og overdragelse | Skemaer, firmware, testrapporter, dokumentationsformat | Gør det muligt at forlade partneren, hvis det bliver nødvendigt |
Spørgsmål, du bør stille, inden du underskriver en kontrakt
En kort og direkte række spørgsmål under evalueringen afdækker de fleste risici, inden de udvikler sig til et kontraktmæssigt problem.
- Hvilke konkrete ingeniører kommer til at arbejde med vores hardware, firmware og tilslutningsmuligheder, og vil de være tilknyttet projektet gennem hele programmet?
- Hvilke trådløse protokoller og cloud-platforme har du implementeret i produktion – ikke blot som prototyper?
- Hvordan håndterer I enhedssikkerheden, herunder sikker opstart, krypteret kommunikation og integriteten af OTA-opdateringer?
- Hvilke erfaringer har I med FCC-, CE- eller UL-certificering, og kan I give et eksempel på et lignende projekt?
- Hvordan tager man højde for leveringstider på komponenter og brug af alternative leverandører allerede under designfasen, og ikke først når der opstår en mangel?
- Hvilken kildekode, hvilke skemaer og hvilken dokumentation ejer vi, når projektet er afsluttet, og i hvilket format?
- Hvordan koordinerer man hardware-, firmware- og cloud-teams, hvis de ikke består af de samme personer?
- Kan du give eksempler på et produkt, der er nået til produktions- og certificeringsfasen, og ikke blot en fungerende prototype?
En partner, der besvarer disse spørgsmål med konkrete oplysninger i stedet for blot at give generelle forsikringer, er som regel det sikrere valg.
Almindelige fejl ved outsourcing af udvikling af indlejrede systemer og IoT
Der er en række mønstre, der går igen, når outsourcing af indlejrede systemer og IoT går galt. At opdele hardware og firmware mellem to uafhængige leverandører er et af de mest almindelige, da integrationsproblemerne først dukker op på et sent tidspunkt, og ingen af parterne tager det fulde ansvar for løsningen. At vælge en partner på baggrund af en overbevisende demonstration af en cloudplatform, mens man overser deres faktiske erfaring med hardware og certificering, er et andet mønster, især for produkter, hvor den fysiske enhed bærer størstedelen af den tekniske risiko. At udskyde en reel sikkerhedsdiskussion til efter, at designet er færdigt, medfører ofte dyre omarbejdninger, da sikker opstart og krypteret kommunikation er langt sværere at eftermontere end at indarbejde fra starten. At undervurdere tidsrammerne for certificering er en fjerde fejl, når en virksomhed antager, at FCC- eller CE-test er en afsluttende formalitet snarere end en proces, der bør præge designbeslutningerne måneder forinden. Endelig skaber det netop den slags afhængighedsproblem, som outsourcing netop skulle undgå, hvis ejerskabet til IP og overdragelsen af dokumentation forbliver udefineret indtil slutningen af samarbejdet.
Udvikling af et forbundet produkt med den rette tekniske partner
Udviklingen af indlejrede systemer og IoT står og falder i højere grad end de fleste andre former for outsourcing inden for ingeniørarbejde med styrken af den partner, der står bag. Arbejdet omfatter discipliner som hardware, firmware, konnektivitet og cloud, der sjældent findes samlet under ét tag, og et svagt led i blot én af disse discipliner kan forsinke et produkt længe efter, at kontrakten er underskrevet. Det er netop kontrollen af, om der er tale om ægte tværfaglig dækning, erfaring med sikkerhed og certificering, kendskab til indkøb af komponenter samt klare vilkår for IP og dokumentation, der adskiller en problemfri vej til produktion fra et program, der går i stå under testfasen.
Monarch Innovation støtter hardware- og produktteams inden for mekanisk design, hardware- og elektroteknik, indlejrede systemer og IoT-udvikling og fungerer som en samlet kontaktpunkt på tværs af discipliner, der ofte er fordelt på forskellige leverandører. Hvis du planlægger at udvikle et forbundet produkt og overvejer, om dit team internt har dækning for hele stakken, kan du kontakte Monarch Innovation for at drøfte dine krav til hardware, firmware og konnektivitet med vores ingeniørteam.
Tal med en ekspert i indlejrede systemer og IoT
Er du i gang med at udvikle et forbundet produkt og har brug for ekspertise inden for hardware, firmware eller cloud-integration? Kontakt Monarch Innovation for at drøfte dine behov inden for indlejrede systemer eller IoT-udvikling med vores ingeniørteam.
Ofte stillede spørgsmål
1. Hvad laver en udviklingspartner inden for indlejrede systemer og IoT egentlig?
En udviklingspartner inden for indlejrede systemer og IoT designer og udvikler hardware, firmware, tilslutningsmuligheder og ofte også cloud-integrationen bag et forbundet produkt. Dette kan omfatte et enkelt lag, såsom firmware til et eksisterende printkort, eller hele stakken fra printkortdesign til cloud-dashboards, afhængigt af hvad produktet og det interne team allerede har på plads.
2. Hvordan vurderer jeg en outsourcingpartner inden for indlejrede systemer?
Sørg for at undersøge, om der foreligger konkret, navngiven erfaring inden for de specifikke discipliner, som dit produkt kræver, herunder hardware, firmware, den nøjagtige trådløse protokol, der anvendes, samt cloud-integration, hvis det er relevant. Spørg ind til sikkerhedspraksis, certificeringshistorik hos FCC, CE eller UL, strategien for indkøb af komponenter, samt hvilken dokumentation og kildekode du modtager ved projektets afslutning.
3. Hvorfor er outsourcing inden for indlejret software og IoT mere risikabel end almindelig software-outsourcing?
Indlejrede produkter og IoT-produkter binder firmwaren tæt til specifik hardware, så det er sværere at udskifte en svag partner midt i et projekt end ved de fleste softwareopgaver. Certificeringskrav, leveringstider for komponenter og fysiske prototypecyklusser medfører desuden en risiko og omkostninger, som ikke findes ved ren softwarebaseret outsourcing.
4. Hvilke sikkerhedsstandarder gælder for udvikling af IoT-enheder?
Det Nationale Institut for Standarder og Teknologi (NIST) udgiver grundlæggende retningslinjer for cybersikkerhed til producenter af IoT-enheder, der omfatter praksis såsom sikker enhedsidentifikation, databeskyttelse og sikre opdateringsmekanismer. En kompetent udviklingspartner bør kunne forklare konkret, hvordan deres designproces tager højde for disse retningslinjer, i stedet for at behandle sikkerhed som en eftertanke.
5. Skal alle IoT-produkter have en FCC- eller CE-certificering?
De fleste enheder, der sender radiosignaler, skal have en FCC-certificering i USA og CE-mærkning i Europa, og mange produktkategorier kræver desuden en UL-sikkerhedstest. Kravene varierer afhængigt af enhedstype og målmarked, så det er en god idé at fastlægge den præcise certificeringsproces tidligt i designforløbet for at undgå, at der skal foretages ændringer i de senere faser.
6. Er det bedre at benytte én partner til hardware, firmware og cloud, eller at bruge separate specialister?
Når ét team har én partner, der dækker alle tre lag, mindskes der generelt antallet af integrationsfejl og gensidige beskyldninger, når noget ikke fungerer som forventet. Separate specialister kan stadig fungere godt, hvis virksomheden har et stærkt internt teknisk lederskab, der kan koordinere overdragelserne mellem dem, men denne koordineringsbyrde bør planlægges på forhånd i stedet for at blive opdaget midt i projektet.
7. Hvad bør jeg spørge om vedrørende intellektuel ejendomsret, inden jeg indgår et samarbejde med en partner inden for udvikling af indlejrede systemer?
Spørg direkte, hvordan partneren håndterer ejerskabet til kildekoden, adgangskontrol under udviklingen, og hvilke vilkår for overdragelse af immaterielle rettigheder der er fastsat i kontrakten. Sørg for at få disse vilkår nedfældet skriftligt, inden designarbejdet påbegyndes, da indlejrede produkter og IoT-produkter ofte rummer en betydelig konkurrencemæssig værdi i deres firmware og systemarkitektur.
