Hallo,
aktuell befasse ich mich mit SysML und UML für Embedded, aber ich finde
es sehr schwierig. Was mir schwer fällt ist:
- Tool_Abhängigkeit, je nach Tool ist vieles anders.
- Man kann mit unterschiedlichen Diagrammen modellieren und es
unterschiedlich verstehen, man muss es in einem Prozess selbst
definieren.
- Zusammenhänge zwischen Modellteilen sind schwer zu modellieren,
besonders am Hardware/Software-Übergang.
- Tracing zur Hardware(Schaltplan) und Software(C-Code)schwierig.
Insgesamt habe ich mich gefragt ob eine "formale Sprache" nicht deutlich
einfacher ist, weil die klarer definiert ist. SysML/UML, für einige
Themen wie I2C-Bus, hab ich noch keine klare Antwort gefunden. Mir Kommt
SysML/UML so „Bla Bla“-Mäßig vor, aber ich bin auch von VHDL, etc. stark
geprägt. Ich hab mich auch gefragt ob sich der Aufwand, gemessen am
Ergebnis/Nutzen, wirklich lohnt, oder ober man mit formalen Sprachen zur
Systembeschreibung (SDL, Z-Notation,.. vielleicht sogar VHDL) mehr für
die investierte Arbeit bekommt.
Modelliert ihr euer Embedded-Systeme, wenn ja was, und wie? ich wäre
über ein paar Tips sehr dankbar.
Vielen Dank,
Grüße
Sebastian
Hallo Sebastian,
warum willst du UML machen? Zwingt dich da wer zu?
Ich sehe ehrlich gesagt UML als einen hinderlichen akademischen Mist an,
frei nach dem Motto: Wir stehn uns selber im Weg und kommen nicht vom
Fleck.
Das Problem ist, dass man in UML Ideen auf viele erdenklichen Arten
ausformulieren kann, es aber kaum eine einheitliche Möglichkeit einer
Simulation - geschweige denn Cosimulation - gibt, im Gegensatz zu VHDL.
Für embedded Design finde ich SysML sinnlos über-skaliert.
Für generische Modellierung (Software/Hardware/Analogmodelle) setzen wir
gerne Python (Cocotb, MyHDL, gnuplot, usw.) ein. Für sowas wie i2c lässt
sich relativ schnell eine robuste Testbench aufbauen. Wenn du richtig
Hardware designen willst (SoC) gibt es IP-XACT zur Modellierung
komplexer Peripherie und Bus-Systeme wie auch Hardware-Register. Auf
einer der letzten Embedded World in Nürnberg hat jemand eine Lösung
demonstriert, bei der ein kompletter Prozessor aus XML erzeugt wird,
offenbar mit OpenSource-Tools. Fällt mir nur gerade nicht mehr ein...
Für mich machen die ganzen *ML nur Sinn, wenn man daraus ohne grossen
Aufwand synthetisierbaren/compilierbaren Code erzeugen kann und sich so
seinen Workflow selbst automatisiert. Alle anderen Ansätze des
grafischen Programmierens haben sich betreffend
Teamwork/Effektivität/Wiederverwertbarkeit m.W. nie gerechnet.
Hallo,
tja, ich denk dass UML und SysML ihren Platz haben, UML passt gut zur
objektorientierten Welt, Server-Anlagen,… und man kann es auch für
Embedded verwenden. Man sollte ja schon ein System-Design machen,
klassisches V, mit Dokumenten, Nachweisen, Anforderungen, Tests, usw. .
Um es effizienter zu machen eignet sich vielleicht ein Tooling. Und so
kam man auf SysML/UML.
Bisher hab ich das in OpenOffice-Draw mit "Kästchen gezeichnet", in ein
Dokument, etwas Pseudo-VHDL, Mathematische Ausdrücke,… rein und fertig.
Die Software-Doku habe ich mit Doxygen generiert, dazu habe ich die
Bilder(UML) aus den Open-Office-Draw Zeichnungen, exportiert, ins
Code-Repository Committed, damit das bezüglich der Versionen zusammen
passt und die UML-Bilder in die Doxygen-Kommentare eingebettet. Außerdem
verwende ich GraphViz für Abhängigkeiten, CallGraphen,… . Das Linking zu
den Anforderungen hab ich durch einfache Kommentare mit HTML-Tags
gelöst, da haben wir DOORS im Einsatz. Ja ich weiß, man kann es
professioneller machen, das Ergebnis ist aber, gemessen am Aufwand
relativ gut. Tracability funktioniert eben nur manuell bzw. men muss mit
einem Script über den Code suchen wo das die Anforderung auftaucht, aber
ok, das ist vertretbar.
Ich tu mir jetzt eben sehr schwer das was ich mit „Low-Tech“ Methoden
locker hin bekommen hab, mit einem „professionellen UML-Tool“ zu machen.
Code generieren geht für Embedded-Software nur bedingt, man muss dem
generator vertrauen, oder man macht ausführliche Back-to-Back Tests, etc
. .
Vor allem für die Software-Grenze zur Hardware, da klemmt es. Aber auch
Static-Variablen aus einem C-File in einem
Control-Flow(UML-Aktivitätsdiagramm) verwenden, mag das Magic-Draw
UML-Tool nicht recht unterstützen. Bzw. was raus kommt ist kaum besser
als mein „OO-Draw Geschmiere“ weil es dann nur „Text“ ist, oder ich muss
jede Variable als Objekt anlegen,… . Ich hab frustriert festgestellt,
dass wir aktuell mit unserem „Low-Tech-Ansatz“ relativ gut sind und wir
den „Tool-Overhead“ nicht hatten. Ich sag immer, wir arbeiten wie die
Russen: „Weißes Blatt Papier, Bleistift, Radierer“, SysML/UML scheint
mir bei einer Gegenüberstellung der Vor- und Nachteile kaum besser zu
sein.
Grüße
Sebastian
also wie es aussieht macht es zum Beispiel CONTINENTAL seit 10 Jahren...
http://mesconf.de/programm/#as
könnte natürlich auch sein, dass die da von eingebetteten Systemen keine
Ahnung haben <<sarkasmuss>>
Gruß BT
Seastian schrieb:> - Tracing zur Hardware(Schaltplan) und Software(C-Code)schwierig.
Das Tracing erfolgt gegenüber den Anforderungen. Das Testen ebenso. Im
Grunde genommen richtet sich einfach alles nach den Anforderungen. Die
wird man nicht alleine mit UML-Diagrammen modellieren können; es wird
immer auch Text im Spiel sein. Je nach System eine riesengroße Menge an
Text.
UML kann hilfreich sein, um eine große Menge von Anforderungen
zusammenzuhalten. Die einzelne Anforderung besteht wie erwähnt aus
Prosa-Text. Wenn man nun aber sehr viele Anforderungen hat, wie will man
da den Überblick behalten?
Neben einer vernünftigen Aufteilung des Systems in Subsysteme und einer
vernünftigen Klassifizierung der Anwendungsfälle bieten sich hier die
UML-Diagramme geradezu an. Man kann hier schön zum Beispiel einen
Zustandsübergang des Systems grafisch darstellen, oder eine Sequenz von
Nachrichten die übertragen wird, welche Fallunterscheidungen bei der
Funktionalität XYZ gemacht werden müssen, und so weiter.
Tracing von Requirements zu Code:
Es hindert niemand die Programmierer daran, im Code und/oder in den
Commits Kommentare mit der Requirement ID zu hinterlassen. Machen sie
nur oft nicht, die faulen Schweine. ;-)
Seastian schrieb:> SysML/UML, für einige Themen wie I2C-Bus, hab ich noch keine klare Antwort> gefunden.
Wo genau ist das Problem? Beschreibe die Teilnehmer der Kommunikation
und die Informationen, die sie miteinander austauschen sollen. Für
Ersteres ist ein Blockschaltbild hilfreich. Für Letzteres kann eine
Tabelle geeignet sein. In den einzelnen Spalten können Informationen
stehen wie: Wer ist der Sender, wer ist der Empfänger, welche
Information wird übertragen (oftmals eine physikalische Größe), in
welchem Format wird die Information übertragen.
Ob man nun mit Hilfe von UML spezifiziert oder nicht:
Das Ziel ist immer, dass auch derjenige die Spezifikation verstehen
kann, der sie nicht geschrieben hat. Dann hat man den Job richtig
gemacht.
