|
|
Software Entwicklung
und Beratung
für Feldgeräte in der Prozessautomatisierung
Individuelle Software, Anforderungs-Management, Projektleitung, Automatisierung
Das HART Protokoll, PROFIBUS und MODBUS sind Industriestandards für die Entwicklung intelligenter Feldgeräte mit Feldbus-Kommunikation für die Prozess-Steuerung (industrielle Verfahrenstechnik) und Fabrikautomatisierung. Auch die Technik der Gerätebeschreibungssprache (Device Description Language, DDL), die ähnlichen Zwecken wie HTML dient, ist mittlerweile ein internationaler Standard. Das Ingenieurbüro Borst Automation bietet Dienstleistungen und Werkzeuge zur Software Entwicklung für Feldgeräte (Embedded Systeme) an, die mit Feldbus Kommunikation ausgerüstet sind.
In der Vergangenheit haben wir ein Active X Control mit dem Namen HartX 3.0 angeboten, welches das Hart-Protokoll in der Version 5 unterstützt. Da Hart heute bereits in Version 7 implementiert wird, entwickeln wir diese Software nicht mehr weiter. Als Beispiel dafür, wie eine solche Komponente arbeitet, bieten daher diese Software in der Vollversion Gratis an. Bitte senden Sie eine Email an Borst Automation(info@hart-profibus.com), falls Sie Interesse haben.
Die neuen Werkzeuge (Host Software) für Hart sind jetzt verfügbar. Sie basieren alle auf einer Windows DLL für HART. Dazu kann ein Monitor namens FrameAlyst eingesetzt werden. Wer den Umgang mit Hart ganz bequem haben möchte, verwendet die HartX.NET Komponente, die auf dem neuen Microsoft .NET Framework 2.0 basiert. Diese neuen Programme unterstützen Hart 5 bis Hart 7. Sie gestatten die Kommunikation über Com Ports 1..254. Selbstverständlich werden auch alle USB Lösungen und HART über INTERNET ermöglicht.
Für die DLL bieten wir bereits eine kostenlose Schnupperversion an. Derzeit gibt es auch ein Beispiel zur Anbindung an C#. Weitere Beispiele werden mit der Zeit folgen.
Für Studenten und junge Ingenieure, die an der Programmierung von Hart Software auf dem PC interessiert sind, bieten wir ein einfaches Beispiel für Visual Studio 6.0 an. Das Beispiel arbeitet ohne andere Programme, die man kaufen müsste.
Borst Automation auf einen Blick
Neue Design Ideen, Embedded Software Plattformen, Geräte Simulation in Echtzeit, Entwicklung von Kommunikationssystemen und Komponenten orientierte Implementierungen.
|
|
Kontakt: weehborst@aol.com oder info@walter-borst.de
Die Geschichte des Ingenieurbüros
Der Start von Feldbus, Profibus & Co.
 |
Die Einführung des Mikroprozessors zu Beginn der 1980er Jahre änderte die Möglichkeiten der Ingenieure, die Feldgeräte für die Prozess-Steuerung (Industrielle Verfahrenstechnik) und die Fabrikautomatisierung entwickelten, von Grund auf. Mikrocontroller - wie die Familie des 8031 - hatten damals schon mindestens eine serielle Schnittstelle 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, die wir Ihnen zur Verfügung stellen, erhalten Sie 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 Prozess-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. Sie können sich eine kostenlose Demoversion
gerne
hier herunterladen. |
 |
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, was denn der Vorteil ist. In einer ANSI C Umgebung dagegen lässt es sich gar nicht einsetzen. Daher haben wir einen neuen Treiber in Form einer 'einfachen' Windows Dll entwickelt, der das Hart Protokoll bis Version 6 unterstützt. Eine kostenlose Versuchsversion können Sie hier bekommen. Eine neue Version des HartX für das Hart Protokoll Revision 6 ist für einen späteren Zeitpunkt geplant. Das jetzige HartX lässt sich aber auch zusammen mit Geräten einsetzten, die die Hart Kommunikation in der Revision 6 unterstützen, da es dafür verträglich ist, indem es die Daten der Kommandos nur auf minimale Länge prüft und nicht auf eine maximale. |
Software für Embedded Systeme
Inzwischen wurde auch einiges an Kommunikationssoftware für Embedded Systeme bei Borst Automation entwickelt. Eines dieser Pakete war ein Slave für das Hart Protokoll in der Revision 5. Da für die Hart Kommunikation mittlerweile die Version 6 aktuell ist, geben wir den Quellkode für die Version 5 gratis ab. Immerhin kann diese Version genutzt werden, um in die Technik der Hart Kommunikation einzusteigen.
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.
Weil die Unternehmen, die Produkte für die industrielle Verfahrenstechnik und Fabrikautomatisierung anbieten, weltweit aktiv sind, ist die Qualität der Software immer mehr entscheidend für den wirtschaftlichen Erfolg eines Produkts. Borst Automation empfiehlt und verwendet daher so genannte Coding Conventions wie z.B. MISRA oder die Hungarian Notation. Mit Priorität passen wir uns aber den Anforderungen der Kunden an.
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 Prozess-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 Prozessmodell. 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. Heute bietet Borst Automation die Erstellung von DDs für das Hart Protokoll und Profibus an. |
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 Device Description 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. Borst Automation bietet die Mitarbeit bei der Entwicklung solcher Single Source Systeme an. Ein kleines Beispiel für eine Datenbank wird zusammen mit unserer kostenlosen C Quellkode für den Hart Slave mitgeliefert. Diese Datei wurde zum Beispiel von einem Generator erzeugt: HrtSrvIn.c. |
Es würde mich freuen, wenn Sie sich bei uns melden! Ihre Fragen beantworten wir jederzeit sehr gerne.
Walter Borst
Zur Zeit steht Ihnen mit Ausnahme der AGBs und eines Profils der Rest unserer Website nur in englischer Sprache zur Verfügung.
Falls Sie meine private Homepage interessiert, klicken Sie bitte hier.
Borst Automation
Walter Borst
Im Wingert 4
65626 Fachingen
Tel.: 06432 989176
Fax: 06432 989129
Email:
weehborst@aol.com oder
info@hart-profibus.com
Home:
http://www.hart-profibus.com
Zuletzt aktualisiert: 13.5.2008