I/O-Sensoren und -Messwandler beschränken
Es sollte von vornherein feststehen, ob ein System eine feste beziehungsweise begrenzte Anzahl an I/O-Anschlüssen und -Typen haben soll, oder ob die Anzahl erweiterbar und in Bezug auf den Typ flexibel sein muss. Diese Entscheidung beeinflusst die Möglichkeiten bei der Auswahl von MCUs und Peripherieschaltungen. Besonders wichtig ist dies, wenn die I/O-Kanäle aus mehr als nur einfachen Niederspannungs-Digitaleingängen bestehen, und stattdessen zum Beispiel Temperatursensoren, Motoren oder sogar serielle wie auch parallele Kommunikationsleitungen umfassen.
Externes, zertifiziertes RF-Modul einsetzen
Oft ist ein separates, vom eigentlichen Anwendungsprozessor getrenntes Modul sinnvoll. Eine hochintegrierte Single-Chip-Lösung mag in Bezug auf Platzbedarf, Stromverbrauch und Kosten attraktiv erscheinen. Bei Änderungen oder Erweiterungen des Wireless-Protokolls, der erforderlichen Reichweite oder sogar gesetzlicher Vorgaben wird jedoch ein umfassendes Re-Design oder sogar eine neue MCU und neue Firmware für den RF-Link nötig. Selbst wenn die Kodierungsaufgaben einfach sind, was relativ unwahrscheinlich ist, kann die MCU für die neuen Anforderungen nicht mehr ausreichend sein und ebenfalls ein Upgrade erfordern. Dies bedeutet zusätzliche Entwicklungszeiten und -risiken.
Stromverbrauch und Leistung abwägen
Es sollte von vornherein klar sein, wo die ausgewählte MCU in der Stromverbrauchs-/Leistungsmatrix steht. Für höhere Werte entlang der Kurve der benötigten Rechenleistung gibt es Punkte, an denen man Schwellenwerte überschreitet und zu größeren MCUs mit höherem Stromverbrauch wechseln muss. Umgekehrt gilt ebenso: Werden weniger Ressourcen benötigt, können auch kleinere, preisgünstigere MCUs zum Einsatz kommen, die weniger Strom verbrauchen. Entwickler sollten deshalb sicherstellen, dass die jeweils ausgewählte MCU eine geeignete Auswahl an Betriebsarten bietet, um Rechenleistung und Energieeffizienz abzustimmen. Damit lassen sich die Betriebsabläufe auf ein Minimum des Gesamtenergieverbrauchs optimieren, gleichzeitig werden die nötigen energieintensiven Spitzen mit hohen Leistungsanforderungen ermöglicht.
Security-Maßnahmen vereinfachen
Manche Prozessoren bieten spezielle, in Hardware implementierte Funktionen zur Automatisierung von Security-Aufgaben. Diese lassen sich dann unabhängig von der Anwendungssoftware oder sogar dem gewählten RTOS ausführen. Noch besser ist es, wenn die gleiche Embedded-Security-Funktion auf allen MCUs der Auswahlliste zur Verfügung steht. Damit kann man diesen wichtigen Teil der IoT-Entwicklung unabhängig vom ausgewählten Prozessor von der Liste der zu erledigenden Aufgaben streichen.
System standardisieren
Eine Möglichkeit besteht darin, das Design auf eine MCU zu standardisieren und dann unterschiedliche Speichergrößen (auf dem Chip integriert oder extern) zu nutzen, die den verschiedenen auf der Größe-/Leistungs-Skala angesiedelten Anforderungen entsprechen. Alternativ dazu kann man auch eine einzige, größere MCU verwenden und akzeptieren, dass bei einfachen Applikationen nicht die gesamte Speicherkapazität ausgenutzt wird. Dies gewährleistet Code- und Treiber-Konsistenz und vereinfacht die Stückliste sowie die Testprozeduren.
Betriebssystem gezielt auswählen
In bestimmten Fällen ist ein einfaches und kostengünstiges Single-Thread-Betriebssystem ausreichend. Es gibt aber auch viele Projekte, die ein Echtzeit-Betriebssystem (Real-time operating system, RTOS) erfordern. In beiden Fällen empfiehlt es sich, dass man die Skalierbarkeit des Betriebssystems als auch die Verfügbarkeit von Versionen mit kleinem, mittlerem und großem Umfang ermittelt. Man sollte einen realistischen Blick auf die Größe der kleinsten Version und den damit verbundenen Funktionsumfang werfen. Schließlich sollte man hier nicht schon an die Grenzen des Betriebssystems gelangen, wenn man das Projekt gerade einmal zu 80 Prozent fertiggestellt hat.
Hardware- versus Software-Upgrades
An wichtigen Punkten der Software-Ressourcen-Kurve, die nötig sind, um zusätzliche Aufgaben (Entwicklungszeit, Prozessor-Ressourcen) bereit zu stellen, muss der Entwickler eine Entscheidung treffen: Will er das System zur Entlastung der voll belegten MCU mit einem Peripherie-IC erweitern oder eine schnellere MCU wählen? Diese Entscheidung erfordert Vorarbeit: Er sollte analysieren, wann man mit einer leistungsfähigeren MCU Hardware-Tasks zurück in Software verlagern und damit Bauteilkosten, Platzbedarf und Stromverbrauch prinzipiell einsparen kann. Dies allerdings hat auch seinen Preis: längere Entwicklungs- und Debugging-Zeiten.
Connectivity-Protokoll sorgfältig auswählen
Ein einfacheres IoT-optimiertes Protokoll ist gegenüber einem Client/Server-HTTP-Protokoll auf Browser-Basis zu bevorzugen. Dies reduziert Protokoll-Stacks und die Datenverarbeitungs-Anforderungen um mehr als die Hälfte. Gleichzeitig ist ein Betrieb mit unterschiedlichsten IoT-Geräten und Peripherieschaltungen möglich. Darüber hinaus sollte man bereits vorab künftige Connectivity-Anforderungen (Protokoll, Geschwindigkeit, Datenintegrität) für immer anspruchsvollere Märkte mit berücksichtigen.
Testplan frühzeitig in der Designphase definieren
Bei Designs mit Wireless-Technologie ist der Testplan nicht nur komplex, er spielt auch eine entscheidende Rolle. Die Art, wie man zunächst informell und später formell überprüft, ob das Endprodukt die Anforderungen des Marktes, die technischen Spezifikationen, die Industriestandards und die gesetzlichen Vorgaben erfüllt, wirkt sich auf die Designphase und damit auch auf die Zeit bis zur Markteinführung aus. Muss man die Prototypen-Testprozeduren oder den Testaufbau in der Produktion verändern, weil ein Produkt höher skaliert oder Zusatzfunktionen für weitere Anwendungen hinzugefügt werden müssen, dann erhöht dies den Arbeitsaufwand, die Unsicherheit und das Risiko. Der Einsatz lizenzierter, vorzertifizierter Hard- und Software-Module gewährleistet Konformität und Compliance für viele, jedoch nicht alle Aspekte des endgültigen Designs. Entwickler sollten daher den strengen gesetzlichen Richtlinien für Design und Verifikation von Software (wie zum Beispiel für die Zuverlässigkeit bei Medizintechnik-Produkten) besondere Aufmerksamkeit schenken und darauf achten, welche ihrer Produkte davon betroffen sind.
Und nochmals: Security, Security, Security
Man sollte produktübergreifende Software-Techniken und -Strategien einsetzen und die Applikationsanforderungen und IoT-Benutzerschnittstellen, wie Firewalls, Authentifizierung und sogar Passwörter, anpassen. Hierfür ist es wichtig, die erforderlichen Security-Ressourcen aus folgender, hierarchisch angeordneten Liste zu ermitteln: Secure-Boot, Authentifizierung, abgesicherte Datenkommunikation, Firewall, Manipulationserkennung, Event-Reporting, Remote Command Audit und Policy-Management. Im nächsten Schritt sollte man sicherstellen, dass die tatsächliche Implementierung jeder dieser Aspekte für die verfügbaren Software-Ressourcen angemessen und machbar ist. Weiterhin ist zu ermitteln, ob die zusätzlichen Security-Funktionen bei verschiedenen Produkten eine größere oder schnellere MCU erfordern. Und schließlich sollten Entwickler einen Plan zur Überprüfung der Stabilität der implementierten Security-Maßnahmen haben.
