Entwerfen eingebetteter Software


11

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

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

Gibt es ein bestimmtes Tool, das dies tut?


8
Embedded-Anwendungen sind absolut nicht spezifisch. Das Besondere sind ressourcenbeschränkte Anwendungen . Die häufigsten dieser Einschränkungen sind zeitliche Einschränkungen, beispielsweise harte Echtzeitanforderungen. Wenn Sie uns mehr über die Anforderungen für Ihre Bewerbung erzählen, können wir Ihnen möglicherweise eine konkrete Antwort geben.
Wouter van Ooijen

3
Ich stimme den Kommentaren von @ Wouter zu Anwendungen mit eingeschränkten Ressourcen voll und ganz zu, glaube jedoch, dass die Verwendung eines RTOS im Vergleich zu einer Soft-Scheduled-Desktop-Entwicklungsumgebung, in der das Blockieren von Anrufen eine akzeptierte Praxis ist, bestimmte Designnuancen aufweist.
HikeOnPast

1
Achten Sie auf die Überentwicklung eingebetteter Systeme. Siehe auch "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html
drxzcl

2
@drxzcl - Nicht einverstanden. Erstens glaube ich nicht, dass Sie beim Entwerfen von platzqualifizierter Software zu vorsichtig sein können . Zweitens ist die Annäherung des Ingenieurs an den King's Toaster der Grund, warum so viel Brot verbrannt wird. Die meisten Toaster sind zu einfach für einen eigentlich nicht trivialen Job.
Raketenmagnet

1
@Cassio: Ich bin mit Wouter in diesem Fall. Sie müssen das Problem selbst analysieren und dann die wichtigen Teile mit einem System abbilden, 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 bestimmte Weise nicht mehr sehen können. UML ist eine Darstellung, die ihre Wurzeln in Unternehmenssoftware hat, und Sie möchten nicht dazu verleitet werden, eingebettete Software wie Unternehmenssoftware zu entwerfen.
drxzcl

Antworten:


8

Es gibt Echtzeit-Erweiterungen für UML, die von einem Unternehmen populär gemacht wurden, dessen Name mir im Moment entgeht. Ich erinnere mich, dass ich vor einigen Jahren ein Papier darüber geschrieben habe. Bruce Powell Douglass hat einige Bücher zum Thema Modellierung eingebetteter Systeme mit UML geschrieben, aber sein Unternehmen ist nicht das, an das ich denke.

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 für die Angabe synchroner oder asynchroner Ereignisse sowie die Antwortzeit in Sequenzdiagrammen. Das Verhalten des Petri-Netz-Typs ist in Aktivitätsdiagrammen und im Verhalten von Statecharts-Modellen noch besser zu finden als Zustandsdiagramme können, etc.

OTOH, viele Leute bevorzugen es, eingebettete Software mithilfe von strukturierten Design- und Datenflusskonzepten zu modellieren. Es geht um die Art des Systems, das Sie entwerfen, und darum, was am besten funktioniert.


Danke @lyndon. Aber wie modelliert man eingebettete Software jeden Tag? Glauben Sie, dass Aktivitätsdiagramme, Zustandsmaschinen und Sequenzdiagramme den Trick machen würden? Ich bin auf der Suche nach dem Konzept, was zu entwerfen ist, und nach welchen Schemata, die in das Designdokument eingefügt werden müssen, falls es eines für eingebettete Systeme gibt.
Cassio

Die häufigsten Konstrukte, die ich sehe, sind Zustandsdiagramme / Zustandsdiagramme und Sequenzdiagramme für den täglichen Gebrauch. Ich denke ehrlich, wir könnten Klassendiagramme besser nutzen, aber ich finde, dass Menschen dazu neigen, nur massive "Gottobjekte" 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
Lyndon

5

Wenn wir uns an ein RTOS wenden, haben wir es normalerweise mit einer Anwendung zu tun, die viele gleichzeitige Aufgaben hat, die optimal geplant werden müssen, damit jeder von ihnen seine Fristen pünktlich einhält oder Ressourcen sicher teilt. Das von Ihnen ausgewählte RTOS-Framework implementiert einen Taskplaner. Ihre Aufgabe besteht (normalerweise) darin, diese einzelnen Aufgaben mit bestimmten Eigenschaften (Zeitraum, Priorität usw.) zu schreiben und dann an den Scheduler zu übergeben. Für die Dokumentation würde ich also jede Aufgabe sorgfältig dokumentieren.

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

Bei der Dokumentation Ihrer RTOS-Aufgaben wäre jedoch jedes Diagramm, das die Aufgabe gut beschreibt, von großem Vorteil. Ich würde mir vorstellen, dass ein Sequenzdiagramm für jede Aufgabe zum Beispiel sehr hilfreich sein könnte. Darüber hinaus können Sie die harten Anforderungen wie Zeitraum / Häufigkeit, Priorität, gemeinsam genutzte Ressourcen, Vorkaufsanforderungen usw. angeben. Sie können auch dokumentieren, wie Sie das RTOS konfiguriert haben, und möglicherweise einen Status. Maschine seines Planungsalgorithmus.

Nehmen Sie einen dieser Ratschläge an, wie Sie möchten. Ich habe mich seit meiner College-Zeit nicht mehr mit RTOS beschäftigt und die Arbeit nie wirklich "dokumentiert".


Danke @JonL. Um 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 muss mich nie damit befassen. Ich benutze RTEMS.
Cassio

@Cassio, ich sage dir nicht, dass du das eine oder andere tun sollst, das liegt wirklich bei dir. Versuchen Sie einfach, das Notwendige zu tun. Wenn Sie mit Ihrem RTOS nicht vertraut sind, ist es meiner Meinung nach ein guter Anfang, zuerst damit zu beginnen und wie Sie es verwenden sollen. Dann können Sie beginnen, Ihre Aufgaben darum herum zu entwerfen.
Jon L

Ja, ich bin immer noch mit den RTOS-Funktionen vertraut. Und danke für den vorgeschlagenen Ansatz! Werde es tun! Und wie ich bereits sagte, bin ich neu in der eingebetteten Software. Ich bin mir nicht sicher, was notwendig ist. Es wäre schön, eine eingebettete Softwarearchitektur oder ein Designdokument zu haben. Würdest du eine davon haben?
Cassio

"Die meisten RTOS sind nicht in einer objektorientierten Sprache geschrieben". Für einen Kurs in Echtzeitmodellierung und -implementierung verwenden wir jedoch ein einfaches (nicht präemptives) RTOS in C ++.
Wouter van Ooijen

5

Beim Modellieren dreht sich alles um

  • zu wissen, welcher Aspekt 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 / usw. 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 weniger nützlich (wenn es sich als sehr nützlich herausstellt, war die Wahl für C wahrscheinlich falsch). Ich mag UseCases nicht sehr und ein Satellit an-sich hat keinen Benutzer. Anwendungsfälle sind am besten geeignet, wenn Sie die Anforderungen für Ihr System mit einem nicht technischen Benutzer besprechen möchten. Wenn dies die Situation ist, in der Sie sich mit einem Satellitenprojekt befinden, ist ein Fehler aufgetreten.


Danke @Wouter. Sie haben ein neues Konzept für mich eingeführt: Aufgabenstrukturdiagramme, schön! Es ist also in C. Was hätten Sie für ein Dokument mit allen Anforderungen, wenn nicht UseCases?
Cassio

IMO benötigen Sie eine Liste identifizierbarer, mehr oder weniger einzelner Anforderungen, schon allein, um Ihre Testfälle darauf zu stützen. UseCases sind für mich nur eine Methode, um zu einer solchen Liste zu gelangen. In einigen Fällen eine gute Methode.
Wouter van Ooijen

1

Ich habe nichts für den Weltraum qualifiziertes entworfen. Aber ich habe für einen Subunternehmer des Verteidigungsministeriums (DoD) für Luft- und Raumfahrt gearbeitet und viele meiner Entwürfe waren flugqualifiziert. Sie erfordern viel Dokumentation zu Ihren Entwürfen und bieten Data Item Descriptions (DIDs), die genau beschreiben, was sie sehen möchten.

Sie können die DoD ASSIST-Schnellsuche verwenden , um alle DIDs für die Dokumente anzuzeigen, die möglicherweise erforderlich sind, wenn Sie "Software" in das Feld "Word (s) In Title" eingeben und auf "Submit" klicken. (Ich finde es lustig, dass eine DoD-Site eine Sicherheitswarnung für Zertifikate auslöst, aber ich versichere Ihnen, es ist sicher).

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

Welche Modellierungsmethode Sie wählen, hängt, wie andere angegeben haben, von Ihrem Design ab. Ich dachte jedoch, dass das Anzeigen einer DID für Luft- und Raumfahrtsoftware Ihnen beim Schreiben Ihres Konstruktionsdokuments helfen könnte, da Ihr Projekt platzbezogen ist.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.