Eingebettete Systeme tun, was eingebettete Systeme tun

Wenn wir gefragt werden, was ein eingebettetes System eigentlich ist, haben wir eine Standardantwort: Es ist ein Computer, für den sich niemand interessiert. Und warum? Nun, eingebettete Systeme sollen ständig funktionieren. Sie tun das, wofür sie entwickelt wurden - tagein, tagaus. Im Allgemeinen ist es recht einfach zu erklären, was sie tun:

Eingebettete Systeme bestehen aus Hardware (wie einem Mikrocontroller) und Software und sind in ein größeres System integriert. Innerhalb dieses größeren Systems erfüllen sie bestimmte Aufgaben. Normalerweise erhalten sie eine Art von Eingabe. Dann verarbeiten sie diesen Input und liefern eine Art Output. Ein einfaches Beispiel wäre ein Thermostat: Er erhält Eingaben von Temperatursensoren, verarbeitet diese Daten, indem er sie mit der optimalen Temperatur vergleicht, und sendet dann ein Signal an die Heizung, wobei er deren Leistung entweder erhöht oder verringert. Solange der Thermostat für eine angenehme Temperatur in deinem Zimmer sorgt, bist du zufrieden und vergisst zu Recht, dass er da ist. Das einzige Mal, dass du dich um den Thermostat kümmern würdest, wäre, wenn er nicht mehr funktioniert. Du kümmerst dich also nur dann um eingebettete Systeme, wenn sie nicht das tun, was sie tun sollen. Das bedeutet, dass die Aufgabe eines Ingenieurs für eingebettete Systeme darin besteht, dafür zu sorgen, dass du dir nie Sorgen um eingebettete Systeme machen müsstest. Das ist schon ein kleines Marketingproblem...

Wozu brauchen wir sie?

Obwohl wir uns nie um sie kümmern sollten, wäre es töricht zu denken, dass eingebettete Systeme nutzlos sind.

Werfen wir einen Blick in die Geschichte:

Die erste berühmte Aufgabe, die ein eingebettetes System hatte, war die Hilfe bei der Eroberung des Mondes. Der Apollo Guidance Computer führte Neil Armstrong, Buzz Aldrin und Michael Collins auf den Mond und schrieb Geschichte. Der AGC war vor allem für die Bereitstellung von Führungsschnittstellen, die Steuerung von Raumfahrzeugen und die Navigation verantwortlich.

Heute sind sogar unsere Waschmaschinen auf eingebettete Systeme angewiesen. So ziemlich jedes ausgefallene technische Gadget und jedes elektronische Gerät, über das wir nie wirklich nachdenken, hängt von ihnen ab. Diese Abhängigkeit hat sogar noch zugenommen, seit sie durch das Aufkommen billiger Funkchips drahtlos mit anderen Systemen verbunden werden können.

Für uns ist das großartig, denn es ermöglicht uns, noch coolere Sachen zu bauen. Wir haben zum Beispiel intelligente Masten für Dubai und ein Indoor-Lokalisierungssystem mit drahtlos verbundenen Chips gebaut.

All dies deutet darauf hin, dass eingebettete Systeme in zukünftigen Technologien eine wichtige Rolle spielen werden. Bedeutet das auch, dass wir anfangen werden, uns mehr für sie zu interessieren?

Werden wir uns in Zukunft mehr um eingebettete Systeme kümmern?

Nun, nicht, solange sie ihre Aufgabe erfüllen! Wenn überhaupt, sollten wir uns weniger um sie kümmern, und diese Denkweise wird sogar auf andere Formen der Datenverarbeitung übergreifen. Es gibt viele Systeme, die heute auf Benutzereingaben angewiesen sind und von einem Benutzer verwaltet werden müssen. Wäre es nicht besser, wenn sie ihre Arbeit selbst erledigen würden, ohne dass wir auf sie aufpassen müssen? Nehmen wir das automatisierte Fahren: Im Idealfall steigen Sie einfach in das Auto ein und sagen ihm, wohin Sie fahren wollen. Oder noch besser, das Auto kennt Ihren Zeitplan und fährt Sie zum Zahnarzt, während es im Radio beruhigende Musik spielt, weil es spürt, dass Sie nervös sind. Ich schätze, ein teuflischeres Auto würde anfangen, Bohrergeräusche zu spielen...

Sogar unsere heutigen technischen Funktionen wie automatische Bremsen, Abstandsregelung oder Einparkhilfe sind als unsichtbare, automatische Helfer konzipiert, die man vergessen kann, dass sie da sind. Ohne sie wären unsere aktuellen und zukünftigen Projekte gar nicht realisierbar. Inzwischen wissen wir also, was eingebettete Systeme leisten, wofür sie verwendet werden und warum sie wichtig sind. Aber wir müssen noch darüber reden, wie sie eigentlich erstellt werden. Der erste Schritt auf dem Weg zu einem Produkt ist das Prototyping. Lassen Sie uns also eintauchen und erkunden, wie man Prototypen erstellt.

Eine Erinnerung daran, wie man Prototypen erstellt

Jeder Prototyping-Prozess beginnt mit der Ermittlung der grundlegenden Anforderungen an das jeweilige Projekt. Du müssest sicherstellen, dass du das Problem, das du zu lösen versuchst, genau kennen. Nur wenn dies der Fall ist, kannst du die richtige Hardware und Firmware auswählen.

Aber Moment, das klingt nicht sehr agil, oder?

Stimmt! Der Zielkonflikt zwischen Agilität und hoher Qualität ist ziemlich groß, wenn es um eingebettete Systeme geht, oder eigentlich um jedes Projekt, das Hardware erfordert. Agiles Vorgehen eignet sich deshalb so gut für Software, weil Software leicht geändert werden kann. Software ist außerdem sehr modular, und selbst wenn sich die Produktvision im Laufe der Zeit ändert, bedeutet das nicht, dass man den gesamten alten Code wegwerfen muss.

Das bedeutet jedoch nicht, dass man eingebettete Systeme nicht auf agile Art und Weise entwickeln kann: Anstatt mit einer genauen Vorstellung davon zu beginnen, was Sie wollen, beginnen Sie mit dem Prototyping, um Ihre Möglichkeiten auszuloten und sich langsam von einer groben Vision zu den genauen Spezifikationen zu entwickeln. Das Ergebnis dieser ersten Prototyping-Phase ist oft ein Proof-of-Concept, das aus handelsüblicher Hardware besteht und zeigt, dass Ihre Idee tatsächlich funktioniert. Noch wichtiger ist jedoch, dass Sie herausgefunden haben, was Ihr Produkt wirklich sein soll. Von diesem Zeitpunkt an können Sie den klassischen Weg der Entwicklung gehen, aber es ist immer noch sinnvoll, die agilen Ideen im Herzen zu behalten. Zunächst einmal können Sie Ihr System modular aufbauen. Entwerfen Sie nicht gleich Ihr fertiges Produkt, sondern die Bausteine dafür. Auf diese Weise haben Sie immer die Möglichkeit, Teile auszutauschen und umzugestalten. Spielen Sie mit Ihren Kindern ein bisschen LEGO, um in Stimmung zu kommen.

Der zweite Grundsatz ist noch einfacher: Kann man es mit Code machen? Verstehen Sie das nicht als pauschalen Ratschlag, alles in Code zu lösen - manchmal kann ein einfaches Stück Silizium auf der Leiterplatte Hunderte von Codezeilen (und all die möglichen Fehler darin) ersparen - aber bedenken Sie, dass die Änderung von Code billig ist, während die Änderung von Hardware mit Blick auf die Frist exponentiell teurer wird. Wir haben also herausgefunden, was wir brauchen, und wir haben die richtige Idee, wie wir es machen können. Jetzt ist es an der Zeit, den ersten echten Prototyp zu entwickeln, unsere Version 0.1. Ihr wichtigstes Ziel dabei ist es, sicherzustellen, dass Ihr Prototyp tatsächlich getestet werden kann. Als Nächstes müssen Sie den Test durchführen und anschließend auswerten. Ziehen Sie so viele Erkenntnisse wie möglich und stellen Sie sicher, dass Sie diese ordnungsgemäß dokumentieren. Danach sollten Sie aktiv werden und Ihren Prototyp entsprechend den gewonnenen Erkenntnissen überarbeiten und verbessern. Dies ist der Zyklus, dem Sie von nun an folgen, bis der Prototyp kein Prototyp mehr ist. Testen, überarbeiten, bauen - bis Sie das haben, was Sie von Anfang an geplant haben. Je kleiner die Schritte sind, desto weniger Kopfschmerzen bereiten sie.

Dieser ganze Prozess ist übrigens dem Design Thinking-Prozess sehr ähnlich. In beiden Prozessen ist es wichtig, kontinuierlich zu lernen und den Prozess selbst zu verbessern, um so einen eigenen Weg zu finden, Dinge zu tun. Design Thinking ist auch das, was du für den ersten Proof-of-Concept verwendest, um deine Idee zu definieren.

Prototypische eingebettete Systeme - Der Motius-Weg

Bei Motius haben wir einige Muster für das Prototyping von Embedded Systems entwickelt. Sie beruhen auf den vielfältigen Erfahrungen, die wir im Laufe der Jahre in Projekten gemacht haben.

Bevor der Prozess überhaupt beginnt, stellen wir sicher, dass dem Projekt ein Systemingenieur zugewiesen wird. Und warum? Interdisziplinarität. Die meisten Embedded-Projekte kombinieren Software und Hardware. Die Software kann von Echtzeit-Regelkreisen bis hin zu speziellen Benutzeroberflächen reichen, und die Hardware kann komplexe mechanische Systeme umfassen, anstatt nur eine Leiterplatte mit ein paar Chips darauf.

Ein Systemingenieur koordiniert dieses interdisziplinäre Vorgehen:

• Kommunikation: spricht mit allen Beteiligten, stellt sicher, dass sie jederzeit wissen, was vor sich geht; sehr wichtig zu Beginn, wenn Hardware und Software ausgewählt und/oder entwickelt werden

• Dokumentation: stellt sicher, dass alles dokumentiert wird, und achtet im Laufe des Projekts auf eine hochwertige Dokumentation

• Zuständigkeit: ist die Kontaktperson für alles, was das Projekt betrifft; kennt die internen Zuständigkeiten, d.h. wer ist wofür verantwortlich

Die richtige Hardware bekommen oder die richtige Hardware bekommen

Das erste, worüber du wirklich nachdenken müsstest, ist die Frage, welche Hardware für deine Bedürfnisse geeignet ist. Oft genug verlieren sich die Leute in einer Art großer Vision dessen, was sie erreichen wollen, nur um dann festzustellen, dass es keine geeignete Hardware gibt, die diese Vision unterstützen könnte. Wenn wir über Hardware sprechen, gibt es auch verschiedene Ebenen, über die wir sprechen: Mit Hardware kann ein fertiger eingebetteter Computer gemeint sein, der in einem schönen, industriellen Gehäuse und mit einem stabilen, gut unterstützten Betriebssystem geliefert wird. Es kann sich aber auch um einen bloßen Mikrocontroller handeln, für den du noch eine Leiterplatte, ein Gehäuse und eine Menge Software entwerfen müsstest. Im Allgemeinen wirst du die fertige Hardware kaufen wollen, die deine Bedürfnisse erfüllt - aber wenn deine Bedürfnisse nicht wirklich langweilig sind, gibt es diese vielleicht nicht. An diesem Punkt müsstest du eine Stufe tiefer gehen und deine eigene Hardware bauen - und sich darüber im Klaren sein, wie sich dadurch dein Risiko- und Kostenschätzungen ändert. Eine Stufe tiefer zu gehen, muss jedoch nicht immer zu einer Erhöhung dieser beiden Faktoren führen! Wenn die vorgefertigte Lösung nicht perfekt passt, sondern in die Lösung deines Problems hineingepasst werden muss, hat das selbst entwickelte System eine gute Chance, es zu übertreffen. Inzwischen bist du vielleicht sicher, dass du die richtige Hardware hast. Aber vergiss nicht, dass die Hardware auch getestet werden muss. Die Hardware muss also auf eine Weise getestet werden können, die zum Projekt passt. Außerdem müsstest du bereits jetzt überlegen, ob die Hardware qualitativ hochwertig und schnell hergestellt werden kann, sobald der Prototyp wie gewünscht funktioniert.

Ein weiterer Punkt. Stelle dir vor, du hast den Prototyping-Prozess abgeschlossen und willst in die Massenproduktion gehen. Doch dann teilt dir einer deiner Zulieferer mit, dass das Bauteil nicht mehr verfügbar ist, so dass eine Massenproduktion nicht möglich ist. Und schon wird deine ganze harte Arbeit die Toilette hinuntergespült. Lektion gelernt? Vergewissere dich, dass der Hersteller die benötigten Komponenten weiterhin produzieren wird. Auf dem Markt für eingebettete Systeme ist es nicht unüblich, dass die Hersteller dir eine Garantie geben, dass das Produkt 15 Jahre oder länger verfügbar ist.

Die Magie einbringen: Entwicklung der Firmware

Das erste, worum Sie sich beim Firmware-Prototyping kümmern müssen, ist die Anpassung der Werkzeuge an das Projekt. Ihr wesentlicher Werkzeugkasten umfasst: eine Programmiersprache, ein Build-System und ein Framework. Das Framework (und es tut mir leid, dass wir kein besseres Wort dafür haben) kann zum Beispiel ein Satz von Bibliotheken sein, um die Hardware zu abstrahieren. Die Firmen, die die Mikrocontroller herstellen, bieten normalerweise solche Bibliotheken an, aber diese sind oft nicht die beste Wahl. Drittanbieter wie FreeRTOS, Mbed oder sogar Arduino stellen Abstraktionsbibliotheken zur Verfügung, die oft über verschiedene Mikrocontroller hinweg funktionieren. Die Verwendung dieser Bibliotheken bedeutet, dass Ihr Code portabel bleibt und es möglich ist, später auf einen anderen Mikrocontroller zu wechseln. Das Build-System ist ein weiterer wichtiger Schlüssel zu Ihrem Projekt. Es ist das Werkzeug, das Ihren Code in ein Programm verwandelt, das auf Ihrer Hardware laufen kann. Es kümmert sich um alle Abhängigkeiten, die Bibliotheken, die Sie in Ihrem Projekt verwenden, und den Compiler, den Sie für Ihren speziellen Mikrocontroller benötigen.

Die wichtigste Aufgabe besteht jedoch darin, dafür zu sorgen, dass Ihr Projekt überall kompiliert wird. Wenn das Projekt nur auf dem Computer des Hauptentwicklers kompiliert wird, weil dies der einzige Rechner ist, auf dem alle richtigen Tools installiert sind, und niemand weiß, welche Tools benötigt werden, haben Sie effektiv kein Projekt. Beachten Sie auch, dass es andere Betriebssysteme als Windows gibt und viele Embedded-Entwickler Linux verwenden. Wenn Ihr Build-System nicht unter Windows, OSX und Linux funktioniert, ist es ein schlechtes Build-System und Sie sollten es nicht verwenden. Ein gutes Tool, das ich für diese Aufgabe empfehlen kann, ist PlatformIO, obwohl Sie für größere und komplexere Projekte wahrscheinlich zu einem leistungsfähigeren Tool wechseln müssen. Es hängt auch von der Programmiersprache ab, die Sie verwenden.

Programmiersprachen sind eines meiner Lieblingsthemen, über das ich gerne spreche, aber leider gibt es bei Mikrocontrollern nicht allzu viel Auswahl. Die gebräuchlichsten Sprachen sind C und C++, aber bitte verwenden Sie diese nicht einfach als Standard. Beide sind großartige Sprachen, aber beide sind auch einfach alt und schwer zu benutzen. Vor allem C++ ist komplex und umfangreich, so dass es viel Disziplin erfordert, damit es gut funktioniert. Eine neue Option, die sich derzeit abzeichnet, ist Rust. Diese Sprache beseitigt effektiv eine ganze Klasse von Fehlern, die in C und C++ häufig auftreten - Speicherfehler. Außerdem verfügt sie über extrem gute Werkzeuge und ein Standard-Build-System, das die Verwaltung von Abhängigkeiten zu einem Kinderspiel macht. Es ist der legitime Nachfolger von C++ und enthält alles, was wir in jahrelanger Arbeit mit C++ gelernt haben. Vor allem für Rapid Prototyping und Exploration lohnt es sich, MicroPython in Betracht zu ziehen - damit können Sie die beliebte Sprache Python auf Mikrocontrollern verwenden. Mit dieser Sprache können Sie Ihre Software viel schneller entwickeln, aber seien Sie sich bewusst, dass Sie dafür mit Leistung und Ressourcen bezahlen: Sie müssen leistungsfähigere (teure) Mikrocontroller verwenden und das Programm wird langsamer laufen. Aber um ehrlich zu sein, ist das viel seltener ein Problem, als man denkt...

Als nächstes müssen Sie Ihre Firmware entwerfen. Was muss sie tun? Denken Sie an alle Eingaben, die Sie lesen müssen, an alle Ausgänge, die Sie ansteuern müssen, und an die gesamte Datenverarbeitung, die Sie durchführen müssen. Stellen Sie sicher, dass Sie einen Plan haben, um alle erforderlichen Funktionen zu erfüllen, bevor Sie auf die Tastatur einhämmern. Genau wie die Hardware muss auch Ihre Firmware testbar sein. Wenn sie nicht testbar ist, können Sie nicht wirklich wissen, was Sie tun. Vor allem, wenn das System komplexer wird, brauchen Sie vollautomatische Tests. Sie müssen nicht nur die einzelnen Komponenten testen, sondern auch die Integration in das Gesamtsystem. Wenn Sie das alles im Voraus bedenken, ersparen Sie sich eine Menge Zeit und Hindernisse.

Zu guter Letzt solltest du sicherstellen, dass deine Firmware zu deiner Hardware passt. Dies ist bei eingebetteten Systemen sehr wichtig, da die Hardware die Firmware in der Regel in irgendeiner Weise einschränkt. Mikrocontroller haben zum Beispiel einen begrenzten Speicher und eine begrenzte Geschwindigkeit. Auch die Batterien sind nicht unbegrenzt. Während diese Dinge in der Proof-of-Concept-Phase nicht so wichtig sind, wird dein Projekt umso reibungsloser verlaufen, je früher du sie einschätzen könntest.

Gibt es mehr als Prototyping?

Das ist alles, was du für den Anfang brauchst. Stelle sicher, dass du dich ein wenig mehr für eingebettete Systeme interessierst als die meisten Menschen. Sie halten die größeren Systeme am Laufen und müssen nahezu perfekt sein, um ihre Funktion zu erfüllen. Wenn du unsere Tipps für den Prototyping-Prozess beachtest, stehen die Chancen gut, dass du einen relativ reibungslosen und erfolgreichen Prozess haben wirst.

Wenn du weitere Motius-ähnliche Einblicke in Prototyping-Prozesse erhalten möchtest, bleibe dran für unseren nächsten Blogbeitrag. Dort werden wir tiefer in das Rapid Hardware Prototyping eintauchen und zeigen, wie es dein Spiel auf die nächste Stufe heben kann. In der Zwischenzeit findest du in unserem Cheat Sheet weitere Insider-Tipps für die Entwicklung eines eingebetteten Systems.