Energieeffizienz mobil: Teil 2/3 In nur acht Wochen zum IoT-MVP

Anbieter zum Thema

Schmid Elektronik AG

MicroConsult Microelectronics Consulting & Training GmbH

Heitec AG

NetModule AG

In dieser Geschichte geht es um das Entstehen eines Onboard-Computers für Rennfahrzeuge im Rahmen eines IoT-Projekts. Von der Idee, Machbarkeitsprüfung und Minimal Viable Product (MVP) über den Prototypen bis zum Serienprodukt und Test. Zu den Erfolgen gesellen sich Rückschläge und ein Scheitern, worüber wir ebenfalls reden. Dank Mut, Teamspirit, einer neuartigen Projektorganisation, dem Entwicklungsbeschleuniger LabVIEW und der Zbrain-Plattform wurde die Aufgabe am Ende des Tages gemeistert.

Es ist die Fortsetzung der Geschichte 100 km mit nur fünf Teelöffel Kraftstoff, die über die magische Energie-Effizienz einer weltweiten MINT-Community berichtet (MINT: Mathematik, Informatik, Naturwissenschaft und Technik). Diese neue und zweite Story erzählt von den technischen und organisatorischen Projektnüssen in den verschiedenen Phasen und wie wir sie geknackt haben:

• 1. Es beginnt mit der technischen Projektkomplexität: ein MVP soll Rennfahrzeuge mit dem Internet verbinden und im Sekundentakt verschiedene Sensordaten wie Energieverbrauch und GPS-Position an einen IoT-Server senden. (Bild 1).

• 2. Dieses MVP erfordert einen Technologie-Mix mit 4G, WIFI und GPS sowie das im IoT-Bereich beliebte MQTT-Protokoll und das JSON-Austauschformat. Das ist keine Raketenwissenschaft, jedoch zeigt ein GPS Desaster schonungslos, dass der Teufel im Detail steckt.

• 3. Der massive Zeitdruck in allen Phasen prägt das Projekt wesentlich. Und hier kommt ein Schmankerl: Wie können mehrere Entwickler der Zeit ein Schnippchen schlagen, indem sie parallel auf ein und derselben Plattform an der gleichen Embedded-Software arbeiten?

• 4. Mehrfache Miniaturisierung, bis der Formfaktor passt.

• 5. Hitze, Feuchtigkeit, Vibrationen und elektromagnetische Felder - in der extremen Umgebung eines Motorraums muss das Embedded-System zuverlässig Daten liefern.

Was bisher geschah…

Da war dieser Telefonanruf aus heiterem Himmel im ersten Teil der Geschichte. Ein Energieriese kontaktierte den Schweizer Mittelständler Schmid Elektronik. Ob wir das MVP eines Onboard-Computers liefern können, welches Rennfahrzeuge mit dem IoT verbindet? In nur acht Wochen! Diese super enge Zeitvorgabe hat einen guten Grund. Die regionalen Rennen im Shell Eco-marathon werden pro Saison dreimal ausgetragen: in den USA, Europa und Asien. Es gibt demnach in einem Jahr nur diese drei Möglichkeiten, ein System auf der Strecke zu testen.

Die technische Projektkomplexität und der Zeitdruck haben uns damals komplett überfordert. Auf der anderen Seite bot diese schwierige Aufgabe auch etwas Reizvolles: Es ging um nichts Geringeres als um die energieeffizientesten Rennfahrzeuge der Welt! Die Besten schaffen im Vergleich die Strecke von London nach Rom und zurück mit nur einem Liter Kraftstoff oder 10 kWh elektrischer Arbeit! Das entspricht dem Energieverbrauch eines Haarföhns in vier Stunden. Wie entscheiden?

Komplexes Projekt mit straffer Markteinführungszeit

Da war also der Anruf, die Frage und die Information, dass das nächste Rennen acht Wochen später in Asien stattfinden sollte. Ein paarmal darüber geschlafen und den ersten „Schock“ verdaut, stellen sich Schmids Entwickler und Entscheidungsträger folgende Fragen: Beherrschen wir diese Komplexität überhaupt? Wie mit den Ressourcen umgehen? Wird das Budget reichen?

Und: Welche Chance hat der erste Meilenstein in acht Wochen? Neben dem rauen Betriebs-umfeld und der technischen Komplexität ist in diesem Projekt vor allem der straffe Zeitplan bestimmend. Die Machbarkeit will in nur einer Woche geprüft sein. Das MVP wird acht Wochen später an der Startlinie erwartet. Für den Prototypen sind drei Monate eingerechnet. Und der Produktionsstart des fertigen Produkts ist ein halbes Jahr danach geplant.

Drei Gründe sind ausschlaggebend, das riskante Projekt trotz den kritischen Eckdaten und extremen Randbedingungen anzunehmen:

• 1. Hier bietet sich eine „Once in a Lifetime“-Chance, die Energie- und Mobilitätszukunft ganz konkret mitzugestalten. Wenn man wie Schmid seit 50 Jahren Energieeffizienz im Blut hat, kann man eine solche Anfrage nicht ablehnen.

• 2. Wir können auf Schlüssel-Knowhow zurückgreifen, welches wir soeben mit LabVIEW in einem Monitoring Projekt für Bahnschienen und -weichen gewonnen haben: 4G, WIFI und GPS. Dieses Dreiergespann ist die Voraussetzung für eine IoT-Aufgabe.

• 3. Wir haben einen Trumpf im Ärmel: den Entwicklungsbeschleuniger „Zbrain“ mit der grafischen Programmiersprache LabVIEW und einem Hard- und Softwarebaukasten (Bild 2). Diese Plattform entstand vor zehn Jahren aus einem Großprojekt in der Norwegischen Tiefsee beim selben Kunden. Aber das ist eine ganz andere Geschichte…

In einer Woche die Machbarkeit einer gewagten Idee prüfen

Der Kunde ist sich des kurzen Zeitfensters bewusst und bietet uns mehrere Softwareentwickler zur Unterstützung an. Nun braucht es neben Abenteuerlust und dem Entwicklungsbeschleuniger ein passendes Projektmodell und eine Embedded-System-Architektur für parallele Teamarbeit.

Plötzlich steht eine gewagte Idee im Raum: Was wäre, wenn das Modell und die Architektur paralleles Arbeiten aller Entwickler auf ein und demselben Embedded-System ermöglichte? Und so die Software in Wochensprints Schritt für Schritt entwickelt und getestet werden könnte? Wir entscheiden uns, die technische Machbarkeit dieses neuen Weges bereits bis zum Ende der ersten Projektwoche zu prüfen. Diese Lösung wird entscheidend für den Projekterfolg.

Dank der hohen Abstraktion des Entwicklungsbeschleunigers LabVIEW und der Zbrain-Plattform kann die Machbarkeit der folgenden Lösung in Rekordzeit geprüft werden. Hier geht es um technisches Teamwork: Die Gesamtaufgabe wird in einem Software-Framework modular auf mehrere Microservices verteilt. Microservices sind in diesem Anwendungsfall gekapselte Prozesse unter Linux, die über Treiber auf Hardware zugreifen und nach außen ein Kommunikations-Interface bieten (Bild 3). Jeder dieser Prozesse wird beim Starten eine Konfigurationsdatei einlesen, Sensordaten erfassen, diese zusammen mit einem Zeitstempel in eine Datei abspeichern und über einen TCP-Socket direkt mit dem Hauptprogramm austauschen. Dieses soll die Daten aller Microservices aggregieren und als Portal zur Außenwelt funktionieren. In den ersten Tagen soll eine gemeinsame Sprache dieses Portals entwickelt und geprüft werden: ein flexibles API (Application Programming Interface).

Die Entwickler bringen all ihr Herzblut ein und am Ende dieser ersten Projektwoche zeigt sich das Ergebnis: Wird das Embedded-System, in diesem Fall ein ZSOM-Control, über Ethernet oder WIFI mit dem Internet verbunden, kann aus einer beliebigen Firma, ob in Europa oder einem fernen Kontinent, jeder am Projekt Beteiligte darauf zugreifen und gleichzeitig Software entwickeln! Über das API ist es sogar möglich, gleichzeitig unterschiedliche Programmiersprachen zu nutzen.

Das macht den Weg frei für die nötige parallele Teamarbeit. Dieses internationale Team wird nun zusammengestellt, jeder erhält eine Teilaufgabe und es kann losgehen!

In acht Wochen zum Minimum Viable Product (MVP)

Das Schmid-Entwicklungsteam macht in den kommenden acht Wochen die Schotten dicht und wird wieder zum hungrigen „Startup“. Es entwickelt das Software-Framework als Grundlage für die parallele Teamarbeit. Das Framework enthält die minimalen Funktionen des Hauptprogramms, Mockups für die zu entwickelnden Microservices und das soeben geprüfte API. Dank Entwicklungsbeschleuniger mit LabVIEW und dem Embedded-System ZSOM-Control geht das System in wenigen Tagen online (Bild 4).

Ein Ingenieur aus Asien entwickelt das Hauptprogramm und nutzt dafür JavaScript. Der IoT-Experte arbeitet von Frankreich aus und der Cloud-Spezialist wohnt in den Niederlanden. Ein Teil der Microservices wird in Irland programmiert und der Rest von Schmids Softwareteam.

Die Hardware wird laufend um weitere Module erweitert und unter dem Dach von Schmid zügig entwickelt und produziert. In diesem Zeitraum führen wir 3D-Design ein und legen uns einen 3D-Drucker zu. Damit umgehen wir die Lieferfristen mechanischer Bauteile.

Der Kraftakt zahlt sich aus: Das MVP wird nach acht Wochen geliefert und schafft es pünktlich zum ersten Rennen der neuen Saison 2016 an die Startlinie des Shell Eco-marathon in Manila. Es hat die Größe einer Schuhschachtel (Bild 5 links), welche wir liebevoll die “BUG-Box” nennen: Big, Ugly and Gray. Die letzten Codezeilen entstehen während des Fluges dahin… Dieses MVP validiert die Idee des Kunden und erfüllt damit seinen Zweck.

In drei Monaten vom MVP zum Prototyp

Dieser erste Erfolg ermutigt den Kunden zum nächsten Schritt. Er möchte beim nächsten Rennen in Europa einen Prototyp an der Startlinie sehen. Das sind nur drei Monate Zeit! Das Volumen soll um 60 Prozent auf einen handlichen Komplett-IPC im Standard-Alu-Gehäuse schrumpfen und es sind weitere Funktionen gefragt (Bild 5 Mitte). Hardwareseitig einigen wir uns auf ein kompaktes Baseboard mit eingestecktem Scheckkartenrechner und Tochterplatine. Softwareseitig treffen wir eine weitreichende Entscheidung, welche die Architektur bis heute prägen wird. Der Sprachmix aus LabVIEW Embedded, C/C++, JavaScript und Python soll einheitlich nach C/C++ überführt werden.

Wir bleiben beim Konzept aus Hauptprogramm und Microservices auf Linux und verabschieden uns von der ZSOM-Control-Plattform. An ihre Stelle tritt ein kommerziell erhältliches Einsteckmodul, betrieben von einem kräftigen und energiesparenden ARM-Cortex-A9 Mikrocontroller. Auch dieser Termin bleibt robust und der Prototyp schafft auf der historischen, französischen Rennstrecke in Le Mans den Härtetest.

Scheitern fühlt sich schrecklich an…

Anschließend wird im selben Jahr eine Protoserie von neun Stück hergestellt und an der allerersten sommerlichen Weltmeisterschaft am Shell Eco-marathon in London die besten Teams damit ausgerüstet. Wir skalieren also von einem Fahrzeug in Le Mans auf neun in London. Und scheitern grandios! Vor den Augen tausender Zuschauer, den Medien und unseres Kunden. Was passiert da gerade? Auf den überall sichtbaren Leinwänden und Bildschirmen zeigt sich ein komplett anderes Bild als das tatsächliche Geschehen auf der Rennstrecke… Ein No-Go! Eines der Fahrzeuge verschwindet und taucht wieder auf. Ein fehlerhafter Energieverbrauch wird angezeigt. Ein anderes Fahrzeug scheint das nahegelegene Shoppingcenter zu besuchen, obwohl es für alle sichtbar auf der Rennstrecke fährt. Was ist die Ursache? Ein überlastetes Mobilfunknetz und WIFI aufgrund der vielen Zuschauer? Korrupte Dateien im Embedded-System? EMV-Probleme in den Motorräumen? Kabelbrüche? Einbrüche in der Stromversorgung der Onboard-Computer? Bandbreitenproblem auf unseren IoT-Servern? Reflexion bei den GPS-Signalen? Ein Programmierfehler in der Software? Wer weiß…

Das gibt Hausaufgaben!

Ich sitze im Renn-Kontrollraum und beobachte mit Entsetzen, was sich da auf den Leinwänden abspielt. Vor Enttäuschung, Verzweiflung und Frust sacke ich kraftlos im Stuhl zusammen. Der Leiter des Data & Technology-Teams kommt auf mich zu. Umarmt mich. „Marco, sowas kommt im Motorsport vor“, meint er. „Wir haben heute zum ersten Mal von einem auf mehrere Onboard-Computer skaliert und sind an Grenzen gestoßen. Wenn man sowas nicht wagt, dann macht man es nicht richtig. Ist ok!“ Es wird nicht das letzte Mal sein, dass mein Nervenkostüm flattert…

Im halben Jahr zum serienreifen Messnetzwerk

Nach diesem Rückschlag in London gilt es abhaken, die Krone richten und weitermachen. Die Rennsaison ist vorbei. Nun soll das serienreife Gerät entstehen, gerade rechtzeitig zum Auftakt der neuen Saison ein halbes Jahr später in Singapur. Es sollen mehrere Dutzend Fahrzeuge ausgerüstet werden und das wird zur emotionalen Achterbahnfahrt. Aber dazu kommen wir gleich…

Es gilt nicht nur die in London aufgetretenen Fehler auszubügeln, sondern auch den Formfaktur zu halbieren. Der Onboard-Computer – neuer Produktname – soll sich als modulares Messnetzwerk entpuppen, welches sich im Fahrzeug über eine Datenbank und intelligente Sensoren flexibel an drei Energietypen anpassen kann: Verbrennungsmotor, Elektromobil und Wasserstoffantrieb. Die fehleranfällige USB-Verbindung ist vom industriellen CAN-Bus mit robusten Kabeln und Steckverbindern abzulösen. Dazu kommt der Wunsch nach weiteren Funktionen wie Beschleunigungs- und Drehratensensor, Over-the-Air-Update und GPS-RTK (Real-Time-Kinematic).

Da sind sie wieder, die hohe Projektkomplexität und der massive Zeitdruck.

Wir müssen vereinfachen und das führt zu einer Designentscheidung, der wir bis heute treu geblieben sind: Die Gesamtfunktion im Messnetzwerk auf intelligente Knoten aufteilen. Der Onboard-Computer besteht aus einem äußeren Knoten auf der Fahrzeugkarosserie und einem inneren Knoten im Motorraum (Bild 6). Der äußere Knoten im 3D gedruckten Gehäuse nennt sich „Fin“ (Flosse). Er verbindet sich über einen robusten Kommunikations-Bus mit dem inneren Knoten, dem „Backbone“ (Rückgrat) als Sammelpunkt für die verschiedenen Energiesensoren. Diese Sensoren sind intelligent und kommunizieren über den CAN-Bus. Ein Sensor dient zur Messung elektrischer Energie, z.B. in elektromobilen Rennfahrzeugen. Ein anderer misst Flüssigkeiten wie Benzin, Diesel oder Etanol. Und - last but not least - gibt es noch den Gasfluss-Sensor für den Wasserstoff.

Diese lokal in den Fahrzeugen installierten Messnetzwerke sind Teil eines übergeordneten IoT-Netzwerkes. Die Komplexität verlangt nach mehreren Servicewerkzeugen und nach Transparenz von der IoT- bis auf die Sensorebene mit einer Gesamtsicht auf die Daten und Zustände. Diese Werkzeuge entstehen dank grafischer Programmierung mit LabVIEW teilweise vor Ort und sind im professionellen Rennstreckenalltag unverzichtbar (Bild 7).

Im Jahr 2024 wird der Fin um weitere 75 Prozent miniaturisiert und stromlinienförmig gestaltet. Der Backbone wird ebenfalls ein massives Redesign erfahren und im EMV-robusten rostfreien Stahlrohr glänzen. Beide Module erhalten ein lötbares System-on-Module im Briefmarkenformat mit einem ARM-Cortex-A53 Mikrocontroller und sind per Ethernet miteinander verbunden.

Im Feldeinsatz - ein Drahtseilakt mit der Technik

Ein paar Wochen vor dem Härtetest in Singapur wird der neue Onboard-Computer auf einer Teststrecke geprüft. Es läuft leider nicht so wie geplant und die Technik steht auf wackligen Füssen. Die Hardware und auch große Teile der Software müssen überarbeitet werden. Zusätzlich löst eine kompakte, passive GPS-Antenne die klobige, aktive Antenne ab. Alles ist nun neu, der Zeitdruck enorm und das Team arbeitet wieder rund um die Uhr.

Dann kommt Singapur. Und ein Showstopper: die neue GPS-Antenne funktioniert hier nicht! Konsequenz: Ohne GPS-Signale keine Fahrzeugpositionen und damit keine Live-Rangliste und digitale Karte für die Zuschauer. Eine Krise bahnt sich an. Erinnerungen an London werden wach…

Hier und jetzt offenbart sich wenige Tage vor dem groß angekündigten Rennen eine empfindliche Schwachstelle, die es vor Ort zu lösen gilt. In Tagen! Der Druck ist enorm, es fühlt sich an wie ein „Berg“ und wir ahnen bereits: Falls wir es überhaupt schaffen, diesen GPS-Berg abzutragen, werden sich dahinter weitere, aber hoffentlich kleinere „Berge“ offenbaren. Nur: Das wissen wir nicht und tappen völlig im Dunkeln. Es gilt also, unter großem Druck entscheiden zu können, Fakten zu sortieren und kaltblütig Probleme zu lösen. Nur so besteht überhaupt eine Chance für Erfolg. Dank übergreifendem Teamwork, die am Shell Eco-marathon üblich ist, sind wir überhaupt in der Lage, Meisterleistungen wie diese abzurufen.

Das GPS-Problem wird gelöst: Wir schwenken kurzfristig auf eine Helix-Antenne um, die im Militär- und Transportbereich sehr beliebt ist, beschaffen diese vor Ort und rüsten in letzter Minute alle Fahrzeuge damit aus. Für das Testen ist keine Zeit mehr…

Als Highlight beschert uns das prestigeträchtige Schlussrennen einen Riesenerfolg. Dieses Beispiel zeigt ähnlich wie die Erfahrungen aus London, dass es auf der Rennstrecke immer wieder Unbekannte und Risiken gibt, die einen zünftig auf Trab halten.

Mit LabVIEW die Hard- und Software testen

Der Onboard-Computer muss im Motorraum dreier Energietypen und in Dutzenden individuell gestalteter Rennwagen permanent und fehlerfrei funktionieren. Das bedeutet eine große Vielfalt an rauen Umgebungen mit hohen Temperaturen, starken Vibrationen, Feuchtigkeit und elektromagnetischen Feldern. Hier ist ein Höchstmaß an Robustheit gefragt. Wir lernen aus den Rückschlägen in London und Singapur und führen ein rigoroses Regime für Qualitätssicherung mit Hard- und Softwaretests ein.

Zunächst definieren wir den Testumfang. Er umfasst den Onboard-Computer, die Sensoren und das Relais, das Betriebssystem, die Microservices, die Embedded-Software sowie das IoT und das GPS. Es werden mehrere Testszenarien festgelegt, darunter Entwicklungs-, Produktions- und Feldtests. Zu den konkreten Tests gehören Funktions-, Regressions-, Langzeit-, Last- und Umwelttests. Im Sinne der Vorgehensweise mit LabVIEW über die ganze Wertschöpfungskette liegt die Wahl nahe: Die NI PXI-Plattform mit Teststand. Damit zähmen wir die Komplexität der zahlreichen Testfälle. Die Testumgebung stellt sicher, dass ab jetzt alle Änderungen am Embedded-System fehlerfrei übernommen werden. Dank Acceptance-Test für jeden Onboard-Computer sind diese jederzeit fit für das nächste Rennen. Und schließlich ziehen wir HIL (Hardware-in-the-Loop) auf (Bild 8). Jede kritische Softwarefunktion des Embedded-Systems soll unter Echtzeitbedingungen getestet werden, genauso wie es die Großen der Automobilbranche vormachen.

Wenn aus Renndaten Energieeffizienz wird…

In diesem zweiten Teil der Geschichte ging es um das Entstehen des Onboard-Computers als praktisches Beispiel, wie LabVIEW in der Produktentwicklung entlang der gesamten Wertschöpfungskette von der Idee bis zur Umsetzung genutzt werden kann.

Heute werden in einem Rennen bis zu 60 Fahrzeuge mit Onboard-Computern ausgerüstet und vom Start bis zum Ziel zuverlässig Renndaten geliefert. In den kommenden Jahren sind pro Rennen über 150 Installationen geplant.

Der dritte und letzte Teil dieser Story wird zeigen, wie Studenten dank der gewonnenen Daten die Energieeffizienz weiter steigern können. Eine dreiteilige Webinarserie bereitet Einsteiger und auch fortgeschrittene Teams auf datenzentrierte Rennmethoden vor. An den Rennen selbst geht’s dieses Jahr im neuen Bootcamp so richtig zur Sache: Aus theoretischer Strategie wird Rennpraxis und die Streckenperformance bis zu 20 Prozent gesteigert.

Erfahre im dritten Teil, wie wir dank den Dimensionen Raum, Zeit und Information Komplexität meistern und die Datenflut zähmen. Wie wir physikalische Probleme aus dem Blickwinkel der Datenwissenschaft auf eine ganz neue und elegante Weise lösen können. Und wie damit AI (Amazing Innovation, Augmented Intelligence) so richtig konkret und lebendig wird…

Informationen über den Autor Marco Schmid und seine Firma Schmid Elektronik gibt es ganz am Schluss des ersten Teils.

Interessiert?

Hier geht’s zum Whitepaper Grafisches Programmieren: Embedded-Systeme neu gedacht. Mit LabVIEW und der Zbrain- Entwicklungsplattform.

Dieses Webinar gibt ebenfalls Antworten: Mit MVPs und Grafischer Programmierung Embedded-Systeme mit Innovation und Effizienz entwickeln

* Marco Schmid, CEO von Schmid Elektronik über sich selbst: Der Systemingenieur in mir hat eine Leidenschaft für Embedded-Systems, die grafische Programmiersprache NI LabVIEW, IoT-Dinge, Minimum Viable Products (MVPs), Komplexität, Netzwerke, Wissensgraphen & Sprachmodelle sowie Informations- und Datenwissenschaft. Als Unternehmer genieße ich das Privileg, das Führungsteam eines 45-köpfigen und über 50-jährigen Familienunternehmens mit cooler DNA und pfiffigen Leuten zu coachen. Privat koche ich gerne indisch, chinesisch, Tapas und Sushi. Das ist zwar aufwändig, aber viel günstiger als im Restaurant und fast so gut. Außerdem macht mir Kochen einfach Spaß.

Ich mag Reisen in ferne Länder und lerne aus anderen Ansichten. Das Campen im Zelt verbindet mich mit der Natur und ich fühle mich sehr wohl unter freiem Himmel. Auch bin ich ab und zu in einer Berghütte anzutreffen. Da schalte ich das Geschäft und das Digitale ab und genieße die Einfachheit. In Büchern und guten Stories verliere ich mich und vergesse Raum und Zeit. Das Verständnis für gegensätzliche und doch ineinandergreifende Kräfte stammt aus meinen früheren Erfahrungen in asiatischen Kampfkünsten. Heute carve ich im Winter gerne schnelle Skipisten hinunter und mache im Sommer auf Rollerblades die Strassen unsicher. (mbf)

Energieeffizienz mobil: Teil 1/3

100 Kilometer mit nur fünf Teelöffel Kraftstoff

(ID:50020760)