Theoretische Grundlagen

Mit iCon-L grafisch programmieren

zum Seitenanfang

Die grafische Programmierung hat sich in den letzten Jahren insbesondere bei der Anwendungsprogrammierung von technischen Systemen durchsetzen können. Hierfür gibt es viele Gründe. Zum einen werden in diesen Bereichen seit langer Zeit grafische Modelle zur Beschreibung der Funktionalität verwendet und zum anderen werden hier Ingenieure, Technologen und Techniker mit der Programmierung konfrontiert, die selten eine klassische IT Ausbildung besitzen. Außerdem ist es hier sehr wichtig, einen engeren Bezug zum physikalisch, technischen Anwendungsgebiet herzustellen.

Die Einsatzschwerpunkte für iCon-L liegen in den Bereichen Verkehrstechnik, Prüfstandautomatisierung, Medizintechnik, Laborautomatisierung, Gebäudetechnik und Datenmonitoring.

Was genau ist iCon-L?

zum Seitenanfang

Diese Frage ist gar nicht so einfach zu beantworten. Auf der einen Seite bieten wir unter dem Namen iCon-L ein grafisches Programmiersystem an, mit dem ausgewählte Mikrocontroller unmittelbar programmiert werden können. Auf der anderen Seite ist iCon-L ein Softwareframework, das wir als Basis für die Entwicklung von kundenspezifischen Programmierlösung nutzen. Dieses Softwareframework besteht aus einer Vielzahl von skalierbaren Modulen, aus denen wir dann das kundenspezifische Programmiersystem zusammenstellen und je nach Bedarf spezifische Anpassungen durchführen.

iCon-L wird derzeit als OEM Produkt von 7 Unternehmen unter eigenem Namen an Endkunden vertrieben und von weiteren 12 Unternehmen als Softwareengineering-Werkzeug für die Programmierung der eigenen Systemlösungen genutzt. Mehr als 1000 Lizenzen des Programmiersystems sind weltweit im Einsatz. Die Anzahl der mit iCon-L programmierten Geräte liegt weit über 20.000.

Blockdigramme zeichnen: Mit dem grafischen Programmiersystem iCon-L ist es möglich, kleine bis mittlere Mikrocontroller vollständig grafisch zu programmieren und zu konfigurieren. Die Programmierung erfolgt hierbei über einen grafischen Editor durch das Zeichnen von Blockdiagrammen.

Volle Kontrolle durch Online-Visualisierung: Neben der grafischen Programmierung unterstützt iCon-L die Online-Visualisierung der aktuellen Zustände im Programm auf grafischer Ebene. Weiterhin können die Dateninhalte der Signallinien durch einen einfachen Klick auf die Linie beobachtet werden. Hierdurch ist eine durchgängige Softwareentwicklung vom Entwurf bis zur Inbetriebnahme und Wartung der Software möglich.

iCon-L 5 Designer: Der Designer wird bei Zielsystemen mit Display zur Gestaltung der Bildschirminhalte genutzt. Aus einer Bibliothek konfigurierbarer grafischer Objekten werden Masken "gezeichnet".  Für die Programmierung der eigentlichen Funktionalität in der HMI, also die spezifische Reaktion auf Ereignisse, wie z.B. einen Tastendruck oder die Verbindung der grafischen Objekte mit den Prozessdaten wird weiterhin der Blockdiagrammeditor genutzt.

Erfahren Sie mehr über das grafische Programmieren in unserem Beitrag Rohstoff Software richtig nutzen...

Grundlagen der Bausteinprogrammierung

Funktionsbausteine
Abbildung 1: einfaches Anwenderprogramm

zum Seitenanfang

Ein Anwenderprogramm wird im sogenannten Continuous Function Chart (CFC) oder Signalflussplan programmiert. Was heißt das genau?

Durch das Zeichnen eines Blockdiagramms wird ein Programm erzeugt. Dabei werden auf einem Arbeitsblatt Funktionsbausteine (FB) platziert und die Ein- und Ausgänge der Funktionsbausteine miteinander verbunden. Nachdem man ein solches Netzwerk aus Funktionsbausteinen und Verbindungslinien fertig gezeichnet hat, wird eine maschinenlesbare Netzwerkbeschreibung in die Steuerung geladen.

Wie der Name „Continuous Function Chart“ schon andeutet, muss man sich ein Anwenderprogramm, das als Netzwerk aus Bausteinen und Verbindungslinien vorliegt, als kontinuierlich laufenden Prozess vorstellen. Genau wie in einer elektronischen Schaltung, in der logische Gatter wie z. B. UND und ODER ständig ausgeführt werden, werden alle gezeichneten Funktionsbausteine von der Steuerung ständig aufgerufen.

In dem abgebildeten Programm  dargestellt, werden die Bausteine IN1, IN2, AND und LED ständig von der Steuerung aufgerufen. Dabei lesen die Bausteine IN1 und IN2 kontinuierlich die aktuelle Spannung an den digitalen Eingangsklemmen 1 und 2 ein und konvertieren den Wert in ein logisches Signal (0 oder 1) für das Programm. Das Ergebnis dieser Konvertierung wird als logisches 1- oder 0-Signal auf den Ausgang geschrieben. Über die Verbindungslinie wird der Wert an den UND-Baustein weitergeleitet. Am UND-Baustein wird die logische Algebra der UND-Funktion ausgeführt und das Ergebnis der Algebra wird auf den Ausgang geschrieben (1 oder 0). Die Verbindungslinie transportiert den Wert zum LED-Baustein. Dort wird das logische Signal 1 oder 0 in das entsprechende Stromsignal umgewandelt und dementsprechend leuchtet die LED oder nicht.

Funktionsbausteine (FB)

Funktionsbausteine

zum Seitenanfang

Der Funktionsbaustein wird in der SPS-Welt auch häufig Funktionsblock genannt. In unserer Programmiersoftware ist der Funktionsbaustein das zentrale Programmiermittel und stellt die kleinste verwendbare Einheit eines Anwenderprogramms dar.

Funktionsbausteine (Funktionsblocks) können mehrere Ausgangsvariablen besitzen und für gleiche Eingangswerte durchaus unterschiedliche Ausgangswerte zulassen. Das ist möglich, weil sie auch interne Variablen besitzen, deren Werte über den Aufruf des Bausteins hinaus erhalten bleiben.

Funktionsbausteine sind parametrierbar, wobei Eingangs-, Ausgangs- und innere Variablen benutzt werden können. Funktionsbausteine werden in unseren Programmiersystemen immer von Programmbausteinen aufgerufen. Der Aufruf erfolgt durch ihre Instanzierung. Die Instanz ist vergleichbar mit einer Kopie des Bausteins für einen speziellen Anwendungsfall, wobei für jede Instanz der notwendige Speicherbereich zur Verfügung gestellt wird. Zwischen den Aufrufen des Bausteins werden die Daten gespeichert. Diese Tatsache wird landläufig als „Gedächtnis“ des FB beschrieben.

In der SPS-Welt unterscheidet man zwischen Funktion und Funktionsbaustein. Hierbei hat die Funktion, z.B eine einfache Addition, kein Gedächnis. Diese Unterscheidung gibt es hier nicht. Hier werden alle Bausteine als Funktionsbausteine bezeichnet.

Einen Katalog der verfügbaren Funktionsbausteine finden Sie unter: Funktionsbausteine

Continuous Function Chart (CFC)

Verbundene Funktionsbausteine

zum Seitenanfang

Auszug aus Wikipedia (DE): Continuous Function Chart

Der Continuous Function Chart (CFC), auch Signalflussplan, ist eine Programmiersprache für Speicherprogrammierbare Steuerungen (SPS). Obwohl sie keine der in der IEC 61131-3-Norm definierten Sprachen ist, stellt sie eine gängige Erweiterung von IEC-Programmierumgebungen dar.

Ihr Hauptanwendungsgebiet liegt vor allem in der Prozessleittechnik, weil sich die dort auftretenden, komplexen Steuerungs- und Regelungsaufgaben sehr gut in CFC abbilden lassen

CFC ist eine grafische Programmiersprache, in der Funktionsblöcke miteinander verschaltet werden, anstatt eine Abfolge von textuellen Befehlen einzugeben wie bei klassischen Programmiersprachen. Als Vorbild sind dabei Schaltpläne aus der Hardwareentwicklung zu sehen. Diese Darstellung eines Programms kommt Entwicklern von Steuerungssoftware entgegen, deren technischer Hintergrund typischerweise eher aus der Elektrotechnik stammt.

CFC kann als eine Erweiterung der Funktionsbaustein-Sprache betrachtet werden, in der keine strikte zeilenweise Abarbeitung von links oben nach rechts unten erzwungen wird, die Funktionsblöcke frei positionierbar sind und der Programmierer mehr Möglichkeiten zur Verknüpfung von Ein- und Ausgängen hat.

Die einzelnen Funktionsblöcke sind selbst in der Programmiersprache C verfasst und werden vom Hersteller der SPS als Standardbausteine mitgeliefert.

Hinweise und Tipps

Goldene Regeln für die methodische Softwarentwicklung mit grafischer Programmiersoftware

Verbundene Funktionsbausteine

Die Software wird so modelliert, das ein Maximum an selbst dokumentierenden Strukturen entsteht, wobei immer ein direkter Bezug zum konkreten Anwendungskontext hergestellt werden sollte.

Verwenden Sie so viele Informationen aus dem Pflichtenheft wie möglich. Wenn im Pflichtenheft Diagramme und Blockschaltbilder mit aussagekräftigen Symbolen verwendet werden, versuchen Sie diese Diagramme und die Symbole in der Programmiersoftware wiederzuverwenden.

Tipp: Anwendungsspezifische Symbole besitzen einen hohen impliziten Informationsgehalt. Nehmen Sie sich die Zeit, diese Symbole in der Programmiersoftware zu nutzen. Wenn Sie einige Jahre später die Software ändern müssen, werden Sie über jede Information dankbar sein, die Sie bekommen können.

Im vorliegenden HDA10-Projekt bot das Pflichtenheft ideale Voraussetzungen, um die goldene Regel anzuwenden. Die Diagramme geben den Kontext der Anwendung klar und deutlich wieder. Zudem unterstützen die Diagramme die Anwendung des TopDown-Entwurfsverfahrens.

Rohstoff Software richtig nutzen

Grafisches Programmieren mit Funktionsbausteinen

Die Entwicklung und Wartung technischer Systeme wird durch die Einbettung komplexer Mikroprozessoreinheiten einem Wandel unterzogen, der in dieser Größenordnung kaum Vorbilder hat. Dabei stoßen die klassischen Ingenieurdisziplinen Maschinenbau, Verfahrenstechnik und Elektrotechnik mit ihren gewachsenen Entwicklungsprozessmodellen und Qualitätsstandards auf die individualisierte Welt der Softwareentwicklung. Während in den klassischen Ingenieurwissenschaften darauf geachtet wird, dass Ideen, Verfahren, Konstruktionen oder Rezepturen genau dokumentiert und damit wieder verwendbar sind, gehen viele Unternehmen mit aufwändig entwickelten Softwarelösungen äußerst nachlässig um. Dabei ist schon lange bekannt, dass das Wertschöpfungspotenzial technischer Systeme durch die Effizienz bei der Softwareentwicklung bestimmt wird.

Obwohl viele Projekte an Softwareproblemen scheitern, wird der Wert guter Softwarelösungen allzu oft nicht erkannt und wegen Zeit- und Projektdruck nur unzureichend, spezifiziert dokumentiert und damit  kaum wiederverwendbar gestaltet.

Verbindung zwischen Software und Hardware

Während Verfahrenstechniker, Elektroingenieure und Maschinenbauer viele Jahre Zeit hatten, sich auf definierte Schnittstellen zu einigen, verdrängen nun Softwarelösungen in rasanter Geschwindigkeit gewachsene Entwicklungsprozesse. Dabei werden Softwareprojekte oft ohne grundlegende Prinzipien und methodische Verfahren realisiert. Insbesondere im sensiblen Bereich der Embedded-Systeme ist in so manchem Unternehmen die Entwicklung durch individuelle, trickreiche Soloprogrammierung geprägt. Der Grund hierfür liegt häufig nicht im fehlenden Problembewusstsein der Mitarbeiter, sondern im Fehlen geeigneter Werkzeuge. Während im Maschinen- und Anlagenbau die Hardwarelösungen aus katalogisierten, CAD-gestützten Standardbaugruppen zusammengestellt werden und nur für spezifische Teile Sonderentwicklungen stattfinden, kann es bei der Softwareentwicklung passieren, dass die selben Funktionen mehrfach programmiert werden, weil eine sinnvolle Katalogisierung und Präsentation der entwickelten Softwarefunktionen fehlt. Flexibilität und Individualität sind zwar die Gründe für das erfolgreiche Eindringen von Software in fast alle technischen Bereiche, sie stellen aber zugleich auch eine enorme Herausforderung für die Beherrschung der Systeme dar. Nie zuvor ist eine Technologie so umfassend und tiefgreifend in Wechselbeziehung zu anderen technologischen Disziplinen getreten.

Technische Software als wertvolles Gut zu verstehen und entsprechend verantwortungsvoll zu entwickeln und zu dokumentieren, wird eines der wichtigsten Wettbewerbskriterien der Zukunft sein.

ProSign Logo

Die Firma ProSign hat es sich zur Aufgabe gemacht, für die Entwicklung von Embedded Softwarelösungen Werkzeuge bereitzustellen, mit denen grundlegende Verfahren für eine methodische Softwareentwicklung praxisorientiert umgesetzt werden können. Das Verhalten technischer Prozesse wird seit Jahren mittels grafischer Methoden modelliert. Insbesondere bei der Systemanalyse und in der Designphase können grafische Verfahren ein besseres Verständnis über die Struktur eines Prozesses vermitteln. Daher existiert gerade für Analyse und Design eine Vielzahl von Werkzeugen. An die Programmierung und Wartung von Embedded-Systemen werden jedoch höhere Anforderungen gestellt.

Nur wenn durchgängige und einfach anwendbare Werkzeugketten existieren, die eine Entwicklung von der Analyse über das Design bis hin zur Implementierung, Inbetriebnahme und Wartung unterstützen, werden methodische Verfahren für das Software-Engineering genutzt.

Softwareprojekte für Embedded Systeme stehen zunehmend unter extremem Zeitdruck. Weil es bei vielen heutigen Software-Engineering-Prozessen zu einem tiefen Bruch zwischen Design und Implementierung kommt, die Entwicklung aber immer ein iterativer Prozess zwischen den einzelnen Phasen ist, werden methodische Verfahren nur rudimentär umgesetzt. Mit dem grafischen Programmiersystem wird eine Systemlösung bereitgestellt, die eine durchgängige Plattform für alle Phasen der Softwareentwicklung bietet. Mit der Programmiersoftware wird die Anwendungssoftware grafisch über das Verschalten fertiger Funktionsbausteine erzeugt. Ähnlich wie in der CAD-gestützten Konstruktion liegen die Funktionsbausteine als katalogisierte, dokumentierte und getestete Bauelemente vor. Erst wenn ein Bauelement (Funktionsbaustein) nicht vorhanden ist, wird ein neuer Baustein entwickelt und sorgfältig getestet, dokumentiert und katalogisiert. Durch die einfache Bausteinprogrammierung bleibt die Flexibilität und die Individualität von Softwarelösungen erhalten, gleichzeitig wird der Weg für eine arbeitsteilige, ingenieurmäßige Entwicklung, Anwendung und Wartung von Software-Systemen geebnet.