Industrie 4.0 08. Sep 2022 Von Harald Weiss Lesezeit: ca. 4 Minuten

Technische Schuld in der Industrie: Bei den Gefahrenquellen ansetzen

Die Folgen schlechter Programmierung beschäftigen die Informatik schon lange. Nun erreicht das Thema die Industrieautomatisierer.

Der Softwareanteil in der Automatisierungstechnik nimmt zu. Damit stellt sich auch hier immer öfter die Frage nach dem Umgang mit der Technischen Schuld.
Foto: PantherMedia / Gorodenkoff

Software ist aus der Automatisierungstechnik kaum noch wegzudenken. Deshalb müssen sich Fachleute dort verstärkt mit Themen auseinandersetzen, die in der Softwareentwicklung längst etabliert sind. Ein Beispiel ist die „technical debt“ – ins Deutsche übersetzt „Technische Schuld“.

Software-Ingenieure wissen was dahintersteckt. Der Begriff wurde schon vor vielen Jahren geprägt, um ein besonderes Problem der Software-Entwicklung in den Griff zu bekommen. Technische Schuld ist das Ergebnis der Priorisierung einer schnellen Lieferung gegenüber „perfektem“ Code. Es ist die kumulative Summe aller Designentscheidungen, die die Zukunftsfähigkeit, wie Wartung und Weiterentwicklung des Produktes beeinträchtigen. Im Programmierjargon spricht man auch von „Quick & Dirty“. Das Vorgehen kann zu erheblichen Folgeschäden und Kosten führen.

Unterschied zwischen beabsichtigter und unbeabsichtigter Schuld

Dabei unterschiedet man zwischen beabsichtigter und unbeabsichtigter Schuld, sowie zwischen kurzfristiger und langfristiger Schuld. Unbeabsichtigt entsteht sie, wenn etwa unerfahrene Softwareentwickler unwissentlich schlechten Code schreiben. Unter „Long-Term Debt“ versteht man dagegen strategische Entscheidungen, wie die Wahl einer Software-Plattform oder einer Datenbank, die zu Herausforderungen in der Zukunft führen kann.

Lesetipp: Messtechnik in der Produktion – Die nächsten Schritte zur Integration

Ein anschauliches Beispiel liefert das Jahr-2000-Problem, das 1999 die IT-Welt beherrschte. Damals ging es darum, dass viele Anwendungsprogramme aus den 70er- und 80er-Jahren die interne Jahreszahl nur zweistellig abspeicherten, also 99 für 1999. Damit aber waren programmierte Zeitdifferenzrechnungen, die über 1999 hinausgehen, nicht möglich. Es bestand die Gefahr, dass diese Programme ab dem 1.1.2000 nicht mehr funktionieren.