Hvorfor forstå hele stacken?

Lad os være ærlige: De fleste taler om AI som noget, der bor i skyen eller i en smart app. Men sandheden er, at hvis du ikke forstår, hvordan hardware og software spiller sammen – helt nede fra silicium og op til brugerens skærm – så risikerer du at bygge systemer, der fejler på de mest uforudsigelige måder. Vi har set et AI-kamera, der gik i sort, fordi et lille stykke firmware ikke kunne håndtere en ny sensor. Det lyder banalt, men det kostede en kunde to ugers nedetid. Det er ikke kun udviklernes problem. Alle, der arbejder med AI, embedded eller større it-projekter, bør kende hele stacken. Ellers famler man i blinde, når noget går galt.

Overblik: Stackens lag – fra SoC til OS

Forestil dig stacken som et lagkagediagram (vi har faktisk tegnet det på en serviet i kantinen, men den blev væk): Nederst har du SoC’en – selve siliciumet. Ovenpå ligger firmware, så device drivers, kernel og til sidst operativsystemet. Hvert lag har sit eget sprog og sine egne fejlmuligheder. Hvis ét lag fejler, kan det hele vælte. Det lyder simpelt, men vi har set selv erfarne teams overse et lag og bruge dage på fejlfinding, der kunne være undgået.

SoC og hardware: Hvad sker der på silicium-niveau?

System-on-Chip (SoC) er hjertet i moderne hardware. Her finder du CPU, GPU, AI-acceleratorer og ofte en række specialiserede enheder. På edge-enheder – fx et AI-kamera eller en IoT-sensor – er det typisk en ARM-baseret SoC med integreret NPU (Neural Processing Unit). Vi så for nylig en edge-enhed fra NVIDIA Jetson-serien, hvor AI-inferens kørte direkte på NPU’en. Det gav 10x hastighed ift. CPU, men kun fordi softwaren var optimeret til at udnytte hardware-accelerationen. Hvis du ikke forstår, hvordan din kode rammer hardwaren, risikerer du at spilde både strøm og performance.

Firmware: Broen fra hardware til software

Firmware er det første softwarelag, der kører, når enheden starter. Det initialiserer hardware, loader drivers og sætter grundlæggende parametre. Tænk på firmware som den, der vækker resten af systemet. Vi har set firmware, der ikke kunne håndtere en ny RAM-type – resultatet var, at hele systemet frøs. Her er et forsimplet flow:

• Power on
• Firmware loader hardware-parametre
• Initialiserer SoC og periferi
• Overdrager kontrol til bootloader/OS

Hvis du vil nørde, så kig på open source-projekter som U-Boot eller Zephyr RTOS’ bootsekvens. Det er overraskende pædagogisk skrevet – selv Anders og Louise i vores netværk blev glade for at se, hvor konkret det faktisk er.

Device drivers: Oversætteren mellem OS og hardware

Device drivers er de små stykker kode, der får operativsystemet til at forstå, hvordan det skal tale med hardware. De er kritiske for både performance og stabilitet. Vi har arbejdet med et AI-acceleratorkort, hvor driveren ikke kunne håndtere concurrent access – resultatet var tilfældige crashes under tung AI-belastning. Et klassisk eksempel: En driver til et kamera skal kunne håndtere både billeddata og styring af autofokus. Hvis driveren fejler, får du enten ingen billede eller ustabil drift. Det er ikke bare irriterende – det kan være fatalt i kritiske systemer.

Kernel: Kernen i systemet

Kernen (kernel) styrer ressourcerne: scheduling, memory management, device access. I Linux-verdenen ser vi ofte, at kernel og drivers arbejder tæt sammen. Fx: Når en AI-workload starter, beder softwaren kernel om at allokere RAM og CPU-tid – kernel spørger driveren, om hardware er klar, og fordeler ressourcerne. Her er et ultrakort kodeeksempel fra Linux:

struct device *dev = get_device_by_name("npu0");
if (dev) {
   allocate_resources(dev);
}

Maria spurgte engang, hvorfor AI workloads kan svinge så meget i performance. Svaret er ofte, at kernel ikke får prioriteret AI-acceleratorerne korrekt – det er ikke bare et softwareproblem, men et spørgsmål om hele stacken.

Operating system: Brugerens grænseflade

Operativsystemet (OS) samler det hele. Det giver brugeren (eller applikationen) adgang til hardware via et sæt API’er. På edge AI ser vi ofte embedded Linux eller et Real-Time OS (RTOS) som FreeRTOS. Embedded Linux er fleksibelt, men kræver mere RAM og CPU – RTOS er lynhurtigt og forudsigeligt, men har færre features. Vi havde et projekt, hvor valget stod mellem Yocto Linux og Zephyr RTOS. Kunden endte med Linux, fordi de ville have Python-support – men det kostede 30% mere strøm. Det er altid et kompromis.

Praktisk case: AI på edge device – hele vejen fra hardware til software

Vi arbejdede for nylig med et AI-kamera til kvalitetskontrol i produktionen. Stacken så sådan ud:

• SoC: ARM Cortex-A53 med integreret NPU
• Firmware: Custom U-Boot
• Drivers: Kamera og NPU-drivere
• Kernel: Linux 5.x
• OS: Embedded Linux (Yocto)
• AI-app: TensorFlow Lite model

Performance-optimeringen handlede om at få AI-modellen til at køre på NPU’en – ikke på CPU. Det krævede, at både driver og kernel var opdateret, og at firmware kunne initialisere NPU korrekt. Vi brugte dage på at debugge en fejl, hvor modellen kun kørte på CPU – årsagen var en forældet driver. Det er præcis her, hele stacken skal spille sammen. Hvis ét lag fejler, mister du hele gevinsten.

Fejl og faldgruber: Hvor går det galt?

De typiske fejl? Forkert firmware-version, inkompatible drivers, kernel der ikke understøtter ny hardware, eller OS der ikke kan håndtere realtidskrav. Vi har set et AI-projekt gå i stå, fordi en driver ikke kunne håndtere interrupt fra en sensor – det betød, at data gik tabt hvert 10. sekund. Konsekvensen? Hele produktionslinjen måtte stoppes. Det lyder som småting, men det er ofte de små lag i stacken, der vælter det hele. Michael sagde engang: “Det er aldrig AI-modellen, der fejler først – det er altid integrationen mellem lagene.” Vi er tilbøjelige til at give ham ret.

Lær mere og prøv selv

Hvis du vil nørde videre, så tjek:

• kernel.org – alt om Linux kernel
• Zephyr RTOS – open source RTOS
• U-Boot – firmware bootloader
• Yocto Project – embedded Linux
• Snillds egne kurser i embedded AI og systemintegration (kontakt os for adgang til kodeeksempler og workshops)

Louise spurgte, hvor man kan lære mere – her er stederne. Anders: Vil du have kode at prøve? Vi har eksempler liggende, bare sig til.

Kilder:

• https://towardsai.net/p/machine-learning/understanding-computer-systems-from-silicon-to-software
• https://www.seas.upenn.edu/~ese5320/
• https://www.reddit.com/r/embedded/comments/1fh7x5s/how_does_a_kernelos_actually_communicate_with_the/
• https://cloud.google.com/blog/products/chrome-enterprise/introducing-modern-computing-alliance
• https://www.robertoiriondo.com/

Målgruppens mening om artiklen

Anders, Embedded udvikler:

Jeg giver artiklen 85. Den er meget relevant for mit arbejde, fordi den rammer plet med de udfordringer, vi ofte oplever i praksis – især omkring integrationen mellem hardware og software. Jeg kan godt lide de konkrete eksempler og cases, men jeg savner lidt mere dybde på de tekniske løsninger og måske flere kodeeksempler.

Louise, AI-ingeniør:

Jeg giver den 90. Artiklen forklarer stacken på en letforståelig måde og fremhæver vigtige faldgruber, som jeg selv har oplevet. Den er både pædagogisk og praktisk, og jeg synes især, det er fedt med links til, hvor man kan lære mere. Jeg kunne dog godt ønske mig endnu flere hands-on eksempler.

Maria, IT-projektleder:

Jeg giver den 75. Den er god til at give overblik og forklarer, hvorfor det er vigtigt at forstå hele stacken, også for os der ikke koder til daglig. Men den bliver lidt teknisk indimellem, så jeg mister lidt af overblikket, hvis jeg ikke lige kender detaljerne i forvejen.

Michael, CTO:

Jeg giver den 80. Artiklen rammer mange af de problemer, vi ser i større AI- og embedded-projekter. Jeg synes, den balancerer fint mellem det tekniske og det strategiske, men jeg kunne godt tænke mig flere konkrete anbefalinger til, hvordan man undgår de nævnte fejl i praksis.

Jonas, Systemintegrator:

Jeg giver den 88. Det er sjældent, jeg ser en artikel, der så klart beskriver nødvendigheden af at forstå alle lagene – især for os, der arbejder med integration. Eksemplerne er spot-on, men jeg savner måske lidt mere om test og validering på tværs af stacken.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.