Vergangene Woche lasen Sie den Artikel über Simulation als Faktor für Smart Grid und Energiewende, mitsamt einem Videointerview von der Electronica Messe. Diese Woche gibt’s ein weiteres Videointerview zum Thema Obsoleszenz und wie Simulink helfen kann, das Risiko einzudämmen, das mit der Abkündigung elektronischer Komponenten einhergeht.
Dieser Artikel ist auch auf auf Englisch verfügbar.
Das Interview mit Wolfgang Patelay erschien auf Embedded News TV.
Obsoleszenz von elektronischen Komponenten bedeutet, dass Hersteller von Prozessoren, Bauteilen, Speicher usw. über die Zeit neue Produkte herausbringen und deshalb die alten nicht mehr fertigen und somit abkündigen [1]. Hersteller von Geräten, die diese Komponenten verbaut haben, sehen sich mit der Herausforderung konfrontiert diese nicht mehr verfügbar zu haben und damit umzugehen. Lösungen reichen von der Einlagerung großer Mengen der Bauteile, so lange sie noch produziert werden, über Auftragshersteller, die dieselben Komponenten in Lizenz nachbauen, hin zur Portierung der eigenen Anwendung auf andere Prozessoren und Komponenten.
Obsoleszenz meint in diesem Kontext nicht die verwerfliche Praktik der »geplanten Obsoleszenz«, bei der Geräte nach einiger Zeit ausfallen, obwohl die Technologie bei gleichen Kosten wesentlich längere Laufzeiten erlauben würde.
Das Portieren auf neue Komponenten hat den Vorteil, dass der Hersteller auch gleich die Funktionalität aktualisieren kann, aber gleichzeitig den Nachteil, dass der Aufwand, Hardwarearchitekturen und hardwarenahen C-Code zu portieren groß ist.
Die Verwendung von Simulink & Stateflow und der Model-Based Design Methode drumherum erlaubt es, einen Schritt zurückzutreten vom direkten Implementieren auf einer bestimmten Hardwarearchitektur. Wenn Sie Modelle verwenden, um Designs zu erstellen und zu simulieren, und dann aus Simulink und Stateflow automatisch C-Code oder C++-Code generieren [2], oder auch automatisch HDL Code für FPGA und ASICs erzeugen lassen [3], reduziert dies den Aufwand und das Risiko der Portierung auf neue Architekturen deutlich. Codeverifikation für Laufzeitfehler [4] nimmt dann noch das Restrisiko für die Wiederverwendung existierenden C-Codes heraus.
Referenzen und Quellen
[1] Diminishing manufacturing sources and material shortages. Wikipedia. License CC-BY-SA
[2] Embedded Code Generation. MathWorks
[4] C-Codeverifikation für Laufzeitfehler
Foto: Ioan Sameli auf Flickr, License CC-BY-SA
Schreiben Sie einen Kommentar