Demo · Automotive L2 · versiegelt synthetisch · absichtliche Lücken
Zwei Wege, wie die Nachweiskette scheitert: Entweder fehlt die Verknüpfung – oder der Test ist grün und belegt das Safety Goal trotzdem nicht.
Siegel 868ac61b… · Was bedeutet das Siegel?
· Bericht (HTML)
PoC/Demo. Synthetische L2-ADAS-Demo. Kein Zertifikat.
Fall A und Fall B zeigen die beiden Lückenarten. Fall C zeigt die Lücke aus Fall A noch einmal, diesmal aus Sicht der Architektur.
Im Sicherheitskonzept ist für das Safety Goal ein Überwachungsmechanismus vorgesehen. In den Software-Artefakten gibt es weder eine Anforderung noch ein Element, das ihn umsetzt.
Das Safety Goal wurde von 200 ms auf höchstens 150 ms verschärft. Der Test wurde nicht nachgezogen und prüft weiterhin gegen die alte Grenze. Er ist grün, belegt die aktuelle Anforderung aber nicht.
Die Architektur soll zeigen, wie das Safety Goal heruntergebrochen wird. Das Überwachungselement fehlt – dieselbe Lücke wie in Fall A, eine Ebene tiefer.
Selten fehlt der einzelne Nachweis. Häufiger fehlt der Beleg, dass die Nachweise zusammengehören.
In Ihrem Projekt lesen die Konnektoren dieselben Artefaktarten direkt aus Ihren Tools. Ein Wechsel der Toolchain ist nicht nötig.
Die Bilder sind Originalaufnahmen aus dem Graph-Explorer. Sie können zwischen der Gesamtansicht und dem Fokus auf die unterbrochene Stelle umschalten.
Nicht belastbar: Ein Nachweis liegt vor, stützt die Aussage aber nicht. Offen: Der Nachweis fehlt noch. Keiner der beiden Status ist eine Ampel für die Sicherheit des Fahrzeugs.
| Safety Goal | Status | Grund | |
|---|---|---|---|
| SG-2 Warnung an der ODD-Grenze (Grenze des Einsatzbereichs) | nicht belastbar | Ein Test ist verknüpft, aber ohne Ergebnis und ohne Zeitangabe. | |
| SG-3 Lenkmoment | nicht belastbar | Das Safety Goal fordert inzwischen 150 ms, der Test prüft noch gegen 200 ms. | Pfad B → |
| SG-4 Abstand | offen | Die Verknüpfung zur Software fehlt, die Zerlegung ist unvollständig, und ein Timing-Nachweis liegt nicht vor. | Pfad A → |
| SG-5 Aktuator | offen | Ein Timing-Nachweis liegt nicht vor. |
Gleiche Eingangsdaten ergeben denselben Hash. So lässt sich prüfen, ob eine erneute Analyse zum selben Ergebnis kommt. Jeder neue Analyselauf erzeugt zudem einen neuen Siegelstand. Das Siegel ist ein prüfbarer Datensatz – kein Zertifikat und keine Freigabe.
Vokabular, Regeln und Normbezug bleiben unverändert, solange sich die Pack-Konfiguration nicht ändert.
Neue Artefakte oder Testergebnisse ergeben einen neuen Projekt-Hash. Der Regel-Hash bleibt gleich.
Ändert sich der Projekt-Hash, hat sich Ihr Projekt geändert. Ändert sich der Regel-Hash, hat sich die Bewertungsgrundlage geändert. Mehrere Siegelstände nebeneinander dokumentieren, wie sich der Nachweisstand im Projektverlauf entwickelt hat. Details im Systemüberblick
viprove findet die Lücken. Ihr Team schließt sie.
Dies ist ein Beispiel. In Ihrem Projekt arbeitet dieselbe Engine mit Ihren Artefakten und Ihren Tools.
Die Robotik-Demo nutzt dieselbe Engine in einer anderen Domäne. Dort gelten Performance Level statt ASIL, die Lückenarten bleiben dieselben.
Zur Robotik-Demo →Siegel, Report-Auszug und Pfadansichten: So sieht der Assessor den Nachweisstand.
Evidence-Auszug ansehen →Packs, Konnektoren und die zwei Takte des Siegels – kompakt erklärt.
Zum Systemüberblick →Andere Domäne, andere Tools? Im Reality Check klären wir gemeinsam, ob viprove zu Ihrem Projekt passt.
Reality Check anfragen →