TL;DR. Unsere empfohlene Methodik für die Konzeption von Lokalisierungssystemen basiert auf dem V-Modell: einem strukturierten Weg von den Anforderungen bis zur Serienproduktion bei minimalem Risiko, minimalen Kosten und minimalem Zeitaufwand. Auf der linken Seite des V-Modells erfolgt die Definition und Konzeption; auf der rechten Seite die Validierung und Skalierung. Jede Entscheidung auf der linken Seite wird auf der rechten Seite zu einem Test oder einer Einschränkung, und die Kosten für eine Änderung steigen pro Stufe um etwa das Zehnfache.
Bei den schwierigsten Positionierungsproblemen geht es selten um die Positionierung selbst. Es geht vielmehr um die Systemgestaltung.
Im Bereich Field Engineering bei Point One wenden sich die Teams für Robotik und Autonomie zunächst mit einer Frage zu Korrekturen an unserem RTK-Netzwerk oder unserer Positionsbestimmungs-Engine an uns, doch innerhalb weniger Minuten entwickelt sich daraus meist eine umfassendere Diskussion über alle Komponenten des Lokalisierungs-Stacks und deren Zusammenspiel.
Man kann keine hochwertige Positionierung erzielen, ohne die Entscheidungen auf Komponentenebene richtig zu treffen. Bevor wir auf bestimmte Komponenten, Fehler oder bewährte Verfahren eingehen, lohnt es sich, einen Überblick über das V-Modell und die Methodik zu geben, mit der Sie bei minimalem Risiko, geringsten Kosten und kürzestem Zeitplan zur Serienfertigung gelangen.
Entwurf eines Lokalisierungssystems definiert
Beim Systemdesign geht es darum, herauszufinden, was man entwickelt, wie es architektonisch aufgebaut sein wird und wie es getestet werden soll, bevor man sich auf die detaillierte Konstruktion und Fertigung festlegt. Wenn dies gut gemacht wird, entstehen klare Anforderungen, eine Architektur, die diesen gerecht wird, sowie ein Validierungsplan, der dies nachweist.
Ein Lokalisierungssystem ist die Gesamtheit der Komponenten, die einem Roboter, Fahrzeug oder Gerät seine Position in der Welt ermittelt. Point One konzentriert sich auf GNSS und Inertialfusion, doch damit ist die Arbeit selten abgeschlossen; wir unterstützen unsere Kunden über den gesamten Stack hinweg, den sie entwickeln. Dieser Stack umfasst alles, was mit der letztendlichen Positionsbestimmung zusammenhängt: Antennen, GNSS-Empfänger, IMUs, die Plattformdynamik, die der Bewegungsweise einer bestimmten Maschine innewohnt, sowie in zunehmendem Maße die Sensorfusion von Kameras und Lidar mit der GNSS/INS-Lösung.
Die folgenden Beispiele stammen aus GNSS-gestützten Stapeln, da wir in diesem Bereich den Großteil unserer Zeit mit Kunden verbringen.
Das V-Modell – in seiner Form
Der V-Modell-Ansatz ist ein weit verbreiteter Standard in der Systemtechnik, der in der Luft- und Raumfahrt, der Verteidigungsindustrie und der Automobilentwicklung zum Einsatz kommt. Wir haben ihn speziell für die Lokalisierung angepasst.
Auf der linken Seite legen Sie fest, was Sie entwickeln: Anforderungen, Systementwurf, detaillierter Entwurf – wobei jede Stufe spezifischer ist als die vorherige. Im unteren Bereich bauen Sie die erste Hardware und validieren diese: EVT (Engineering Validation Test). Auf der rechten Seite stellen Sie sicher, dass das System bei zunehmender Integration und im größeren Maßstab funktioniert: DVT (Design Validation Test), PVT (Production Validation Test) und Serienproduktion.
Jeder Schritt auf der rechten Seite des V-Modells dient der Überprüfung einer zuvor auf der linken Seite getroffenen Entscheidung. So wird beispielsweise die Bauphase im EVT-Test, der detaillierte Entwurf im DVT-Test, der Systementwurf im PVT-Test und die Anforderungen bei der Abnahme validiert.
Jede Entscheidung auf der linken Seite führt auch zu einer Prüfung oder einer Einschränkung auf der rechten Seite. Wenn man auf der linken Seite etwas überstürzt hat, merkt man das auf der rechten Seite. Je weiter man auf der rechten Seite vorankommt, bevor man es bemerkt, desto aufwendiger ist die Behebung.
Die Phasen des V-Modells erklärt
Anforderungen
Es beginnt mit der Frage, von der alles andere abhängt: Was möchten Sie eigentlich erreichen?
Bei einem Lokalisierungssystem lautet die oberflächliche Antwort meist eine Zahl, etwa „wir benötigen eine Genauigkeit von 10 cm“. Doch das ist nur der Parameter, nicht die Anforderung. Die eigentlichen Fragen liegen darunter:
- Welche Positionsdaten benötigen Sie eigentlich? Absolute Position, Lage, Geschwindigkeit – oder alle drei?
- Welche geschäftlichen Ergebnisse hängen von dieser Position ab? Eine Drohne, die Kartendaten in Vermessungsqualität erfasst, hat ganz andere Anforderungen als ein Lieferroboter, der zu einer Haustür navigiert.
- In welcher Umgebung wird das System eingesetzt? Unter freiem Himmel, in einer „Urban Canyon“-Umgebung, in Innenräumen, unter einem Dach, oder in allen genannten Umgebungen?
- Was bedeutet „gut genug“, wenn die GNSS-Verbindung unterbrochen wird? Darf das System ausfallen, oder muss es weiterarbeiten?
- Welche Zuverlässigkeit muss die Anwendung aufweisen, und für welche Flottengröße gilt dies?
Die Frage ist nicht nur, wie genau, sondern auch, wie genau genug für welchen Zweck. Ein Team, das Kartierungen mit Drohnen durchführt, und ein Team für autonome Fahrzeuge könnten beide „drei Zentimeter“ angeben, doch die Anforderungen, die hinter diesen beiden Aussagen stehen, deuten auf völlig unterschiedliche Hardware-Stufen, Korrekturstrategien und IMU- Qualitätsklassen hin.
Wir verwenden viel Zeit darauf, unseren Kunden dabei zu helfen, Genauigkeitsziele in konkrete Anforderungen umzusetzen, die Umweltbedingungen, Dynamik, Fehlermodi und geschäftliche Ergebnisse berücksichtigen.
Systemdesign
Sobald die Anforderungen klar sind, wird im Rahmen der Systemkonzeption auf allgemeiner Ebene festgelegt, wie die Architektur aussehen soll. Welche Sensoren benötigt die Anwendung? Wie interagieren diese miteinander? Welche Hardware-Anforderungen ergeben sich aus den angestrebten Leistungszielen? Je nach Komplexität kann diese Phase schnell oder langwierig sein.
In dieser Phase entwerfen Sie noch keine endgültige Leiterplatte (PCB). Sie bauen eine hardware-getreue Version des Systems, das Sie entwickeln möchten – manchmal auf Basis von Entwicklungskits und Referenzhardware – und prüfen, ob es die Anforderungen erfüllt, bevor Sie mit dem detaillierten Entwurf beginnen.
Dies ist einer der Bereiche, in denen Point One den größten Nutzen erzielt. Wir halten die übliche Hardware vorrätig (Empfänger, IMUs, Antennen, Entwickler-Kits und die auf repräsentativen Rechenplattformen laufende Positionsbestimmungs-Engine), um frühzeitige Tests zu ermöglichen, ohne dass Sie alles selbst beschaffen und integrieren müssen. Dadurch verkürzt sich die Zeit von „Wir glauben, dass diese Architektur funktioniert“ bis hin zu „Wir haben gemessen, dass sie funktioniert“ von Monaten auf Wochen.
Detaillierte Planung
Die Detailkonstruktion wandelt die validierte Architektur in ein fertigungsreifes Produkt um: den Schaltplan, die mechanische CAD-Konstruktion, die Stückliste und das Leiterplattenlayout. Die Grenze zwischen den beiden Phasen kann verschwommen sein, doch die Unterscheidung ist wichtig. Bei der Systemkonstruktion wird die Funktionsweise des Systems validiert; die Detailkonstruktion wandelt es in etwas um, das man herstellen kann.
Die Erstellung eines detaillierten Entwurfs, bevor das System validiert wurde, ist einer der häufigsten Gründe, warum ein Programm kostspielige Nacharbeiten verursacht.
EVT, technischer Validierungstest
Am unteren Ende des V-Modells ist EVT der Zeitpunkt, an dem die vom Kunden entworfenen Platinen zum ersten Mal bei ihm eintreffen – in der Regel fünf oder zehn Stück. Das Ziel ist klar: Es soll überprüft werden, ob die Hardware funktioniert. Erhalten wir Daten vom Empfänger? Liefert die IMU Daten? Erzeugt das System die erwarteten Ausgangssignale?
Bei EVT geht es hauptsächlich um Labortests und technische Validierung und weniger um eine Validierung unter Praxism Bedingungen. Die Frage lautet: „Liefert der von uns entworfene Entwurf das erwartete Ergebnis?“
EVT ist KEIN Leistungstest. Sie werden noch nicht wissen, wie das System mit starken Mehrwegstörungen umgeht oder wie sich die IMU unter den tatsächlichen dynamischen Bedingungen Ihrer Plattform verhält. Das folgt als Nächstes mit DVT.
DVT, Designvalidierungstest
Mit DVT verlagert sich die Frage von „Funktioniert die Hardware?“ hin zu „Erfüllt das integrierte System die geschäftlichen und technischen Anforderungen?“. Sie testen nun in Umgebungen, die der tatsächlichen Anwendung entsprechen, mit einem Datenaufkommen im niedrigen dreistelligen Bereich, wobei die Daten durch den tatsächlichen Stack des Kunden fließen.
An dieser Stelle kommt die Plattformdynamik ins Spiel. Ein Motorrad ist ein gutes Beispiel. Bei der EVT wird auf einem Prüfstand überprüft, ob die Chips und die Platine korrekt arbeiten. Bei der DVT wird das Motorrad auf die Rennstrecke gebracht, um zu überprüfen, ob das System echte Lageänderungen in Kurven bewältigt – beispielsweise wie die Lageangaben bei einer scharfen Kurve aussehen. Das Ziel ist nicht mehr nur: „Meldet der Empfänger eine Position?“ sondern: „Bewältigt das Ortungssystem das, was die Plattform tatsächlich tut?“
Bei der Zusammenarbeit mit Kunden spielt Point One bei DVT eine zentrale Rolle. Wie Sie die Positionsdaten in Ihrem Gesamtsystem nutzen, die Integration optimieren und mit Randfällen umgehen – all das wird hier über unsere API, die Positionierungs-Engine und das Korrekturnetzwerk gesteuert.
Die bei DVT getroffenen Entscheidungen entscheiden darüber, ob das System den Sprung zu PVT übersteht.
PVT, Produktionsvalidierungstest
Bei der PVT stellt sich die Frage: Können wir das zuverlässig und in großen Stückzahlen herstellen? Die Herausforderung verlagert sich von der Frage „Funktioniert das Design?“ hin zu „Funktioniert der Produktionsprozess?“
Nach dem PVT-Test sollte das Design stabil sein. In der Regel haben Sie zu diesem Zeitpunkt bereits einige 10-fache Iterationen durchlaufen – von 5 Einheiten über 50 bis hin zu 500 –, wodurch Probleme zutage treten, die bei geringeren Stückzahlen nicht erkennbar sind. Der PVT-Test validiert den Fertigungsprozess: die Prüfstände, die Validierungssoftware, die Kalibrierungsverfahren und die Qualitätskontrollen. Es geht nicht mehr darum, ein funktionsfähiges Exemplar herzustellen, sondern darum, dies konsistent zu tun.
Hier werden auch die Validierungstools entwickelt, die in der Fertigungslinie zum Einsatz kommen, damit ein Gerät vor dem Versand mit der Software versehen und geprüft werden kann. Das ist ein eigenständiger Arbeitsbereich, der sowohl die Hardware- als auch die Software-Validierung umfasst und leicht unterschätzt wird. Point One unterstützt bei der Erstellung dieser Testpläne, einschließlich der API-Integration und der Funktionen, die in der Testumgebung verfügbar sein müssen, um eine Validierung in großem Maßstab zu ermöglichen.
Massenproduktion und Akzeptanz
In der Massenproduktion ist das Ziel einfach: Jedes Gerät, das vom Band läuft, entspricht jedes Mal den Spezifikationen. Der Lokalisierungs-Stack wird im Rahmen des Build-Prozesses geflasht und konfiguriert, und die PVT-Validierung wird nun als Produktions-Gate durchgeführt. Die Abnahme ist die endgültige Bestätigung, dass die zu Beginn festgelegten Anforderungen erfüllt wurden.
Die Kosten eines Rückschritts
Das V-Modell ist von Bedeutung, weil die Kosten für die Änderung einer Entscheidung mit jeder Stufe, die man nach rechts voranschreitet, stark ansteigen – und zwar um etwa das Zehnfache pro Stufe. Eine Änderung der Anforderungen bedeutet eine Besprechung. Eine Änderung des Systemdesigns bedeutet einige Tage Nacharbeit. Sobald jedoch der Schaltplan feststeht, entstehen echte Kosten. Sobald Prototypen gebaut sind, muss die Werkzeugausstattung angepasst werden. Sobald die Produktion läuft, droht ein Rückruf.
Diese Rechnung ist das gesamte Argument für die linke Seite. Dieselbe Entscheidung – ob sie nun von der linken Seite getroffen oder von der rechten Seite entdeckt wird – macht den Unterschied zwischen einem fünfminütigen Gespräch und einer sechsmonatigen Verzögerung aus.
Im inneren Ring bleiben statt im äußeren Ring
Wenn sich spät eine Lücke auf der linken Seite auftut, gerät ein Projekt in eine von zwei Schleifen. Die äußere Schleife lautet: Anforderungen, Entwurf, Entwicklung, EVT, Fehlschlag, von vorne beginnen – Monate und Budget sind verloren. Die innere Schleife lautet: Anforderungen, Proof of Concept, Systementwurf, Detailentwurf, mit ständigem Feedback zwischen den einzelnen Schritten – straff, kostengünstig, schnell.
Die Vorgehensweise, mit der Sie immer auf dem Laufenden bleiben, besteht darin, sich nicht auf eine bestimmte Architektur festzulegen, bevor Sie diese auf ihre Tauglichkeit geprüft haben. Wir empfehlen Ihnen, zwei oder drei Optionen offen zu halten, bis die Daten Ihnen zeigen, welche Sie verwerfen sollten.
Der Maßstab verändert, was zählt
Das V-Modell ist kein einmaliger Vorgang; jeder Sprung in der Größenordnung ist ein Übergang, bei dem das V-Modell erneut durchlaufen wird. Der Übergang von zehn Boards auf hundert bedeutet eine Verzehnfachung Ihrer Größenordnung, und Sie werden einige dieser Sprünge durchlaufen, bevor Sie sich sicher fühlen. Entscheidend ist, was sich auf jeder Stufe ändert: Bei zehn Einheiten kann man jedes Gerät noch von Hand optimieren; bei tausend dominieren die Stückkosten, und die Wahl einer günstigen IMU wirkt sich auf die Kosten der gesamten Flotte aus; bei zehntausend bedeutet eine Ausfallrate von einem Prozent, dass hundert Einheiten im Einsatz Probleme haben.
Mit jedem Sprung tauchen zudem neue Umgebungen und Anforderungen auf, die auf der vorherigen Stufe noch nicht sichtbar waren, was dich wieder auf die linke Seite zurückführt.
Was kommt als Nächstes: Häufige Fehler auf der linken Seite des V-Modells
Die Teams, die termingerecht liefern, sind nicht diejenigen mit den besten Entwickler oder den größten Budgets. Es sind diejenigen, die vor der Hardware-Bereitstellung einen strukturierten „Left Side“-Prozess durchlaufen: Anforderungen, die als Dialog behandelt werden, frühzeitige Tests in der realen Umgebung und ein Validierungsplan, der rückwärts von der Produktion ausgearbeitet wird. In späteren Beiträgen werden wir näher darauf eingehen, wie wir diesen Prozess umsetzen.
Das sind keine isolierten Probleme. Ein System, das zwar über alle richtigen Komponenten verfügt, aber falsch konfiguriert oder in der falschen Umgebung getestet wurde, wird nicht funktionieren. Es kommt darauf an, wie sich das System als Ganzes verhält.
Im nächsten Beitrag gehen wir auf die Fehler ein, die auf der linken Seite am häufigsten auftreten: das Copy-Paste von Empfängerspezifikationen als Anforderungen, die Wahl des Antennenstandorts aufgrund von Gehäuseanforderungen, die Auswahl der billigsten IMU ohne Modellierung von Ausfällen, die Annahme, dass Mobilfunk überall verfügbar ist, und die Validierung auf dem Parkplatz. Jeder dieser Fehler lässt sich auf der linken Seite vermeiden, ist aber auf der rechten Seite nur sehr schwer zu beheben.
Das V-Modell lässt sich nicht verkürzen. Man kann nur entscheiden, wo man die Zeit investiert: im kostengünstigen Anfang oder am teuren Ende.
🚀 Legen Sie einen Discovery-Workshop Termin mit einem Point One-Ingenieur fest
Sehen Sie sich das gesamte Gespräch an – „Das V-Modell für den Entwurf von Lokalisierungssystemen“
Häufige Fragen
Was versteht man unter dem V-Modell im Entwurf von Lokalisierungssystemen?
Das V-Modell ist eine Struktur um ein Produkt vom Konzept bis zur Serienfertigung zu dirigieren. Auf der linken Seite erfolgt die Definition und Konzeption anhand von Anforderungen, Systementwurf und Detailentwurf. Auf der rechten Seite erfolgt die Validierung durch EVT, DVT und PVT in zunehmend größerem Umfang. Jede Entwurfsentscheidung auf der linken Seite entspricht einem Test oder einer Nebenbedingung auf der rechten Seite.
Was ist ein Lokalisierungssystem?
Die gesamte Systemarchitektur, die für die Ermittlung einer zuverlässigen Positionsangabe verantwortlich ist, besteht aus: die GNSS-Antenne und der Empfänger, der IMU, die plattformspezifische Bewegungsdynamik, sowie die Positioning Engine Software, die alle diese Komponenten vereinigt. Viele Systeme verbinden zudem auch Kamera, Lidar oder Raddrehgeber Daten.
Was ist der Unterschied zwischen EVT, DVT und PVT?
Die EVT (Engineering Validation) bestätigt, dass eine entworfene Platine funktioniert; dies geschieht in der Regel im Labor mit fünf bis zehn Einheiten. Die DVT (Design Validation) bestätigt, dass das integrierte System unter repräsentativen realen Bedingungen in größeren Stückzahlen die Anforderungen erfüllt. Die PVT (Production Validation) bestätigt, dass das Design zuverlässig in großem Maßstab hergestellt werden kann, einschließlich der Fertigungsvorrichtungen in der Produktionslinie, mit denen jede einzelne Einheit geprüft wird.
Warum steigen die Kosten für eine Designänderung im weiteren Verlauf der V-Modell Entwicklungsphasen an?
Mit jeder Phase steigt der Aufwand, den eine Änderung mit sich bringt. Eine Änderung der Anforderungen erfordert nur ein kurzes Gespräch; eine Änderung der Schaltpläne bedeutet Nacharbeit; eine Änderung nach der Fertigstellung von Prototypen erfordert eine Umrüstung der Fertigungsanlagen; eine Änderung in der Produktion kann einen Rückruf zur Folge haben. Die Kosten steigen pro Phase um etwa eine Größenordnung, weshalb eine frühzeitige, kostengünstige Validierung so viel bewirken kann.