SDVault.ai™
SDVault.ai™ är ett bevislager för det programvarudefinierade fordonet.
Genom att införa teknisk intelligens i kvalitetssäkringscykeln utformar plattformen arkitekturen, verifierar integrationen och certifierar resultatet – allt inom en enda sammanhängande struktur istället för tre parallella pappersspår.
Verifieringsgapet
När SDV-utvecklingen sker kontinuerligt, men kvalitetssäkringen släpar efter
I SDV-ekosystemet utgör kraven arkitekturen. Detta omsätts i design, som sedan blir din kod. Koden blir ett testfall, vilket leder till bevis. Det sker flera överlämningar, och vid varje sådan tolkas innebörden av en ny ingenjör som arbetar utifrån det material som ligger framför hen.
Ingen av dessa tolkningar är fel, men tillsammans kan de leda till avvikelser. En designändring införs och någonstans längre fram i kedjan slutar en analys tyst att beskriva fordonet – inget går sönder, inget varnar, dokumentet blir helt enkelt inaktuellt.
När kretsarna väl anländer är frågan inte längre om programvaran fungerar. Frågan är om någon fortfarande kan visa att det som byggdes är det som specificerades.
Hur SDVault.ai™ kopplar samman SDV-arkitektur, validering och kvalitetssäkring
Arkitektur som en graf, inte en ritning.
Block, gränssnitt, strömdomäner och kritikalitetsnivåer är objekt som du kan göra sökningar på. Det gör att säkerhets- och integritetsreglerna för din programvarudefinierade fordonsplattform blir något som designen kontrolleras mot medan den skapas, snarare än något som en granskare letar efter i ett diagram flera veckor senare.
- Referensarkitekturer som består av en reglerad blockkatalog, uppbyggda i lager från applikation ner till hårdvara.
- Regler för separering, redundans, routning och kritikalitet tillämpas på den mjukvarudefinierade fordonsdesignen, där överträdelser leder till blockering snarare än varningar.
- Ett kravdokument som används som indata och omvandlas till en beslutsstyrd arkitekturkandidat – där valmöjligheterna läggs på ingenjören, aldrig antas.
Reglerade referensarkitekturer
Regler för utformning av körbara program
Beslutsstyrd kandidatarkitektur
Integration, testad mot verkliga förhållanden.
Leveranser från leverantörer sammanställs i samma diagram, och de artefakter för den programvarudefinierade fordonsplattformen som behövs för att verifiera integrationen genereras utifrån detta. Valideringstester av fordonsprogramvara utförs mot verkliga mål, och det är bevis – inte intuition – som avgör var den grundläggande orsaken ligger.
- Gränssnittsbeskrivningar från alla leverantörer stäms av, eventuella konflikter upptäcks och båda ursprungen bevaras istället för att tyst skrivas över.
- En punkt-för-punkt-jämförelse som besvarar integrationsteamets faktiska fråga: vad har förändrats sedan den senaste leveransen?
- Spår, loggar och diagnostik läses tillsammans, och grundorsaken begränsas till det område som bevisen stöder; befintliga resultat från statisk analys och tester införlivas som bevis istället för att ersättas.
Avstämning av leverantörsgränssnittet
Jämförelse av förändringar mellan enskilda värden
Evidensbaserad analys av grundorsaker
Fordonssäkerhet, cybersäkerhet och processer – i en och samma struktur.
Funktionell säkerhet, cybersäkerhet och processöverensstämmelse för det programvarudefinierade fordonet är tre vyer av samma bevisstruktur snarare än parallella dokumentsamlingar. Ändra en vy så uppdateras de andra automatiskt istället för att tyst föråldras.
- Funktionell säkerhet enligt ISO 26262, där riskanalys, felanalys, felträd och spårbarhet behandlas som sammanhängande artefakter och exporteras i de format som era bedömare redan accepterar.
- Cybersäkerheten följer ISO/SAE 21434 med hänsyn till FN:s R155 och R156: hotanalys, argument om nåbarhet med tillhörande bevisspår samt ett fall med påstående, argument och bevis som uppdateras i takt med att situationen förändras.
- Automotive SPICE-överensstämmelse granskas kontinuerligt mot den dokumentation ni redan producerar, där iakttagelser lyfts fram som granskningsbara ändringsförslag snarare än tysta redigeringar.
Bevis för funktionell säkerhet i uppkopplade system
Integrerad säkerhet för cybersäkerhet
Kontinuerlig efterlevnad av SPICE inom fordonsindustrin
SDVault.ai™
Handpicked for You
SDVault.ai™ i praktiken
Varför välja SDVault.ai™ för kontinuerlig SDV-säkerhet?
Arkitektur som körbara tekniska data
Block, gränssnitt, effektdomäner och kritikalitetsnivåer framställs som objekt som går att söka i, vilket gör det möjligt att tillämpa säkerhets- och integritetsregler på konstruktionen allteftersom den byggs upp.
Sammanlänkade bevis genom hela livscykeln
Arkitekturbeslut, leveranser från leverantörer, valideringsresultat och kvalitetssäkringsdokumentation är sammankopplade genom hela utvecklingscykeln.
Förändringsmedveten kvalitetssäkring
Ändringarna i utformningen gör att de berörda vyerna för säkerhet, cybersäkerhet och processer åter öppnas, vilket bidrar till att förhindra att analyserna i tysthet blir inaktuella.
Fungerar med befintliga verktygskedjor för teknikutveckling
SDVault™ samlar in krav, befintliga analysresultat, statiska analyser och testresultat som underlag och lägger till den sammanhängande strukturen som ser till att de hålls uppdaterade.
Utvecklad för alla beslutsfattare i SDV-livscykeln
Nej. Systemet är utformat för att utnyttja det du redan använder; kravhantering, befintliga analysresultat, statisk analys och testresultat matas in som underlag. Det som systemet tillför är den sammanbindande strukturen mellan dessa delar och den disciplin som ser till att informationen hålls uppdaterad.
ISO 26262 när det gäller säkerhet, med tillhörande täckning för IEC 61508 och IEC 62304; ISO/SAE 21434 tillsammans med FN:s R155 och R156 när det gäller cybersäkerhet; Automotive SPICE när det gäller processer.
Båda. SDVault™-miljön är vår, och vi implementerar den tillsammans med de ingenjörer som ska använda den. Det första steget är en genomgång utifrån er arkitektur, inte en demonstration utifrån vår.
Ja. Driftlägen som klarar luftspalt ingår i konstruktionen, just av de skäl som du undrar över.
Den används för att läsa, utarbeta och förklara. Den används inte för att fatta beslut. Domarna beräknas; en modell skriver själva domen, aldrig siffran, och dess resultat jämförs med det beräknade resultatet.
En steg-för-steg-genomgång tillsammans med teamet som utvecklat det, där vi utgår från en del av ditt eget program. Allt därefter bygger på vad vi upptäcker där.