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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.