Wasserfälle sind von Natur aus atemberaubend, daher ist es keine Überraschung, dass Ingenieure ein wenig von ihnen besessen sind. Der alte DOD-STD-2167A-Standard empfahl die Verwendung des Wasserfallmodells, und mein bisheriger technischer Hintergrund basierte auf dem Phase-Gate-Modell , das meiner Meinung nach dem Wasserfallmodell verdammt ähnlich ist. Andererseits wissen diejenigen von uns, die an der Universität Informatik studiert haben, wahrscheinlich, dass das Wasserfallmodell in gewisser Weise ein Anti-Muster ist . Unsere Freunde im akademischen Elfenbeinturm sagen uns nein, nein, AgileIst der Weg zum Erfolg und es sieht so aus, als hätte die Branche bewiesen, dass dieser Anspruch wahr ist.
Was sollte ein Entwickler zwischen dem alternden Wasserfallmodell und dem neumodischen Agile wählen? Ändert sich die Gleichung bei der Entwicklung von Algorithmen? Oder eine sicherheitskritische Software?
Wie im Leben üblich liegt die Antwort irgendwo dazwischen.
Hybrid, Spirale und V-Muster
Hybride Entwicklung ist die Antwort, die in der Mitte liegt. Wenn das Wasserfallmodell kein Zurückgehen und Ändern der Anforderungen zulässt, ist dies beim Hybridmodell der Fall. Und wo Agile Probleme mit dem Upfront-Design hat, lässt die Hybridentwicklung Raum dafür. Darüber hinaus zielt die Hybridentwicklung darauf ab, die Anzahl der Fehler im Endprodukt zu reduzieren , was wir wahrscheinlich beim Entwurf von Algorithmen für sicherheitskritische Anwendungen wünschen.
Hört sich gut an, aber wie effektiv ist es?
Um diese Frage zu beantworten, wir wetten auf Hybrid - Entwicklung , während auf der Arbeit des NDT Lokalisierungsalgorithmus.. Die Lokalisierung ist ein wesentlicher Bestandteil jedes selbstfahrenden Stacks, der über die reine reaktive Steuerung hinausgeht. Wenn Sie mir nicht glauben oder mit der Lokalisierung nicht vertraut sind, empfehle ich Ihnen dringend, sich einige der Designdokumente anzusehen , die durch diesen Prozess entwickelt wurden.
Was ist Hybridentwicklung auf den Punkt gebracht? Aus meiner Sicht als Amateur würde ich sagen, dass dies ein idealisiertes V-förmiges oder spiralförmiges Modell ist . Sie planen, entwerfen, implementieren und testen und durchlaufen dann den gesamten Prozess basierend auf den gewonnenen Erkenntnissen und den neuen Kenntnissen, die Sie in dieser Zeit gewonnen haben.
Praktischer Nutzen
Insbesondere haben wir mit der NDT-Arbeitsgruppe bei Autoware.Auto unseren ersten Abstieg entlang der linken Kaskade des V-Modells abgeschlossen (d. H. Die erste Iteration durch die Entwurfsphase durchgeführt), um uns auf den Autoware-Hackathon in London vorzubereiten (durchgeführt von Parkopedia !). Unser erster Durchgang durch die Entwurfsphase bestand aus den folgenden Schritten:
- Literaturische Rezension
- Übersicht über vorhandene Implementierungen
- Entwerfen von Komponenten auf hoher Ebene, Anwendungsfällen und Anforderungen
- Fehleranalyse
- Definition von Metriken
- API-Architektur und -Design
Sie können sich jedes der resultierenden Dokumente ansehen, wenn Sie an etwas Ähnlichem interessiert sind, aber für den Rest dieses Beitrags werde ich versuchen, einige davon aufzuschlüsseln und auch zu erklären, was und warum in jeder dieser Phasen daraus entstanden ist.
Überprüfung der Literatur und bestehender Implementierungen
Der erste Schritt in einem anständigen Unterfangen (so würde ich eine NDT-Implementierung klassifizieren) ist zu sehen, was andere Leute getan haben. Menschen sind schließlich soziale Wesen, und alle unsere Errungenschaften stehen auf den Schultern von Riesen.
Abgesehen von Anspielungen sind bei der Betrachtung der „Kunst der Vergangenheit“ zwei wichtige Bereiche zu berücksichtigen: akademische Literatur und funktionale Realisierungen.
Es ist immer hilfreich zu sehen, woran arme Doktoranden mitten in der Hungersnot gearbeitet haben. Bestenfalls werden Sie feststellen, dass es einen hervorragenden Algorithmus gibt, den Sie anstelle Ihres eigenen implementieren können. Im schlimmsten Fall erhalten Sie ein Verständnis für den Raum und die Variation von Lösungen (die zur Informationsarchitektur beitragen können), und Sie können auch einige der theoretischen Grundlagen des Algorithmus kennenlernen (und somit auf welche Invarianten Sie achten sollten ).
Auf der anderen Seite ist es genauso hilfreich zu sehen, was andere Leute tun - schließlich ist es immer am einfachsten, etwas mit einer Startaufforderung zu beginnen. Sie können nicht nur kostenlos gute Architekturideen ausleihen, sondern auch einige der Vermutungen und schmutzigen Tricks entdecken, die Sie möglicherweise benötigen, um den Algorithmus in die Praxis umzusetzen (und Sie können sie möglicherweise sogar vollständig in Ihre Architektur integrieren).
Aus unserer Überprüfung der NDT-Literatur haben wir die folgenden nützlichen Informationen zusammengestellt:
- Die NDT-Familie von Algorithmen weist verschiedene Variationen auf:
- P2D
- D2D
- Limited
- Semantic - Es gibt unzählige schmutzige Tricks, mit denen der Algorithmus eine bessere Leistung erzielen kann.
- NDT wird normalerweise mit ICP verglichen
- NDT ist etwas schneller und etwas zuverlässiger.
- NDT arbeitet zuverlässig (hat eine hohe Erfolgsquote) innerhalb eines definierten Bereichs
Nichts Unglaubliches, aber diese Informationen können für die spätere Verwendung sowohl beim Design als auch bei der Implementierung gespeichert werden.
Ebenso haben wir aus unserer Übersicht über vorhandene Implementierungen nicht nur konkrete Schritte gesehen, sondern auch einige interessante Initialisierungsstrategien.
Anwendungsfälle, Anforderungen und Mechanismen
Ein wesentlicher Bestandteil jedes Entwurfs- oder Plan-First-Entwicklungsprozesses besteht darin, das Problem, das Sie lösen möchten, auf hoher Ebene anzugehen. Im weitesten Sinne ist die "hochrangige Sicht des Problems" unter dem Gesichtspunkt der funktionalen Sicherheit (die ich gestehe, ich bin weit entfernt von einem Experten) ungefähr wie folgt organisiert:
- Was die Verwendung Fällen versuchen Sie zu lösen?
- Was sind die Anforderungen (oder Einschränkungen) für eine Lösung, um die oben genannten Anwendungsfälle zu erfüllen?
- Welche Mechanismen erfüllen die oben genannten Anforderungen?
Der oben beschriebene Prozess bietet eine disziplinierte Gesamtansicht des Problems und wird schrittweise detaillierter.
Um eine Vorstellung davon zu bekommen, wie dies aussehen könnte, können Sie sich das übergeordnete Projektdokument zur Lokalisierung ansehen, das wir zur Vorbereitung der Entwicklung des NDT zusammengestellt haben. Wenn Sie nicht in der Stimmung sind, vor dem Schlafengehen zu lesen, lesen Sie weiter.
Anwendungsfälle
Ich mag drei Denkansätze für Anwendungsfälle (Achtung, ich bin kein Experte für funktionale Sicherheit):
- Was soll die Komponente tun? ( Erinnere dich an SOTIF !)
- Wie kann ich Eingaben in eine Komponente eingeben? (Input Use Cases, ich nenne sie gerne Upstream)
- Wie kann ich die Ausgabe erhalten? (Wochenend- oder Top-Down-Anwendungsfälle)
- Bonusfrage: In welchen Gesamtsystemarchitekturen kann sich diese Komponente befinden?
Alles zusammen haben wir uns Folgendes ausgedacht:
- Die meisten Algorithmen können Lokalisierung verwenden, aber letztendlich können sie in Varianten unterteilt werden, die sowohl lokal als auch global funktionieren.
- Lokale Algorithmen benötigen Kontinuität in ihrer Transformationshistorie.
- Fast jeder Sensor kann als Quelle für Lokalisierungsdaten verwendet werden.
- Wir brauchen eine Möglichkeit, unsere Lokalisierungsmethoden zu initialisieren und Fehler zu beheben.
Abgesehen von den verschiedenen Anwendungsfällen, an die Sie denken können, denke ich auch gerne an einige häufig verwendete Anwendungsfälle, die sehr streng sind. Dazu habe ich die Möglichkeit (oder Aufgabe) einer völlig unbemannten Offroad-Fahrt, die durch mehrere Tunnel mit Verkehr in einem Wohnwagen führt. Es gibt einige Probleme mit diesem Anwendungsfall, wie die Anhäufung von Kilometerzählungsfehlern, Gleitkommafehlern, Lokalisierungskorrekturen und Ausfällen.
Bedarf
Der Zweck der Entwicklung von Anwendungsfällen besteht neben der Verallgemeinerung aller Probleme, die Sie lösen möchten, darin, Anforderungen zu definieren. Damit ein Anwendungsfall stattfinden kann (oder erfüllt werden kann), müssen wahrscheinlich einige Faktoren realisiert oder möglich sein. Mit anderen Worten, jeder Anwendungsfall hat bestimmte Anforderungen.
Letztendlich sind die allgemeinen Anforderungen an ein Lokalisierungssystem nicht so beängstigend:
- Stellen Sie Transformationen für lokale Algorithmen bereit
- Stellen Sie Transformationen für globale Algorithmen bereit
- Bereitstellung des Mechanismus zur Initialisierung relativer Lokalisierungsalgorithmen
- Stellen Sie sicher, dass keine Conversions überlaufen
- Stellen Sie die REP105-Konformität sicher
Qualifizierte Spezialisten für funktionale Sicherheit werden wahrscheinlich viel mehr Anforderungen formulieren. Der Wert dieser Arbeit liegt in der Tatsache, dass wir bestimmte Anforderungen (oder Einschränkungen) für unser Design klar formulieren, die wie Mechanismen unsere Anforderungen für den Betrieb des Algorithmus erfüllen.
Die Mechanismen
Das Endergebnis jeder Art von Analyse sollte ein praktischer Satz von Lektionen oder Materialien sein. Wenn wir als Ergebnis der Analyse das Ergebnis nicht verwenden können (auch kein negatives!), Wurde die Analyse verschwendet.
Im Fall eines übergeordneten Konstruktionsdokuments handelt es sich um eine Reihe von Mechanismen oder ein Konstrukt, das diese Mechanismen kapselt und für unsere Anwendungsfälle angemessen geeignet ist.
Dieses spezielle Lokalisierungsdesign auf hoher Ebene ermöglichte die Reihe von Softwarekomponenten, Schnittstellen und Verhaltensweisen, aus denen die Architektur des Lokalisierungssystems besteht. Ein einfaches Blockdiagramm der vorgeschlagenen Architektur ist unten gezeigt.
Wenn Sie an weiteren Informationen zu Architektur oder Design interessiert sind, empfehle ich Ihnen dringend, diese zu lesenden vollständigen Text des Dokuments .
Fehleranalyse
Da wir Komponenten auf sicherheitskritischen Systemen aufbauen, sollten wir versuchen, Fehler zu vermeiden oder zumindest zu mindern. Bevor wir versuchen, etwas zu entwerfen oder zu bauen, sollten wir uns zumindest darüber im Klaren sein, wie Dinge kaputt gehen können.
Wie in den meisten Fällen ist es bei der Analyse von Fehlern hilfreich, eine Komponente aus mehreren Blickwinkeln zu betrachten. Um die Fehler des NDT-Algorithmus zu analysieren, haben wir ihn auf zwei verschiedene Arten betrachtet: als allgemeinen (relativen) Lokalisierungsmechanismus und speziell als Instanz des NDT-Algorithmus.
Unter dem Gesichtspunkt des Lokalisierungsmechanismus wird der Hauptfehlermodus wie folgt formuliert: "Was ist zu tun, wenn die Eingabe falsche Daten enthält?" In der Tat kann aus Sicht einer einzelnen Komponente nur wenig getan werden, um eine grundlegende Überprüfung der Angemessenheit des Systems durchzuführen. Auf Systemebene haben Sie zusätzliche Optionen (z. B. Aktivieren von Sicherheitsfunktionen).
Wenn NDT als isolierter Algorithmus betrachtet wird, ist es nützlich, vom Algorithmus zu abstrahieren, indem die entsprechende Anzahl von Aspekten hervorgehoben wird. Es ist hilfreich, auf die Pseudocode-Version des Algorithmus zu achten (dies hilft Ihnen als Entwickler, den Algorithmus besser zu verstehen). In diesem Fall haben wir den Algorithmus detailliert analysiert und alle Situationen untersucht, in denen er brechen kann.
Ein Implementierungsfehler ist ein durchaus vernünftiger Fehler, der jedoch durch geeignete Tests behoben werden kann. Einige Nuancen in Bezug auf numerische Algorithmen tauchten etwas häufiger und heimtückischer auf. Insbesondere geht es darum, inverse Matrizen zu finden oder allgemeiner lineare Gleichungssysteme zu lösen, die zu numerischen Fehlern führen können. Dies ist ein sehr sensibles Fehlerszenario und sollte behoben werden.
Zwei weitere wichtige Fehler, die wir ebenfalls identifiziert haben, sind die Überprüfung, ob bestimmte Ausdrücke nicht unbegrenzt groß sind (Gleitkomma-Präzisionssteuerung), und die Überprüfung, ob die Größe oder Größe der Eingaben ständig überwacht wird.
Insgesamt haben wir 15 Empfehlungen entwickelt. Ich würde empfehlen, dass Sie sich mit ihnen vertraut machen.
Ich möchte auch hinzufügen, dass die Fehlerbaumanalyse ein hervorragendes Werkzeug zur Strukturierung und Quantifizierung des Problems der Fehleranalyse ist , obwohl wir diese Methode nicht verwendet haben .
Definition von Metriken
"Was gemessen wird, ist überschaubar"Leider reicht es in der beruflichen Entwicklung nicht aus, mit den Schultern zu zucken und „erledigt“ zu sagen, wenn Sie es leid sind, an etwas zu arbeiten. Grundsätzlich erfordert jedes Arbeitspaket (das wiederum eine NDT-Entwicklung ist) Akzeptanzkriterien, die sowohl vom Kunden als auch vom Lieferanten vereinbart werden müssen (wenn Sie sowohl Kunde als auch Verkäufer sind, überspringen Sie diesen Schritt). Die gesamte Rechtsprechung ist vorhanden, um diese Aspekte zu unterstützen. Als Ingenieure können wir jedoch einfach die Zwischenhändler ausschalten, indem wir Metriken erstellen, um die Verfügbarkeit unserer Komponenten zu bestimmen. Immerhin sind die Zahlen (meistens) eindeutig und unwiderlegbar.
- beliebte Redewendung von Managern
Auch wenn Akzeptanzkriterien unnötig oder irrelevant sind, ist es immer noch schön, einen genau definierten Satz von Metriken zu haben, die die Qualität und Leistung eines Projekts charakterisieren und verbessern. Am Ende ist das, was gemessen wird, steuerbar.
Für unsere NDT-Implementierung haben wir die Metriken in vier große Gruppen aufgeteilt:
- Allgemeine Softwarequalitätsmetriken
- Allgemeine Firmware-Qualitätsmetriken
- Allgemeine Metriken des Algorithmus
- Lokalisierungsspezifische Metriken
Ich werde nicht auf Details eingehen, da diese Metriken alle relativ Standard sind. Wichtig ist, dass die Metriken für unser spezifisches Problem definiert und identifiziert wurden. Dies ist ungefähr das, was wir als Entwickler eines Open-Source-Projekts erreichen können. Letztendlich sollte die Akzeptanzgrenze basierend auf den Besonderheiten des Projekts von denjenigen festgelegt werden, die das System bereitstellen.
Das Letzte, was ich hier wiederholen werde, ist, dass Metriken zwar fantastisch zu testen sind, aber keinen Ersatz für die Überprüfung des Implementierungsverständnisses und der Verwendungsanforderungen darstellen.
Architektur und API
Nachdem wir das Problem, das wir zu lösen versuchen, sorgfältig definiert und ein Verständnis für den Lösungsraum aufgebaut haben, können wir endlich in den Bereich eintauchen, der an die Implementierung grenzt.
Ich war in letzter Zeit ein Fan von testgetriebener Entwicklung . Wie die meisten Ingenieure liebe ich den Entwicklungsprozess, und die Idee, Tests zu schreiben, erschien mir in erster Linie umständlich. Als ich anfing, professionell zu programmieren, ging ich geradeaus und testete nach der Entwicklung (obwohl meine Universitätsprofessoren mir sagten, ich solle das Gegenteil tun). ForschungZeigen Sie, dass das Schreiben von Tests vor der Implementierung tendenziell zu weniger Fehlern, einer höheren Testabdeckung und allgemein besserem Code führt. Vielleicht noch wichtiger ist, dass eine testgetriebene Entwicklung dazu beiträgt, das große Problem der Algorithmusimplementierung anzugehen.
Wie sieht es aus?
Anstatt ein monolithisches Ticket namens "Implement NDT" (einschließlich Tests) einzuführen, das zu mehreren tausend Codezeilen führt (die nicht effektiv angezeigt und untersucht werden können), können Sie das Problem in aussagekräftigere Fragmente aufteilen:
- Schreiben Sie Klassen und öffentliche Methoden für einen Algorithmus (erstellen Sie eine Architektur)
- Schreiben Sie Tests für den Algorithmus mithilfe der öffentlichen API (sie sollten fehlschlagen!).
- Implementieren Sie die Logik des Algorithmus
Der erste Schritt besteht also darin, die Architektur und die API für den Algorithmus zu schreiben. Ich werde die anderen Schritte in einem anderen Beitrag behandeln.
Während es viele Arbeiten gibt, die darüber sprechen, wie man "Architektur schafft", scheint es mir, dass das Entwerfen von Softwarearchitektur etwas mit schwarzer Magie zu tun hat. Persönlich denke ich gerne daran, dass Softwarearchitektur Grenzen zwischen Konzepten zieht und versucht, die Freiheitsgrade bei der Aufstellung eines Problems zu charakterisieren und es in Bezug auf Konzepte zu lösen.
Was sind dann die Freiheitsgrade in NDT?
Eine Überprüfung der Literatur zeigt, dass es verschiedene Möglichkeiten gibt, Scans und Beobachtungen darzustellen (z. B. P2D-NDT und D2D-NDT). In unserem hochrangigen technischen Dokument heißt es ebenfalls, dass wir verschiedene Möglichkeiten haben, die Karte darzustellen (statisch und dynamisch), sodass dies auch ein Freiheitsgrad ist. Neuere Literatur schlägt auch vor, dass das Optimierungsproblem erneut aufgegriffen werden könnte. Wenn wir jedoch die praktische Implementierung und die Literatur vergleichen, sehen wir, dass sogar die Details der Optimierungslösung abweichen können.
Und die Liste geht weiter und weiter.
Basierend auf den Ergebnissen des ursprünglichen Entwurfs haben wir uns für die folgenden Konzepte entschieden:
- Optimierungsprobleme
- Optimierungslösungen
- Scanansicht
- Kartenansicht
- Anfängliche Hypothesengenerierungssysteme
- Algorithmus- und Knotenschnittstellen
Mit einigen Unterteilungen innerhalb dieser Elemente.
Die ultimative Erwartung einer Architektur ist, dass sie erweiterbar und wartbar sein sollte. Ob unsere vorgeschlagene Architektur dieser Hoffnung gerecht wird, wird nur die Zeit zeigen.
Des Weiteren
Nach dem Design ist es natürlich Zeit für die Implementierung. Offizielle Arbeiten zur Implementierung von NDT in Autoware.Auto wurden beim von Parkopedia organisierten Autoware-Hackathon durchgeführt .
Es sollte wiederholt werden, dass das, was in diesem Text vorgestellt wurde, nur der erste Durchgang durch die Entwurfsphase ist. Bekanntdass kein Schlachtplan es aushält, sich dem Feind zu stellen, und dasselbe gilt für das Software-Design. Das endgültige Versagen des Wasserfallmodells wurde unter der Annahme durchgeführt, dass die Spezifikation und das Design perfekt waren. Es ist unnötig zu erwähnen, dass weder die Spezifikation noch das Design perfekt sind. Mit fortschreitender Implementierung und Prüfung werden Fehler entdeckt und Änderungen an den hier beschriebenen Designs und Dokumenten vorgenommen.
Und das ist okay. Wir als Ingenieure sind nicht unsere Arbeit oder identifizieren uns damit, und alles, was wir versuchen können, ist zu iterieren und nach perfekten Systemen zu streben. Nach all dem, was über die Entwicklung des NDT gesagt wurde, denke ich, dass wir einen guten ersten Schritt gemacht haben.
Abonnieren Sie Kanäle:
@TeslaHackers — Tesla-, Tesla
@AutomotiveRu — ,
: