Technischer Entscheidungsleitfaden · Vernetzte Produkte

Wie planen Sie Geräteverwaltung und OTA-Updates für vernetzte Produkte?

Dass ein IoT-Gerät erstmals Daten an den Server sendet, bedeutet noch nicht, dass sich das Produkt verwalten lässt. Erstinstallation, Geräteidentität, Berechtigungen, Verbindungsunterbrechungen, Fernbefehle und Softwareupdates müssen gemeinsam entwickelt werden. Dieser Leitfaden erläutert, welche Verhaltensweisen und technischen Liefergegenstände bei einem kundenspezifischen Geräte- und Serverprojekt von Anfang an festgelegt werden sollten.

Leitfaden zur Produktentwicklung · · Veröffentlichung: · Aktualisiert:

Beschreiben Sie Ihr Projekt Lesen Sie den Leitfaden
Identität, Telemetrie, Befehle und Softwareaktualisierungen fließen zwischen dem verbundenen Gerät und dem Server
Konzeptionelle technische Darstellung · Leitfaden für technische Entscheidungen · Vernetzte Produkte
LebenszyklusVon der Fertigung bis zur Wartung im Feld
ArchitekturGerät, Verbindung und Server gemeinsam
LieferungQuellen, Schnittstellen- und Betriebsinformationen

VOMRO Engineering-Ansatz

Machen Sie die Vernetzung aus einer Demofunktion zu einer dauerhaft betreibbaren Produkteigenschaft.

In einem Pilotversuch mag es ausreichend erscheinen, einige Geräte in derselben Oberfläche zu sehen. Mit zunehmendem Feldeinsatz werden Fragen wichtig: Welches Gerät gehört zu welchem Kunden, wann kamen die letzten Daten und welche Version läuft darauf? Ein Gerät kann neu eingerichtet werden, Netzwerkdaten können sich ändern oder es kann eine Zeit lang ohne Internet bleiben. Auch verzögerte Fernbefehle und unterbrochene Updates müssen zu vorhersehbarem Produktverhalten führen.

Die Lösung beginnt damit, Verantwortlichkeiten und Szenarien zu definieren, bevor eine bestimmte Cloudmarke ausgewählt wird. Embedded-Software, API, Datenbank und Verwaltungsoberfläche müssen ein gemeinsames Datenwörterbuch verwenden. Die folgenden Schritte dienen dazu, die Anforderungen an das kundeneigene Produkt zu erarbeiten. VOMRO entwickelt den Hardware- und Softwareumfang Ihres Projekts, statt ein fertiges Geräteverwaltungsabonnement zu verkaufen; die Zuständigkeiten für Hosting, Betrieb und Wartung werden gesondert geklärt.

01

1. Geräteidentität, Benutzerkonto und Installationsdatensatz trennen

Geräteseriennummer, Kommunikationskennung und Benutzerkonto erfüllen unterschiedliche Aufgaben. Für das gefertigte Gerät wird ein eindeutiger Datensatz angelegt; Hardware-Revision und aufgespielte Software werden nachverfolgt. Bei der Erstinstallation ist ein definierter Ablauf erforderlich, um das Gerät dem richtigen Kunden oder Standort zuzuordnen. Die Kenntnis der Gerätekennung darf keine Zugriffsberechtigung bedeuten.

Legen Sie fest, was bei einem Besitzerwechsel, einer Wartung oder dem Zurücksetzen auf Werkseinstellungen geschieht. Möglicherweise müssen der Zugang des bisherigen Benutzers gesperrt und die neue Installation dem richtigen Datensatz zugeordnet werden. Es wird definiert, wo die bei der Fertigung zugewiesenen Informationen gespeichert werden, wer sie nutzen darf und welche Daten das Serviceteam sieht. So bleibt die Geräteverwaltung nicht auf ein Namensfeld in der Oberfläche beschränkt, sondern wird zu einem nachvollziehbaren Prozess im Produktlebenszyklus.

  • Eindeutiger Gerätedatensatz und Hardware-/Softwareversion
  • Zuordnung zu Kunde, Standort und Benutzer
  • Szenarien für Service, Übergabe und Zurücksetzen
02

2. Umfang der Ersteinrichtung und Zugangsdaten festlegen

Bei der Ersteinrichtung (Provisioning) erhält das Gerät die Informationen, die es für den Beitritt zum Netzwerk und zum jeweiligen Dienst benötigt. Die vom Benutzer eingegebenen WLAN-Daten, die Serveridentität des Geräts und das Benutzerkonto dürfen nicht als dasselbe Geheimnis behandelt werden. Je nach Produktnutzung kommen Verfahren wie BLE, eine lokale Verbindung oder die Programmierung in der Fertigung infrage. Auch Rückkehr- und Wiederholungsverhalten bei einer unterbrochenen Einrichtung werden definiert.

Die Zugriffsberechtigung des Geräts wird auf die benötigten Ressourcen beschränkt. Damit ein Gerät nicht auf Daten anderer Kunden zugreift, ist eine serverseitige Berechtigungsprüfung erforderlich. Die Erneuerung oder der Widerruf von Zugangsdaten werden für verlorene Geräte und Servicefälle betrachtet. Vertrauliche Informationen werden nicht unnötig in Protokollen oder der Clientoberfläche angezeigt. Diese Designgrundsätze werden entsprechend den Projektanforderungen umgesetzt; die Wahl eines einzelnen Protokolls garantiert nicht die Sicherheit des Gesamtsystems.

  • Ablauf für Erstinstallation und erneute Konfiguration
  • Nach Gerät und Rolle begrenzter Zugriff
  • Regeln für Erneuerung, Widerruf und Protokollierung von Zugangsdaten
03

3. MQTT und HTTP-basierte APIs gemeinsam mit dem Datenfluss planen

Das Publish/Subscribe-Verfahren von MQTT und der Anfrage-Antwort-Austausch über eine HTTP-basierte API unterstützen unterschiedliche Datenflüsse. Beide Verfahren können in einem Produkt gemeinsam für verschiedene Aufgaben eingesetzt werden. Messhäufigkeit, Befehle vom Server zum Gerät, Verbindungscharakteristik und vorhandene Softwareinfrastruktur werden gemeinsam bewertet. MQTT-Topic-Struktur beziehungsweise HTTP-API-Pfade, Datenfelder und Versionen werden dokumentiert. Transportschutz wie TLS, Prüfung der Serveridentität und Zugriffsberechtigung werden als getrennte Designaufgaben behandelt.

Die MQTT-Zustellstufen beziehen sich auf die Nachrichtenübertragung. Der Empfang einer Nachricht bedeutet nicht, dass ein Ventil geöffnet oder eine Einstellung physisch umgesetzt wurde. Mögliche Mehrfachzustellung und Sitzungsverhalten müssen auf Anwendungsebene berücksichtigt werden. Gerätezeit, Wiederverbindung mit dem Netzwerk und der Lebenszyklus der Serverzertifikate gehören ebenfalls zu den Verbindungstests. Die Auswahl erfolgt anhand des gesamten Betriebsszenarios des Produkts und nicht allein anhand der Fähigkeit, kleine Pakete zu senden.

  • Topic-/API-Verzeichnis, Datenschema und Versionierung
  • Trennung von Transportschutz, Authentifizierung und Berechtigung
  • Trennung von Nachrichtenzustellung und Ergebnis des physischen Vorgangs
04

4. Offlinedaten mit Zeit- und Qualitätsinformationen speichern

Müssen lokale Messung oder Steuerung bei unterbrochener Internetverbindung weiterlaufen, werden Aufzeichnungskapazität und Speicherverfahren festgelegt. Datenpriorität, Verhalten bei vollem Puffer und Schreibgrenzen des Speichers werden bewertet. Messzeitpunkt und Eingang am Server müssen getrennt bleiben. Für Datensätze, deren Geräteuhr noch nicht verifiziert ist, sind Angaben zur Zeitqualität oder zur Reihenfolge erforderlich.

Nach Wiederherstellung der Verbindung darf die Übertragung gespeicherter Datensätze neue Messungen nicht behindern. Es wird festgelegt, wie der Server erneut gesendete Datensätze erkennt und an welcher Stelle die Übertragung fortgesetzt wird. In der Oberfläche dürfen der Zeitpunkt der letzten Kommunikation und der letzten Messung nicht verwechselt werden. Benutzer müssen erkennen können, wenn sie alte Daten sehen. Aufbewahrungsdauer und Aufzeichnungsvolumen sind Produktanforderungen, die sowohl den Gerätespeicher als auch den Serverspeicher beeinflussen.

  • Puffergröße, Füllstand und Aufzeichnungspriorität
  • Messzeit, Eingangszeit und Datengültigkeit
  • Erkennung doppelter Datensätze und Fortsetzung nach Unterbrechung
05

5. Annahme, Ausführung und Ergebnis von Fernbefehlen verfolgen

Befehle werden durch Kennung, Erstellungszeit und gegebenenfalls Gültigkeitsdauer definiert. Versionsinformationen helfen zu verhindern, dass ein älteres Gerät einen unbekannten neuen Befehl unbemerkt falsch interpretiert. Beim Empfang kann das Gerät zunächst die Zulässigkeit prüfen; Zustände wie angenommen, abgelehnt oder zurückgestellt werden nach Anwendungsbedarf festgelegt. Das Ergebnis des physischen Vorgangs wird gesondert gemeldet.

Nicht in jedem Projekt ist es erwünscht, dass ein alter Befehl nach einer Verbindungsunterbrechung später ausgeführt wird. Es gibt auch Fälle, in denen ein erneut übertragener Befehl keine zweite Aktion auslösen darf. Für gleichzeitige Änderungen derselben Einstellung durch lokale und entfernte Benutzer werden Priorität oder Versionskontrolle definiert. Bei Maschinen- und Feldsteuerungen werden die Verantwortlichkeiten für Verbindung, lokale Steuerung und Sicherheit gemeinsam geklärt. Der erforderliche Nachweis, damit eine Schaltfläche in der Oberfläche Erfolg anzeigt, kann über den bloßen Nachrichtenversand durch den Server hinausgehen.

  • Befehlskennung, Version und Gültigkeitsdauer
  • Zustände empfangen, angenommen und ausgeführt
  • Wiederholte und verspätete Befehle sowie lokale/entfernte Priorität
06

6. OTA-Updates vor der Auswahl der Platine planen

OTA bezeichnet die Fernaktualisierung der Gerätesoftware und hängt mit Speicheraufteilung, Bootloader und Verhalten der Energieversorgung zusammen. Es wird festgelegt, wo die neue Software gespeichert wird, was bei einem unterbrochenen Download geschieht und für welche Hardware-Revision sie geeignet ist. Prüfung signierter Software und sichere Übertragung werden entsprechend den Projektanforderungen ausgelegt. Die Signatur dient dem Nachweis einer autorisierten Softwarequelle; allein beweist sie keinen fehlerfreien Betrieb.

Wenn eine Prüfung beim ersten Start und eine Rückkehr von einer fehlerhaften Version (Rollback) erforderlich sind, wird eine geeignete Architektur geschaffen. Eine vorhandene Rückkehrmöglichkeit bedeutet nicht, dass bedingungslos jede ältere Version wiederhergestellt werden darf; Sicherheitsversion und Datenkompatibilität werden gesondert bewertet. Die Dokumentationen zu Espressif OTA und MCUboot zeigen unterschiedliche Implementierungsbeispiele. Der gewählte Ansatz hängt von der ausgewählten Hardware ab. Szenarien wie Stromausfall während des Updates und fehlgeschlagener Start werden am Prototyp geprüft.

  • Speicher, Bootloader und Hardwarekompatibilität
  • Signatur- und Versionsprüfung entsprechend den Projektanforderungen
  • Tests zu Unterbrechung, erstem Start, Rollback und Wiederherstellung
Testaufbau für Netzwerk- und Stromunterbrechungen beim Softwareupdate eines vernetzten elektronischen Geräts
Repräsentatives Anwendungsbild.
07

7. Flottenübersicht und Updateabnahme konkretisieren

Für die Verwaltungsoberfläche kann die reine Onlineanzeige eines Geräts unzureichend sein. Letzte Messung, letzte Kommunikation, Softwareversion, Hardware-Revision und Updatestatus werden in getrennten Feldern geführt. Welche Informationen Installationsteam, Kunde und Entwickler sehen, richtet sich nach ihren Rollen. Fehlerprotokolle sollen die Diagnose unterstützen, ohne sensible Daten unnötig offenzulegen.

Es wird besprochen, ob neue Software zunächst in einer Pilotgruppe bewertet und anschließend schrittweise verteilt werden soll, statt alle Geräte gleichzeitig zu aktualisieren. Das Erfolgskriterium wird ausdrücklich festgelegt: Ist es der abgeschlossene Download oder der Betrieb mit der neuen Version samt Verifizierungsbericht? Für Geräte mit unzureichender Verbindung, zu wenig Energie oder inkompatibler Hardware werden Zurückstellungszustände definiert. Ändert sich das Datenmodell, wird auch das Zusammenwirken alter und neuer Versionen in die Tests aufgenommen. Betriebsverantwortung und Supportablauf werden vor der Projektübergabe festgelegt.

  • Getrennte Anzeige von Version, letzter Kommunikation und Updatestatus
  • Anforderungen an Pilotgruppe und schrittweise Verteilung
  • Ablauf bei Inkompatibilität, Zurückstellung und Fehlern
08

8. Neben Quellcode auch Installations- und Betriebsinformationen in die Übergabeliste aufnehmen

Die Übergabeliste sollte neben Embedded-Software- und Serverquellen auch API-/Datenwörterbuch, Build- und Installationsinformationen, Datenbankänderungen und Testszenarien enthalten. Es wird erläutert, wie Programmierung, Erstellung von Geräteidentitäten und Veröffentlichung von Updates erfolgen. Die Zuständigkeiten für Zugangsdaten und Projektschlüssel werden festgelegt; Geheimnisse gehören nicht in öffentlich zugängliche Quelldateien. Lizenz- und Betriebsbedingungen genutzter Dienste und Bibliotheken Dritter werden gesondert aufgeführt.

Bei VOMRO unterzeichnen wir auf Ihren Wunsch vor dem technischen Austausch eine NDA. Projektspezifische Quellcodes, Designdateien und technische Dokumente werden zum Projektabschluss übergeben. Im ersten Gespräch können Sie die erwartete Gerätezahl, Datenhäufigkeit, Verbindungsart sowie den Bedarf an Offlinebetrieb und Fernbefehlen erläutern. Gibt es bereits einen Server oder eine API, werden die Integrationsbedingungen geprüft. Der Umfang von Hosting, Datensicherung, Updates und Wartung wird gemeinsam mit den technischen Entwicklungsergebnissen geklärt.

  • Geräte- und Serverquellen sowie Schnittstellendokumentation
  • Informationen zu Installation, Identitätsvergabe, Updates und Tests
  • NDA, technische Übergabeliste und Betriebsverantwortung
Zustände, die bei vernetzten Produkten getrennt werden müssen
Anzeige in der OberflächeTechnische BedeutungZusätzlich zu beobachtender Aspekt
Gerät verbundenKürzlich fand Kommunikation stattZeitpunkt der letzten gültigen Messung
Befehl gesendetDer Server hat die Übertragung gestartetAnnahme durch das Gerät und physisches Ergebnis
Update heruntergeladenDie Datei ist auf dem Gerät angekommenPrüfung, Start und Versionsbestätigung

Wie es funktioniert

Verwandeln Sie Entscheidungen in einen Projektplan.

Nicht jedes Projekt sieht gleich aus; Die messbaren Anforderungen, die kontrollierte Überarbeitung und die Schritte zur Feldverifizierung bleiben jedoch unverändert.

  1. 01

    Lebenszyklus beschreiben

    Definieren Sie Szenarien für Fertigung, Erstinstallation, Nutzung, Service und Übergabe.

  2. 02

    Schnittstelle definieren

    Vereinheitlichen Sie das Verzeichnis für Identitäten, Berechtigungen, Daten, Befehle und Versionen.

  3. 03

    Unterbrechungen erproben

    Prüfen Sie Verbindungs- und Stromausfall, veraltete Daten und fehlgeschlagene Updates.

  4. 04

    Quellen übernehmen

    Übernehmen Sie Code, Design-, Installations- und Betriebsdokumentation anhand der technischen Übergabeliste.

häufig gestellte Fragen

Vor Beginn des Projekts

Der technische Umfang, die zu liefernden Leistungen und der Testplan werden gemeinsam entsprechend den Anforderungen Ihres Projekts geklärt.

Bedeutet MQTT, dass das Gerät sicher ist?

Nein. MQTT definiert das Nachrichtenverhalten. Transportschutz, Authentifizierung, Zugriffsberechtigungen, Schlüsselverwaltung und Anwendungsverhalten werden gesondert entwickelt und unter den Projektbedingungen verifiziert.

Kann OTA nachträglich ergänzt werden?

Bei manchen Designs ist das möglich, jedoch können Änderungen an Speicher, Bootloader, Hardware und Wiederherstellungskonzept erforderlich sein. Es ist sinnvoll, den Bedarf an Fernupdates vor der Wahl von Platine und Softwarearchitektur festzulegen.

Müssen bei einem Internetausfall Daten verloren gehen?

Nein. Bei geeigneten Speicher- und Energiebedingungen lässt sich eine lokale Pufferung entwickeln. Kapazität, Zeitinformationen, Verhalten bei vollem Speicher und Erkennung doppelter Datensätze nach Wiederverbindung werden zu Beginn festgelegt.

Verkauft VOMRO ein eigenes Cloudprodukt?

Diese Leistung umfasst die kundenspezifische Entwicklung vernetzter Geräte und Software. Der Umfang der Integration in Ihre vorhandene Infrastruktur oder einer Serveranwendung für das Projekt wird festgelegt. Die Zuständigkeiten für Hosting und Wartung werden gesondert erläutert; Projektquellen und technische Dokumente werden zum Abschluss übergeben.

Verwandte Inhalte

Vom Gerät bis zum Verwaltungspanel

Serversoftware und Geräteverwaltung

 Zuverlässige Daten vom Feld bis zum System

IoT, Kommunikation und Automatisierungsintegration

 Wir entwerfen das Verhalten des Geräts

Entwicklung von Embedded-Software und Embedded-Systemen

 Von der Idee zum Produkt Ihrer Marke

Entwicklung von Konsumelektronik und Produkten für Endanwender

Alle Produktentwicklungsdienstleistungen

Ihr Projekt, Ihr Produkt

Wir entwickeln vertraulich und übergeben die Quelldateien.

Vor dem Austausch technischer Details können wir mit einer Geheimhaltungsvereinbarung (NDA) arbeiten. Zum Projektabschluss übergeben wir Ihnen die von uns entwickelten Quellcodes, Designdateien und technischen Dokumente.

  • Vor der Weitergabe technischer Informationen NDA
  • Von Beginn an eine klare Übergabeliste
  • Quell- und technische Dateien am Ende des Projekts
Unser Datenschutz- und Lieferprozess
Beginnen wir mit Ihrer Idee

Lassen Sie uns über das Produkt sprechen, von dem Sie träumen, und über den Bedarf, den Sie lösen möchten.

Senden Sie eine Projektanfrage +90 534 487 98 02