Firmware, ingen tør røre ved

Forestil dig en virksomhed, der har leveret den samme industrielle måleenhed i ti år. Den fungerer stabilt, og kunderne er tilfredse. Nu udgår en sensor, og en ny skal ind i produktet.

Det burde være en overskuelig opgave. Men da udviklerne åbner koden, finder de en uforklaret ventetid og særregler for flere versioner af elektronikken. Den kollega, der skrev dem, er stoppet.

Ingen kan med sikkerhed sige, hvilke konsekvenser en ændring vil få.

Koden, der får elektronikken til at virke

Firmware er den indbyggede software, der blandt andet læser sensorer, håndterer kommunikation og styrer elektronikkens komponenter. Den findes i alt fra varmepumper og trådløse målere til industrielle styringer.

Her er det ikke altid nok, at en beregning giver det rigtige resultat. Resultatet skal også være klar på det rigtige tidspunkt, og en komponent skal måske have tid til at starte, før den kan svare.

Derfor kan en tilsyneladende mærkelig detalje i koden have en fysisk forklaring. Ventetiden i vores tænkte måleenhed kan være nødvendig, fordi den oprindelige sensor ikke var klar umiddelbart efter opstart.

Fjerner en udvikler ventetiden for at gøre opstarten hurtigere, kan enheden forsøge at læse sensoren, før den er klar. Så kan den første måling være ugyldig. En tilsyneladende harmløs oprydning har ændret produktets funktion.

Når løsningen overlever forklaringen

Den uforklarede ventetid er kun ét eksempel på, hvordan firmware kan samle teknisk gæld. I andre produkter kan en ekstra kontrol være indført efter en fejl hos en kunde. En særregel kan få en bestemt printversion til at fungere, mens en midlertidig omvej kan være blevet tilføjet for at nå en leverance.

Hvert greb kan have været fornuftigt, da det blev indført. Men efter flere års ændringer kan det være svært at skelne mellem nødvendige hensyn og rester, som produktet ikke længere har brug for.

Det er en form for teknisk gæld: Tidligere valg gør fremtidige ændringer dyrere og vanskeligere. I firmware kan gælden være tæt forbundet med fysiske komponenter, som stadig findes i produkter hos kunderne.

Gammel kode er dog ikke automatisk dårlig kode. Den kan rumme mange års erfaring med fejl og driftsforhold. Problemet opstår, når den erfaring hverken er forklaret eller fastholdt i test.

Kildekoden er ikke hele produktet

Selv hvis virksomheden har gemt al kildekoden, er det ikke sikkert, at en ny udvikler kan genskabe den firmware, kunderne bruger.

Det kræver også de rette udviklingsværktøjer, biblioteker og indstillinger, som omsætter koden til et program, elektronikken kan køre. Hvis opsætningen kun findes på en gammel computer, er produktets vedligeholdelse afhængig af mere end filerne i kodearkivet.

At kunne genskabe den samme firmware på en anden computer er derfor en vigtig del af at bevare kontrollen over produktet.

Samtidig kan flere hardwareversioner være i drift. En ændring, der virker på det nyeste print, er ikke nødvendigvis afprøvet på den version, en kunde købte for syv år siden.

At lade være er også et valg med konsekvenser

Så... hvorfor ikke bare lade koden være?

Det kan være fornuftigt at undgå unødvendige ændringer i et stabilt produkt. Men omgivelserne står ikke nødvendigvis stille. Komponenter udgår, kunder får nye behov, og en opdaget sikkerhedsfejl kan kræve en rettelse.

I måleenheden bliver sensorskiftet derfor en prøve på noget større: Kan virksomheden stadig videreudvikle sit eget produkt?

En komplet omskrivning er heller ikke en enkel genvej. Den nye kode skal stadig håndtere de driftsforhold og hardwareproblemer, som den gamle gennem årene er blevet tilpasset til.

Før sensorskiftet skal produktet forstås igen

Vejen videre begynder med at skabe et pålideligt udgangspunkt:

• Hvilken firmware kører på hvilke enheder?
• Kan den genskabes?
• Og hvilke funktioner skal fortsat virke efter ændringen?

Udviklerne kan så fastholde kritiske funktioner i test, der gentages efter ændringer. Noget kan testes på en computer, mens samspillet med elektronikken også skal undersøges på den relevante hardware. 

For måleenheden betyder det konkret at undersøge, hvornår den nye sensor er klar, og kontrollere, at firmwaren håndterer opstarten korrekt. Skal samme firmware også bruges i ældre enheder, skal den fortsat understøtte deres sensorer.

Selve kodeændringen kan vise sig at være lille. Arbejdet med at finde ud af, hvad den må ændre, og hvad den skal bevare, kan være langt større.

Dermed kan en enkelt sensor, der udgår, tvinge virksomheden til at genåbne et udviklingsarbejde, den troede var afsluttet for ti år siden.