Funktionsblock-Grafische Programmierung

Funktionsblock-Grafische Programmierung

Inhalt


Topic:.fblock.

Als Grafische Programmierung wird die Formulierung von Computerprogrammen wesentlich mit grafischen Mitteln verstanden. Dabei sind selbstverständlich textuelle Angaben für Indentifier (Namen), Operation-Angaben oder Anweisungsblöcke in der Ziel-Programmiersprache oder einer anderen passenden (Meta-)-Sprache dabei. Wesentlich ist, dass der Überblick über die Anwendungs-Programmierung grafisch erfolgt. Damit wird ein großes Problem der ausschließlich textuellen Programmierung gelöst: Der Überblick.

Dieser Artikel stellt grundsätzliche Dinge dar. Daraus werden Schlussfolgerungen abgeleitet, die entweder Diskussionsinputs für die Zukunft sein sollen oder aufbauend auf vorhandenen grafischen Tools diese anwenden und erweitern. Da dem Autor eine mehrjährige Erfahrungspraxis beim Tool Simulink (Mathworks) vorliegt, sind die konkreten Anwendungen und Erweiterungen darauf bezogen.

Im speziellen wird versucht, die textuelle und grafische Herangehensweise der Programmierung zu vereinen, indem auch mit Simulink aus der grafischen Ansicht eine textuelle FunktionsBlockConnection-Sprache (FBCL) erstellt wird, die auch ein Roundtrip in das Simulink-Modell ermöglicht. An dieses FBCL ist dann auch eine Codegenerierung für Zielsystemcodes angedockt. Das damit verfolgte Ziel ist die Kompatibilität verschiedener grafischer Programmiertools. Diese Arbeiten sind allerdings im Entwicklungsstadium.

Ein weiteres Thema widmet sich dem Einbringen der Objektorientierung in die grafische Funktionsblock-orientierte Programmierung.

Die grafische Programmierung hat zweifellos Vorteile. Es ist nicht einfach, in vielen Programmzeilen und Aufrufschachtelungen die Struktur zu erkennen. Grafisch ist der Überblick besser weil zweidimensional gearbeitet wird, und es ist die Erkennbarkeit besser, weil sich Programmzeilen, außer durch geschickte Kommentierungen, zu sehr gleichen. In der Grafik ist die Struktur als solche erkennbar und kann mit Bildchen (image) noch aufgebessert werden.

Daher ist es nicht sehr folgerichtig, dass die grafische Programmierung bisher immer noch eine untergeordnete Bedeutung hat und es keine standardisierte Vorgehensweise gibt.

Achtung Verwechslunggefahr: Programmierung grafischer Oberflächen - dies ist ein anderes Thema, nicht hier behandelt. Häufig wird hierfür das Schlagwort visuell verwendet, es meint die Möglichkeit der Programmierung grafischer Benutzeroberfächen, und/oder die marginale Unterstützung der IDE mit Grafik.


1 Überblick über Tools und Herangehensweisen der Grafische Programmierung

Topic:.fblock..

Grafische Programmierung nach Wikipedia

Zitat Wikipedia: https://de.wikipedia.org/wiki/Visuelle_Programmiersprache

Als Visuelle Programmiersprache (englisch visual programming language, VPL) bezeichnet man eine Programmiersprache, in der ein Programm, Algorithmus oder Systemverhalten durch grafische Elemente und deren Anordnung definiert wird.

In dem Wikipedia-Artikel wird darauf hingewiesen, dass einige Programmierumgebungen das Attribut visuell verwenden, eher aus Marketinggründen. Zitat Das Schlagwort "visuell" haftet heute aus marketingtechnischen Gründen auch Systemen an, die wenig visuelle Sprachelemente benutzen. Visual Basic Classic, Xcode und Visual C++ ... Entgegen den Ausführungen im Wikipedia-Artikel möchte der Verfasser anmerken, dass das Schlagwort visuell wohl eher auf die Möglichkeit der Programmierung grafischer Benutzeroberflächen hindeutet - ein seit Entstehen von Visual Studio und MS-Windows in den 90-ger Jahren wesentliche Entwicklung.


1.1 UML

Topic:.fblock...


Bild: UML-ObjectModelDiagram

Die modellorientierte oder modellgetriebene Programmierung ist ein Schlagwort, das vorderhand aus der UML (Unified Modelling Language kommt. Das Modell ist hier eine grafische Ausdrucksform von Aktivitäten, Klassenbeziehungen, Abfolgesequenzen, Zustandsdiagrammen und einiges mehr, repräsentiert mit den 14 im UML-Standard definierten Diagrammarten. Als Erweiterung oder Spezialisierung gibt es die SysML mit einigen weiteren Diagrammarten. Die https://de.wikipedia.org/wiki/Unified_Modeling_Language ist in den 90-ger Jahren aus Vorarbeiten und deren Vereinheitlichung insbesondere aus der Aktivität der drei Amigos Grady Booch, Ivar Jacobson und James Rumbaugh entstanden. Seither gibt es einige Firmen, die UML-Tools vertreiben und weitere Firmen, die UML coachen. Die UML ist durchaus weit verbreitet,


1.2 Funktionsblock-Darstellungen, Vertreter Simulink

Topic:.fblock...


Bild: Simulink-Modell

Es gibt eine zweite Art der modellorientierten Programmierung neben der UML, die repräsentiert wird von den Funktionsblock-Darstellungen. Die ersten Funktionsblock-Sprachen sind etwas älter als die UML und wohl unabhängig von den drei Amigos entstanden. Jedenfalls ist die bereits in den 80-ger Jahren bekannte Funktionsblockdarstellung nicht von der UML beachtet worden. Ein Grund dafür könnte sein, dass die UML vorderhand auch objektorientiert ist und die Funktionsblock-Darstellungen in diese Welt wohl nicht passen.

Wie im Folgeabschnitt dargestellt hat das Zustandsdiagramm die Aufnahme in die UML geschafft. Die zur Gründungszeit der UML schon bekannten Funktionsblock-Darstellungen haben diese personelle Verbindung wohl nicht gehabt und haben es damit nicht in die Unified Modelling Language geschafft.

Als wichtiger Verteter der Funktionsblock-Darstellungen sei Simulink (Mathworks) genannt. Es gibt allerdings, wie im Folgeabsatz dargestellt, eine Reihe ähnlicher Modelldarstellungen mit ihren Tools.


1.3 Zustandsdiagramm (State Diagram)

Topic:.fblock...


Bild: Beispiel Zustandsdiagramm mit Petri-Netz

Die Arbeit mit Zuständen (States) und deren Übergängen (Transitionen) ist grundlegend in der Programmierung. Die Einheitlichkeit der Anwendung der Zustandsdiagramme ist an sich durch die Standardisierung in der UML erreicht. Zuvor (vor und in den 80-ger Jahren) gab es mit einfachen Zustandsdiagrammen ohne Schachtelung der States, teils mit Petri-Netzen, unter dem Oberbegriff der Automatentheorie, als Mealy- und Moore-Automat. Das Bild rechts zeigt ein sehr einfaches Zustandsdiagramm mit Petri-Netz, Quelle Wikipedia-Artikel bzw. https://de.wikipedia.org/wiki/Petri-Netz#/media/File:Seasons_1.svg. Petri-Netze haben den Vorteil, dass damit parallele Zustände definiert werden können. Das sind aber aus heutiger Sicht Vorarbeiten zum standardisierten Zustandsdiagramm der UML.

Das in der UML standardisierte Statechart ist im wesentlichen von David Harel in den 80-ger Jahren entwickelt wurden und im Tool https://de.wikipedia.org/wiki/Statemate erstmalig etabliert. Es wurde mit Augenmerk auf komplexe System in praktischen Anwendungen entwickelt und kennt sowohl geschachtelte States (internes Verhalten in einem übergeordnetem State), Parallität von Abläufen, Fork- und Join-Syncbar. Letzteres erinnert an Petri-Netze und hat wohl dort möglicherweise seinen Ursprung. StateMachines in UML können entweder Event-getriggert werden, oder zyklisch ablaufen. In beiden Fällen sind Bedingungen für das Schalten definiertbar. Bei Eventtriggerung ist folgendes Prinzip wichtig: Wenn ein Event im aktuellen Zustand nicht verarbeitet werden kann, dann verfällt es. Mit diesem Prinzip wird ein unerwartetes Verhalten aufgrund eines alten gespeicherten Events vermieden. Das Prinzip ist allerdings aufgeweicht durch die mögliche Definition von dereferred Events, vom Autor nicht empfohlen.


Bild: Beispiel-Statechart in UML

Das Zustandsdiagramm hat die Aufnahme in die UML geschafft, obwohl es auch unabhängig aus einer anderen Ecke kam und daher von einigen bis vielen UML-Tools ursprünglich nicht unterstützt wurde. Das wird wohl an personellen / firmellen Gründen liegen: https://de.wikipedia.org/wiki/Statemate wurde bereits in den 80-ger Jahren von der Firma i-Logix entwickelt. Diese Firma ist dann in der Weiterentwicklung in die UML eingestiegen, mit dem Tool Rhapsody, heute als Rational Rhapsody von IBM vertrieben. Es ist folgerichtig und technisch sinnvoll, dass die eigene StateChart-Darstellung von i-Logix in die UML eingebracht wurde. Die UML unterscheidet mit Blick auf zwei wichtige Hauptvertreter der Diagrammarten zwischen statischer Beschreibung - mit dem ObjectModelDiagram und Verhaltensbeschreibung (einer Klasse) mit dem Statechart.

Das Zustandsdiagramm ist als Stateflow Bestandteil von Simulink, in etwa gleichem Funktionsumfang wie in der UML. An dieser Stelle gibt es also eine Vereinheitlichung.


1.4 Weitere Darstellungen

Topic:.fblock...

In den 80-ger Jahren kamen die Petri-Netze in Mode, als Darstellungsmittel der parallelen und konkurrierenden Verarbeitung. Die Petri-Netze, als Idee in den 60-ger Jahren entstanden, sind allerdings immer noch in einigen Bereichen präsent. Sie werden auch als Modellierungswerkzeug benutzt.

Allbekannt ist selbstverständlich der Programmablaufplan. Ob das https://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm mit zur grafischen Programmierung hinzugezählt werden soll, sei dahingestellt.

https://de.wikipedia.org/wiki/Graphviz scheint eine Umkehrung des Prinzips der Grafischen Programmierung darzustellen: Aus einer textuellen Beschreibung wird automatisch eine grafische Darstellung erzeugt.

TODO: noch ein paar weitere Recherchen, etwas ausführlichere Beschreibung


1.5 Objektorientierung in Funktionsblockdarstellungen oder Erweiterungen aus der UML

Topic:.fblock...

Es erscheint derzeit, dass die beiden Welten der modellorientierten oder -getriebenen Entwicklung in UML und die Entwicklung mit Funktionsblock-Darstellungen sich nicht kennen. Es sind vollkommen verschiedene Tools, Nutzerkreise und Denkschemen. Beide haben ihre etablierte Lobby. Es ist nicht zu erwarten, dass es in naher Zukunft seitens der Toolentwickler eine vereinheitlichende Entwicklung geben wird, wie beispielsweise die Aufnahme der Funktionsblock-Darstellungen in die UML.

Man muss dabei bedenken, dass speziell Simulink als einer der Hauptvertreter der Funktionsblock-Darstellungen einen ganz anderen Unterbau hat als die UML. Simulink ist nicht nur oder nicht erstrangig ein Tool zur Grafischen Programmierung, sondern ein Tool der Simulation. Die Funktionsblock-Darstellung dient also dazu, zusammenzustellen, was in der Simulation zusammenspielen soll. Eine nachfolgende Codegenerierung ist ein nice to have, 'schön, es zu haben' - oder eine notwendige Selbstverständlichkeit da das Simulierte auch auf einer Zielhardware laufen soll, aber nicht der Hauptzweck.

Es wäre aber anzustreben, eine Vereinheitlichung dieser beiden Welten in Details zu erreichen. Damit sprechen die jeweiligen Nutzer zumindestens in einigen Dingen eine ähnliche Sprache. Das kann so weit gehen, dass Kompatibilitätsformate den Datenaustausch ermöglichen. Man stelle sich die Situation vor, dass eine Abteilung in einem Unternehmen traditionell seit Jahren auf UML setzt, eine andere Abteilung gute Erfahrungen mit Simulink hat, und nun beide für Grafische Programmierung zusammenarbeiten sollen.

Die Welt der UML ist bereits vereinheitlicht, dafür steht das Unified schon im Namen. Die Verantwortung für die Standardisierung liegt in einer toolherstellerübergreifenden Organisation: https://www.omg.org/. Das XMI-Format dient dem toolübergreifenden Datenaustausch. Es ist zwar zu beobachten, dass die Toolhersteller nicht unbedingt erstrandig diese Kompatibilität unterstützen, sondern selbstverständlich ihre speziellen Features hervorkehren. Sie müssen aber unterstützen, wenn sie die Anerkennung des Standards haben wollen.

Die Welt der Funktionsplan-Darstellungen ist nicht vereinheitlicht. Im Folgekapitel Chapter: 2 Bekannte Tools für Funktionsblock-Darstellung sind einige Darstellungen und Tools genannt.

Ein Hard- und/oder Systemsoftwareanbieter kann nun, wenn er die Grafische Programmierung unterstützen möchte und dabei auf die Funktionsblock-Darstellung setzt,

Ein Ausweg aus diesem Dilemma ist vorderhand ein einheitliches Ausgabe- oder Austauschformat, wie es die UML mit dem XMI bereits hat. Einfach so auf XMI selbst zu setzen dürfte aber nicht gelingen, da die Funktionsblock- oder datenflussorientierte Darstellung dort gar nicht berücksichtigt ist. XMI ist zudem auch sehr komplex.

Eine andere Denkrichtung kann die bessere Lösung sein, im Folgekapitel dargestellt:


1.6 Komplementarität der Textuellen und Grafischen Programmierung

Topic:.fblock..txtGrafPrg.

Es könnte/sollte ein wichtiges Grundprinzip Pate stehen für die Vereinheitlichung der Funktionsblockorientierten Grafiktools: Komplementarität der textuellen und Grafischen Programmierung.

Mit XMI ist dies kaum zu machen, zu komplex.

Folgend Vorüberlegungen/Anregungen:

Die Komplementarität von Text und Grafik hat gewichtige Gründe, die auch im Folge- Chapter: 1.7 Mögliche Gründe der geringen Nutzung der grafischen Programmierung genannt sind.

Zu fordern ist:

Für Simulink ist ein solches textuelles Komplement generiert aus dem slx-File mit Roundtripmöglichkeit beim Verfasser in Arbeit. Ergebnisse werden in naher Zukunft präsentiert.

Für andere Tools der Funktionsblock-Darstellung kann das gleiche Format toolspezifisch entwickelt werden, Einigt man sich auf ein bestimmtes Format, dann ist das Ziel der Vereinheitlichung der Tools an dieser Stelle geschafft.


1.7 Mögliche Gründe der geringen Nutzung der grafischen Programmierung

Topic:.fblock..noGProg.

Geschätzt über 90% der Programmierung in allen Bereichen wird heute noch nicht grafisch ausgeführt. Dies wird häufig beklagt, aber der Zustand hat sich, obwohl Tools der Grafischen Programmierung schon mittlerweile jahrzehntelang etabliert sind, nicht geändert.

Im Wikipedia-Artikel für Labview (National Instruments) werden folgende Nachteile genannt, die im Artikel auf Labview bezogen sind, aber in etwa der gleichen Form überall zutreffen dürften:

---Zitat aus https://de.wikipedia.org/wiki/LabVIEW Stand 2018-07-16

Neben den genannten Vorteilen hat die graphische Programmierung gegenüber der textbasierten auch Nachteile:

---ende Zitat.

Im ersten und zweiten Punkt wird beklagt, dass ein Kollege am Nebenplatz, der eben mal keine Labview-Lizenz hat, nichts mit der Arbeit seines Nachbarn anfangen kann. Solange es um den Nebenplatz in der gleichen Firma geht, kann man argumentieren, dass es Netzlizenzen gäbe. Damit ist das Problem aber nicht gelöst, denn man möchte Modelle oder Informationen daraus auch mit Partnerfirmen austauschen. Bei der Vielzahl und Diversität der Tools kann man nicht damit rechnen, dass der Partner auch eine Lizenz hat, beziehungsweise noch problematischer, sich nicht auf das Tool eingearbeitet hat.

Vergleicht man dies nun mit den textuellen Softwarequellen, dann ist es schlicht egal, ob man einen Quelltext mit einem kostenpflichtigem Visual Studio 2017 bearbeitet hat, oder mit Eclipse CDT, oder nur mal eben mit Notepad++ damit hineinschaut um zu erkennen wie eine Ausgabe gebildet wird. Der Unterschied ist nicht die Kostenpflichtigkeit der Lizenz sondern die nicht notwendige spezielle Einarbeitung in das Tool. Die gemeinsame Sprache ist der Quelltext der Programmierung, der ist bekannt.

Also wird gezögert in der Entscheidung für ein Tool der Grafisches Programmierung:

Es gibt einige weitere Aspekte, die für die Bevorzugung der zeilenorientierte Programmierung sprechen:

Im Moment der Programmierung, also über einen Zeitraum von 1..2 Jahren kennt man sich im eigenem Quelltext aus. Suchfunktionen und Strukturierung die die IDE anzeigt, helfen. Möglicherweise nimmt man ein UML-Tool oder eine passende Grafik zur Unterstützung der Dokumentation. Über diese zwei Jahre der Bearbeitung im kleinen Team kommt man mit dem Quelltext gut hin. Das Problem der Unübersichtlichkeit der rein textuellen Programmierung fällt erst dann auf, wenn entweder Zeit vergangen ist oder der Quelltext einem anderen Kollegen erklärt werden muss. Im letzten Fall, sobald sich der Kollege etwas hereingedacht hat, ist das Problem wieder weg, man kommt gut mit dem Quelltext zurecht.

Die IDEs (Integrated Development Environment) sind in den letzten Jahrzehnten besser geworden' und bieten weitreichende Unterstützung beim Refactoring. Debugging wird direkt unterstützt. Man debuggt eher im Quelltext.

Für den Vergleich der Softwareversionen, der Absicherung, was ist beim Kunden, ist der Quelltext besser geeignet.

Eine langjährige Pflege der Software, also mögliche Anpassungen beispielsweise beim Ersatz defekter nicht mehr beschaffbarer Hardware, erfordert beim Quelltext lediglich das Aufheben der Compiler und Linker für das Zielsystem. Man kann ältere Versionen entweder auf einem älteren PC, der extra archiviert wird, ablaufen lassen, oder man benutzt beispielsweise VMware zur Emulation der damaligen Systemumgebung. Dazu sind die Aufwände gering. Bei einem Grafiktool muss man nicht nur das Tool selbst vorhalten, gegebenenfalls auf Lizenzen und Zugänge achten, sondern muss auch das Wissen um die Bedienung bewahren. Langjährig bedeutet 20..40 Jahre (bei Industrieanlagen). Entscheidet man sich jetzt also für ein Graphik-Programmiertool dann stehen diese Fragen, bezogen auf eine ferne Zukunft, ebenso im Raum.

Die letzten beiden Punkte im Zitat der Labview-Nachteile sprechen ein Thema an, das mit einem Styleguide beziehungsweise einer modularen Arbeitsweise lösbar ist. Im Vergleich zu textuellen Tools hat man ja bei letzteren das gleiche Problem, wenn man einfach darauf los programmiert. Aber es erscheint bei Texten einfacher, Inhalte zu verschieben, nachdem man die Notwendigkeit der Umstrukturierung erkannt hat. Zudem wird von modernen IDEs das Refactoring gut unterstützt.

Dem Verfasser erscheinen diese letzten beiden Punkte jedoch nicht als typisch für die Grafische Programmierung. Im Gegenteil: Beim 'Aufräumen' im grafischen Modell hat man den besseren Überblick als beim aufräumen in Textzeilen. Grafische Teile lassen sich, zumindestens in Simulink, per Zwischenablage in andere Modellteile oder Submodule einfügen. Eine spezielle Unterstützung in Simulink für Create Subsystem from Selection ist genau für solche Aufräumaktionen gedacht. Man sieht an dieser Anmerkung eines oder mehrerer Wikipedia-Schreiber, das wohl auch hier noch Nachholebedarf gegeben ist.


2 Bekannte Tools für Funktionsblock-Darstellung

Topic:.fblock.tools.

In der Wikipedia Kategorie Grafische Progammiersprachen findet sich eine Übersicht, die ein Teil der hier genannten Tools unterstützt. In dieser Kategorie fehlt (Stand 2018-07) die UML, es fehlt auch Simulink und einige weitere Tools. Die UML gehört zu den Grafischen Programmiersprachen, wird von den Verfassern aber offensichtlich dort so nicht eingeordnet.

Folgend wird jedes dem Verfasser bekannte Tool kurz vorgestellt. Es soll damit gezeigt werden, wie vielfältig (und nicht standardisiert) diese Welt ist.

TODO: Noch genauer recherchieren, das ist erstmal ein kurzer Überblick.


2.1 ICon-L

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/ICon-L An einigen Instituten/in einigen Firmen verwendete grafische Programmiersprache mit integrierter Ablage des zu interpretierender Ablaufcode, Aufruf der zugehörigen in C geschriebenen Funktionen.


2.2 Labview

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/LabVIEW National Instruments, Verschaltung von Messgeräten, Anzeigen und Berechnungen vorderhand für Messungen in Labors.


2.3 Max/MSP and Pure Data

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Max/MSP

https://de.wikipedia.org/wiki/Pure_Data Datenstromdarstellung / Planung


2.4 Posity

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Posity

Etwas sehr spezifisch für betriebswirtschaftliche, datenbankzentrierte Anwendungen (aus Wikipedia-Artikel)


2.5 Qfix Grape

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Qfix_Grape

Kann alles, wenig Angaben.


2.6 VisSim

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/VisSim

Erstversion 1989, aktuell aus 2008, grafische Blockdiagramm-Programmiersprache für die Simulation von dynamischen Systemen. (Zitat aus Wikipedia-Artikel). Äußerlich irgendwie wie Simulink-Blockdiagramme.


2.7 Simulink

Topic:.fblock.tools..

Obwohl nicht in der Wikipedial-Kategorie:Grafische Programmiersprache benannt, ist Simulink adäquat. Aus Sicht der grafischen Programmierung ist es eine Funktionsblockorientierte Grafische Programmiersprache. Erwähnenswert sollte allerdings sein, dass mit Matlab als Background und sehr vielen Addons eine vollständige Simulation der grafisch gezeichneten Programmierung erfolgt. Codegenerierung für C, aber auch für FPGAs (VHDL) sowie einige andere Programmiersprachen ist als addon zukaufbar. Eine home-Edition (keine kommerzielle Nutzung) ist bereits für wenige 100 Euro erhältlich, auch als Studentenversion, alle Simulationsmöglichkeiten umfassend aber ohne die C-Code-Generierung.

In Simulink ist direkt in C geschriebener Code einbindbar (sogenannte S-Functions), auch in der Home-Edition. Damit ist eine Brücke zu Systemprogrammen und hardwarenaher Programmierung vorhanden.


3 Konkrete Arbeiten des Verfassers

Topic:.fblock.do.

Dieser Artikel wäre wenig nutzbringend, wenn nicht konkrete Realisierungen in die hier aufgestellte Richtung bereits in Arbeit oder erledigt wären.


3.1 Objektorientierung in Simulink-Funktionsblockdarstellungen

Topic:.fblock.do..

Dazu ist auf ein vom mir erstelltes pdf verwiesen: ../../smlk/SmlkOOguide-de.pdf. Dazu ein Grundsatzpapier: ../../smlk/SmlkOOapproach-de.pdf. Ein passendes Beispiel zum Auspacken und Testen ist abzholen: ../../smlk/Example_ObjO.zip. Im Beispiel ist nicht das Generierscript enthalten. Es ist nicht zum eigenen Arbeiten, sondern nur zum Nachverfolgen der Herangehensweise gedacht. Bei Interesse bitte mit dem Verfasser in Verbindung setzen: mailto: hartmut.schorrig@vishia.de

Detailliertere Erklärungen befinden sich in ../../fbg/html/GraphProgr_1.html.


Bild: Beispiel Object-FB in Simulink

Die Idee ist, Funktionsblöcke in Simulink als Object-FB und Operation-FB zu untergliedern und mit Referenzen zu verbinden. Das Bild rechts zeigt zwei Object-FB, param2 ist als Aggregation auf OrthOsc2_FB verbunden. calcmagn2 ist ein Operation-FB. Die Referenzen sind in Simulink Handle, die einen Index auf eine globale Adresstabelle darstellen. Die Adressen selbst sind damit intern. Die Adressen stehen in einem shared-memory-Bereich da jeder Funktionsblock als S-Function realsisiert sonst seinen eigenen Speicherbereich hat. Die Object-FB legen Daten an und kennen über Aggregationen andere Object-FB. Die Operation-FB bekommen den Handle von ihren Object-FB und wenn notwendig noch von anderen Object-FB. Damit können die Operation-FB mit den Daten der Object-FB beliebig arbeiten, wie es der Objektorientierung entspricht. Das für die Funktionsplan-Darstellungen gewohnte Datenflussprinzip wird hier etwas durchbrochen, da die Zugriffe auf die Daten nicht gezeichnet sind. Die Handleverbindungen sind aber gezeichnet. Man sieht in der Grafik nicht direkt, mit welchen Daten gearbeitet werden. Die Grafik ähnelt zum Teil eher einem ObjectModelDiagram aus der UML, nur die Zeigerrichtungen sind umgekehrt: In der UML als Depedency vom Nutzenden zum Genutzten, in der Funktionsblock-Darstellung vom Bereitstellenden zum Nutenden. Der Datenfluss wird also dargestellt, aber mit dem Handle bekommt man den Zugriff auf alle Daten.

Der notwendige Typtest der Handle oder Zeiger erfolgt zur Runtime in einer speziellen Tinit-Abtastzeit über Reflection. Die Handle sind formal uint32-getypt. Für das Zielsystem enthalten die Handle direkt die Instanzadressen (kurze Rechenzeit). Im Zielsystem werden vom Simulink-Codegenerator die Zeiger immer noch als uint32 gespeichert, vor Aufruf erfolgt codegeneriert das notwendige casting. Der Typtest darf im Zielsystem entfallen, wenn die Verbindungen aggregiert sind (nicht zur Laufzeit geändert) und das Modell getestet ist, der Typtest also im Modell jedenfalls durchlaufen wurde. Der Typtest ist nur notwendig, um Anwender-Verbindungsfehler im Modell zu erkennen.


Bild: FunctionCall ObjO_Smlk

Die Themen Vererbung bzw. Abstraktion, wie sie für die Objektorientierung typisch sind, sind ebenfalls abgehandelt: Es ist möglich, einen mehr abstrakten Typ als Input eines Operation-FB zu verdrahten auf den abgeleiteten Instanztyp, damit wird eine Basis-Operation gerufen. Aus einer Basis-Operation heraus kann über den Aufruf einer anderen Basisoperation die für die Instanz abgeleitete Operation gerufen werden, indem entweder in C über eine Nachbildung der virtuellen Tabelle über Funktionszeiger die instanzrichtige Operation gerufen wird, oder, wie im Bild rechts gezeigt, der Funktionsaufruf über eine triggered Operation läuft. Die Arbeit mit abgeleiteten Operationen ist deshalb interessant, weil ein Basissystem als Modell unverändert übernommen werden kann, ein anderes Modellteil aber spezialisiert ist. Es muss dann keine Anpassung erfolgen.


Bild: ObjO_Smlk Funktion in Simulink

Das Ganze funktioniert nicht nur mit S-Functions, die in C programmiert sind, sondern auch mit Modellteilen in Simulink. Dabei sind nur die Schnittstelle beispielsweise zu einem Operation-Submodul in C programmiert. An den Ausgängen dieser S-Functionen stehen die Daten der Klassen-Instanz (des zugehörigen Object-FB) an. Diese werden in einem reinen Simulink-Modell verknüpft und auf Eingänge einer S-Funktion zum Einschreiben der Daten in die Klasseninstanz gelegt. Für den Controlflow können triggered Subsystems des Simulink eingesetzt werden. Das rechtstehende Bild zeigt die Einbettung einer Funktionalität in einen datenliefernden und einen datenspeichernden Operation-FB. Beide sind einfache S-Functions. Die eigentliche Funktionalität ist modelliert. Der Datenzugriff in diesen Operation-FB kann mit entsprechenden C-Funktionen insbesondere geschützt sein, für Mulitthreading mit Wechselpuffer oder Mutex und dergleichen. Solche Dinge sind dann in C besser ausprogrammierbar, da direkt Betriebssystemdienste in Anspruch genommen werden können.

Busse in Simulink werden unterstützt. Da die Busse aber teils mit der Zeiger- oder hier Handle-Technik nicht verträglich sind, werden Datenstrukturen nicht mit Bussen sondern als struct in C definiert. Die zugehörigen S-Function-Blöcke sehen dann in der Grafik schmal geschoben fast so aus wie ein Bus-Selector.

Die Realisierung baut also stark auf S-Functions in C. Damit diese S-Functions unaufwändig in das Modellieren integriert werden können, ist ein eigener Codegenerator für die S-Function-Wrapper gebaut, der mit Informationen aus den Headerfiles arbeitet und pro S-Function viel weniger Aufwand braucht als etwa das Mathworks- oder Simulink-eigene Legacy Code Tool. Dieser Teil der Realisierung ist nicht Opensource, muss also vom Autor geliefert werden. Das Grundprinzip kann aber anhand eines umfangreichen Beispiels studiert werden. Die Zielcodegenerierung läuft über den Simulink-Coder. Die dafür notwendigen tlc-Files werden vom S-Function-Wrapper-Generator geliefert, so dass ein reibungsloses Zusammenspiel gesichert ist.

Würde dieses System nativ in Simulink von Mathworks unterstützt werden (was durchaus in den nächsten Jahren vorstellbar ist), dann könnte die C-Ebene teils herausgenommen werden. Wenn Busse andere Busse referenzieren können (das sind Assoziation oder Aggregation), dann wäre die Datenanlage vollständig mit dem Bus-System in Simulink möglich. C-Funktionen kommen dann nur ins Spiel (ggf. mit dem S-Funktion-Wrapper-Generator des Verfassers) wenn sie von der Anwendung wirklich gewünscht wären.


3.2 Funktionsblock-Connection-Language

Topic:.fblock.do.FBCL.

Der Verfasser hat sich mit dem Auslesen von Informationen aus dem slx-File beschäftigt, um eine spezielle Codegenerierung zu entwickeln, die von Simulink nicht unterstützt wird. Dabei wurden die Informationen, die im slx-File Simulink-spezifisch enthalten sind, zunächst unifiziert. Es wurde mit verschiedenen Simulink-Versionen gearbeitet, dabei traten Änderungen im slx-File auf, die zwar klar erkennbar und schnell behandelbar waren, aber eine Trennung der Aufbereitung der Informationen aus dem slx-File von der eigentlichen Codegenerierung nahelegen. Im derzeiten Stand dieses Projektes wird die unifizierte Ablage der Modelldaten nur intern gehalten. Die Idee, damit eine allgemeingültige Datenablage zu bilden, ist daraus entstanden.

Die Idee und die Anforderungen an diese allgemeingültige textuelle Datenablage von Funktionsblock-Darstellungen ist im Kapitel Chapter: 1.6 Komplementarität der Textuellen und Grafischen Programmierung oben bereits beschrieben. Diese Idee ist nicht mehr nur auf verschiedene Versionen der slx-Codierungen des Simulink bezogen, sondern soll andere Grafik-Darstellungen und Tools der Funktionsplan-Represetationen mit einbeziehen. Das können die im Kapitel Chapter: 2 Bekannte Tools für Funktionsblock-Darstellung genannten sein.

Es ergibt sich damit folgende Situation:

Der letzte Punkt ist nochmals darzustellen: Eine Codegenerierung aus der noch zu beschreibenden FBCL ist keinesfalls etwa mit einem einfachen Perl-script oder dergleichen noch etwa in einer Bachelorarbeit machbar. Die Zielcodegenerierung benötigt eine hohe Verlässlichkeit, die auch durch langjährigen Praxiseinsatz gegeben ist. Aber mit einem anfänglichen experimentellen Ergebnis kann bei intensiver Beschäfigung eine solide Lösung entstehen. Für den einzelnen Toolhersteller kann das im Verlauf von einigen Jahren eine gewisse Konkurrenz bedeuten. Diese Konkurrenz erwächst aber aus den Anforderungen der Nutzer. Diese wollen möglicherweise Lösungen, die kompatibel für verschiedene Tools anwendbar sind. Dies ist ein vergleichbarer Ansatz wie die Standardisierung der UML-Darstellung im XMI-Format.

Die Idee der FBCL hat also zukunftsweisenden Charakter. Man muss sehen, was sich daraus entwickelt.


3.3 Zielcodegenerierung aus der FBCL, Hinweise

Topic:.fblock.do..

ident=FBCL2target

Folgend ist nur stichpunktartig benannt, was alles zu beachten ist bei einer Codegenerierung aus einer textuellen Funktionsblock-Connection-Darstellung, die als Output aus verschiedenen Tools möglich sein sollte:


4 Instrumentierung, Beobachtung im Zielsystem

Topic:.fblock.inspc.

Es gibt zwei verschiedene Herangehensweisen der Simulation:

Einige der einfachen funktionsplandarstellungsorientieren Tools arbeiten nach dem System b). Das Zielsystem wird direkt unterstützt, Compilierung in einer PC-Umgebung reicht für einen Test ohne Zielhardware.

Simulink arbeitet typischerweise (im typischen Anwendungsfall) nach der Variante a). Das liegt auch daran, dass Simulink nicht vorrangig ein Tool zur grafischen Zielsystemprogrammierung ist, sondern ein Simulationstool auch für Grundsatzuntersuchungen. Wenn beispielsweise komplexe technische Systeme nachgebildet und simuliert werden (mit Simscape), dann ist eine Codegenerierung für diese Systeme nicht angebracht. Die Simulation erfolgt durch numerische Integration der Differenzialgleichungen über interne Algorithmen.

Dennoch ist für Simulink eine Instrumentierung des Zielsystems möglich.

Instrumentierung bedeutet: Im Zielsystem werden Daten erfasst und auf Modellebene an passender Stelle im Modell mit dem laufenden Zielsystem dargestellt. Es ist dann beispielsweise beobachtbar


5 Weblinks

Topic:.fblock..

https://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software