Eingebettete Software entwerfen

Ich beginne mit der Programmierung eingebetteter Software mit einem RTOS und da ich bereits Entwickler für Desktop-Anwendungen bin, habe ich mich immer wieder gefragt, wie es ist, eingebettete Software mit UML-Diagrammen wie Aktivitätsdiagrammen, Sequenzdiagrammen, Anwendungsfällen usw. zu modellieren.

Wird eingebettete Software mit UML entworfen, so wie es Desktop-Anwendungen tun? Ist es die beste Option oder gibt es eine bessere? Kann ich einige Beispiele haben?

Gibt es dafür ein spezielles Tool?

Es gibt absolut nichts Spezifisches über eingebettete Anwendungen. Das Besondere sind ressourcenbeschränkte Anwendungen , die häufigsten dieser Beschränkungen sind Zeitbeschränkungen, zum Beispiel harte Echtzeitanforderungen. Wenn Sie uns mehr über die Anforderungen für Ihre Anwendung mitteilen, können wir Ihnen möglicherweise eine konkrete Antwort geben.
Ich stimme den Kommentaren von @Wouter zu ressourcenbeschränkten Anwendungen voll und ganz zu, aber ich glaube, dass es spezifische Designnuancen gibt, die mit der Verwendung eines RTOS im Vergleich zu einer Desktop-Entwicklungsumgebung mit weichem Zeitplan verbunden sind, in der das Blockieren von Anrufen eine akzeptierte Praxis ist.
Danke @WoutervanOoijen und @DeanB. Ich werde an der Entwicklung der eingebetteten Software für einen Universitätssatelliten mitwirken. Und da ich gerade erst in diesem Bereich anfange, wollte ich wissen, wie es ist, eine Software zu modellieren, die nicht objektorientiert ist (das ist in diesem Fall C) und auch ihre Architektur (ich bin an TAM-Blockdiagramme gewöhnt - Technische Architekturmodellierung, von SAP). Ist UML angemessen, da es sich um einen objektorientierten Standard handelt?
Hüten Sie sich vor Overengineering eingebetteter Systeme. Siehe auch „Der Toaster des Königs“ ee.ryerson.ca/~elf/hack/ktoast.html
@drxzcl - Stimme nicht zu. Erstens glaube ich nicht, dass man beim Entwerfen von weltraumtauglicher Software zu viel Sorgfalt walten lassen kann. Zweitens ist die Herangehensweise des Engineers an den Toaster des Königs der Grund, warum so viel Brot verbrannt wird. Die meisten Toaster sind zu einfach für eine eigentlich nicht triviale Aufgabe.
@Rocketmagnet: Ich muss zugeben, ich habe teilweise nur auf einen guten Grund gewartet, um die Toaster-Geschichte zu teilen. Ich stimme zu, dass das Schreiben eingebetteter Software Sorgfalt erfordert, aber meiner Erfahrung nach ist es eine ganz andere Art von Sorgfalt als bei Unternehmenssoftware. Ich bin mir nicht sicher, ob zB UML auch das Richtige für den Job hier ist.
@drxzcl Danke für deine Antwort. Können Sie bitte mitteilen, was in dieser Situation ein Werkzeug wäre, wenn nicht UML?
@Cassio: Ich bin da mit Wouter zusammen. Sie müssen das Problem selbst analysieren und dann die wichtigen Teile mit einem System darstellen, das Sie für angemessen halten. Das Problem bei der Auswahl einer Darstellung vor der Analyse des Problems besteht darin, dass Sie das Problem auf eine bestimmte Weise sehen. UML ist eine Darstellung, die ihre Wurzeln in Unternehmenssoftware hat, und Sie sollten sich nicht dazu verleiten lassen, eingebettete Software wie Unternehmenssoftware zu entwerfen.
@Cassio: Unternehmenssoftware definiert üblicherweise eine große Anzahl interner Abstraktionsschichten. Dies ist wahrscheinlich eine gute Sache für diese Aufgabe, da es Anforderungsänderungen antizipiert und es einer großen Anzahl relativ unerfahrener Programmierer ermöglicht, gleichzeitig mit relativ geringem Kommunikationsaufwand an derselben Software zu arbeiten. In einer Umgebung, in der jeder Zeiger ein Wort Ihres wertvollen 32-KB-Speichers verbraucht und jeder Funktionsaufruf Ihren Stack auffrisst, sind die Dinge jedoch anders. UML als Repräsentation konzentriert sich auf diese internen Abstraktionen und lockt Sie in diese Denkweise.

Antworten (4)

Es gibt Echtzeit-Erweiterungen für UML, die von einer Firma populär gemacht wurden, deren Name mir im Moment nicht bekannt ist. Ich erinnere mich, dass ich vor einigen Jahren eine Arbeit darüber geschrieben habe. Bruce Powell Douglass hat einige Bücher zum Thema Modellierung eingebetteter Systeme mit UML geschrieben, aber seine Firma ist nicht diejenige, an die ich denke.

Allerdings, um Wouter zu wiederholen, ist eingebettete Software an sich nichts Besonderes. Ich schreibe jeden Tag eingebettete Software für ein System, das auf Prozessoren der Pentium-Klasse läuft; UML ist durchaus anwendbar. Denken Sie auch daran, dass UML im Laufe der Zeit viele Aspekte der Steuerungssoftware hinzugefügt wurden: Es gibt eine Syntax zur Angabe synchroner oder asynchroner Ereignisse zusammen mit der Reaktionszeit in Sequenzdiagrammen, Petrinetz-artiges Verhalten kann in Aktivitätsdiagrammen gefunden werden, Zustandsdiagramme modellieren das Verhalten sogar noch besser als Zustandsdiagramme können usw.

OTOH, viele Leute ziehen es vor, eingebettete Software mit strukturiertem Design und Datenflusskonzepten zu modellieren. Es dreht sich alles um die Art des Systems, das Sie entwerfen und was am besten funktioniert.

Danke @lyndon. Aber wie modelliert man eingebettete Software im Alltag? Glauben Sie, dass Aktivitätsdiagramme, Zustandsmaschinen und Sequenzdiagramme ausreichen würden? Ich suche eigentlich nach dem Konzept, was zu entwerfen ist, und nach welchen Schaltplänen, die in das Designdokument eingefügt werden sollen, falls es eines für eingebettete Systeme gibt.
Die häufigsten Konstrukte, die ich sehe, sind Zustandsdiagramme/Zustandsdiagramme und Sequenzdiagramme für den täglichen Gebrauch. Ich denke wirklich, dass wir mehr Nutzen aus Klassendiagrammen ziehen könnten, aber ich finde, dass die Leute dazu neigen, einfach riesige „Gott-Objekte“ zu erstellen. Oh: Die Firma, an die ich dachte, ist Artisan Software. Dieser Link kann informativ sein: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

Wenn wir uns einem RTOS zuwenden, haben wir es normalerweise mit einer Anwendung zu tun, die viele gleichzeitige Aufgaben hat, die optimal geplant werden müssen, damit jede von ihnen ihre Fristen pünktlich einhält oder Ressourcen sicher teilt. Das von Ihnen gewählte RTOS-Framework implementiert einen Aufgabenplaner, und Ihre Aufgabe besteht (normalerweise) darin, diese einzelnen Aufgaben mit einem bestimmten Satz von Eigenschaften (Zeitraum, Priorität usw.) zu schreiben und sie dann an den Planer zu übergeben. Für die Dokumentation wäre der Ansatz, den ich wählen würde, jede Aufgabe sorgfältig zu dokumentieren.

Die meiste eingebettete Software und, soweit ich weiß, die meisten Echtzeitbetriebssysteme sind nicht in einer objektorientierten Sprache geschrieben und profitieren daher möglicherweise nicht von vielen Dingen, die darauf ausgerichtet sind, wie zum Beispiel Klassendiagramme.

Beim Dokumentieren Ihrer RTOS-Aufgaben wäre jedoch jedes Diagramm, das die Aufgabe gut beschreibt, von großem Vorteil. Ich könnte mir vorstellen, dass zum Beispiel ein Sequenzdiagramm für jede Aufgabe sehr hilfreich sein könnte. Darüber hinaus könnten Sie seine harten Anforderungen wie Zeitraum/Häufigkeit, Priorität, alle gemeinsam genutzten Ressourcen, die es möglicherweise verwendet, Präemptionsanforderungen usw. Maschine seines Planungsalgorithmus.

Nehmen Sie jeden dieser Ratschläge, wie Sie möchten, ich habe seit meiner College-Zeit nicht mehr mit RTOS-Sachen herumgespielt und die Arbeit nie wirklich "dokumentiert".

Danke @JonL. Um also ein schönes Designdokument zu haben, müsste ich nur die Aufgaben entwerfen, die mit meiner Anwendung verbunden sind? Außerdem bin ich mit einem Planungsalgorithmus nicht sehr vertraut, ich musste mich nie damit befassen. Ich verwende RTEMS.
@Cassio, ich sage dir nicht, dass du das eine oder andere tun sollst, das liegt wirklich an dir. Versuchen Sie einfach, das Notwendige zu tun. Wenn Sie mit Ihrem RTOS nicht vertraut sind, wäre es meiner Meinung nach ein guter Anfang, zuerst damit anzufangen und zu wissen, wie Sie es verwenden sollen. Dann können Sie damit beginnen, Ihre Aufgaben darum herum zu gestalten.
Ja, ich mache mich immer noch mit den RTOS-Funktionen vertraut. Und danke für die vorgeschlagene Vorgehensweise! Werde es tun! Und wie ich bereits sagte, ich bin neu in der eingebetteten Software, ich bin mir nicht wirklich sicher, was notwendig ist. Es wäre schön, eine eingebettete Softwarearchitektur oder ein Designdokument zu haben. Hättest du so einen?
"Die meisten Echtzeitbetriebssysteme sind nicht in einer objektorientierten Sprache geschrieben" In der Tat. Aber für einen Kurs in Echtzeitmodellierung und -implementierung verwenden wir ein einfaches (nicht präemptives) RTOS in C++.

Beim Modeln dreht sich alles um

  • wissen, was in Ihrer Anwendung schwierig und komplex ist,

  • Finden eines Modellierungswerkzeugs/einer Sprache/Abstraktion/Konvention/Notation, die für diesen Aspekt geeignet ist

  • diesen Aspekt zu entwerfen

Daher ist kein Modellierungswerkzeug/Ansatz/etc. für alle Situationen geeignet. Ein Satellit wird wahrscheinlich ein Echtzeit-Multitasking-System sein, wahrscheinlich mit mehr als einem Prozessor. Aufgabenstrukturdiagramme, STDs und Sequenzdiagramme sind wahrscheinlich nützlich (um nur einige zu nennen). Wenn das Projekt in C durchgeführt wird, ist ein Klassendiagramm wahrscheinlich weniger nützlich (wenn es sich als sehr nützlich herausstellt, war die Wahl für C wahrscheinlich falsch). Ich bin kein großer Freund von UseCases, und ein Satellit hat an-sich keinen Benutzer. Anwendungsfälle eignen sich am besten in einer Situation, in der Sie die Anforderungen für Ihr System mit einem technisch nicht versierten Benutzer besprechen möchten. Wenn dies die Situation ist, in der Sie sich bei einem Satellitenprojekt befinden, ist etwas schief gelaufen.

Danke @Wouter. Sie haben ein neues Konzept für mich eingeführt: Aufgabenstrukturdiagramme, schön! Also in C. Was hätten Sie für ein Dokument mit allen Anforderungen, wenn nicht UseCases?
IMO benötigen Sie eine Liste identifizierbarer, mehr oder weniger Single-Issuse-Anforderungen, und sei es nur, um Ihre Testfälle darauf aufzubauen. UseCases sind für mich nur eine Methode, um an eine solche Liste zu kommen. In manchen Fällen eine gute Methode.

Ich habe nichts entworfen, was weltraumtauglich ist. Aber ich habe für einen Luft- und Raumfahrtzulieferer des Verteidigungsministeriums (DoD) gearbeitet, und viele meiner Entwürfe waren flugqualifiziert. Sie verlangen eine Menge Dokumentation zu Ihren Entwürfen und stellen Data Item Descriptions (DIDs) zur Verfügung, die genau das beschreiben, was sie sehen möchten.

Sie können die DoD ASSIST-Schnellsuche verwenden , um alle DIDs für die möglicherweise erforderlichen Dokumente anzuzeigen, wenn Sie „Software“ in das Feld „Wort(e) im Titel“ eingeben und auf „Senden“ klicken. (Ich finde es lustig, dass eine DoD-Site eine Zertifikatssicherheitswarnung ausgibt, aber ich versichere Ihnen, es ist sicher).

Da Sie speziell nach einem Designdokument fragen, ist hier die Software Design Description (SDD) DID. Sie betonen die Verwendung von Wörtern, um jeden Teil des Designs zu beschreiben. Aber wenn die Verwendung von UML, Zustandsdiagrammen, Flussdiagrammen, Pseudocode usw. das Verständnis des Designs verbessern kann, möchten sie natürlich, dass Sie es einbeziehen.

Welche Modellierungsmethode Sie wählen, hängt, wie andere bereits gesagt haben, von Ihrem Design ab. Aber ich dachte, dass das Sehen einer DID für Luft- und Raumfahrtsoftware Ihnen beim Schreiben Ihres Designdokuments helfen könnte, da Ihr Projekt weltraumbezogen ist.

Eingebettete Software entwerfen
AntwortenHierDatenschutz-Bestimmungen1y, 0v