In vorangegangenen Blogbeiträgen habe ich zwei wesentliche Komponenten einer einfachen und universell einsetzbaren Software-Architektur vorgestellt: Events mit Dispatcher, Listeners und Datapool. Damit lassen sich bereits sehr viele einfache Use-Cases einfach umsetzen.
Aber einfach ist es ja nur in den seltensten Fällen. Bei der Kommunikation mit Remote-Systemen (z.B. mit einer zweiten MCU, mit der via UART kommuniziert wird) muss zur Sicherheit immer wieder auf Timeouts reagiert werden. Das heißt, man muss jedes Mal einen Timer „aufziehen" und in der Timer-Callback-Funktion (die aufgerufen wird, wenn der Timer abläuft) entsprechend reagieren. Ach ja, wenn die gewünschte Aktion erfolgreich war, darf man nicht vergessen, den Timer auch noch zu canceln.
Das bedeutet ziemlich viel Code mit der obendrein nötigen Fehlerbehandlung nebst erforderlichen Unittests. Und sind wir mal ehrlich: Welcher Softwareentwickler hat da wirklich Bock d'rauf? Ich bin dafür ehrlich gesagt viel zu faul! Nur: Wie könnte eine minimal arbeitsaufwändige Lösung aussehen?
Geplante Verspätung
Das Lösungswort lautet „Delayed Events". Die dafür nötigen Zutaten sind:
- Ein Delayed Event, das als Payload das Event mitbekommt, das zu einem späteren Zeitpunkt gescheduled werden soll, nebst der Timeout-Zeit.
- Ein Delayed-Event-Scheduler: Er bekommt alle Delayed-Events und fügt sie in der Reihenfolge der Ablaufzeit in seine interne Queue. Ein Thread wartet lediglich so lange, bis das Timeout des nächsten Delayed-Event abläuft.
- Der Deleyed-Event-Scheduler gibt das Payload-Event nach Ablauf der Timeout-Zeit an den „normalen" Scheduler weiter.
- Der Delayed-Event-Scheduler bekommt eine „cancel“-Funktion, die entsprechende Timeout-Events aus der Queue entfernt.
Nun haben wir alle wichtigen Komponenten beisammen, um selbst komplexe, zeitabhängige Abläufe zu modellieren.
Jetzt fragen sich wohlmöglich einige: „Wie bitteschön, modellieren?“ Nun, um dieses Thema geht es im Folge-Blogbeitrag, wo es um die Modellierung und Generierung von Statemachines geht.
Ausblick
Aber hier ist schon mal (in stark vereinfachter Form) eine Statemachine zur Steuerung einer Defi-MCU über eine Statemachine, die in der Host-MCU läuft. Das Schöne an dieser Methode ist, dass die Timeout-Behandlung zusammen mit dem „good path“ visualisiert ist.
Das Pattern ist dabei immer dasselbe: Zusammen mit der Entry-Action wird ein Event mit entsprechendem Delay „aufgezogen" und in der Entry-Action wird es gecancelt. Dabei ist es egal, ob der Stateübergang aufgrund des Delayed-Events erfolgt oder durch ein anderes Event. In diesem Beispiel führen alle Timeout-Events vom Root-State zum State DefiTimeoutOccured. Bei Bedarf könnte selbstverständlich auf die einzelnen Timeouts individuell reagiert werden.
Brauchen Sie Unterstützung beim Design einer Software-Architektur oder bei der Entwicklung von Embedded Software? Dann wenden Sie sich gerne an uns. Unsere erfahrenen MEDtech Ingenieurinnen und Ingenieure helfen ihnen gerne dabei ihr Medizinprodukt zu entwickeln oder offene Fragen zu klären.
