iCon-L

Die Programmierung der Anwendungssoftware erfolgt dabei nicht mit Hilfe einer textuellen Programmiersprache, sondern über einen grafischen Editor durch das Zeichnen von Blockdiagrammen. Der wichtigste Grund für die Verwendung von Blockdiagrammen liegt darin, dass Blockdiagramme schon lange vor der Verbreitung von Computern für die Beschreibung bzw. Modellierung von technischen Systemen genutzt wurden. Hierdurch können die Programme auch von Spezialisten erstellt werden, die nicht aus der IT-Welt kommen. Des Weiteren wird für eingebettete Systeme häufig eine Anwendungssoftware benötigt, die technisch/physikalische Prozesse beschreiben soll. Diese oftmals kontinuierliche Prozesse, wie z. B. Regelungsalgorithmen oder Signalaufbereitung, können mit Blockdiagrammen ähnlich der Continuous Function Charts (CFC) optimal dargestellt werden.

Neben den praktischen Gründen für die Anwendung von Blockdiagrammen gibt es weitere Gründe, die sich aus der Softwaretechnik ableiten. Die Anwendung fundamentaler Prinzipien der Softwareentwicklung können hierdurch auch von Mitarbeitern und Auftraggebern nachvollzogen werden, die nicht unmittelbar in die Software-Entwicklung einbezogen waren. Dies ist insbesondere für das Review, die Abnahme oder auch die Zertifizierung von Software wichtig.

In iCon-L können Blöcke (Funktionsbausteine) sehr ausdrucksstarke Symbole besitzen und den Zustand bzw. die Werte des Blocks online visualisieren, falls eine Echtzeitkopplung zum Zielsystem existiert. Hiermit soll die Semantik für die Erstellung und Inbetriebnahme des Anwenderprogramm auf den konkreten Anwendungsbereich (siehe auch: Domänenspezifische Sprache) zugeschnitten werden. Der Vorteil von anwendungsspezifischen Symbolen liegt in dem sehr hohen Maß an impliziter Information. Wird ein Baustein als Ventil symbolisiert und mit anderen Bausteinen verbunden, weiß der Fachmann, was sich hinter diesem Baustein verbirgt und in welcher Beziehung er zur Umwelt steht.

Durch die Verwendung von fachspezifischen Beschreibungen bzw. Modellen können die Informationen aus der Anforderungsspezifikation unmittelbar in die Programmierumgebung übernommen werden. Das Anforderungsmodell selbst wird zur treibenden Kraft in der Programmierung. Die Anforderungsspezifikation ist hierdurch immer aktuell. Die Wartung und Inbetriebnahme von Software wird durch diese Methode spürbar erleichtert.

iCon-L ist im engeren Sinne kein geschlossenes Programmiersystem, sondern ein Framework bzw. Software-Technologiepaket für die Entwicklung geräte- und anwendungsspezifischer Konfigurations- und Programmierlösungen. Das Framework besitzt zunächst noch keinen Bezug zu einer konkreten Hardware oder einer konkreten Anwendung (Ausprägung). Dieser Bezug wird erst durch die system- bzw. anwendungsspezifische Konfiguration bzw. Entwicklung von PlugIns und Bibliotheken hergestellt. Fast alle PlugIns, Bausteinbibliotheken und IDE-Einstellungen sind projektbezogene Konfigurationen. Somit passt sich der Framework nur durch das Laden eines Projektes und der darin eingebetteten Bibliotheken automatisch auf die Bedingungen für unterschiedlichste Hardwaresysteme und Anwendungen an.

Beispiel für ein Kontextdiagramm in iCon-L 4.5

Beispiel für die Online-Inbtriebnahme mit iCon-L 5

Umsetzung der Data Page Architectur in iCon-L

In iCon-L werden vorwiegend deklarative Programmiersprachen realisiert. Ein wesentliches Ziel von iCon-L ist die Verbesserung der Softwarequalität durch die Verwendung anerkannter Methoden und Prinzipien für das Softwareengineering. Zugleich sollen mit iCon-L Vorgehensmodelle zur Softwareentwicklung wie z. B. das V-Modell praxisorientiert umgesetzt werden.

Die technische Umsetzung von iCon-L basiert auf zwei grundlegenden Prinzipien.

• Die Anwendungsprogrammierung ist streng von der Systemprogrammierung (Firmwareprogrammierung) getrennt.
• Der grafische Editor für die Anwendungsprogrammierung besitzt keine feste Bindung an bestimmte Funktionsbausteine (Blöcke). Alle Funktionsbausteine werden erst während der Laufzeit durch das Laden eines Projektes in den Editor eingebunden.

Funktionsbausteine sind in iCon-L die kleinste Softwareeinheit. Die Zielfunktion, welche der Mikrocontroller ausführen soll, wird in C oder C++ geschrieben. Die Programmierung der Funktionsbausteine wird in iCon-L der Systemprogrammierung zugerechnet und sollte von Mitarbeitern durchgeführt werden, die entsprechende Erfahrungen in der Systemprogrammierung mit C und C++ besitzen. Für jeden Funktionsbausteintyp wird eine C-Funktion implementiert und zusammen mit dem iCon-L-Laufzeitumgebung für den entsprechenden Mikrocontroller kompiliert und gelinkt. Der Systemprogrammierer benutzt für das Erzeugen der Laufzeitumgebung + alle anwendbaren Funktionsbausteintypen die C/C++ – Entwicklungsumgebung für den jeweiligen Mikrocontroller. Für die Fehlersuche im System stehen weiterhin alle Funktionalitäten der Werkzeugkette für die Programmierung des Controllers zur Verfügung. Die Laufzeitumgebung inklusive aller Funktionsbausteintypen wird in kompilierter Maschinensprache als Firmware auf den Mikrocontroller übertragen.[1]

Mit der Anwendungsprogrammierung wird in der Regel erst begonnen, wenn der erforderliche Funktionsbausteinvorrat fertig entwickelt, vollständig getestet und dokumentiert ist. Für Testzwecke können aber auch Funktionsbausteine eingebunden werden, die lediglich bezüglich der verfügbaren Ein- und Ausgänge spezifiziert worden sind.

Für die Anwendungsprogrammierung werden nun die in der Firmware vorliegenden, Funktionsbausteintypen zu einer Anwendersoftware verknüpft. Obwohl in der Firmware der Funktionsbausteintyp nur ein Mal als Funktion hinterlegt ist, kann der Anwendungsprogrammierer beliebig viele Bausteine bzw. Baustein-Instanzen nutzen. Die IDE erzeugt automatisch die entsprechenden Datenstrukturen für die Instanzierung der Bausteine. Im Anwenderprogramm können Funktionsbausteine auf grafischer Ebene zu neuen, komplexeren Bausteinen (Makro-Bausteine) verknüpft werden. Die hierbei entstehenden (Makro-)Bausteine können wiederum wie Funktionsbausteine in anderen Projekten genutzt werden.

Für die Abarbeitung der Anwendersoftware im Mikrocontroller wird ein sehr einfaches Konzept der verketteten Liste genutzt. Ein sogenannter Dispatcher (siehe auch Lit.) arbeitet hintereinander die Liste ab und ruft hierbei die entsprechenden C-Funktionen mit den instanzierten Datenstrukturen für Eingänge, Ausgänge, Parameter und interne Speicherelemente auf. Da in der Programmiersprache C ein Zeiger sehr einfach in einen Funktionsaufruf umgewandelt werden kann und die C Funktion bereits vollständig im Maschinensprache übersetzt vorliegt, ist die Abarbeitung des Anwenderprogramms nur geringfügig langsamer als einen übersetztes C-Programm. Im Vergleich zu einem Programm mit sehr vielen Aufrufschichten kann die Anwendungssoftware sogar schneller abgearbeitet werden.

Da der Mikrocontroller nur sehr wenig zusätzliche Arbeit für das Abarbeiten des Anwenderprogramms leisten soll, erzeugt die IDE eine Verkettungsliste, die bereits die realen Speicherbedingungen im Zielsystem abbildet. Um dies zu realisieren, fordert die IDE den Mikrocontroller auf, eine genaue Gerätebeschreibungsdatei zu senden. In dieser Datei steht die Aufteilung des Speichers, welche Funktionensbausteintypen der Laufzeitkern kennt und vor allen Dingen um was für einen Controller es sich handelt, 8,16 oder 32 Bit und in welcher Byte-Reihenfolge der Speicher organisiert ist. Aus diesen Informationen kann die IDE sehr einfach eine Verkettungsliste erzeugen, die genau auf die Anforderungen des Controllers zugeschnitten ist.

Mini-SPS auf PIC18F Basis der Firma Barth Elektronik

Eine Besonderheit von iCon-L ist es, dass es als grafisches Programmiersystem für sehr kleine Mikrocontroller eingesetzt werden kann. So ist der Laufzeitkern bereits auf Systemen einsetzbar, die über 4 KByte RAM und 32 KByte Flash-Speicher verfügen:

Auf folgende Mikrocontroller wurde der iCon-L Laufzeitkern erfolgreich portiert:[2]

8 Bit

• 8051
• PIC18F von der Firma Microchip Technology

16 Bit

• x186/IPC@CHIP von der BECK
• C166/167 von Infineon

32 Bit

• Arm7/9 von NXP, Atmel, Analog Devices, STMicroelectronics
• PowerPC, Coldfire von freescale
• x86-Prozessoren von Intel, AMD
• Atom von Intel

Ohne direkten Bezug auf einen konkreten Prozessor existieren der iCon-L-Laufzeitkern auch für unterschiedliche Betriebssysteme:

• µLinux
• Linux mit RTAI-Echtzeiterweiterung
• Windows CE
• QNX
• RT-Kernel32

Anwendung von iCon-L in der Medizintechnik
Automatisierung eines Hemodialyser Analyser
IBP Medical GmbH

iCon-L wird von vielen Unternehmen der Industrie als Inhaus-Engineering-Lösung eingesetzt. Weiterhin setzen eine Reihe von Unternehmen iCon-L als OEM Werkzeug unter eigenem Namen mit den eigenen Steuerungslösungen ein.

Die Haupteinsatzgebiete sind:

• Verkehrstechnik
• Prüfstandsautomatisierung
• Gebäudeautomation
• Medizintechnik
• Forschung und Ausbildung
• Laborautomatisierung

iCon-L ist aus dem Produkt Prosign 1988–1992 hervorgegangen, aktuelle Version ist zurzeit (Stand Januar 2014) iCon-L 6.0.

Folgende Produkte basieren auf dem Softwareframework iCon-L:

• test.con: Gantner Instruments Prüfstandsautomation, Monitoring
• GDS: GRAF-SYTECO HMI-Programmierung
• DACHSview : Steinhoff Echtzeitapplikationen
• IPOCS: SysMik Gebäudeautomation
• SprintProsi: Ing. Büro Linsenbarth Anlagensimulation
• Lucky Logic
• miCon-L: Barth Elektronik GmbH Mini-SPS in der Fahrzeug- und Maschinenbauindustrie
• PACstudio: ProSign GmbH Programmierwerkzeug für PACcubes-Geräte

Neben den Anwendern der oben genannten Programmierwerkzeuge wird iCon-L weiterhin als Inhaus-Programmierwerkzeug von folgenden Unternehmen eingesetzt:

• Kiepe Electric (Verkehrstechnik)
• messMa (Verkehrstechnik; VT 1.0/1.5-ETCS)
• Eckert & Ziegler AG (Medizintechnik)
• IBP Medical (Medizintechnik)
• Otto-von-Guericke-Universität Magdeburg (Energietechnik)
• Martin-Luther-Universität Halle (Forschung[3])
• Fachhochschule Köln (Verkehrstechnik, Regelungstechnik)
• NSD-Fusion (Forschungsprojekt CERN[4])

Die Wurzeln von iCon-L liegen bereits sehr weit zurück. So wurde eine interpretergesteuerte Verkettung von Funktionsbausteinen (Modulverbindungsliste) bereits vor 1985 in unterschiedlichen Mikroprozessorsteuerungen der DDR verwendet.

• EAW Compact S2000 vom VEB Elektro-Apparate-Werke Berlin-Treptow, Sprache PROMAR 5000
• Mikroprozessorregler RBS 05 vom VEB Wetron-Weida, Sprache MARCO
• ursamar 5000/5001 vom VEB Werton-Weida, Sprache MARCO

Die Realisierung der Module und des Laufzeitkerns erfolgen hier noch vollständig in Assembler.

Seit 1992 wurde für die Programmierung des Laufzeitsystems erstmals C als Systemprogrammiersprache genutzt. Bei den ersten Geräten wurden die Anwenderprogramme allerdings noch textuell programmiert (Hardware Z80, MC68332). Anfangs wurde die Modulverbindungsliste in ASCII mit einem normalen Texteditor erstellt.

Für den grafischen Editor liegen die Wurzeln ebenfalls schon in den 1980er Jahren. Bereits 1988 wurde das grafischen Simulationssystems PROSIGN vorgestellt.[5] Dieser Editor lief allerdings nur auf einer Unix-Workstation. 1993 wurde damit begonnen, den Editor und die weiteren IDE-Module auf Windows zu portieren.

Anfang 1994 wurde mit der MR92 von ABB das erste Steuerungssystem vollständig grafisch programmiert.

• Strukturierte Analyse
• eingebettetes System
• Anlagensimulation

• Andreas Wandenälis: Programmiersystem macht aus Sensoren Edge-Controller. In: ets elektronik & automation. 11-2018, S. 28.
• U. Witfer: GRAF-SYTECO: Softwareentwicklung für Bediengeräte – es kann so einfach sein. In: Elektronik Informationen. 04-2009, S. 62.
• St. Mertens: Kaffeemaschine systematisch programmieren. (PDF; 1,8 MB) (= Firmenschrift ProSign. 2008).
• St. Mertens: Systembaukasten für Kleinststeuerungen mit modellbasierter grafischer Programmierung. (PDF; 1,1 MB). In: SPS-Magazin. 3/2006.
• ProSign GmbH Rohstoff Software richtig nutzen. (PDF; 59 kB). In: Mitteldeutsche Mitteilungen. 3/2005, S. 9.
• R. Kehrer: Intelligente Lösungen für autarke Anwendungen in der Prüftechnik. In: MessTec & Automation. 09/2004, S. 78–79, GIT VERLAG.
• T Wust: Podiumsvortrag Messe IPC/SPS/Drives 2002.
• W. Günther: Entwicklung einer offenen Fachsprache für ein freiprogrammierbares Steuer- und Regelgerät auf Mikroprozessorbasis. Dissertation. Universität Magdeburg, 1988.
• W. Günther, B. Mattner: iCon-L für die Hardware-in-the-Loop-Simulation. A&D-Kompendium, 2001.
• W. Günther, St. Mertens: iCon-L – Einsatz bei Soft-SPS, bei Meß-, Steuer- und Regelgeräten und in der Anlagensimulation. A&D Kompendium 1999
• W. Günther: Komponentenbasierte Anlagenmodellierung mit iCon-L. Tagungsband zum Kongress SPS/IPC/DRIVES’98 Hüthig 1998, S. 714–715.
• St. Enderle, W. Guenther, H-J. Hilscher, H. Kenn, xROB-S and iCon-X: Flexible Hardware, Visual Programming and Software Component Reuse. In RoboCup 2008: Robot Soccer World Cup XII pp 485-494. Springer, Berlin, Heidelberg 2009. Print ISBN 978-3-642-02920-2 Online ISBN 978-3-642-02921-9 (https://link.springer.com/chapter/10.1007%2F978-3-642-02921-9_42)

• Dokumentationsseite von iCon-L
• Offizielle Website der ProSign GmbH
• Eigenständiges Wiki zu iCon-L
• Dokumentationsseite von test.con[6]
• Dokumentationsseite von miCon-L
• Dokumentationsseite PACcubes

1. iCon-L Framework Laufzeitumgebung@1@2Vorlage:Toter Link/www.pro-sign.de (Seite nicht mehr abrufbar, festgestellt im April 2018. Suche in Webarchiven)
2. Firmenschrift ProSign Serie 1-F7 Messe IPC/SPS/DRIVES Nürnberg 2010.
3. Forschungsprojekt UNI Halle
4. Forschungsbericht CERN
5. 5. Symposium Simulationstechnik, Aachen, 28.–30. September 1988.
6. test.con Home - test.con. Abgerufen am 11. Dezember 2018.