Att välja leverantör av diagnostikmjukvara för fordonsindustrin: frågorna som avgör före avtalet

En leverantör av diagnostikmjukvara för fordonsindustrin utvecklar, levererar och underhåller den mjukvara som läser, uppdaterar, verifierar och spårar mjukvaran i fordonets styrenheter (ECU:er) — dels on-board, som inbyggda komponenter i styrenheten, dels off-board, i de externa verktyg som används i utveckling, end-of-line-test och verkstad. Arbetet vilar på standarder som UDS (ISO 14229), ODX (ISO 22901) och DoIP (ISO 13400), och leveransen sträcker sig från bootloader, kommunikationsstack och cybersäkerhetskomponenter till kompletta off-board-system för konfiguration, spårbarhet och diagnostik.

Uppdelningen mellan on-board och off-board är grunden för hela utvärderingen: on-board-logiken följer styrenheten och ändras sällan, medan off-board-sidan måste förbli korrekt över varje variant, marknad och mjukvarurevision i femton år eller mer efter att fordonet lämnat bandet. Vi har beskrivit skillnaden i detalj i vår genomgång av off-board kontra on-board-diagnostik — det bestående ingenjörsarbetet ligger på off-board-sidan, och det är där leverantörsvalet väger tyngst.

Det gör valet till ett livscykelbeslut snarare än ett verktygsinköp. Fordonsplattformar lever 20–40 år; verktyg och hårdvara gör det inte. Leverantören ni väljer ska finnas kvar — eller åtminstone lämna efter sig data och format som gör att någon annan kan ta vid.

I en demonstration fungerar allt; produktion är det som händer när det inte längre gör det. Kostnaderna som avgör ett program ligger sällan i licensen utan i det som omger den: integrationsarbetet mot er specifika E/E-arkitektur och säkerhetsmodell samt genomströmningen på bandet, där end-of-line-programmering sker inom takttiden, inte vid sidan av den. Därtill kommer variant- och beroendehanteringen över hela flottan och förvaltningen av verktygskedjan när plattformen väl är i drift.

Verifieringen är ofta den enskilt största dolda posten. Diadroms testautomationsverktyg Dolphin är byggt kring just den ekonomin: helt automatiserad verifiering som kortar utvecklingsprocessen med cirka 20 procent och sparar upp till 80 procent av de kostnader som normalt förknippas med verifiering av inbyggd mjukvara. Oavsett vems verktyg ni väljer är frågan densamma: hur mycket av verifieringen kan automatiseras — och vem bär arbetet att hålla den i gång?

Räkna också på kostnaden för det som inte får hända. En felaktig omprogrammering i fält gör en styrenhet obrukbar, och en verktygskedja som hanterar det säkert är billigare än varje enskild incident. Diadroms Autotech Bootloader har rullat i serieproduktion med signerade paket och utan en enda obrukbar enhet sedan 2016 — och bakom den siffran ligger verifieringsdisciplinen: i ett enda bootloader-projekt omkring 550 testfall, körda över ett trettiotal releaser, runt 16 000 testexekveringar. Det är den sortens sifferunderlag ni bör begära av varje leverantör.

Den verkliga inlåsningen sitter sällan i verktyget utan i datan. Om era diagnostikdefinitioner bara existerar i ett leverantörsspecifikt format är ni bundna till det verktyget så länge plattformen lever. Kräv därför verktygsoberoende, standardbaserade data: ODX (ISO 22901) för diagnostikbeskrivningen och DoIP (ISO 13400) för transporten. Det är det som håller flottan diagnostiserbar när det ursprungliga verktyget är borta.

Granska också licensmodellen. En licensmodell byggd för återanvändning innebär att moduler kan lyftas in i er kontext i stället för att allt byggs om från grunden — som när Lynk & Co licensierade och återanvände Diag Studio-funktionalitet i molnet, med UDS, DoIP, VCI och mjukvara over the air (SOTA), i tjänster som idag betjänar både Lynk & Co och Lotus och förvaltas av Diadrom i produktion. Motsatsen — en sluten svit där varje anpassning går genom leverantörens produktplan — är en inlåsning som märks först när ni behöver något den inte byggdes för.

Ställ ägandefrågan tidigt: vem äger diagnostikdatan, testfallen och konfigurationen den dag avtalet löper ut? Svaret säger mer om leverantören än någon produktbroschyr.

Kärnan är protokollstacken: UDS (ISO 14229) för tjänsterna, ODX för databeskrivningen, DoIP för transporten. Sedan ISO 14229-1:2020 finns dessutom den certifikatbaserade autentiseringstjänsten 0x29 vid sidan av klassisk SecurityAccess (0x27) — en leverantör som ska bära er säkerhetsmodell behöver hantera båda, med signerade mjukvarupaket och nycklar förankrade i hårdvara. Vår genomgång av UDS-tjänsterna visar vad som faktiskt ingår.

Lika viktigt som protokollen är datan som beskriver dem. ODX-beskrivningen måste följa styrenheten genom utveckling, produktion och många år på eftermarknaden — och när beskrivning och verklighet glider isär sker det tyst och blir dyrt: varje verktyg nedströms läser fel värden, missar fel eller slutar kommunicera helt. Fråga leverantören hur beskrivningen hålls i synk över hundratals varianter och revisioner; vi har beskrivit datalagret i vår genomgång av ODX (ISO 22901).

Ovanpå protokollen ligger regelverken. UN R156 gjorde ett Software Update Management System till ett villkor för typgodkännande, och det svåra är sällan uppdateringsmekanismen utan spårbarheten: att kunna visa vilken mjukvara som rullade på vilket fordon, när den ändrades och med vems godkännande. En leverantör av diagnostikmjukvara ska kunna visa hur verktygskedjan producerar det underlaget — och hur den stödjer ert arbete enligt UN R155 och ISO/SAE 21434.

För program med försvarsanknytning tillkommer en dimension. Svensk försvarsupphandling formar systemsäkerhetsarbetet genom H SystSäk 2022, och kraven når leverantören via avtalet — godkännanden ligger alltid hos beställare och myndighet, aldrig hos leverantören. Diadroms mjukvara har varit i försvarsdrift sedan 2012, och vi lär oss kontinuerligt av de systemsäkerhetsramverk som styr området — vi har beskrivit vad H SystSäk 2022 förväntar sig av leverantörer ur just leverantörsstolen. En leverantör som rör sig i båda världarna bär med sig samma fråga mellan dem: vilken mjukvara är faktiskt installerad — och går den att lita på?

För en svensk inköpsorganisation är närhet en riskfråga, inte en trivselfråga. Diagnostik- och omprogrammeringsarbete kräver täta avstämningar med era plattformsteam — samma språk, samma tidszon och möjligheten att sitta på plats förkortar varje varv. Fråga var integrationsingenjörerna faktiskt sitter, och vem ni ringer när bandet står stilla. Grundfakta bör dessutom gå snabbt att kontrollera — för Diadroms del: svenskägt, med huvudkontor och utveckling i Göteborg, certifierat enligt ISO 9001 och 14001 och noterat på Nordic Growth Market (NGM) som DIAH. Begär motsvarande transparens av varje leverantör på listan.

Granska sedan leveransmodellen. Ett leverantörsval är sällan binärt mellan produkt och konsult: modellen bör kunna växla mellan integrerad specialist i ert team, komplett expertteam under er ledning, projektleverans med helhetsansvar och långsiktigt livscykelstöd — utifrån det ansvar ert program behöver i varje fas. En leverantör som bara erbjuder en av formerna tvingar in programmet i sin egen affärsmodell.

Referenser i serieproduktion är det slutliga beviset. Diadrom har byggt off-board-diagnostik som disciplin sedan 1999 — bevisat i serieproduktion hos Volvo sedan dess, idag med över 250 000 fordon som rullar med Diadroms diagnostik, och med ett verkstadsdiagnostiksystem utrullat på över 60 marknader, byggt på Diag Studio. Poängen är inte namnen utan mönstret: begär referenser där leverantörens mjukvara överlevt mötet med serieproduktion, inte bara med en demonstrationsbänk.

Sex frågor skiljer en leverantör som klarar produktion från en som klarar en demonstration. Ett: vilka referenser finns i serieproduktion, och hur länge har de rullat? Två: vilka standarder bär datan — ligger diagnostikbeskrivningen i ODX och transporten i DoIP, så att datan överlever verktyget? Tre: hur hanteras säkerhetsmodellen — SecurityAccess (0x27), certifikatbaserad autentisering (0x29), signerade paket, hårdvaruförankrade nycklar?

Fyra: hur produceras spårbarhetsunderlaget för UN R156 — vilken mjukvara, på vilket fordon, med vems godkännande? Fem: vem utför integrationsarbetet mot er arkitektur, och var sitter de? Sex: vad händer efter leverans — vem förvaltar verktygskedjan genom plattformens livscykel, och vad äger ni själva den dag samarbetet upphör?

Svaren på de sex frågorna säger det broschyren inte gör: om ni köper ett verktyg eller en verktygskedja — en licens eller en förmåga. Ett verktyg diagnostiserar eller programmerar en styrenhet i en definierad situation, oftast på bänk eller i en enskild arkitektur. En verktygskedja bär diagnostik och omprogrammering genom serieproduktion: säkerhetsmodellen, obsolescensen över en plattform som lever i 20–40 år, takttiden på bandet, variant- och beroendehanteringen över flottan och spårbarhetsunderlaget som typgodkännandet kräver. Verktyget är en komponent i verktygskedjan — och det är verktygskedjan ni upphandlar; hela resonemanget finns i vår genomgång av verktyg kontra verktygskedja.

Nästa konkreta steg är att ställa frågorna, till oss eller till andra: en briefing på 30 minuter räcker för att gå igenom listan i ert sammanhang — online eller på plats i Göteborg.