Zusammenfassung: Die meisten Embedded-Teams starten mit denselben Referenzdesigns, SDKs und Hardwareplattformen, deshalb sehen viele Produkte am Ende ähnlich aus. Die größten Wettbewerbsvorteile liegen selten im Prozessor oder SDK. Sie liegen meist in der Systemarchitektur.
Warum sich so viele Produkte ähneln
Referenzdesigns, SDKs und gängige Hardwareplattformen helfen Teams, schneller auf den Markt zu kommen. Weil so viele Teams mit denselben Bausteinen starten, sehen viele Produkte am Ende erstaunlich ähnlich aus.
Was Referenzdesigns bieten und was nicht
Ein Referenzdesign ist der Nachweis eines Chip- oder Modulherstellers, dass ein Chip funktioniert: ein Schaltplan, ein Layout, ein Board Support Package und Beispielsoftware. Das ist wertvoll. Es nimmt viel frühes Risiko, verkürzt die Inbetriebnahme und gibt Ihnen einen bewährten Ausgangspunkt für Stromversorgung, Speicher und High-Speed-Signale.
Was es Ihnen nicht gibt, ist Ihr Produkt. Es ist gebaut, um die Funktionen des Chips allgemein zu zeigen, nicht um Ihr Kostenziel, Ihr Gehäuse, Ihren Zertifizierungsplan, Ihre Einsatzbedingungen oder Ihre Update-Strategie zu erfüllen. Alles, was Ihr Produkt besonders macht, muss darauf aufgebaut werden.
| Referenzdesign | Ihre Systemarchitektur | |
|---|---|---|
| Zweck | Nachweisen, dass der Chip funktioniert | Die Anforderungen Ihres Produkts erfüllen |
| Tempo bis zum ersten Prototyp | Schnell | Baut auf dem Referenzdesign auf |
| Differenzierung | Für jeden Kunden des Chips gleich | Hier wird Ihr Produkt besonders |
| Kosten und Stückliste | Universell, oft mehr als nötig | Optimiert für Ihre Stückzahl und Funktionen |
| Kommunikation und Orchestrierung | Generische Beispiele | Für Ihre Geräte und Daten entworfen |
| Lebenszyklus und Updates | Nicht im Umfang | Von Anfang an geplant |
Das Beispiel LaMetric SKY
Bei LaMetric SKY mussten wir Grafiken über 16 intelligente Kacheln mit je 64 einzelnen Zonen mit videoähnlichen Bildwiederholraten synchronisieren und gleichzeitig einzelne Kacheln über denselben RS-485-Bus aktualisieren.
Standardprotokolle waren dafür nicht ausgelegt. Bei einem System mit über 1.000 Lichtzonen und grafischen Updates in Echtzeit wird der Protokoll-Overhead zum Engpass.
Statt diese Grenzen hinzunehmen, haben wir ein eigenes RS-485-Protokoll mit hohem Durchsatz entwickelt, optimiert für das Streaming grafischer Daten, Synchronisation, Geräteadressierung, Zuverlässigkeit und Software-Updates über verteilte Embedded-Knoten.
Die Lektion: asymmetrischer Vorteil
Die Lektion handelte nicht von RS-485. Es ging um asymmetrischen Vorteil. Referenzdesigns helfen, schneller auf den Markt zu kommen, aber Differenzierung entsteht oft in den Architekturebenen darüber:
- Kommunikations-Stacks.
- Verteilte Systeme.
- Orchestrierung von Geräten.
- Management des Software-Lebenszyklus.
- Abwägung zwischen Stücklistenkosten, Hardwarekomplexität und Zertifizierungsanforderungen.
- Ein einziges Funkmodul für mehrere Recheneinheiten nutzen, statt Konnektivitätshardware zu duplizieren.
- User Experience.
Die wertvollsten technischen Entscheidungen sind für den Endnutzer oft unsichtbar.
Fragen, die Chancen in der Architektur aufzeigen
- Wo begrenzt ein Standardprotokoll oder Standardbauteil, was das Produkt kann?
- Welche Teile des Systems sind doppelt vorhanden und könnten geteilt werden?
- Was passiert mit Kosten, Energie und Zertifizierung, wenn eine Funktion zwischen Hardware und Software wandert?
- Wie wird jeder Teil des Systems im Feld aktualisiert, auch Jahre nach dem Launch?
- Was bemerken die Nutzer, und was kann unsichtbar bleiben und das Produkt trotzdem besser machen?
Häufige Fehler
- Das Referenzdesign mit minimalen Änderungen ausliefern und damit seine Kosten und Grenzen übernehmen.
- Die Kommunikation zwischen Komponenten als Detail statt als Designentscheidung behandeln.
- Updates nur für den Hauptprozessor planen und die anderen Prozessoren im System vergessen.
- Eigene Lösungen bauen, wo eine Standardlösung reichen würde. Eigenentwicklung lohnt sich nur dort, wo sie einen echten Vorteil schafft.
Wo sich der Vorteil versteckt
In den Jahren, in denen wir eigene Produkte gebaut und OEMs bei der Entwicklung vernetzter Geräte unterstützt haben, haben wir gelernt: Die größten Wettbewerbsvorteile liegen selten im Prozessor, im SDK oder im Referenzdesign. Sie stecken meist in der Systemarchitektur. Sie zu finden braucht mehr als starkes Engineering: Es hilft, Menschen mit der Denkweise von Produktentwicklern und Erfindern im Team zu haben oder mit solchen zusammenzuarbeiten.
Wie sich Architektur in den Kosten zeigt
Architekturentscheidungen bestimmen die Stückliste oft stärker als die Bauteilauswahl. Ein Funkmodul für mehrere Prozessoren teilen, eine Funktion von einem eigenen Chip in die Software verlagern oder einen Bus wählen, der weniger Stecker braucht: Jede dieser Entscheidungen kann Bauteile aus jeder Einheit entfernen. Umgekehrt gilt dasselbe: Eine Architektur, die Funktionen doppelt oder zusätzliche Prozessoren braucht, trägt diese Kosten über die gesamte Produktlebensdauer.
Auch die Zertifizierung folgt der Architektur. Die Anzahl der Funkmodule, ihre Lage und wie sie geteilt werden, bestimmen den Zertifizierungsaufwand für jeden Markt. Wer das in der Architekturphase bedenkt, vermeidet später wiederholte Prüfungen.
Für die gesamte Produktlebensdauer planen
Ein Referenzdesign ist meist für die erste Version eines Produkts gebaut. Eine Produktarchitektur muss die folgenden Versionen tragen: neue Funktionen, neue Hardware-Revisionen und jahrelange Software-Updates. Planen Sie, welche Teile des Systems im Feld aktualisiert werden können, wie verteilte Komponenten auf kompatiblen Softwareversionen gehalten werden und wie sich das System erholt, wenn ein Update auf einem Teil fehlschlägt. Solche Entscheidungen sind später schwer nachzurüsten und früh leicht zu planen.
FAQ
Sollten wir Referenzdesigns meiden?
Nein. Starten Sie damit. Sie sparen Zeit und senken das Risiko. Entscheidend ist, sie als Ausgangspunkt zu behandeln, nicht als Architektur.
Wann lohnt sich ein eigenes Protokoll?
Wenn ein Standardprotokoll eine für das Produkt wichtige Anforderung nicht erfüllen kann, etwa bei Durchsatz, Latenz oder Synchronisation, und der Vorteil den Aufwand für Entwicklung und Pflege rechtfertigt.
Wann sollte ein Architektur-Review stattfinden?
Bevor die Plattform und die wichtigsten Schnittstellen eingefroren werden. Änderungen sind auf dem Papier am günstigsten.
Woran erkennen wir, wo unser Vorteil liegt?
Schauen Sie, was Kunden schätzen und was Wettbewerber schwer kopieren können. Das ist meist eine Kombination aus User Experience, Zuverlässigkeit, Kosten und wie gut sich das Produkt nach dem Launch weiter verbessert. Architekturentscheidungen, die genau das stützen, lohnen die Investition.
Verzögert eine eigene Architektur das erste Release?
Das kann sie, wenn alles eigenentwickelt ist. Behalten Sie Standardkomponenten dort, wo sie funktionieren, und konzentrieren Sie die Eigenentwicklung auf die wenigen Stellen, die das Produkt verändern. So bleibt das erste Release im Zeitplan, und der Vorteil entsteht dort, wo er zählt.
Wer sollte die Systemarchitektur verantworten?
Eine Person oder eine kleine Gruppe sollte für das Gesamtsystem über Hardware, Firmware, Cloud und Fertigung verantwortlich sein. Optimiert jedes Team seinen Teil isoliert, driftet das System auseinander, und die Vorteile aus dem Blick auf das ganze Produkt gehen verloren. Viele Unternehmen haben keinen Vollzeit-Systemarchitekten, weshalb ein Architekt in Teilzeit eine praktische Option sein kann.
Wie wir helfen
Diese Denkweise als Produktentwickler bringen wir in die Architekturen unserer Kunden ein, von Kommunikations-Stacks bis zu Abwägungen bei Stückliste und Zertifizierung. Siehe unsere Leistungen Architektur-Review für Embedded-Produkte und Systemarchitekt in Teilzeit. Wenn Sie einen zweiten Blick auf Ihre Systemarchitektur möchten, sprechen Sie mit einem Ingenieur.
