embedded power for your project embedded power for your project

| Home | Services | Software | Support | Contact |

 Embedded Prozessor
   8-Bit Prozessoren
   16-Bit Prozessoren
   32-Bit Prozessoren
   64-Bit Prozessoren
   ARM
   DSPs
   FPGA
   Intel
   MIPS
   PowerPC
 Tool Information
   BDM/JTAG tool
   Emulator
   Hardware design
   Logikanalysator
   Eval Boards
   Simulator
   Compiler
   Real Time OS
   Software Tools
   Debugger
 Services
   Consulting
   Support
   Verkauf
   Links
   Literatur

Automotive Embedded Software Information

"Gegen das Chaos in der Automobilsoftware .."

AUTOSAR ist die aktuelle automobile Software-Initiative die sich der allmächtigen Komplexität der verteilten Datenverarbeitung im KraftFahrzeug annimmt, und es wird wohl nicht die letzte sein denn wieder gelingt es nur Teilaspekte in den Griff zu bekommen und gewisse Technologien entwickeln sich unterhalb des Abstandsradars. So wurden alle deutschen Hersteller von der MP3-Welle kalt erwischt, mal sehen was als nächstes kommt. Das Herumgegackere um Hybrid-Fahrzeuge hat mit einem gemäßigterem Dollar-Ölpreis wohl vorerst ein Ende, hier in Europa bringt der zusätzliche Elektromotor kaum mehr als etwas Prestige, aber keine wirkliche Treibstoffersparniss.

Zurück zur Software: UML oder Domänenspezifische Ansätze zur Lösung des gordischen Knotens Komplexität???

Von den entsprechenden Tool-Anbietern werden viele Fallstudien zur erfolgreichen Anwendung von Code-Generierung Werkzeugen und Technologien in das Internet gestellt, um in der Komplexität versinkenden Projekten einen Weg aus der Krise zu weisen. Diese Tools erlauben den Anwendern die vereinfachte Handhabung höherer Abstraktionsniveaus. Dabei gibt es verschiedene Ansätze zur Hebung des Abstraktionsniveaus, in der Vergangenheit waren dies Software Engineering Frameworks, oder auch fortgeschrittene Programmiersprachen. Die heute oft beworbene Code-Generierung ist flexibel und schnell, und kann an neue Bedingungen und Umgebungen angepasst werden.
Betrachten wir die beiden populären Philosophien zur Code-Generierung: UML, um Programme zu modellieren [als Teil des OMG Model Driven Architecture (MDA) Ansatzes], und Domänenspezifische Sprachen (DSL - Domain-Specific Language) - eigenständige kleine Sprachen die zur Modellierung eines spezifischen Problems geschaffen wurden. Es folgt eine kleine Einführung wie auch einige Hinweise zu Vor- und Nachteilen beim Einsatz im Produktivbetrieb.
UML und MDA Als Modellierungssprache ist UML dank Standardisierung weit verbreitet und so wird UML auch häufig genutzt um System-Anforderungen auszudrücken und viele Firmen generieren daraus akzeptablen Basiscode. Code Generierung in UML meinte ursprünglich ein sehr einfache Umformung - die Konvertierung von Diagramm-Klassen in C- or Java-Klassen. Die Erfahrung hat gezeigt das dieses Niveau der Generierung kaum für die Generierung kompletter Embedded Systeme nützlich ist. Immerhin ist es durch spezielle oder abstrahierte Modell-Elemente möglich, den Schieber etwas in Richtung "vollständige Generierung" zu bewegen, aber immer noch kommt bestenfalls ein Rahmen dabei heraus, in den schlimmstenfalls händisch Code eingefügt wird, um das System letztendlich zum gewünschten Verhalten zu bringen.
Dieser UML-basierte Ansatz wurde 2001 durch OMG als Teil ihres MDA-Standards herangezogen. Model Driven Architecture (http://www.omg.org/mda/) wurde entwickelt damit Firmen ihre Software-Investition bei sich verändernden Technologie-Platformen (Frameworks, OS, Architekturen ..) schützen können. Wenn eine Implementierung Platform-abhängig ist dann bedeutete der Wechsel der Platform einen erheblichen Aufwand zur Anpassung der Software. MDA bietet einen Weg, um die Spezifikation von Systemfunktionalität von der Implementierung auf einer bestimmten Technologieplatform zu trennen: Die Spezifikation der Systemfunktionalität ist ein Platform-unabhängiges Modell (Platform Independent Model - PIM); die Spezfikation auf einer bestimmten Platform ist ein Platform-Spezifisches-Modell - PSM. Die PSM kann von Entwicklern ergänzt werden, um Hinweise für die endgültige Code-Generierung zu enthalten.
Damit dieser Ansatz gewinnbringend genutzt werden kann, muss die PIM über verschiedene Platformen hinweg nutzbar sein, ob dies nun verschiedene Betriebssysteme, Programmiersprachen oder Entwicklungsumgebungen sind. Dies hat zwei Konsequenzen: zum Ersten werden die Modelle vorrangige Artefakte im Entwicklungsprozess, zum anderen wird die Code-Generierung wichtig, denn das händische Mapping der PIM zur PSM ist teuer und fehlerträchtig. Ein automatisches Mapping wäre im Falle eines Platformwechsels von Vorteil.
Seit 2007 definiert MDA eine Reihe Standards zur Transformation von Modellen. Diese Standards werden schon in den Sektoren Telecom und Defence unterstützt, wo es eine Tradition eigener Entwicklungswerkzeuge als Teil großer Projekte gibt. In unser oft aus einfachen Verhältnissen kommenden Embbedded Entwicklung führten die fehlenden Standards zum Model Driven Ansatz (MDD - development, MDE - engineering etc.) mit einer Vielzahl Tools um UML Modelle in brauchbare Systeme umzuformen - "pragmatisches MDA" wäre eine passende Bezeichnung.
Aber MDA ist kein Wunderheilmittel. Zunächst ist da die detailierte Beschreibung der Funktionslogik. Zwar können 90-95% der Software von betrieblich genutzten Informationssystemen aus UML Modellen generiert werden, aber es gibt einen Punkt wo die Funktionslogik nicht mehr generisch erfassbar ist und somit nicht aus UML generierbar wird. Es gibt zwei Ansätze, diese Limitierung zu umgehen:
Der "pure" Ansatz modelliert die spezielle Funktionslogik, eine der MDA-Spezifikationen befasst sich damit. Der "pragmatische" Ansatz läßt Löcher in der generierten Anwendung, zum Einsetzen von handgeschriebener Funktionslogik; dies ist sehr populär in Bereichen für die es eine standardisierte umfangreiche Entwicklungsumgebung gibt wie zum Beispiel Java oder C# und .NET.
Ein weiteres Problem von UML ist der Klassenansatz und die lockere Semantik (oder Universalität, um es positiver auszudrücken): allgemeine Kritik an UML sagt daß es zu umfangreich und undeutlich ist. Dahinter steckt aber das die einzige Codegenerierung die Low-Level Umformung der Klassenkonstrukte ist - und damit UML keine abstrakteren oder spezialisierten Konzepte ausdrücken kann. Diese Kritik wird durch das UML "Profile" Feature umgangen. Die Hersteller von Toolketten für die "Pragmatische MDA" verwenden Profile, um UML für ihre Zwecke zurechtzuschneidern. So werden Profile definiert, die es den Entwicklern erlauben Modelle mit einer spezielleren Terminologie nebst entsprechenden Daten zu entwerfen. Obendrein haben fortschrittliche Tools eine eingebaute Validierung der UML Semantik. Etwa so wie ein C-Compiler der auch einen MISRA-check oder eine statische Codeanalyse durchführt. Und das Ergebnis ist eine domänenspezifische Untermenge von UML, kann man sagen.
UML Profile ergeben eine Ausdruckskraft wie die der domänenspezifischen Sprachen (DSL): stereotype Klassen gleichen der DSL Terminologie und stereotype Beziehungen sind die selben wie in der graphischen DSL Terminologie. In anderen Worten, beide Ansätze können Konzepte für alle Level von Abstraktion ausdrücken. Zwei Hauptprobleme ergeben sich nun wenn UML mit Profilen für eine neue Modellierungssprache genutzt wird: mit herkömmlichen UML Tools ist es schwierig ungebrauchte UML Semantik zu entfernen, oder UML für eine spezialisierte Verwendung zurechtzuschneidern, und alle Diagrammtypen haben Beschränkungen basierend auf der UML Semantik.
Eine Herausforderung ist es, eine grafische DSL für ein neues Middleware Produkt zu entwerfen. Der Knackpunkt ist die Modellierung von Methoden als Basis-Artefakte. In Theorie sollte dies mit Aktions-Diagrammen gehen, aber in der Praxis gibt es zu viele Schmutzeffekte die dieses mit sich bringt. Wie wir unten sehen werden, die DSLs werden von Grund auf gebaut, so hat der Modellierer keine irrelevante UML Semantik oder überflüssige Modell-Elemente zu beachten.
Trotzdem war die Definition eines High-Level UML Profils der beste Ansatz zur Realisierung von MDA. Ein neues Profil ist relativ billig. Das Marketing der Tools-Lieferanten verkauft dank der häufig vorhandenen UML Tools und dem Verständnis der Modellierung diese MDA Producte eher als Zubehör, denn als völlig neues Entwicklungs-Konzept.

Domänenspezifische Sprachen: Domain-Specific Languages (DSL)

Die Theorie und erste Tools für domänenspezifische Sprachen und Modellierung gibt es bereits einige Zeit, aber erst in den letzten Jahren gibt es vermehrt Interesse - zum Teil vielleicht auch weil Microsoft "DSL Tools for Visual Studio" in den Markt gebracht hat.
Wie schon angesprochen, DSLs sind kleine Sprachen um Konzepte direkt in speziellen Domänen zu modellieren. Diese Sprachen können auf Text, wie Programmiersprachen, oder grafisch orientiert sein. Unter jeder DSL gibt es einen domain-specific code generator der domain-specific models auf den entsprechenden Code abbildet.
Eine Möglichkeit sich den Gebrauch einer (grafischen) DSL vorzustellen ist eine Palette mit Kästchen und Linien um Konzepte und Beziehungen in einer speziellen Problem-Domäne zu beschreiben. Modellierung mit dieser Palette besteht aus der Auswahl der Konzepte und dem 'Malen' auf die Leinwand. Das 'Malen' verschiedener Linienarten zwischen diesen Konzepten kann verschiedene Beziehungen zwischen den Konzepten herstellen.
Ein Vorteil des DSL Ansatzes ist daß die Modellierungsumgebung ein Modell auf die spezielle Domäne einschränken und validieren kann, etwas was nicht mit UML Profilen gemacht werden kann. Tools-Unterstützung für die Definition der DSL und domänenspezifische Codegeneratoren sind zwar schon eine Weile erhältlich, aber viel weniger als die MDA-Toolketten, und es gibt kaum eine Handvoll Anbieter mit ausgereiften Produkten.
Deshalb haben viele Projekte den steinigen Weg beschritten, ihren eigenen Generator zu implementieren, mit wechselndem Erfolg, denn diese Aufgabe an sich ist schon sehr komplex. Aber die Lage ändert sich mit zunehmender DSL Unterstützung von Firmen wie MetaCase, Microsoft und vor allem als Bestandteil des Eclipse Modelling Framework. Diese Tools haben die Hemmschwelle für den Einsatz von DSLs erheblich gesenkt.

Was tun?

Beide prinzipielle Ansätze haben nun einiges an Studien, kommerziellen wie Open Source Tools, und Anerkennung in der Industrie auf ihrer Seite, bleibt die Frage: welchen Weg gehen solange der Geist der Entwickler noch frei für grundlegende Entscheidungen ist. In nicht wenigen Firmen werden Entwicklungsparadigmen wie "ANSI-C", "UML" oder gar "Microsoft-Technologien" vorgegeben, und dann wird es politisch schwierig überhaupt die eine oder andere "konkurrierende" Lösung anzuschauen, wiewohl das existierende ziemlich sicher früher oder später in eine Sackgasse führt.
Modellierung und Codegenerierung sind nur ein Teil des Software Life cycle, wenn auch ein wichtiger, und müssen mit dem Rest der Methoden und Prozesse in einer Firma zusammenpassen. Im Bereich des Echtzeit-System-Engineering wurde bereits intensiv an Modellierungsanforderungen gemäß den typischen Echtzeit-Einschränkungen gearbeitet, daraus entstand zum Beispiel SysML, ein UML-Derivat. Auch finden Entwickler oft keinen kostengünstigen Weg ihre eigenen UML Profile oder DSLs zu erzeugen, ohne auf vorheriger Arbeit aufzusetzen.
Wie oben geschildert, kann eine einfache DSL mit Hilfe von UML Profilen generiert werden und dies ist oft ein brauchbarer und relativ schneller Ansatz für einen ersten Code Generator. Doch kann die Vielfalt von UML vor allem Einsteiger in diese Technologie verwirren; um dies zu vermeiden tendieren Entwickler von Generatoren dazu, ihre eigenen DSLs zu bauen - entweder mit einem entsprechenden Tool oder nach einer Hauseigenen Methode.
Es ist auch oft so, daß bestimmte Software Systeme nur mit Hilfe verschiedener Modellierungsansätze oder Sprachen sowie geeigneten Code Generator für die verschiedenen Aspekte der Problemlösung realisiert werden können. So hält auch nichts den pragmatischen Systementwickler davon ab, einen gemischten Ansatz zu verfolgen, UML mit DSLs zu kombinieren und die Stärken jedes Ansatzes zu seinen Gunsten zu nutzen.
Wie sieht die Tendenz im Markt aus? Wir glauben daß UML basierte Tools - in ihrer jetzigen Form - über Zeit weniger populär werden als DSLs: DSLs addressieren direkter die konkret zu lösenden Probleme und sind einfacher zu nutzen. UML Tools werden auf der anderen Seite aber weiterentwickelt, und zum Beispiel eine nicht-UML Modellierungsumgebung einschließen. Solch ein Kombinationsprodukt wäre für viele existierende Kunden ein Grund, nicht nach weiteren Lösungsmöglichkeiten Aussschau zu halten.

Embedded Expert for your Embedded Software Design Process

| Home | Products | Services | Support | Impressum |

EmbeddedExpert 2008 - Alle Marken, Warenzeichen und Handelsnamen sind Eigentum der jeweiligen Inhaber.

© BK media systems 2002, 2016.

All trademarks and registered names are property of their respective owners. German law requires Impressum