28 Jahre Software Entwicklung Die kleine Technikgeschichte von Walter Borst

Mit der Entwicklung von Software beschäftige ich mich bereits seit 1978. In den meisten Vermittlungszentralen der Post taten noch Heb-Dreh-Wähler ihren Dienst, als ich den ersten Mikroprozessor kennen lernte. Damals war es ein 6800 von Motorola, dessen Programm in hexadezimalen Kodes eingegeben wurde. Als ich 1982 mit dem Studium der Nachrichtentechnik fertig war, begann ich als Projektleiter und wurde später Abteilungsleiter. Seit 1992 betreibe ich ein kleines Ingenieurbüro. Die ganze Zeit über war das Thema Software irgendwie mit meiner Arbeit verknüpft. Die Geschichte der Technik, die sich in meinem Umfeld abgespielt hat, erfährst Du im Folgenden.

Die Idee 'Feldbus'

Die Einführung des Mikroprozessors zu Beginn der 1980er Jahre änderte die Möglichkeiten der Ingenieure, die Feldgeräte für die Prozeßsteuerung (Industrielle Verfahrenstechnik) und die Fabrikautomatisierung entwickelten, von Grund auf. Mikrocontroller - wie die Familie des 8031 - hatten damals schon serielle Schnittstellen auf dem Chip. Man bekam diese sozusagen geschenkt. Die Entwickler benutzten den Kommunikationszugang zum Testen und zur Fehlersuche. Später wurde die Schnittstelle auch dazu verwendet, das Gerät mit neuen Funktionen auszustatten, die dem Geräte-Betreiber zur Verfügung standen. Die Idee, dass es von Vorteil sein könnte, diese serielle Verbindung zu standardisieren, war logisch. Die Idee zum Feldbus entstand Mitte der 1980er Jahre. Wie die Entwicklung des Feldbus schließlich ausgegangen ist, zeigt, dass die Vorstellung 'Ein Feldbus für alle Anwendungen' so nicht durchsetzbar war. Es gibt ja auch nicht eine einzige Schraube für alle Sorten von Schraubverbindungen. Besonders interessant ist aber, dass das Hart Protokoll und Modbus niemals Standards wurden wie z.B. der Profibus, aber eine bemerkenswerte und vergleichbare Verbreitung gefunden haben. In der Liste mit Links, erhältst Du einen Überblick über die Technologien.

Windows Software

Seit Beginn der 1990er Jahre gibt es das Ingenieurbüro Borst Automation. Inzwischen begann Windows als Betriebssystem langsam damit, DOS bei der PC Programmierung zu verdrängen. Allerdings war zu dieser Zeit die Programmierung unter Windows relativ kompliziert verglichen mit DOS. Die Entwickler von Embedded Systemen hatten zunächst gar nicht die Zeit, sich schnell genug mit der Programmierung unter Windows vertraut zu machen. Einige Manager von Firmen, die Produkte für Prozeßsteuerung und Fabrikautomatisierung anbieten, trafen sogar Aussagen wie: "Die Programmierung unter Windows ist nicht unsere Kernkompetenz!". Das war eine Chance für Borst Automation, in die Windows-Programmierung einzusteigen. Es wurden Programme zur Konfiguration von Feldgeräten entwickelt, die mit den Hart Protokoll, Profibus oder Modbus ausgestattet waren. Aus diesen Entwicklungen wurde eine Version zusammengestellt, die ich Visual Instrument genannt habe.

Ende der 1990er Jahre war die Programmierung von Anwendungen unter Windows kein so großes Geheimnis mehr, gab es doch mittlerweile Programmierumgebungen wie Delphi, Visual Basic und viele andere. Aber jetzt wurden Treiber benötigt, die das jeweilige Kommunikations-Protokoll unterstützten. Ein Treiber für das Hart Protokoll ist deshalb nicht so einfach in Windows zu realisieren, weil das Hart Protokoll Reaktionszeiten im Bereich Millisekunden benötigt. Borst Automation brachte 1998 ein Aktiv X für die Hart Kommunikation auf den Markt, was zunächst den Produktnamen ActiveHART hatte und später in Hart X 3.0 unbenannt wurde. Dieses OCX basierte auf dem OLE Interface von Windows und arbeitete ähnlich wie ein OPC Server. Ein Aktiv X lässt sich in einer Visual Basic Umgebung sehr einfach und komfortabel einsetzen. Setzt man ein Aktiv X in C++ ein, fragt man sich aber, was denn der Vorteil ist. In einer ANSI C Umgebung dagegen lässt es sich gar nicht einsetzen. Daher habe ich einen neuen Treiber in Form einer 'einfachen' Windows Dll entwickelt, der das Hart Protokoll bis Version 6 unterstützt.

Software für Embedded Systeme

Seit dem Jahr 2000 wurde Software ein immer wichtigeres Thema bei der Entwicklung von Feldgeräten. Die Komplexität der Lösungen wächst von Generation zu Generation und die Qualität der Software nimmt inzwischen eine zentrale Stellung bei den Entwicklungskosten ein. Früher war es üblich, dass nur ein Entwickler für die Software eines Geräts zuständig war, heute ist dies meist die Aufgabe eines Teams. Daher ist es heute üblich, dass zunächst ein Software Design erfolgt und dass das Software Projekt nach strengen Regeln betrieben wird. Es muss eine funktionale Beschreibung und eine Testspezifikation existieren, bevor mit der Entwicklung überhaupt begonnen wird.

Auch da die Firmen, die Produkte für die industrielle Verfahrenstechnik und Fabrikautomatisierung anbieten, weltweit aktiv sind, ist die Qualität der Software entscheidend für den wirtschaftlichen Erfolg eines Produkts. Ich empfehle und verwende daher so genannte Coding Conventions  wie z.B. MISRA oder die Hungarian Notation.

Die neueste Methode zur Steigerung der Qualität der Software-Entwicklung wird Anforderungsmanagement genannt. Es gibt bereits zahlreiche Werkzeuge dafür. Eines dieser Programme zum Verwalten von Projekten heißt in-Step und ist sehr populär. Eigentlich ist das ganze für die IT-Technik gedacht und trifft daher nur zum Teil auf Geräte für die Prozessautomatisierung zu. Das Besondere an in-Step ist, dass man neben den Aktivitäten auch die Ergebnisse planen kann (so verspricht es zumindest der Hersteller). Was soll das denn? Ich plane sofort, dass ich am Wochenende im Lotto gewinne! Und wenn es schief geht? Gemeint ist wohl, dass man die Überprüfung von Ergebnissen planen kann und das ist wirklich neu und sicher auch hilfreich.

Schon immer gab es Probleme, die Software in eingebetteten Systemen im Projektablauf zu erfassen und die entwicklerischen Ergebnisse zu bewerten. Eigentlich sollte alles, was ein Produkt betrifft, von einem so genannten Pflichten- oder auch Lastenheft abgedeckt werden. Verschiedentlich gab und gibt es Ansätze, ein Software-Pflichtenheft zu erstellen. Das funktioniert aber nur, wenn man bereits weis, welche Funktionen mit Software und welche mit Hardware realisiert werden. Es gibt sicher Teilbereiche innerhalb eines Produkts, bei denen von Anfang an feststeht, dass es sich um reine Software handelt, die aber - wie bereits erwähnt - immer komplexer wird. Da kann man schon von einem Software-Pflichtenheft reden.

Man darf sich durch die Anwendung von Werkzeugen wie in-Step allerdings nicht täuschen lassen. Der Einsatz eines solchen Produkts garantiert noch keine Qualität; denn eines kann dieses Programm nicht, nämlich die inhaltliche Richtigkeit und Vollständigkeit der Anforderungen prüfen. Disziplin und gesunder Menschenverstand sind immer noch gefragt, damit es am Ende keine Überraschungen gibt wie zum Beispiel ein Handy, welches ich mal hatte und das zum Aufstarten eine geschlagene halbe Minute benötigte; das sind Produkte, die der Markt nicht braucht.

PC Simulation eines Embedded Systems

Eine weitere Methode, die Qualität von Software für Feldgeräte zu erhöhen, ist die Simulation in einer Visual Studio Umgebung (PC Simulation). Visual Studio hat einen Debugger zur Fehlersuche, der fast allen Emulatorsystemen haushoch überlegen ist. Ausserdem ist das Arbeiten in der PC Umgebung viel bequemer und geht besser von der Hand als in jedem anderen System. Wenn es in einem Embedded System zu einem nicht initialisierten Zeiger oder einem Zeiger mit dem Inhalt null kommt, kann dies eine fehlerhafte Reaktion zur Folge haben, muss aber nicht. Auf dem PC löst so etwas eine Ausnahmebehandlung aus, die sich sofort bemerkbar macht.

Eine PC Simulation Emuliert fast 90 % des Verhaltens eines Geräts. Selbst das Hart Protokoll lässt sich in Echtzeit darstellen. Daher kann die Entwicklung beginnen, bevor die Hardware überhaupt zur Verfügung steht. Damit muss die Software nicht auf die Hardware warten und ist aus diesem Grund zumindest nicht mehr zwingend der kritische Pfad des Projekts.

Ein weiterer wichtiger Aspekt ist das Testen. Eine PC Simulation verfügt über Software Schnittstellen, an denen sich Testautomaten andocken lassen. Da die Software in der PC Simulation sehr viel schneller abläuft als auf dem Zielsystem, lassen sich in der gleichen Zeit in der PC Simulation wesentlich mehr Tests durchführen.

Gerätebeschreibungssprache (Device Description Language, DDL)

VARIABLE range_limit_upper {   CLASS CORRECTION;   LABEL "UPPER RANGE LIMIT";   TYPE FLOAT   {     DISPLAY_FORMAT "3.2f";   }   CONSTANT_UNIT "Bar";   HANDLING READ; }

Im Jahre 1989 fand die erste Vorstellung eines vollständigen Feldbussystems auf der INTERKAMA statt. Diese Vorstellung wurde unternommen von Firmen, die Produkte für die Prozeßsteuerung anbieten. Neben Mess-/ und Stellgeräten wurden auch ein Handheld Terminal und ein SCADA System gezeigt, all dies war integriert in einem funktionsfähigen Prozeßmodell. Ich war damals der Projektleiter für Endress+Hauser. Da diese Aktion bei den Anwendern eine sehr positive Resonanz fand, wurde die International Fieldbus Group (IFG) gegründet. Aufgabe der IFG war es, Anforderungen und Spezifikationen zu dokumentieren, um diese als zusätzliche Beiträge der internationalen Feldbusnormung zukommen zu lassen. Innerhalb dieser Gruppe war ich einer der beiden Entwickler, die den Entwurf einer Gerätebeschreibungssprache (Device Description Language, DDL) vorangetrieben haben. Ende 1990 wurde in der IFG das erste Spezifikationsdokument verteilt. Später hat Rosemount Inc. diese Papiere um die Beschreibung der Kommandos im Hart Protokoll erweitert und die Gerätebeschreibung als Ergänzung der Hart Spezifikation übernommen.

Single Source Konzepte

Ein paar Jahre später wurde die inzwischen so genannte Electronic Device Description Language (EDDL) auch bei Profibus und Fieldbus Foundation eingeführt. Die DDs im Hart Protokoll, Profibus und FF dienen zwar dem gleichen Zweck, sind aber - wie zu erwarten - leicht unterschiedlich. Für jedes Kommunikationssystem wird daher eine andere Variante der Gerätebeschreibung benötigt. Da stellt sich natürlich die Frage, wie man hier die Kosten im Rahmen halten kann. Die Antwort ist ein Single Source Konzept. Die einfache Grundidee ist, alle Informationen über die Parameter eines Gerätes in einer Datenbank zu speichern. Diese Datenbank wird dann von Generatorprogrammen benutzt, die aus den Daten die jeweils benötigte DD und eventuell auch Quellkode für das Embedded System erzeugen.

Nach Oben