SDVault.ai™
SDVault.ai™ ist eine Evidenzebene für das softwaredefinierte Fahrzeug.
Die Plattform bringt „Engineering Intelligence“ in den Qualitätssicherungszyklus ein, entwirft die Architektur, überprüft die Integration und zertifiziert das Ergebnis – alles innerhalb einer einzigen vernetzten Struktur anstelle von drei parallelen Papierdokumentationsketten.
Die Sicherheitslücke
Wenn die SDV-Entwicklung kontinuierlich voranschreitet, die Qualitätssicherung jedoch hinterherhinkt
Im SDV-Ökosystem bilden die Anforderungen die Architektur. Diese wird in ein Design umgesetzt, das dann zu Ihrem Code wird. Der Code wird zu einem Testfall, der zu Belegen führt. Es gibt mehrere Übergaben, und bei jeder davon wird die Bedeutung von einem neuen Ingenieur interpretiert, der anhand des ihm vorliegenden Artefakts arbeitet.
Keine dieser Interpretationen ist ein Fehler, aber zusammen können sie zu einer Abweichung führen. Eine Designänderung wird umgesetzt, und irgendwo weiter unten in der Kette hört eine Analyse stillschweigend auf, das Fahrzeug zu beschreiben – nichts versagt, nichts löst einen Alarm aus, das Dokument verliert einfach seine Gültigkeit.
Wenn die Hardware schließlich eintrifft, lautet die Frage nicht mehr, ob die Software funktioniert. Es geht vielmehr darum, ob noch jemand nachweisen kann, dass das, was gebaut wurde, auch dem entspricht, was spezifiziert wurde.
Wie SDVault.ai™ die SDV-Architektur, -Validierung und -Sicherung miteinander verbindet
Architektur als Graph, nicht als Zeichnung.
Blöcke, Schnittstellen, Stromversorgungsdomänen und Kritikalitätsstufen sind Objekte, die Sie abfragen können. Dadurch werden Sicherheits- und Integritätsregeln für Ihre softwaredefinierte Fahrzeugplattform zu etwas, anhand dessen das Design bereits während der Erstellung überprüft wird – und nicht erst zu etwas, wonach ein Prüfer Wochen später in einem Diagramm sucht.
- Referenzarchitekturen, die aus einem regulierten Blockkatalog zusammengestellt sind und sich von der Anwendung bis hin zur Hardware in Schichten anordnen.
- Regeln zu Trennung, Redundanz, Routing und Kritikalität, die auf das softwaredefinierte Fahrzeugdesign angewendet werden, wobei Verstöße zu einer Blockierung statt zu einer Warnung führen.
- Ein Anforderungsdokument, das als Eingabe dient und in eine durch Entscheidungen gesteuerte Architekturvariante umgewandelt wird – wobei die Entscheidungswege dem Ingenieur überlassen bleiben und niemals vorausgesetzt werden.
Regulierte Referenzarchitekturen
Regeln für die Ausführungsfähigkeit
Entscheidungsgesteuerte Kandidatenarchitektur
Integration, in der Praxis bewährt.
Lieferungen der Zulieferer werden in ein und demselben Diagramm abgeglichen, und daraus werden die für die Verifizierung der Integration erforderlichen Artefakte der softwaredefinierten Fahrzeugplattform generiert. Validierungstests für Automobilsoftware werden an realen Zielen durchgeführt, und nicht die Intuition, sondern konkrete Nachweise entscheiden darüber, wo die Ursache liegt.
- Schnittstellenbeschreibungen aller Lieferanten werden abgeglichen, wobei Konflikte aufgedeckt und beide Herkunftsangaben beibehalten werden, anstatt stillschweigend überschrieben zu werden.
- Ein Detail-zu-Detail-Vergleich, der die eigentliche Frage des Integrationsteams beantwortet: Was hat sich seit der letzten Lieferung geändert?
- Traces, Protokolle und Diagnosedaten werden gemeinsam ausgewertet, wobei die Ursache auf den Bereich eingegrenzt wird, den die Beweise stützen; vorhandene Ergebnisse aus statischer Analyse und Tests werden als Beweismittel einbezogen, anstatt ersetzt zu werden.
Abstimmung der Lieferantenschnittstelle
Vergleich der Veränderungen von Tröpfchen zu Tröpfchen
Evidenzgestützte Ursachenanalyse
Fahrzeugsicherheit, Cybersicherheit und Prozess – in einer Struktur.
Funktionale Sicherheit, Cybersicherheit und Prozesskonformität für das softwaregesteuerte Fahrzeug sind drei Sichten auf dieselbe Nachweisstruktur und keine parallelen Dokumentensätze. Ändert man eine Ansicht, werden die anderen aktualisiert, anstatt stillschweigend zu veralten.
- Die funktionale Sicherheit erfolgt gemäß ISO 26262, wobei Gefahrenanalysen, Fehleranalysen, Fehlerbäume und Rückverfolgbarkeit als miteinander verknüpfte Artefakte geführt und in den Formaten exportiert werden, die Ihre Gutachter bereits akzeptieren.
- Die Cybersicherheit erfolgt gemäß ISO/SAE 21434 unter Berücksichtigung der UN-Vorschriften R155 und R156: Bedrohungsanalysen, Erreichbarkeitsargumente mit ihrem Nachweispfad sowie ein Fallmodell aus Behauptung, Argument und Nachweis, das sich bei Änderungen der Situation automatisch neu generiert.
- Die Konformität mit Automotive SPICE wird kontinuierlich anhand der von Ihnen bereits erstellten Nachweise geprüft, wobei Feststellungen als überprüfbare Änderungsvorschläge und nicht als stille Bearbeitungen vorgebracht werden.
Nachweise zur funktionalen Sicherheit vernetzter Systeme
Integrierte Cybersicherheitssicherung
Kontinuierliche SPICE-Konformität im Automobilbereich
SDVault.ai™
Handpicked for You
SDVault.ai™ in der Praxis
Warum sollten Sie sich für SDVault.ai™ zur kontinuierlichen SDV-Sicherung entscheiden?
Architektur als ausführbare technische Daten
Blöcke, Schnittstellen, Stromversorgungsbereiche und Kritikalitätsstufen werden als abfragbare Objekte dargestellt, wodurch Sicherheits- und Integritätsregeln bereits während der Entwurfsphase auf das Design angewendet werden können.
Vernetzte Nachweise über den gesamten Lebenszyklus hinweg
Architekturentscheidungen, Lieferungen von Anbietern, Validierungsergebnisse und Sicherungsartefakte bleiben über den gesamten Entwicklungslebenszyklus hinweg miteinander verknüpft.
Änderungsorientierte Qualitätssicherung
Durch Änderungen am Design werden die betroffenen Ansichten zu Sicherheit, Cybersicherheit und Prozessen wieder geöffnet, wodurch verhindert wird, dass Analysen unbemerkt ihre Gültigkeit verlieren.
Kompatibel mit bestehenden Entwicklungswerkzeugen
SDVault™ erfasst Anforderungen, vorhandene Analyseergebnisse, Ergebnisse statischer Analysen und Testergebnisse als Beleg und fügt eine Verknüpfungsstruktur hinzu, die dafür sorgt, dass diese Daten stets auf dem neuesten Stand bleiben.
Entwickelt für alle Entscheidungsträger im SDV-Lebenszyklus
Nein. Es ist darauf ausgelegt, das zu nutzen, was Sie bereits einsetzen: Anforderungsmanagement, vorhandene Analyseergebnisse, statische Analysen und Testergebnisse werden als Belegdaten übernommen. Was es hinzufügt, ist die Verbindungsstruktur zwischen diesen Elementen und die Disziplin, die dafür sorgt, dass alles auf dem neuesten Stand bleibt.
ISO 26262 im Bereich Sicherheit, mit angrenzender Abdeckung der Normen IEC 61508 und IEC 62304; ISO/SAE 21434 zusammen mit UN R155 und R156 im Bereich Cybersicherheit; Automotive SPICE im Bereich der Prozessabläufe.
Beides. Die SDVault™-Umgebung gehört uns, und wir richten sie gemeinsam mit den Ingenieuren ein, die sie nutzen werden. Der erste Schritt ist eine gemeinsame Bestandsaufnahme Ihrer Architektur, keine Demo unserer Lösung.
Ja. Betriebsmodi, die einen Luftspalt zulassen, sind Teil der Konstruktion – genau aus den Gründen, die Sie anführen würden.
Es dient zum Lesen, Entwerfen und Erläutern. Es dient nicht zum Entscheiden. Urteile werden berechnet; ein Modell schreibt den Satz, niemals die Zahl, und seine Ausgabe wird mit dem berechneten Ergebnis abgeglichen.
Ein Schritt-für-Schritt-Leitfaden mit dem Entwicklerteam, bei dem ein Ausschnitt aus Ihrem eigenen Programm verwendet wird. Alles, was danach folgt, ergibt sich aus dem, was wir dort vorfinden.