Merkspruch – Hardware durch Software kaputt machen

Manchmal gehen mir so Dinge durch den Kopf, die es gefühlt wert sind, mit der Welt “geteilt” bzw. für die Welt vervielfältigt zu werden. Eben war es wieder so weit, als ich über die Entwicklung von Hard- und Software sowie deren Zusammenspiel nachdachte. Viele Embedded-Entwickler dürften das Phänomen kennen, wenn sie ein Stück Hardware auf den Tisch bekommen und dazu sinngemäß einen Hinweis der Art: “Setz den Inhalt des Registers X niemals auf den Wert Y, sonst hast Du das Teil ‘gebrickt’ (kaputt gemacht)”. Es kommt aber auch vor, dass man diesen Hinweis aus verschiedenen Gründen zu spät oder gar nicht bekommt …

Dazu fiel mir spontan folgender Spruch ein:

Hardware, die man einfach per Software kaputt machen kann, ist entweder

  1. ein Funktionsmuster,
  2. billig in der Massenproduktion oder
  3. schlichtweg schlecht konzipiert.

Bei genauer Reflektion stimmt diese Aussage natürlich nur mit Einschränkungen. Denn in vielen Anwendungsfällen führen Softwarefehler zwangsläufig zu echten Problemen, zum Beispiel bei der Steuerung von Maschinen, beim autonomen Fahren bzw. Fliegen, in vielen Anwendungen der Medizintechnik und generell bei jeder Art von Software, die sicherheitsrelevante Aufgaben zu erfüllen hat. Solche Fälle meine ich in diesem Kontext jedoch nicht, denn jeder halbwegs vernünftige Entwickler bzw. jedes Entwicklerteam ist sich bei den hier aufgezählten Gebieten im Klaren darüber, dass sicherheitsrelevante Technik besondere Sorgfalt erfordert.

Es geht mir bei meiner Überlegung um jene Fälle, bei denen es eben nicht klar ist. Zum Beispiel, wenn man ein gekapseltes Modul hat, bei dem man per Software einen größeren Strom einstellen kann, als das Modul verträgt. Oder wenn es um hochpreisige Hardware geht, die sich selbst durch Dauerbetrieb überhitzen kann. In so einem Fall würde eine thermische Schutzschaltung weder preislich noch vom sonstigen Aufwand ernsthaft in’s Gewicht fallen, logischerweise müsste sie vorhanden sein, aber dennoch gibt es Fälle in denen sie fehlt – und per Software implementiert werden muss.

Wie ich darauf kam? In einem aktuellen Projekt entwickle ich selbst entsprechende Module, welche zur Zeit noch per Software “über die zulässigen Grenzen hinaus beansprucht” werden können. Das ist für mich in diesem Fall ausnahmsweise in Ordnung und zwar aus folgenden Gründen:

  1. Es ein Funktionsmuster,
  2. entwickle ich sowohl Hard- als auch Software selbst, bin mir also der Thematik vollständig bewusst (Kommunikationsprobleme mit mir selbst schließe ich in diesem Fall aus) und
  3. wird eine entsprechende Schutzschaltung bereits in der nächsten Funktionsmuster-Iteration implementiert sein.

Auf den Markt bzw. in andere Hände kommen dann nur Module, welche solide konzipiert und mit funktionsfähiger Schutzschaltung ausgestattet sind. Damit fühle ich mich erheblich besser und kann stolz auf meine Hardware sein, auch wenn sie dadurch ein paar Euro mehr kostet. Lieber hochwertig als billig.