In Zeiten der DEV-OPS Philosophie spricht jeder von kontinuierlicher Integration und kontinuierlichem Test. Wer schon ein altes Haus renoviert hat weiß, wenn eine Unzulänglichkeit beseitigt wird, tritt die nächste Schwachstelle in den Fokus.
In aktuellen Entwicklungskonzepten wird meist der Fokus auf die Software gelegt. Änderungen werden umfänglich getestet und effektiv ausgeliefert. HW-Fehler bestehen meist Jahrzehnte im Feld. Trotz SW-Änderung (um die Welt zu retten) bleibt oft eine funktionale Degradierung.
Kurzgefasst:
Die Qualität der Hardware Entwicklung bei IoT/IIoT-Geräten tritt nach der Standardisierung und Verbesserung der Software-Prozesse noch stärker in den Fokus.
Auch beim DEV-OPS Ansatz steht und fällt alles mit der strukturierten Analyse der System-Anforderungen, der Testabdeckung und der kontinuierlichen Automatisierung der Lieferkette.
Nur vollumfänglich durchgetestete standardisierte Module, die zusätzlich im Integrationstest abgesichert werden, helfen Fehler im Feld zu vermeiden.
—
Eine Kombination aus übereifriger Markteinführung, nicht haltbaren Versprechen an den Kunden und fehlende Prozess-/Methoden-Kompetenz ist tödlich und führt zu einem Desaster im Feld.
Bei einer Fehlerrate von 0,5 Promille werden bei 10 Millionen ausgelieferten Teilen immer noch 5000 Geräte im Feld ausfallen.
Eine alte Weisheit in der Produktentwicklung ist: Kann ein Fehler auftreten, wird er beim Kunden gesehen.
Nur zwei Beispiele aus der Praxis:
- Änderungen im zeitlichen Verhalten von Speicherzugriffen verursachen plötzlich Störungen bei der EMV in den unterschiedlichsten Frequenzbereichen.
- Die Flankensteilheit der Signale wird optimiert und das Produkt funktioniert nicht mehr unter -20°Celsius.
Noch kritischer wird die Lage, wenn Sicherheitsanforderungen ins Spiel kommen.
Immense Kosten und ein negatives Image können folgen.
Nicht selten werden komplette Lieferungen gestoppt oder sogar Produkte zurückgerufen.
Was kann daraus gelernt werden?
- Unscharfe Anforderungen müssen so schnell wie möglich eliminiert werden.
- Funktionen, wenn möglich von der HW in die SW verlagern.
- Bevorzugt hochintegrierte Standard Module verwenden.
- Produktspezifischen Teil kapseln.
- Unterschiedliche Ausbaustufen mit Modularen PCB’s entwickeln (reduziert die Komplexität und den Aufwand für Entwicklung und Test).
- HW Produkt Fahrplan definieren (Agieren anstatt reagieren).
- Produkte auf Systemebene entwickeln (SW zentrische Entwicklung des Produkts führen oft zu Schwachstellen auf der Systemebene).
- HW-Entwurfsmuster und Goldene-Regeln einsetzen (um schon bekannte Fehlerquellen in der Entwicklung zu vermeiden).
- Jede SW-Änderungen auf EMV- und Umwelt-Auswirkungen überprüfen.
- Wird eine vorhandene HW für weitere Produkte mit gleicher Funktion übernommen, muss explizit eine Analyse der Anforderungen (Umwelt, EMV, FUSA, …) durchgeführt werden.
- Simulationen für EMV und Umwelt einsetzen um frühzeitig Schwachstellen und Fehler zu entdecken.
- Optimierung der HW zur Kostenreduktion müssen überprüft werden, um Mehrkosten im Feld zu vermeiden.
- HW-Design kontinuierlich säubern (um die Komplexität zu reduzieren).
- CAE-Werkzeuge müssen eine Schnittstelle für Skriptsprachen besitzen.
- Designdaten müssen in einem Computer lesbaren Format abspeichert werden (z.Bsp. XML – nicht binär).
- Automatisierte Überprüfung von Design und elektrischen Regeln sind Pflicht.
- Automatischer Export von Metriken, Schaltplan, Layout und Gerber Files helfen den Ingenieuren sich auf das Wesentliche zu konzentrieren.
- Der gesamte Lebenszyklus des Produktes muss geplant werden (nicht nur bis Start der Produktion)!
Eine klare vorauseilende HW-Entwicklung mit akkurater Spezifikation verhindert die Explosion von HW-Varianten und den damit verbundenen Kosten.
Durch die strikte Anwendung der DEV-OPS Philosophie auf die HW-Entwicklung und der Automatisierung der Lieferkette kann die Dauer der Entwicklungszyklen deutlich reduziert werden!
Markennamen und geschützte Warenzeichen sind Eigentum ihrer jeweiligen Inhaber. Die Nennung von Markennamen und geschützter Warenzeichen hat lediglich beschreibenden Charakter. Genannte Marken stehen in keinerlei Partnerschaft oder Kooperation zu Tobias Haar IT&A. Die Angabe der Marken erfolgt durch den jeweiligen Autor/Nutzer. Irrtümer vorbehalten.