Ein Kunde wünsche die Neuentwicklung eines Vermessungsgerätes für Messungen im \(R_2\), „auf der grünen Wiese“. Das Messverfahren erforderte 100 Messungen pro Sekunde bei der taktil manuellen Erfassung einer Kontur. Das Gerät sollte klein, relativ leicht und batterie- oder akkubetrieben sein. Konkreter Arbeitsbereich und Genauigkeiten werden hier nicht offenbart, sie liegen im unteren Meterbereich und unter einem Millimeter. Die Messdaten sollten via BLE im laufenden Messvorgang übertragen werden. Zunächst stellte ich dem Kunden drei Lösungsansätze vor, wovon zwei derzeit technologisch sofort umsetzbar waren, sowie ein optisches Verfahren, wo sich Bildsensor und -verarbeitung für die geforderten Genauigkeiten noch etwas weiter entwickeln müssen, sich aber eine Entwicklung „griffbereit für die Schublade“ lohnt, um zu einem späteren Zeitpunkt dann „Erster“ auf dem Markt zu sein.
Der Kunde entschied sich für eine der sofort realisierbaren Lösungen. Bei dieser müssen für jede Messung die Winkelwerte von zwei hochauflösenden Drehgebern möglichst zeitgleich abgefragt werden. Ein Drehgeber ist als Singleturn, der andere als Multiturn ausgelegt. Im ersten Schritt wurde der Ansatz von mir durch 3D Modelle konkretisiert und durch eine Marktstudie verfügbarer und geeigneter Komponenten und Sensoren gegengeprüft. Hier waren die größten Herausforderungen Absolutgenauigkeit, Größe und Gewicht der mechanischen Komponenten und der Drehgeber, bei letzteren auch die Leistungsaufnahme, Protokoll etc. Letztendlich wurde der Markt wieder einmal real „sehr klein“.
Tipp: Sehr wichtig ist, wie lange können die Komponenten real geliefert werden (Stabilität der Firma, Verhalten z.B. in der Chipkrise). Hier ist nicht nur das Papier entscheidend.
Bei der Auswahl der Komponenten spielt auch das Wesen der beteiligten Firma eine große Rolle. Gerade KMUs können sehr gute Zulieferer sein, die Kommunikationswege sind eher flach, bei der richtigen Firma sind die Mitarbeiter sehr engagiert und offen für Anpassungen an ihrem Produkt.
Wichtig ist auch die Fehlerkultur des Zulieferers (z.B. gut gepflegte Errata). Jeder macht Fehler, wie verhält sich der Zulieferer, wenn diese am Produkt gefunden werden? Warnt er proaktiv vor oder versucht er eher auszusitzen oder zu mauern?
Gerade bei kleinen Entwicklungsprojekten ist die Qualität des Supportes ein entscheidender Faktor für die Kosten. Bekommt man beim Zulieferer z.B. nur ein first level, der „stille Post“ zu den Entwicklern im Haus spielt, oder bekommt man z.B. Direktkontakt zu diesen? Wie schnell reagiert die Firma gerade bei technisch tieferen Fragen? Gibt es eine Community oder vergleichbares?
Weiter stellt sich die Frage, ob bereits geeignete Komponenten beim Kunden verwendet werden. Für jede neue Komponente stehen auch zusätzliche Kosten der Buchhaltung, weniger Preisnachlass im Einkauf, mehr Kontrolle im Wareneingang, Entwicklungsarbeit bei der Anbindung und bei Fehlerkorrekturen. Häufig eingesetzte Komponenten offenbaren schneller Fehler, von ihrer Korrektur profitieren schneller alle sie nutzende Produkte.
Diese Fragen sind gerade bei kleinen Projekten in den Gesamtkosten viel relevanter als die bloßen Einkaufspreise. Ein guter Zulieferer mit höheren Preisen kann am Ende der wirklich Günstigste sein.
Der nächste Schritt war der Aufbau des Projektmanagements für diesen Auftrag. Hier griff ich auf meine Standardkonfiguration zurück. Dies ist für die Projektverwaltung OpenProject CE auf einem gehärteten Linux-Server (Basis Debian). Es reichte in diesem Umfang und bereitet keine weiteren Kosten als die Installation und Administration. Bei der Quellcodeverwaltung setze ich in der Regel auf Gitlab CE auf dem gleichen Server, ergänzt über Nextcloud für Dokumente etc. Die Tools können eng miteinander verzahnt werden, Nextcloud unterstützt durch Plugins die Kopplung zu OpenProject und Gitlab, OpenProject wieder zu Nextcloud und Gitlab. Alle Tools unterstützen bereits in der CE-Version die Anbindung an LDAP (hier setzte ich in der Regel OpenLDAP ein), die EE-Versionen von OpenProject und Gitlab dann auch Kerberos. Alle Tools liegen auch als Docker Container vor. Für kleine Projekte reichen diese Werkzeuge und bereiten keine weiteren Lizenzkosten.
Auf Basis des gewählten Ansatzes strukturiere ich das Projekt Top Down in seine einzelnen Komponenten. Diese werden einzeln von mir entwickelt, getestet und dann Button Up zum Gesamtsystem zusammengesetzt. Bei dieser Arbeitsweise kommen Dinge wie das genaue Gehäusedesign erst sehr spät. Die saubere Funktionalität jeder Komponente steht zunächst im Mittelpunkt. Dabei kommen immer wieder Ergebnisse zutage, die so nicht vorhersagbar waren. Die Arbeitsweise schützt dabei vor technisch „faulen Kompromissen“ durch vorweggenomme Entscheidungen. Bei der Umsetzung versuche ich, vor allem riskante Punkte, welche das Projekt zum Scheitern führen könnten, so früh wie möglich zu lösen, oft zunächst als proof of concept. Zunächst geht es also um einen „Durchstich“.
In diesem Projekt gab es mehrere riskante Punkte. Der erste Punkt war die reale Präzision (früher als Wiederholgenauigkeit bezeichnet) eines Seilzuggebers. Für Tests wurde dieser von mir zunächst mit einem Drehgeber mit 21 Bit Auflösung pro Umdrehung versehen und eine einfache Testanlage aufgebaut. Bei Testaufbauten dieser Art setze ich gern massive Nutenprofile (häufig als Boschprofile bezeichnet) ein und erstelle mit 3D Druckern die nötigen mechanischen Adapter in FDM. Hier eignet sich besonders eine Mischung aus ABS und PC (Acrylnitril-Butadien-Styrol und Polycarbonat) z.B. wegen ihrer Steifigkeit und trotzdem Schlagfestigkeit. Die hohe Auflösung des Drehgebers ermöglicht dabei in Verbindung mit vielen Messwiederholungen, viel besser das reale Verhalten des Seilzuggebers zu verstehen. In diesem Fall zeigte sich eine große Abweichung in der Präzision zwischen den beiden Bewegungsrichtungen, fast Faktor 10. Bei Zug war die Präzision wesentlich höher als bei Entspannung.
Tipp: Leider zeigt sich immer wieder, bei vielen Komponenten kann man sich nicht auf Datenblätter oder Zusagen verlassen. Man muss selbst testen, testen, testen, und das bevor man sich auf die Komponenten festlegt. Bei dem Aufbau der Testumgebungen lohnt es sich, dabei den späteren Wareneingang mit im Blick zu haben. Gerade bei entscheidenden Komponenten reicht nicht eine einmalige Testphase in der Entwicklung, viel mehr muss später der Wareneingang kontinuierlich die Qualität der Komponenten überwachen. Und diese Tests sind mit denen, die man nun in diesem Entwicklungsschritt entwickeln und durchführen muss, äußerst ähnlich. Man muss ja nicht das Rad zweimal erfinden …