Författare: Heather Campbell är marknadschef för PAVE360 på Siemens EDA, med fokus på påskyndning av utvecklingen med digitala tvillingar för fordonskunder i hela världen. Innan hon började på Siemens år 2022 arbetade Heather för flera ledande elektronikleverantörer, däribland Infineon, Texas Instruments och Freescale, i olika roller inom produktmarknadsföring och produktledning.

Utvecklingstiderna behöver kortas och innovationstakten öka – något som går på tvärs mot den ökande komplexiteten inom mjukvara och system. Det är därför fordonstillverkare (OEM), tier 1- och tier 2-leverantörer samt IP-leverantörer alla undersöker möjligheterna med virtualisering, eller digitala tvillingar, för att hantera utmaningen.

Dagens mjukvarudefinierade plattformar hämmas av komplexitet på mjukvaru- och systemnivå. Det leder ofta till förseningar i mjukvaruleveranser, hotar värdeskapande funktioner och resulterar i vissa fall till och med i att fordonsplattformsprogram ställs in. En möjlig lösning är det som kallas ”shift-left”, där mjukvaruutveckling och integration utförs med hjälp av virtuella modeller innan kisel finns tillgängligt – men det återstår stora utmaningar i att faktiskt skapa ett utvecklingsflöde som är ändamålsenligt.

Figur 1: En digital tvilling möter utmaningarna med det mjukvarudefinierade fordonet.

Den tid och de resurser som krävs för att utveckla en komplett modelleringsplattform för fordonselektronik utgör ett betydande hinder för att dessa nya metoder ska få genomslag. Det finns många olika typer av modeller i olika utvecklingsmiljöer att hantera, med varierande nivåer av noggrannhet som kräver olika tidsdomäner. Synkroniseringen av dessa domäner skapar verkliga problem när man försöker skapa en integrerad och meningsfull virtuell simuleringsplattform. Därtill är många nuvarande modelleringstekniker också för långsamma för att mjukvaruutvecklare ska kunna använda dem för kodning och felsökning. Att försöka förena det som utvecklas i den virtuella världen med det som till slut hamnar på den fysiska fordonsplattformen är därför en klyfta som utvecklare har svårt att överbrygga.

Komplexiteten är inte det enda problemet som fordonstillverkarna står inför. Det integrationsarbete som krävs för att skapa ett värdefullt resultat av de disparata element som finns tillgängliga är för vissa OEM-tillverkare och tier 1-leverantörer en oöverstiglig uppgift. Dagens hårdvaru- och mjukvaruutveckling sker till stor del i silos, där separata team arbetar parallellt, ofta utan verklig insyn i sina kollegors framsteg. Det är därför inte förvånande att systemintegrationsfasen är den mest riskfyllda delen av ett projekt inom elektronikutveckling. Många problem uppstår när hårdvaran ska sättas samman till det färdiga systemet, och de beror ofta på oförutsedda systemberoenden. Detta kan kallas en ”integrationsstorm”, som i de sena faserna av utvecklingen riskerar att orsaka katastrofala förseningar. Sannolikheten för sådana problem ökar avsevärt när det saknas ett gemensamt och kontinuerligt angreppssätt för design, test och validering.

Det säger sig självt att idén om att använda digitala tvillingar för att ge bättre insikt och analys innan hårdvaran finns tillgänglig är god, den har använts inom vissa delar av fordonsindustrin i många år – och användningen ökar. Men bristen på sammanhållet tänkande på systemnivå innebär att resultaten för närvarande är begränsade; det är helt enkelt för fragmenterat för att kunna hantera integrationsstormen.

Som EDA-leverantör med verksamhet inom hela fordonselektronikindustrin har Siemens haft goda förutsättningar att identifiera de utmaningar som är förknippade med att försöka genomföra virtualisering på systemnivå. 

Här är de viktigaste problemen som observerats och som påverkar hela värdekedjan från OEM-tillverkare till tier 1-leverantörer samt kisel- och IP-leverantörer:

Det råder en generell brist på erfarenhet av virtuell modellering på systemnivå 

Leverantörer saknar en konsoliderad valideringsmiljö som ger en fullständig systemöversikt – och inser ofta att tiden och kostnaderna för att utveckla en sådan internt är oöverstigliga 

Mjukvaru- och hårdvaruteam arbetar oberoende av varandra som isolerade öar 

Mjukvarans behov bör styra valet av hårdvara, inte tvärtom. Risken är annars att hårdvaran är föråldrad redan innan den når marknaden 

Modellerings- och simuleringssystem är inte rustade för att hantera verkliga stimuli och är inte integrerade med CI/CD/CC-flöden 

 Det finns sällan en test- och valideringsstrategi på systemnivå

Kombinationen av alla dessa problem kan sammanfattas i ett enkelt konstaterande. Idag tar det för lång tid att bygga en meningsfull digital tvilling – i många fall kan det ta flera år, vilket motverkar de fördelar som är tänkta att inkludera möjligheten att flytta utvecklingen ”åt vänster” och påskynda tiden till färdig produkt.

Figur 2: Det tar år att utveckla en digital tvilling på systemnivå.

Ytterligare en nivå av komplexitet kommer från det faktum att det finns ett brett spektrum av underleverantörer som utvecklar mjukvara till fordonsindustrin, och som alla står inför olika utmaningar och har olika slutmål.

Låt oss titta närmare på några av de viktigaste aktörerna:

Systemarkitekter: Arkitekterna hos OEM-företag och tier 1-leverantörerna måste bestämma den övergripande strukturen för ett fordons komplexa elektroniska och elektriska (E/E) system samt definiera hur hårdvaru- och mjukvarukomponenter samverkar för att uppfylla funktionskraven. En arkitekt av systemkretsen kan behöva integrera heterogena flerkärniga arkitekturer plus processorer, grafik, AI-motorer samt olika kringutrustningar på ett enda chip. Båda grupperna måste följa strikta säkerhets- och skyddsstandarder.

• Virtualiseringsmål: Det behövs en enda, heltäckande miljö där de kan köra mjukvaruuppgifter över ett komplett system. Den måste vara anpassningsbar och snabb så att flera konfigurationer kan utvärderas och täcka hela det mjukvarubaserade utvecklingsflödet.

Utvecklare av mjukvaruapplikationer: Även denna kategori kan delas in ytterligare. Utvecklare i användarrymden använder generiska operativsystemmiljöer för att skriva mjukvara, varefter den färdiga mjukvaran porteras till den hårdvarurelevanta BSP:n (Board Support Package). Virtuella modeller skulle kunna användas för detta men är ofta för långsamma. Lågnivåutvecklare av inbyggd mjukvara förlitar sig däremot inte på snabba modeller – de behöver noggrannhet och precision för att på ett meningsfullt sätt kunna utnyttja dagens virtuella modeller.

• Virtualiseringsmål: Utvecklare i användarrymden vill kunna starta utvecklingen tidigare och behöver därför tillgång till modeller innan kisel finns tillgängligt. De behöver snabbare modeller och vill att modellbasen ska ligga så nära den slutliga BSP:n som möjligt för att minska porteringsarbetet. Deras resultat skulle kunna bli betydligt effektivare om de hade tillgång till kod från kollegor i andra designteam för att kunna ta hänsyn till systemberoenden. Om modeller som är både snabba och noggranna fanns tillgängliga skulle de kunna användas av både utvecklare i användarrymden och BSP-utvecklare.

Ingenjörer inom mjukvaruvalidering och testning, inklusive CI/CD-integration: Detta team säkerställer att fordonet uppfyller sina prestanda- och kvalitetsmål samt alla relevanta fordonsstandarder. De utformar och genomför tester samt använder simulerings- och testverktyg för att förutsäga systembeteende. Detta håller på att bli en process som omfattar hela fordonets livscykel, i takt med att korrigeringar och uppgraderingar görs trådslöst (OTA).

• Virtualiseringsmål: Vill kunna börja validera mjukvara på systemnivå innan hårdvara finns tillgänglig, samt kunna identifiera var fel uppstår och återkoppla problemen till systemarkitekterna så att designen kan itereras.

HiL-ingenjörer (som migrerar mot vHiL) arbetar för att minska antalet tester som behöver utföras i hårdvara, vilket är kostsamt. De vill virtualisera så mycket som möjligt på systemnivå för att eliminera den stora majoriteten av fel innan testning i hårdvara.

• Virtualiseringsmål: De behöver bygga en komplett systemplattform för att hitta fel tidigt och kunna upptäcka sådana som uppstår till följd av systemberoenden. De behöver också bättre insyn i vad som händer när systemet fallerar.

Figur 3: Virtualiseringsmål per användarprofil.

Mot en heltäckande digital tvilling

Flera av dessa virtualiseringsmål kan betraktas som gemensamma för flera användarprofiler. Vad de alla behöver är förmågan att utföra virtualisering på systemnivå och att ha tillgång till en miljö som gör det möjligt att dela resultat och ta tillvara på kunskapen från de övriga användarprofilerna.

Vad som krävs är en tydlig väg mot en integrerad, anpassningsbar, molnbaserad och heltäckande digital tvilling som kan tillgodose behoven hos flera användarprofiler. Detta är det enda sättet att verkligt möjliggöra den gränsöverskridande ingenjörskonst mellan silos som det mjukvarudefinierade fordonet kräver.

Kom igång snabbt med hjälp av en förintegerad digital tvilling

Som diskuterats har kostnaden och integrationsarbetet för att bygga upp fullständiga systemsimulationsmodeller – för att inte tala om det faktum att det kan ta flera år – hindrat en utbredd användning av digitala tvillingar på systemnivå hos OEM-tillverkare och tier 1-leverantörer.

Det är därför Siemens EDA tar en ny approach genom att erbjuda en förintegerad digital tvilling på systemnivå för ADAS- och IVI-marknaden. Det finns naturligtvis inte någon heltäckande lösning för komplexa fordonssystem, men att ha en gemensam plattform som kan användas inom en hel organisation för att snabbt komma igång med utvecklingen kan avsevärt påskynda användningen av virtualisering. Med en sådan digital tvilling kan driftsättning ske på dagar snarare än månader eller år. Mjukvaruutveckling med den senaste fordons-IP:n, som Zena-CSS från Arm, kan påbörjas omedelbart. Plattformen har förmågan att erbjuda scenariogenerering och att ansluta till verklig hårdvara så att designen kan itereras med verklig hårdvara. När det är nödvändigt att skapa en mer noggrann simulering av slutanvändarens system kan den sedan anpassas för att återspegla den slutliga designen.

Figur 4: Exempel på en heltäckande digital tvilling på systemnivå.

Genom att erbjuda en gemensam plattform som kan användas av flera användarprofiler för molnbaserad utveckling är det nu möjligt för den digitala tvillingen att användas på systemnivå och spela en nyckelroll i att påskynda utvecklingen av mjukvarudefinierade fordon på ett skalbart sätt.

Läs mer om hur du kan flytta utvecklingen ”åt vänster” med Siemens EDA:s digitala tvillinglösning: ”PAVE360 puts a virtual car on every engineer's desk”.