Zwei Projekte, zwei Tools, viele Erkenntnisse<\/p>\n
Autor: Joachim Terasa, coming GmbH<\/p>\n
Zwei Werkzeuge f\u00fcr MBSE, die sich durch ihre Eigenheiten und einzigartigen Features unterscheiden, haben dabei aber auf den ersten Blick eine Menge Gemeinsamkeiten. In der Praxis entpuppen sich einige als durchaus relevant. Im den hier betrachteten F\u00e4llen sind besonders die „polled Statemachines“ gegen\u00fcber den „eventgetriebenen Statemachines“ die hervorstechendsten Unterschiede, die zu einem nicht vergleichbaren Verhalten des generierten embedded Systems f\u00fchren.<\/strong><\/p>\n Modellbasiertes Softwareentwicklung f\u00fcr Embedded Systeme ist ein Fakt und seit vielen Jahren praktizierte Realit\u00e4t.<\/p>\n Bei der konventionellen Entwicklung, also z.B. Codieren in C\/C++, gab es immer schon die notwendige Entscheidung f\u00fcr eine Toolchain, wie z.B. Versionsverwaltung \/ Editor \/ Compiler \/ Linker \/ Debughilfsmittel \/ Testhilfsmittel. Das Glied der Kette, das hier im Fokus steht, ist der Editor.<\/p>\n Die Wahl eines geeigneten Editors ist nicht kritisch. Seine Benutzung f\u00fchrt immer zu dem einen definierten Ergebnis: dem Sourcecode. Dessen Inhalt bestimmt der Programmierer. Beim Einsatz eine Modellierungswerkzeugs wird auch innerhalb des Modells manuell erstellter Sourcecode verwendet. Auch wenn sich Werkzeuge gemeinsam an Standards wie UML orientieren, sind die Spielr\u00e4ume, die diese Standards zulassen, gro\u00df, wenn es darum geht, aus grafischen Modellbestandteilen Code zu erzeugen. Anhand zweier Beispiele von Modellierungswerkzeugen soll gezeigt werden, dass oberfl\u00e4chliche \u00c4hnlichkeit nicht ausreicht. Aufgrund umfangreicher Praxiserfahrung in mehreren Projekten der vergangenen 5 Jahre stehen sich diese beiden gegen\u00fcber:<\/p>\n radCASE \/ Hersteller: IMACS GmbH, Deutschland<\/a><\/strong><\/p>\n QP\/QM-Framework \/ Hersteller:\u00a0 Quantum Leaps, LLC, USA<\/a><\/strong><\/p>\n Beide …<\/p>\n Die oben genannten Gemeinsamkeiten sind oberfl\u00e4chlich, w\u00e4ren aber bei einem Auswahlverfahren mittels einer Featureliste durchaus ausreichend aussagef\u00e4hig<\/p>\n Stichworte: Anbindung an die Hardware \/ Zugriff auf IO-Ressourcen \/ mehrfache Instanzen einer Klasse. radCASE verlangt zu jeder Hardware zwingend eine API, die zur Applikation hin eine fest definierte Schnittstelle vorweist. Damit ist das Modell auf jede beliebige Hardware mit existenter API \u00fcbertragbar. Die Zuordnung von Hardwareressourcen erfolgt au\u00dferhalb der eigentlichen Software in der „Entity-Tab“. Hierin werden logische Ressourcen innerhalb der Software und der Instanzen mit physikalischen Ressourcen verbunden. Die Anpassung an Hardware\u00e4nderungen ist allein durch Anpassung der Entity-Tab ohne \u00c4nderungen am Code m\u00f6glich.<\/p>\n F\u00fcr QP muss ein BSP erstellt werden. Dieses hat keine vorgegebene feste Form oder Schnittstelle. Laut UML beinhaltet ein Zustand eine Entry- und eine Exit-Action. Eine Transition hat ein ausl\u00f6sendes Event, eine Schutzbedingung und eine Aktion (Event[Guard]\/Action). Beide Werkzeuge weichen hiervon ab (siehe dazugeh\u00f6rige Abbildung,\u00a0PDF<\/a>).<\/p>\n radCASE kennt in Zust\u00e4nden zus\u00e4tzlich eine Do-Action und bei den Transitions lediglich [Guard]\/Action. Actions sind C-Codefragmente, die mit der Codegenerierung in den Code eingef\u00fcgt werden (siehe dazugeh\u00f6rige Abbildung,\u00a0PDF<\/a>).<\/p>\n Bei QP\/QM hat eine Transition Event\/Action, was sich allerdings mit einem einfachen Kunstgriff auf UML-Form Event[Guard]\/Action erweitern l\u00e4sst. Au\u00dferdem gibt es hier sogenannte interne Transitions. Actions sind auch hier C-Codefragmente, die mit der Codegenerierung in lokale Unterprogramme abgebildet werden.<\/p>\n Die zugrundeliegenden Laufzeitsysteme sind grunds\u00e4tzlich unterschiedlich.<\/p>\n Statemachines in radCASE pollen anhand der [Guards] zyklisch auf Zustands\u00e4nderungen. Die Do-Action innerhalb eines aktiven Zustands wird zyklisch ausgef\u00fchrt. F\u00fcr jedes Objekt d\u00fcrfen auch mehrere Statemachines existieren. Das System hat durch das Polling immer eine Grundlast.<\/p>\n QP setzt auf ein voll asynchrones Konzept. Events – das sind Nachrichten, die neben einer Kennung auch Inhalte enthalten – werden entweder systemweit oder gezielt verschickt. Emp\u00e4nger ist immer die Statemachine eines AO, ohne die sich nichts bewegt. Die internen Transitions f\u00fchren nicht zu einem Zustandswechsel, sondern f\u00fchren eine lokale Aktion aus. Im Laufzeitsystem ist ein aufw\u00e4ndiger Event-Queue-Mechanismus enthalten. Eine Statemachine tut ohne Event nichts.<\/p>\n Beide Werkzeuge verwenden zur Definition von Klassen eine textuelle Baumstruktur.<\/p>\n QP\/QM erlaubt hier f\u00fcr Methoden und Attributen alles, was der verwendete Compiler erlaubt. Au\u00dferdem muss eine Statemachine Bestandteil einer Klasse sein. Methoden sind dabei Unterprogramme oder Funktionen in C. Die Instanzen einer Klasse nennen sich „Active Objects“ und sind die kleinsten Einheiten des Tasking in QP.<\/p>\n radCASE verfolgt f\u00fcr Methoden die \u00fcblichen Sichtbarkeitstypen und zus\u00e4tzlich den Typ „Permanent“, der die betreffende Methode in eine Liste von zyklisch auszuf\u00fchrenden Methoden einf\u00fcgt. Diese sind Basis des kooperativen Tasking in radCASE. F\u00fcr Attribute wird ein eigenes Typkonzept verwendet. Jede Variable („Element“) beinhaltet Zusatzinformationen \u00fcber ihre Lokalisierung in Code- oder Speichersegmenten, d.h. ob sie unter anderen konstant, persistent, analog IO, digital IO oder variabel sind. Alle Typen verf\u00fcgen \u00fcber Metadaten, wie Einheit, Darstellungsformat, Ober- und Untergrenze, Beschreibung und Kommentar, um komfortabel in GUI-Bausteinen verwendet zu werden.<\/p>\n radCASE setzt auf ein Round-Robin-Konzept, bei dem alle als „Permanent“ markierten Methoden zyklisch aktiviert werden. Statemachines werden hier identisch wie Methoden behandelt. Unterschiedliche Zykluszeiten sind m\u00f6glich. Ein kooperatives Tasking ist die Grundlage und muss bei der Implementierung der Methoden ber\u00fccksichtigt werden.<\/p>\n Die kleinste Einheit des Taskings bei QP ist das Active Object, bei dem die Statemachine zentrales steuerndes Element ist, ohne das nichts l\u00e4uft. Allein aufgrund\u00a0 eines zu bedienenden Events werden Aktionen durchgef\u00fchrt, Events generiert, Berechnungen durchgef\u00fchrt. Jedes AO erh\u00e4lt dabei eine eindeutige Priorit\u00e4t, die \u00fcber die Reihenfolge der Abarbeitung von Events entscheidet.<\/p>\n Beide Werkzeuge bieten die M\u00f6glichkeit einer Entwicklung mit Simulation unter Zuhilfenahme einer GUI am PC. radCASE geht hier einen Schritt weiter. Es unterst\u00fctzt lokale Displays am Controller mit diversen Steuer- und Bedienmechanismen. Remote-GUIs f\u00fcr PC oder Web werden unterst\u00fctzt. Diese k\u00f6nnen f\u00fcr eine Simulation oder als Visualisierung und Bedienoberfl\u00e4che \u00fcber eine Datenverbindung im laufenden Betrieb genutzt werden. Diese GUI-Elemente sind jeweils Bestandteil der Klassen. Jedes GUI-Element wird mit dem zugeh\u00f6rigen Objekt instanziiert und \u00fcber eine \u00fcbergeordnete GUI dargestellt, ohne dass irgendetwas kopiert oder modifiziert werden muss. Ohne GUI steht eine Standard-Oberfl\u00e4che mit Zugriff auf alle Variablen, IO-Werten und animierten Statemachines zur Verf\u00fcgung.<\/p>\n Bei beiden Werkzeugen basieren die eingebauten Debugging-M\u00f6glichkeiten auf der Kommunikation mit einem externen Rechner.<\/p>\n radCASE greift zum Debugging auf die umfangreichen GUI-Funktionen mit triggerbare Record\/Replay-Funktion zur\u00fcck. Diese Funktion l\u00e4uft vollst\u00e4ndig auf dem PC. Fehlersituationen lassen sich gezielt einkreisen.<\/p>\n QP bedient sich eine Zusatzpaketes namens QSpy, das auf dem Target Events und Zustands\u00fcberg\u00e4nge an einen mit einem QSpy-Client ausgestatteten PC meldet. Es lassen sich benutzerdefinierte Ausgaben einf\u00fcgen. Das Ganze wird von dem Client lesbar mit Timestamps ausgegeben. Dieser Trace l\u00e4sst sich zur Compilezeit nach diversen Kriterien filtern. Trotzdem ist die Analyse aufgrund der immer noch immensen Datenmengen aufw\u00e4ndig.<\/p>\n radCASE verwendet dazu „Bibliotheken“, die typischerweise Typ- oder Klassendefinitionen enthalten. Bibliotheken werden per „include“ eingebunden.<\/p>\n QP\/QM bietet die M\u00f6glichkeit, ein Package in ein „External Package“ auszulagern. Die kleinste auszulagernde Einheit ist damit ein Package.<\/p>\n QP\/QM zeigt sich als auf Geschwindigkeit optimierte Umgebung – vollst\u00e4ndig, aber ohne viel Zusatzkomfort. radCASE hat lediglich polled Statemachines, weist aber diverse komfortable Funktionen auf, die einen Entwicklungsprozess stark vereinfachen k\u00f6nnen.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nMBSE? – MBSE!<\/h2>\n
Konventionell – Modellbasiert<\/h2>\n
Vom Editor zum Modellierungswerkzeug<\/h2>\n
Gemeinsamkeiten<\/h2>\n
\n
Detaillierter Vergleich der „Gemeinsamkeiten“<\/h2>\n
Wie spricht die Software mit der Hardware?<\/h2>\n
\nJedes Objekt muss auf eine maximale Zahl von Instanzen ausgelegt sein. Anhand einer Instanznummer wird der Zugriff auf physikalische Ressourcen unterschieden. Eine Hardware\u00e4nderung hat auch eine SW-\u00c4nderung zur Folge.<\/p>\nWie arbeiten die Statemachines?<\/h2>\n
Objektorientierung<\/h2>\n
Tasking<\/h2>\n
GUI<\/h2>\n
\nQP\/QM setzt da auf die M\u00f6glichkeiten von VC++ mit einer C-API zur Anbindung an die Targetsoftware. Auf diese Weise l\u00e4sst sich die komplette Zielhardware simulieren, mit Anzeige von Variablen, Ausg\u00e4ngen und Ansteuerung von Eing\u00e4ngen. Anhand der Simulation l\u00e4sst sich die Applikation austesten.<\/p>\nDebugging<\/h2>\n
St\u00fcckelung<\/h2>\n
Fazit<\/h2>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n