Simulink und C - und dazu auch noch objektorientiert

Topic:.Smlk_de.C_ObjO.

Last changed: 2017-12-10

C ist für Embedded Applikationen der Standard schlechthin. Die Gründe liegen in der Hardwarenähe und der Flexibilität für verschiedene Hardware-Anforderungen. Applikationen werden aber mehr und mehr komplex, entsprechend der steigenden Leistungsfähigkeit von Prozessoren und Boards und der gestiegenen Anforderungen an die Software-Applikationen. Die Softwaretechnologie muss schritthalten, sonst geht der Überblick über die Software verloren.

Daher ist eine grafische Programmierung wünschenswert. Zweidimensional lässt sich mehr Überblick gewinnen. Die Informationen sind mit Bild-Darstellungen aufbereitbar - Funktionalitäten sind aufgrund eines Bildes viel schneller auffindbar und verstehbar.

Bild: Programmierung in Facetten

Man kann hier soweit gehen, dass die Programmierung in C oder C++ nichts in der Anwenderschicht zu suchen hat. Die Denkschemen - Pointer, malloc, dangling, exception, <Template> - sind zu weit weg von den eigentlichen Problemen.

Andererseits: Die letztliche Realität ist die funktionsfähige Software in der Hardwareplattform. Diese wird in C exakt beschrieben. Datenabbildungen - in Telegrammen - gehören dazu.

Wichtig: Simulation der gefundenen Algorithmen der Anwenderprogrammierung in einer realistisch simulierten Umgebung.

Topic:.Smlk_de.C_ObjO..

Es gibt Tools für die grafische Programmierung, bei denen das Hinabsteigen in die C-Ebene vollkommen überflüssig wird. Damit braucht der Anwender nicht mehr C zu können oder lernen. Auch Operationen bis auf Bit-Ebene werden grafisch unterstützt. Mit Mathworks Simulink ist dies möglich.

Ein Hauptgrund für die Verwendung von Simulink als zentrales Tool der Softwareentwicklung dürfte die Möglichkeit der Simulation der Software einschließlich der Umgebung in Simulink sein. Simulink dient also vordergründig nicht als Hilfstool zur Softwareerstellung sondern als Gesamt-Tool zur Lösungsfindung mit anschließender Implementierungsgenerierung. Mathworks bietet dazu für Simulink eine Reihe Toolboxes an, beispielsweise zur Simulation elektrischer Netzwerke (Simscape Power Systems) aber auch mechanischer Komponenten. Der Vorteil: Simulink verfügt von haus aus über viel eingebautes Knowhow zur numerischen Berechnung von Differenzialgleichungssystemen. Würde man dies manuell ausprogrammieren müssen, oder jeweils für den Test ein mechanisches Modell beistellen müssen - viel Aufwand.

Topic:.Smlk_de.C_ObjO..

Simulink leistet die Generierung von C aus dem Modell für ein Target-System, auch mit Unterstützung spezieller Prozessoren (Embedded Coder) für optimale Laufzeit und Speicherausnutzung. In Simulink ist es aber auch möglich, mittels sogenannter S-Funktionen C-Code sowohl im Simulationslauf am PC einzubinden als auch in gleicher oder adaptierter Form (Hardwareanbindung) für das Target nutzen.

Die Einbindung von C in Teilmodule der grafischen Programmierung bringt folgende Vorteile mit sich:

• C wird nicht offiziell über Bord geworfen. C tritt in der Implementierungsschicht wieder auf - und wird als Kernfunktionsmodul in C auch als Quelle angesehen.

• Alt-C-Code lässt sich einbinden.

• Dinge die eigentlich in C besser formulierbar sind, müssen nicht verkompliziert grafisch dargestellt werden. Es ist durchaus Ansichts-, Gewöhnungs- oder Praxiserfahrungs-Sache, ob man beispielsweise ein Bit Schieben besser grafisch darstellen möchte oder in C.

Die unbestrittenen Vorteile der grafischen Programmierung sind:

• Besserer Überblick.

• Funktionen können mit dem Nutzer der Software am Modell geklärt werden.

Möchte man aus eigener Intension C und Simulink miteinander zweckmäßig verbinden, dann bietet sich folgende Herangehensweise an:

• Treiber, Grundfunktionen werden nach wie vor in C belassen.

• Auch Daten-Strukturen werden in C beschrieben - das ist übersichtlich. Ein Datenaustausch erfolgt oft in Telegrammen (Ethernet, Dual-Port-Ram), bei dem der Datenaufbau auf Maschinenebene genau bekannt sein muss. In vielen Fällen kommt es auf Datenkonsistenz an. Entsprechende Betriebssystemzugriffe sind in C bekannt, geläufig und gehören an sich nicht zur Anwenderfunktionalität. Wenn dies also in C gekapselt wird, diese C-Module dann im Modell eingebunden sind, dann ist dies praktisch gut. Aus den struct-Definitionen in C werden in Simulink Busse generiert, die die Daten auch im Simulink-Modell darstellbar werden lässt. Simulink unterstützt dies mit der Angabe 'Imported' bei Headerfiles zu Bussen.

• Alle übergeordneten Softwareteile, insbesondere die Zusammenschaltung großer Softwareblöcke aber auch einfache Operationen werden grafisch dargestellt.

• Aus der grafischen Darstellung werden C-Codes für die Zielsystemimplementierung generiert.

• In C realisierte Module sind aus der Simulink-Sicht eine Black Box oder besser Gray Box. Ein nicht C orientierter Simulink-Modellierer wird die Inhalte nicht ändern können oder wollen, es sind fertige Module. Der Zugriff auf die dort enthaltenen Daten ist aber auch aus Simulink möglich, über Simulink-Busse als Output oder Reflection. Die Daten der C-Module können als gekapselt ('private') aufgefasst werden, sind aber natürlich für das Beobachten des Simulationslaufes sehr wahrscheinlich wichtig.

Kommt man aus der Ecke der reinen C-Programmierung, möglicherweise mit Seitenblick auf das noch nicht ganz so verbreitete aber mit besserem Ruf versehene C++, dann stellt sich mit Nutzung von Simulink die Welt ganz anders dar: Anstelle der Planung der Softwarestruktur etwa mit UML-Tools und doch wieder Handcodierung der Einzelfunktionen tritt die vollkommen grafisch zweidimensional besser dargestellte Übersicht über die Software. Insbesondere auch aus Sicht der umfassenden Möglichkeiten der Simulation mit Umgebung, damit Test der Software am PC wird hier der Rat gegeben: Simulink anschauen, als Trial testen, Informationen einholen, kaufen und einsetzen.

Topic:.Smlk_de.C_ObjO..

Die Objektorientierte Programmierung (OOP) ist eine feste Größe in der Softwaretechnologie. Objektorientierung im Kern bedeutet, dass Daten gemeinsam mit ihren Operationen, Methoden oder Funktionen betrachtet werden. Nicht-Objektorientierung liegt vor, wenn Funktionen ohne direkte Zuordnung zu Daten definiert werden und Daten nicht zusammengebunden dargestellt werden. Weitere Eigenschaften der Objektorientierten Programmierung wie Abstraktion, Vererbung, überladene Operationen sind ergänzend und im Gesamtsystem zweckmäßig, aber kein grundsätzliches Kennzeichen. Überladene Operationen (overridden operations, virtual methods) sind teilweise notwendig.

Objektorientierung wird zuerst mit den bekannten objektorientierten Sprachen wie C++ und Java in Verbindung gebracht. C-Entwickler sind oft und traditionell der Meinung, dass C dafür nicht geeignet sei. Daher wird oft nicht objektorientiert gedacht, sondern Einzelfunktionen geschrieben, die mit globalen Daten arbeiten. In Simulink kommt die Objektorientierung deshalb eher nicht vor, weil dort datenflussorientiert gedacht wird. Die Zusammenfassung zu Modulen ist noch keine Objektorientierung.

Bild: Object-FB und Operation-FB

Sowohl in C als auch in Simulink ist aber eine Objektorientierung zweckmäßig. Die Objektorientierung ist nicht primär eine Eigenschaft einer Sprache, sondern eine Herangehensweise der Programmierung. Man könnte, wenn man so wollte, auch in Assembler objektorientiert programmieren, in dem man Daten zweckmäßig zusammenfasst, bei Assemblerfunktionen jeweils den Zeiger auf den zugehörigen Datenbereich mit übergibt und für overridden methods eine Adresstabelle nutzt, die in den Daten geeignet verzeigert ist (Das ist die vtable in C++). C verfügt nun über einige Sprachmittel, um objektorientiert heranzugehen:

• struct für Datenzusammenfassen

• struct {Basetype base; ...}: Basisdaten am Anfang einer struct für Einfachvererbung. Auch Java kennt nur die Einfachvererbung.

• Funktionszeiger für overridden operations, Anordnung in Funktionszeigertabelle

Im Grunde genommen muss man nur etwas mehr schreiben als in C++, hat aber die selben Maschinencodes. Die Nicht-Objektorientierte Programmierung in C, das heißt lose globale Daten, Funktionen, die möglichst intern nicht sichtbar auf globale Daten zugreifen, sollte man als negative oder Anti-Pattern benennen.

Die UML ist eine Beschreibungssprache zur Objektorientierung, geeignet um die Softwarestrukturen aufzuzeigen. UML-Tools sind verbreitete und spezifisch leistungsstark, sie sollten verwendet werden.

Topic:.Smlk_de.C_ObjO..

Simulink-Blöcke als S-Funktionen werden aufgeteilt in

• Object-FB: Enthält Daten in C erstellt,

• Operation-FB: Enthält keine Daten, nutzt einen thiz-Zeiger als Input zum Referenzieren der zu verwendeten Daten.

• Die Verbindung passender Object-FB mit Operation-FB wird beim Start des Modells überprüft. Es sind dabei auch Verbindungen von einer abgeleiteten Instanz eines Object-FB zu einem Basisdaten-Operation-FB möglich. Das ist Aufruf einer Basisklassen- oder abstrakten Operation.

• Der Aufruf überladener Operationen muss in C (oder auch C++) im Object-FB implementiert sein. Man kann dann etwa einen fertigen Modellteil, der abstrakte Operation-FB enthält, mit einem speziellem Modellteil, der die abgeleiteten zweckentsprechenden Object-FB enthält, auch dynamisch verbinden. Man erhält somit eine zweckentsprechende Funktionalität ohne das fertige Modellteil anpassen zu müssen. Das ist der Grundgedanke der Abstraktion in der Objektorientierung.

• Object-FB werden miteinander verbunden, wobei ein aggregierter Object-FB seinen thiz-Zeiger einem nutzenden Object-FB in der startup-Phase oder als Assoziation auch dynamisch bereitstellt. Die Pfeilrichtung im Modell ist damit lediglich umgekehrt im Vergleich zu einem Object-Model-Diagram der UML.

Damit hält auch die Objektorientierung Einzug in die Simulink-Welt und Architektur-Denkweisen wachsen zusammen.

Topic:.Smlk_de.C_ObjO..

Mathworks-Simulink bietet für die Erstellung von S-Funktionen, also Aufrufe von C-Anteilen im Simulink, 3 Wege an:

• Ein sogenantes Legacy-Code-Tool soll den Anwender unterstützen, insbesondere vorhandenen C-Code in die Simulink-Modellierung einzubinden. Der Anwender wird dabei entlastet vom Schreiben der nicht ganz einfachen Wrapper der S-Funktionen, der tlc-Files für die Zielsystem-Codeerstellung und auch der grafischen Repräsentation der S-Funktion.

• Grafische Eingabemöglichkeit anstelle des Schreibens eines Matlab-scripts für das Legacy-Code-Tool

• Manuelles Erstellen der Wrapper und tlc-Files.

Der letzte Punkt bietet alle Möglichkeiten. Das sind sehr viele, beispielsweise die Nutzung dynamischer (vom Modell bestimmter) Port-Eigenschaften, mehrere Abtastzeiten in einem Block, beliebige Parameter. Das manuelle Erstellen ist aber aufwändig. Insbesondere bei vielen kleinen S-Funktionen ist das erheblich.

Daher hat der Verfasser einen Generator erstellt, der S-Funktion-Wrapper und tlc-File aus Zusatzinformationen im Headerfile erstellt. Das dazu nötige Script kann mehrere Headerfiles verarbeiten und damit eine Vielzahl meist kleiner S-Funktionen erstellen ('Kerne in C') und muss nicht angepasst werden, wenn sich Operationen im Header ändern. Der Generator arbeitet wie folgt:

• Parsen des Headerfiles mit Open-Source ZBNF-Parser, Überführung der relevanten Daten aus dem Header in einen Datenhaushalt in Java. Dazu ist ein Semantic-Script-File notwendig.

• Generieren der Wrapper und tlc-Files aus dem Daten in Java mit einem Open-Source-JZtxtcmd-Generator. Dazu ist ein textuelles Generierungs-Script-File notwendig. Dies enthält alle Befehle und Texte. Der Generator für Simulink Sfunction-wrapper und tlc ist also ausschließlich mit diesen Scripts realisiert.

Die Tools zum Generieren sind Open-Source, nicht aber die genannten Script-Files. Diese enthalten wesentliches Knowhow der S-Funktion-Technik des Mathworks-Simulink und schon von daher notwendigerweise geschützt. Mit vorhandener Simulink-Lizenz und entsprechender Anfangsbetreuung können diese Scripts dann vom Kunden genutzt und auch angepasst werden.

mailto: simulink@vishia.org

oder Mathworks anfragen.

Topic:.Smlk_de.C_ObjO..

• www.vishia.org/smlk/SmlkOOguide-de.pdf Handbuch für die Einbindung von C über Sfunction in Simulink mit vishia-Sfunction-Generator, Objektorientierung in Simulink.

• www.vishia.org/smlk/Example_ObjO.zip Dieses zipfile enthält einige Beispielmodelle in Simulink mit generierten Sfunction.mex64 dll für Windows 64 bit (debugbar mit Microsoft Visual Studio 17), mex-Aufruf generiert (für andere Compiler auf dem PC nutzbar) und generiertem Zielsystem-Code (mit einem Microsoft Visual Studio 6 Project auf dem PC als 32-bit Executable testbar, Quellen auch mit anderem Compiler compilierbar, grt-Codegenerator).