iCon-L

iCon-L
Blockdiagrammeditor in iCon-L 5
grafisches Programmiersystem
Basisdaten
Paradigmen: deklarativ
Erscheinungsjahr: 1994
Entwickler: ProSign GmbH
Aktuelle Version: 7.0  (11.12.2018)
Typisierung: stark
Wichtige Implementierungen: PIC18F, 8051, C166/C167, ARM, Cortex, x186, x86, PowerPC
Dialekte: Datenfluss / Ablaufketten / Funktionsbausteinsprache / Programmablaufplan / Domänenspezifische Sprachen
Beeinflusst von: Blockdiagramm
Betriebssystem: Windows 2000, Windows XP, Windows Vista, Windows 7
Lizenz: proprietär
www.pro-sign.de

iCon-L ist ein grafisches Programmiersystem, das vorwiegend für die Programmierung von Mikrocontrollern in eingebetteten Systemen verwendet wird.

Einführung

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.

Ziele

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.

Programmiersystem für Ingenieure und Techniker

Das zentrale Ziel von iCon-L ist die Bereitstellung eines Programmiersystems, mit dem Ingenieure und Techniker in einer Beschreibungssprache programmieren können, die ihrer gewohnten Sicht auf technisch, physikalische Systeme entspricht. Mit iCon-L sollen Fachleute unterschiedlicher technologischer Gebiete unmittelbar an die Programmierung herangeführt werden.

Kommunikation in interdisziplinären Teams

Eingebettete Systeme sind naturgemäß sehr stark in technologische Prozesse bzw. in einen technischen Kontext eingebunden. Um die Software für eingebettete Systeme zu entwickeln, ist es erforderlich, die mechanischen, physikalischen, biologischen oder chemischen Prozesse genau zu kennen. In der Ingenieurdisziplin besteht die Schwierigkeit darin, in einer großen Anzahl von Bereichen das erforderliche Know-how aufzubauen. Eingebettete Systeme werden daher in Teams aus Spezialisten entwickelt, wobei die Kommunikation zwischen den Team-Mitgliedern an Bedeutung gewinnt. iCon-L bietet mit dem Anzsatz der Modellierung in domänenspezifischen Sprachen die Grundlage für die Kommunikation in interdisziplinären Teams.

Modellgetriebene (modellbasierte) Softwareentwicklung für Eingebettete Systeme

iCon-L bietet einen Ansatz, die modellgetriebene Softwareentwicklung auch für sehr kleine Controller in eingebetteten Systemen verfügbar zu machen. So ist iCon-L bereits für Systeme verfügbar die lediglich über 4kByte RAM und 32 kByte Programmspeicher verfügen. Im Gegensatz zu vielen anderen modellbasierten Programmiersystemen wird in iCon-L aber kein C-Code generiert. In iCon-L wird die Modellsicht nie verlassen, es werden alle Entwicklungsphasen in grafischer Form umgesetzt.

Domänenspezifische Sprachen

iCon-L ist von seiner gesamten Konzeption so ausgelegt, dass es als Fundament für die Entwicklung von domänenspezifischen Sprachen genutzt werden kann. In iCon-L wird sehr bewusst auf standardisierte Bausteine verzichtet. Die Bausteine werden weitgehend an die Anforderungen der spezifischen Anwendung orientiert. Über eine universelle Makrobaustein-Technik kann sehr schnell eine eigene domänenspezifische Semantik der Bausteine erstellt werden. (siehe Abbildung : Kontextdiagramm)

Entwicklung neuer Architekturmuster

Auf Grund der Offenheit von iCon-L und der damit verbundenen Möglichkeit zur Spezifikation eigener Sprachmittel, wird iCon-L auch für die Entwicklung neuer Architekturmuster wie z. B. der Data Page Architectur (DPA) genutzt.

Technisches Konzept

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.

Zielsysteme

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

16 Bit

32 Bit

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

Verbreitung im Markt

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])

Geschichte

Versionen
iCon-L IDE (Editor, Linker, Kommunikationsserver, Treiber)
Datum Name Version
11.12.2018 iCon-L V7.0.0.0
16.02.2015 iCon-L V6.2.0.0
11.10.2013 iCon-L V6.0.0.0
16.05.2012 iCon-L V5.0.0.0
21.12.2010 iCon-L V4.5.0.0
16.03.2009 iCon-L V4.3.2.0
14.01.2009 iCon-L V4.3.1.0
25.02.2008 iCon-L V4.3.0.0
12.03.2007 iCon-L V4.2.3.0
25.04.2006 iCon-L V4.2.2.0
27.01.2006 iCon-L V4.2.1.0
16.03.2005 iCon-L V4.2.0.0
18.11.2004 iCon-L V4.1.4.1
05.05.2004 iCon-L V4.1.4.0
01.04.2004 iCon-L V4.1.3.0
20.11.2003 iCon-L V4.1.2.2
26.06.2003 iCon-L V4.1.0.0
09.04.2002 iCon-L V4.0.0.7
05.10.2001 iCon-L V4.0.0.2
22.06.2001 iCon-L V3.0.0.4
15.03.2000 iCon-L V3.0
28.07.1999 iCon-L V2.61E
12.03.1999 iCon-L V2.61
28.01.1999 iCon-L V2.60
18.11.1998 iCon-L V2.54
01.07.1998 iCon-L V2.51 - 16/32 Bit
08.08.1997 iCon-L V2.50 - 16/32 Bit
1996 iCon-L V2.40
1996 iCon-L V2.30
1995 iCon-L V2.20
1994 iCon-L V2.10
1993 OFS V1.00
1988–1992 PROSIGN

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.

Siehe auch

Literatur

  • 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)

Weblinks

Einzelnachweise

  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.
Quelle: https://de.wikipedia.org/wiki/ICon-L