Så, vad är det stora problemet när det gäller mjukvarusidan inom automotive-segmentet?
”Det finns förstås flera, men viktig bit gäller mjukvara kontra hårdvara,” svarar Filip Stål. ”Utmaningen handlar ju långt ifrån bara om att utveckla och producera mjukvaran. Lika viktigt är att få ihop kravställningarna kring hård- och mjukvara tillsammans till en fungerande helhet. Bara en sån sak som att mjukvarorna i allmänhet har mycket kortare livcyklar är ett bekymmer. Dessa ska, och måste, ändå synkroniseras med de längre cyklarna för de mekaniska systemen. Biltillverkarna har i denna kontext när det gäller mjukvara t ex OTA att tillgå – ”Over-the-Air-uppdateringar”. Men hur ser det ut när det gäller de mekaniska uppdateringar? De kan möjligen äga rum i samband med servicetillfällen, men dessa skilda möjligheter att uppdatera är tufft att få ihop och ger implikationer: Ett exempel – hur säkerställer man att en uppdatering av ett bromssystem ”lirar” ihop med de mekaniska bitarna i systemet?”
Krav på att utveckla infrastrukturlösningar för mjukvaruhanteringen
Detta är nu bara ett problem i en rad som har skapat och skapar huvudvärk inom inte bara fordonsindustrin, utan också överallt där mjukvaror – förvisso också elektronik – växer exponentiellt i andel av helheten när det gäller utvecklings- och produktframtagnings-arbetet.
Det hela kokar ner till att man i större organisationer måste skapa hållbara infrastrukturer för att hantera detta med mjukvaruintegration. Mercedes har t ex, enligt CSO Magnus Östberg, lagt ner enorma resurser för att bygga upp en sådan struktur: för att kunna möta SDV-kraven handlar det i reda pengar om hundratals miljoner euro, motsvarande mer än elva gånger så mycket i svenska kronor, skriver han i en LinkedIN-artikel. Han noterar vidare att man satsat på att samla mjukvara, hårdvara, systemintegration och testfunktioner under ett tak.
”Dessutom har vi redan rekryterat omkring 3 000 mjukvaruutvecklare över hela världen som arbetar i 19 tvärfunktionella avdelningar.”
Häri ligger utmaningen, inte bara hos Mercedes, utan i lika stor utsträckning också för Volkswagen-koncernen, Volvo Cars och andra.
”Med efterfrågan på AI-baserade system, infotainment, autonoma körfunktioner och trådlösa uppdateringar som växer i en exponentiell takt, är det en enorm utmaning att ha kapacitet att hantera allt mer komplex mjukvaruutveckling och integration i snabb takt,” menar Filip Stål, som också hävdar att PTC med Codebeamer och Windchill RV&S ligger väl till i framtidsracet.
”Codebeamer och Windchill RV&S är integrerade i moderna ALM-strategier och har omfattande lösningar för kravhantering, kvalitetssäkring och riskhantering,” tillägger han och pekar också på nya Norden-partnerns, Nanga Systems, djupa kunskap och erfarenhet av dessa verktyg. ”På sista raden kommer detta att göra det möjligt för oss tillsammans att leverera stort värde och stöd till organisationer som strävar efter excellens i sina produktutvecklings-processer. Inte minst för att vi via PLM-sidan har mycket goda grunder att stå på när det gäller hantering och integration av lösningar i detta.”
Codebeamer-köpet har givit ringar på vattnet
Övergripande är det alltså en komplex helhet kring mjukvaruhanteringen som måste till för att effektivt och i parallellt integrerade spår kunna utveckla system, leva upp till regulatoriska bitar, sköta tester och hantera/koordinera en uppsjö av programreleaser. Att bygga upp en infrastrukturell arkitektur betyder oerhört mycket. Man behöver inte heller fundera länge för att inse betydelsen av ett kapabelt IT- och PLM-stöd i detta. Vad har köpet av Codebeamer för några år sedan inneburit i detta sammanhang vid sidan av VW-koncernens satsning? Stål igen:
”Köpet har betytt mycket för PTC. Man kan tala om ringar på vattnet. Det har blivit lite av en ketchup-effekt. Många av de stora order PTC har fått har inte kommit inom typ ett kvartal, folk rusar inte bara till kiosken och köper, så att säga. Utan det har varit lite av varje, samarbeten med Nanga i vissa fall, samarbeten med de som utvecklade Codebeamer i andra. Det har drivits piloter i olika projekt och sen har man i dessa tagit större satsningar under parollen att, ’nu ska vi rulla ut detta på bred front.’ Det har i sin tur givit effekter som att andra fordonsindustrier tagit en genväg och hoppat på med större satsningar.”
Men detta sker inte i en handvändning. Det tar tid, säger Stål. Bilindustrin står verkligen inte bara på ett blankt papper och funderar över vad man ska göra.
”Nej, långt därifrån, men att uppnå tillräcklig effektivitet i mjukvaruhanteringen är knappast något överraskande problem. Titta bara på Volvo Cars, som har en hel del förseningar med sin nya EX 90-modell. De har varit öppna och ärliga mot media i detta och anledningen är att man inte får ihop mjukvaran. Den är inte testad och färdig och man vågar inte med tanke på tuffa implikationer med återtagningar och annat att lansera fordonet innan detta känns helt tryggt och klart.”
Vad kan Nanga System tillföra?
Intressant i detta med Volkswagen-gruppens satsning är att det Nanga, som PTC valt att partner-samarbeta med, har varit involverade i Codebeamer-satsningen. Men allmänt, hur jobbar Nanga och vad kan man tillföra?
Först några ord om Roger Thyrell, som ska leda den nordiska verksamheten. Klart är att han har en bred och intressant CV, som inkluderar centrala positioner på tuffa konkurrenter som Siemens Digital Industries Software, där han bl a jobbat med Siemens motsvarighet till Codebeamer, Polarion, och på PTCs världsledande VAR-partner (Value Added Reseller) PDSVISION som Customer Success Manager. Han har också varit anställd direkt på PTC som affärsutvecklingschef och har i övrigt på meritlistan också erfarenheter från mjukvaror som IBM Rational DOORS.
”Jag skulle vilja börja i den änden att vi, Nanga Systems, jobbar på tre ben: Konsulting med specialistkompetens förstås, men också försäljning av mjukvaran och utveckling av egna verktyg med adderande och kompletterande kapabiliteter till Codebeamer, säger Thyrell och fortsätter: ”I det senare fallet har vi t ex en JIRA-integration som är betydligt mycket starkare än vad standardintegrationen är. Varför är detta viktigt? När man kommer in från ALM-sidan så är man vanligtvis inte ute efter att byta ut JIRA, som ofta är så hårt rotat inne på företagen så att vi integrerar med JIRA istället. Det är detta som gör att ALM blir så kraftfullt med Codebeamer; det är en plattform som integrerar med resten av verksamheten. Lite av den utmaning vi har sett tidigare i Norden är att det normalt inte är samma avdelning man talar med när man börjar diskutera ALM i stort med mjukvaruutveckling och liknande. Visst, kravhanteringen går över flera broar och PLM-avdelningen förstår det bättre, men traditionellt är det här mycket silofierat ute hos kunderna.”
Mjukvaruinnovation som en kärna i produktutvecklingen
Men vad handlar då detta med SDV om? Det finns flera definitioner, men en användbar är att en SDV är ett fordon där kärnfunktioner hanteras av ett mjukvarulager som sitter mellan förarens fordonsgränssnitt och som hanterar dess funktioner via huvudsakligen sensorer. Detta gör det möjligt för tillverkaren att förbättra både användbarheten och funktionerna dynamiskt via uppdateringar, inklusive trådlösa, ”Over-The-Air” (OTA) installationer. Vad man nu på många ställen inom automotive tar sikte på är att skapa mjukvarudefinierade plattformar för fordon, inklusive mjuk- och hårdvara, som utgör grunden för att differentiera digitala fordonsfunktioner.
Denna utveckling inom fordonsindustrin understryker den ökande betydelsen av programvara för att driva på automotives industriella omvandling. Integrationen av mjukvara med hårdvara har förvandlats från grundläggande inbyggda system till sofistikerade, mjukvarudefinierade produkter. Denna övergång betonar mjukvaruinnovation som kärnan i produktutvecklingen, vilket möjliggör kontinuerliga funktionsuppdateringar utan att kräva hårdvaruförändringar.
Varianthanteringens betydelse för SDVer
Dagens fordon är mer uppkopplade, autonoma och elektriska än någonsin. Vart och ett av fordonen innehåller i dagsläget ofta mer än 150 miljoner rader kod, och mer lär det bli. Därför behövs lösningar som kan hantera tiotals terabyte data varje dag. Det är, som MBs Magnus Östberg, beskriver utvecklingen: ”Ett enormt åtagande och det har lett till en seismisk förändring i vårt sätt att arbeta.”
PTC menar att man med framför allt Codebeamer, har en habil lösning som integrerad med Windchill PLM kommer att kunna bli ett vasst fundament i denna utveckling, inte bara inom VW utan generellt i fordonsindustrin.
Men man ska heller inte glömma att vid sidan av mjukvaru- och elektrifierings-stöd i produktutvecklingsarbetet kommer variant-hanteringen att bli en nyckelteknolgi, med starka kopplingar till fordonsföretagens SDV-strategier. PTCs lösningar i detta gör Product Line Engineering (PLE) smidigt, vilket kommer av det nyliga köpet av Pure-Systems, som är en konfigurationsmotor som innehåller alla regler som är nödvändiga för att hantera alla produktvarianter (konfigurationer), särskilt på mjukvarusidan. I grund och botten innehåller en SDV en mängd mjukvaru-konfigurationer som måste fungera tillsammans, och varje konfiguration har olika krav, källkod, inställningar och testfall. Medan Codebeamer används för att utveckla mjukvara, hanterar Pure-Systems Pure::Variants-mjukvara denna konfigurationskomplexitet. Precis som Codebeamer, används, eller kommer att användas, stöder Pure::Variants många bilföretag i deras SDV-strategier.
Ett nog så viktigt påpekande
”Det senare är ett nog så viktigt påpekande,” kommenterar PTCs Filip Stål. ”Hela vår PLM-strategi bygger på dels integrationen mot våra egna system, dels mot integrationen mot andra system. Men tar du Codebeamer så är den absoluta planen att man inuti Windchill ska kunna se en hel och färdig produktstruktur, som innehåller både mjukvara och hårdvara, krav och test, oavsett om det är på hård- eller mjukvarusidan. Allt detta ska finnas på plats med spårbarhet. Denna integration pågår, men vi går inte till marknaden idag och säger att Codebeamer är totalt integrerat i Windchill ännu.”
”Precis,” tillägger Roger Thyrell. ”Vi använder ju idag standardiserings-tekniken OSLC för att knyta ihop verktyg, som också gör att vi öppnar upp Codebeamer och även Windchill mot andra verktyg. Därmed kan vi ha en flora av verktyg och behöver inte låsa in någon i detta tänk, varken från den digitala tråden från PTCs sida eller från Nangas sida. Vi har kort sagt en öppen arkitektur när vi kommer till dessa bitar. En viktig diskussion i detta är: ’Vad är syftet med att integrera mjukvaran i hårdvaruhanteringen? Varför behöver vi se mjukvaran ihop med en BOM (Bill of Material)? Det är just för att det blivit så mycket viktigare och att det är hårdvaran som ger den stora kvalitetskänslan.”
”Integration är ju också viktigt av flera skäl. Om du bara tänker dig en gräsklippare, en automover, eller bil, ja, vilken fysisk produkt som helst i liknande kategorier, så innehåller de väldigt mycket mjukvara. Mjukvaruutveckling är mycket mer agil, du släpper nya releaser och patchar stup i kvarten. Men du kan inte släppa detta med mindre än att du testat att hårdvaran spelar väl ihop med mjukvaran, den måste vara garanterat kompatibel med en viss hårdvarukonfiguration,” tillägger Filip Stål.
Här vill ingen produktutvecklare hamna i två olika silos, där s a s ”den handen inte vet vad det andra gör”. Det är bl a detta PTC och Codebeamer tagit sikte på att bibringa marknaden, där också standarder och myndighetskrav driver mycket av utvecklingen.
”Man måste också kunna följa spårbarhetskraven i båda leden, hård- och mjukvara,” avslutar Roger Thyrell.
