Toolchain für das Sicherheitsdesign

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.

Toolchain für das Sicherheitsdesign

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.

Workflow für die Toolchain für das Sicherheitsdesign

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.

Beispiel-Figma-Designdatei zum Erstellen des Sicherheitsmonitors

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.json im 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.json angegebenen Knoten für die weitere Verarbeitung, indem das Flag RenderOptions::PixelPerfect im Toolkitschema festgelegt wird.

Diese Abbildung zeigt eine Figma-Designdatei.

Inhalte der ZIP-Datei

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.

Verzeichnisstruktur der generierten Bestätigungsbilder

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.

Aktive und inaktive sicherheitsrelevante Elemente Aktive und inaktive sicherheitsrelevante Elemente

Abbildung 6 und Abbildung 7. Aktive und inaktive sicherheitsrelevante Elemente.

Abbildung 8 zeigt das sicherheitsrelevante Informationsbild für die Kontrollleuchte „Kein Sicherheitsgurt“:

Sicherheitsrelevante Informationen zur Kontrollleuchte für nicht angelegten 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.

UI-Tests und ‑bestätigung 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

HTML-Beispielbericht zur Überprüfung

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.