Mit der Toolchain für das Sicherheitsdesign können Sie eine Sicherheitsmonitorlösung bereitstellen, die aus einem Figma-Designdokument generiert wurde. Verwenden Sie diese Tools nacheinander.
Der Compiler für das Sicherheitsdesign erzeugt Sicherheitsartefakte, die die nachfolgende Codegenerierung für die Erstellung des Sicherheitsmonitors steuern. Durch die Trennung zwischen der Designkompilierung und der Codegenerierung kann der Codegenerator die ISO-26262-Bewertung TCL-3 erreichen.
Abbildung 1. Toolchain für das Sicherheitsdesign
Nachdem der Compiler Artefakte generiert hat, erstellt die Toolchain einen Bericht, den ein OEM-Sicherheitsingenieur prüfen kann, um die aus dem Figma-Design generierten Artefakte zu validieren.
Abbildung 2: Workflow für die Toolchain für das Sicherheitsdesign.
Compiler-Eingaben entwerfen
Das serialisierte Designdokument stellt ein UI-Design dar, das aus einem Designtool importiert und mit einem Toolkit-Schema verarbeitet wurde. Die Datei enthält die folgenden Informationen, die aus dem Design geparst wurden:
- Vollständiger Knotenbaum eines Designs
- Bilder und Komponenten
- Metadaten wie Name, Version und Datum der letzten Änderung
Die Stammknoten des Designs müssen in der Knotenliste definiert sein und die Stammknoten für die im Design identifizierten sicherheitsrelevanten Elemente sein.
Diese Datei wird in Android Automotive OS eingebunden, um das Kombiinstrument zu rendern. Die nicht sicherheitsrelevanten Elemente werden mit einem HAR (High Availability Renderer) angezeigt, der auf SDV Media als Overlay ausgeführt wird, um die sicherheitsrelevanten Elemente für den Nutzer darzustellen.
Der Design-Compiler verwendet DesignCompose-Anpassungen, um Ausgaben zu generieren, mit denen die Sichtbarkeit sicherheitskritischer Elemente im Design umgeschaltet werden kann. Das Design wird mit Impeller ohne Benutzeroberfläche gerendert. Zwischen den Anpassungsänderungen sendet das System Screenshot-Befehle an das Rendering-Backend, um Bildartefakte zu generieren.
Abbildung 3: Beispiel für eine Figma-Designdatei zum Erstellen eines Sicherheitsmonitors.
Ausgabeverzeichnis
Dies ist der Speicherort im lokalen Dateisystem, an dem der Compiler die generierten Artefakte speichert.
JSON-Konfigurationsdatei
Die JSON-Konfigurationsdatei wird in den meisten Fällen von einem OEM-Sicherheitsingenieur erstellt. Sie enthält Metadaten mit sicherheitsrelevanten Informationen zum Fahrzeug, die nicht in einem UI-Design erfasst werden. Diese Datei enthält die folgenden Daten:
Designelement, das als Stamm der sicherheitsrelevanten Anzeige festgelegt ist. Dieses Designelement ist auf das Fahrzeugdisplay abgestimmt. Die Größe muss dieselbe Auflösung wie das Display haben. Alle sicherheitsrelevanten Elemente müssen untergeordnete Elemente dieses Elements sein. Sie müssen keine direkten untergeordneten Elemente sein, sondern können in Zwischenknoten verschachtelt sein. Dieser Stamm ist das Stammknotenobjekt und sein Name muss mit einem Knoten im Designdokument übereinstimmen.
Zieldisplay für das Design Um UIs mit Elementen auf mehreren Displays zu unterstützen, kann in der Konfigurationsdatei mehr als ein Design angegeben werden. Jedes Design ist für die Anzeige auf einem separaten Bildschirm vorgesehen.
Dictionary mit Namen von Fahrzeugbussignalen und zugehörigen UI-Elementen. Schlüssel und Werte dieses Dictionary sind:
Schlüssel:Name des Fahrzeugbussignals, das eine Bedeutung enthält, sodass das zugehörige UI-Element angezeigt wird, wenn dieses Signal aktiv ist. Wenn das Signal inaktiv ist, wird das zugehörige UI-Element nicht angezeigt.
Werte:Figma-Knoten-ID für das sicherheitsrelevante Element, das vom Fahrzeugbussignal gesteuert wird.
Beispiel für eine JSON-Konfigurationsdatei:
{
"documents" : [
{
"rootnode" : "#Stage",
"display_id" : 1,
"document_id": "GLJJrR1JI4HVEjL1qB40zq",
"states" : {
"abs": "#cluster/telltale/abs",
"airbag": "#cluster/telltale/airbag",
"low_tire_pressure": "#cluster/telltale/low-tire-pressure",
"brake": "#cluster/telltale/brake",
"traction": "#cluster/telltale/traction",
"lowbeam": "#cluster/telltale/lowbeam",
"hibeam": "#cluster/telltale/hibeam",
"park_lights": "#cluster/telltale/park-lights",
"fog_lights": "#cluster/telltale/fog-lights",
"seatbelts" : "#cluster/telltale/no-seatbelt"
}
}
]
,
"displays": [
{
"id": 1,
"width": 1920,
"height": 720
}
]
}
Design-Compiler ausführen
So führen Sie den Design-Compiler aus:
/path/to/safety-design-compiler -c path/to/<input-file>.json
-o path/to/output_directory
Die Eingaben für den Design-Compiler werden in dieser Tabelle beschrieben:
| Eingabe | Kurz | Typ | Beschreibung |
|---|---|---|---|
| Konfiguration | -c |
String | Pfad, unter dem die JSON-Datei mit der Sicherheitskonfiguration gespeichert werden soll. |
| Ausgabe | -o |
String | Pfad, unter dem generierte Artefakte gespeichert werden sollen. |
Compiler-Ausgabe entwerfen
Der Design-Compiler generiert und speichert die Ausgabe im Ausgabeverzeichnis, das beim Aufrufen des Compiler-Tools angegeben wurde. Mit dieser Ausgabe werden die Headerdateien generiert, die zum Definieren der Pixeltests zur Laufzeit im Sicherheitsmonitor und zum Generieren des lesbaren Berichts verwendet werden. Die Ausgabe des Design-Compilers wird in einer ZIP-Datei bereitgestellt, die Folgendes enthält:
Die Metadatendatei
data.jsonim Stammverzeichnis der exportierten Assets beschreibt die Struktur des exportierten Designs. Alle Pfade in der Datei sind relativ zu dieser Datei.Eine Reihe von isolierten Bildern von UI-Elementen, die sicherheitsrelevante UI-Elemente im aktiven Zustand zeigen, die bei der nachfolgenden Code-Generierung verwendet werden. Der Alphakanal in diesen Bildern enthält Pixelinformationen, die sich nicht auf die Sicherheit auswirken.
Eine Reihe von Bildern der vollständigen Benutzeroberfläche, die sicherheitsrelevante UI-Elemente im aktiven und inaktiven Zustand zeigen, zur Verwendung beim Testen des generierten Codes.
Aktualisierte Version des serialisierten Figma-Dokuments, das vom Compiler als Eingabe verwendet wird. Das HAR kennzeichnet und aktualisiert die in
Config.jsonangegebenen Knoten für die weitere Verarbeitung, indem das FlagRenderOptions::PixelPerfectim Toolkitschema festgelegt wird.
Diese Abbildung zeigt eine Figma-Designdatei.
Abbildung 4: Inhalt der ZIP-Datei
Eingabedatei erstellen
Erstellen Sie eine data.json-Eingabedatei für den Generator für Sicherheitsmonitore. Die Ausgabe ist als Array strukturiert, das Dimensionsdaten und einen Bildlink für jedes sicherheitsrelevante Anzeigeelement enthält. Die Struktur dieser Ausgabedatei wird in dieser Tabelle beschrieben:
| Element | Typ | Einheiten | Beschreibung |
|---|---|---|---|
static_ui_elements |
Wörterbuch | – | Struktur mit Metadaten für alle sicherheitsrelevanten UI-Elemente, die aus dem Figma-Dokument extrahiert wurden. |
x |
int | Pixel | Horizontale Koordinate des sicherheitsrelevanten Elements. |
y |
int | Pixel | Vertikale Koordinate des sicherheitsrelevanten Elements. |
width |
int | Pixel | Die Breite des sicherheitsrelevanten Elements |
height |
int | Pixel | Höhe des sicherheitsrelevanten Elements. |
name |
String | – | Name des sicherheitsrelevanten UI-Elements, das aus dem Figma-Dokument extrahiert wurde. Stellt den relativen Pfad zu Bildern dar, die mit diesem Element generiert wurden. |
screen |
Wörterbuch zur Beschreibung des Bildschirms, auf den sich die Benutzeroberfläche bezieht. | ||
width |
int | Pixel | Breite der Figma-Dokument-Benutzeroberfläche. |
height |
int | Pixel | Höhe der Figma-Dokument-Benutzeroberfläche. |
build |
Wörterbuch mit Build-Informationen für diesen Aufruf des Design-Compilers. | ||
figma_document_id |
String | – | ID des Figma-Dokuments, das zum Generieren der Artefakte verwendet wurde. |
design_compiler_version |
String | – | Version von Design Compiler, die zum Generieren der Artefakte verwendet wurde. |
In diesem Abschnitt finden Sie ein Beispiel für eine generierte data.json-Datei:
{
"static_ui_elements": [
{
"x": 71,
"y": 663,
"width": 38,
"height": 47,
"name": "cluster/telltale/no-seatbelt"
},
{
"x": 149,
"y": 667,
"width": 40,
"height": 39,
"name": "cluster/telltale/low-tire-pressure"
},
{
"x": 1727,
"y": 676,
"width": 43,
"height": 27,
"name": "cluster/telltale/hibeam"
},
{
"x": 1810,
"y": 675,
"width": 43,
"height": 30,
"name": "cluster/telltale/lowbeam"
},
...
...
],
"screen": {
"width": 1920,
"height": 720
},
"build": {
"figma_document_id": "taQnsdPS96wZY8dB1TbzOH",
"design_compiler_version": "0.1.0"
}
}
Exportierte Designbilder
Das System rendert und speichert Bilder der sicherheitsrelevanten Knoten in einer verschachtelten Verzeichnisstruktur basierend auf ihrer Benennung im serialisierten Designdokument.
Abbildung 5: Bestätigungsbilder.
Das System generiert für jede angegebene Kontrollleuchte Bilder mit sicherheitsrelevanten Elementinformationen. Diese Bilder enthalten die erwarteten Pixel des sicherheitskritischen Elements, wenn es auf dem Bildschirm zu sehen ist. Der Sicherheitsmonitor ignoriert möglicherweise die transparenten Pixel in diesen Bildern für die Laufzeit-Pixeltests.
Das System generiert auch Bilder für UI-Tests und ‑Überprüfungen. Es werden Screenshots der gesamten Benutzeroberfläche mit jedem einzelnen Telltale gerendert und zur Generierung eines für Menschen lesbaren Berichts bereitgestellt, damit Sicherheitsexperten die Sicherheitskonfiguration überprüfen und genehmigen können.
Sie können diese Bilder auch für nachfolgende Tests des Sicherheitsmonitors verwenden. Das System generiert Prüfbilder für alle Kontrollleuchten im Ein- und Aus-Zustand.
Diese Bilder veranschaulichen das Design mit allen sicherheitsrelevanten Elementen, aktiv und inaktiv.
Abbildung 6 und Abbildung 7. Aktive und inaktive sicherheitsrelevante Elemente.
Abbildung 8 zeigt das sicherheitsrelevante Informationsbild für die Kontrollleuchte „Kein Sicherheitsgurt“:
Abbildung 8. Kontrollleuchte für nicht angelegten Sicherheitsgurt.
Abbildung 9 zeigt das Bild für UI-Tests und ‑Überprüfung für die Kontrollleuchte.
Abbildung 9. UI-Tests und ‑bestätigung für das Kontrolllämpchen.
Das System generiert Prüfbilder für jedes Element im kompilierten Artefaktordner. Das System verarbeitet diese Bilder im Schritt zur Code-Generierung und fügt sie einer Header-Datei hinzu, die für Pixeltests zur Laufzeit im Sicherheitsmonitor verwendet werden soll.
Für Menschen lesbarer Berichtsgenerator
Nachdem Sie die Artefakte aus einem Figma-Dokument generiert haben, können Sie einen lesbaren Bericht erstellen. Der Berichtsgenerator befindet sich unter utils/human-readable-report-generator.
Das System fasst Artefakte der sicherheitsrelevanten Knoten, die vom Design Compiler generiert wurden, in einer HTML-Datei zusammen, einschließlich eines Screenshots der Benutzeroberfläche mit dem aktiven Knoten. Sie können die kompilierten Artefakte prüfen, bevor Sie den Sicherheitsmonitor erstellen.
Führen Sie den Berichtsgenerator über die Befehlszeile aus:
cargo run --bin human-readable-report-generator -- -d /path/to/data.json
-o /path/to/output_folder
In dieser Tabelle werden für Menschen lesbare Eingaben für die Berichtsgenerierung beschrieben.
| Eingabe | Kurz | Typ | Beschreibung |
|---|---|---|---|
data_folder |
-d |
String | Speicherort von data.json, das vom Sicherheitscompiler generiert wurde. |
output_path |
-o |
String | Pfad zum Speichern des generierten Berichts. |
Tool zur Sicherheitsgenehmigung
Um ein Genehmigungstoken zu generieren, kann ein Sicherheitsexperte nach der Überprüfung des menschenlesbaren Berichts das Sicherheitsgenehmigungsskript für die output.json ausführen.
Dieses Tool befindet sich ebenfalls in utils/human-readable-report-generator.
Beispiel:
cargo run --bin approve-hrr -- -f /path/to/compiler_inspection_output.html -n
"Your Name" -e youremail@domain.com -o output/path
Abbildung 10. Beispiel für einen HTML-Bericht.
In diesem Abschnitt werden die Eingaben für das Tool zur Sicherheitsgenehmigung beschrieben.
| Eingabe | Kurz | Typ | Beschreibung |
|---|---|---|---|
file_path |
-f |
String | Dateipfad zum für Menschen lesbaren Bericht. |
approver_name |
-n |
String | Name des genehmigenden Technikers. |
approver_email |
-e |
String | E-Mail-Adresse des genehmigenden Technikers. |
output_path |
-o |
String | Ziel für die generierte Ausgabe. |
In diesem Abschnitt sehen Sie ein Beispiel für approval_file.json.
{
"approver_name": //Name of the approver
"approver_email": //Email of the approver
"file_hash": //SHA-256 hash generated against the human readable report.
}
Referenz-Sicherheitsmonitor
Der Referenz-Sicherheitsmonitor ist ein Rust-basierter Dienst, der sich unter reference/safety-monitor befindet. Der Monitor verwendet die vom Design Compiler generierten Artefakte, um den Systemstatus zu überwachen und die Einhaltung der Display-Sicherheitsanforderungen zu gewährleisten.
Der Monitor wird als eigenständige Binärdatei (har_safety_monitor) ausgeführt und verwendet den Pfad zur data.json-Datei und den Basispfad für Artefakte als Argumente.
/path/to/har_safety_monitor --data-json-path /path/to/data.json
--artifact-base-path /path/to/artifacts
Der Monitor führt die folgenden Aufgaben aus:
- Artefakt wird geladen:Lädt
data.json, um sicherheitsrelevante UI-Elemente sowie ihre erwarteten Positionen und Abmessungen zu identifizieren. - Vergleich mit Golden Images:Vergleicht den aktuellen Bildschirminhalt mit Golden Images von sicherheitskritischen Elementen, die vom Compiler generiert wurden.
- Datenintegration von Fahrzeugen:Stellt eine Verbindung zu Fahrzeugdatenquellen her, um den erwarteten Status der einzelnen Kontrollleuchten zu ermitteln.
- Erkennung von Abweichungen:Es wird ein Fehler protokolliert, wenn es eine Abweichung zwischen dem gibt, was basierend auf den Fahrzeugdaten erwartet wird, und dem, was auf dem Bildschirm zu sehen ist.
Der Sicherheitsmonitor ist so konzipiert, dass er als Teil des System-Images erstellt und bereitgestellt wird, in der Regel in einem dedizierten APEX.