{"id":8060,"date":"2025-11-29T09:14:16","date_gmt":"2025-11-29T08:14:16","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=8060"},"modified":"2026-02-11T05:59:45","modified_gmt":"2026-02-11T04:59:45","slug":"health-check-for-the-development-of-real-time-systems","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/health-check-fuer-die-entwicklung-von-echtzeitsystemen\/","title":{"rendered":"Health Check for the Development of Real-Time Systems"},"content":{"rendered":"
\n

Woran es im Entwicklungsprozess krankt<\/h2>\n

Autoren: Ralf M\u00fcnzenberger, INCHRON, Friedhelm Stappert, Technische Hochschule N\u00fcrnberg<\/p>\n

Beitrag – Embedded Software Engineering Kongress 2015<\/h3>\n

Viele SW-Projekte f\u00fcr eingebettete Systeme haben Probleme bzgl. Budget- oder Termin\u00fcberschreitung. Gr\u00fcnde sind z.B., dass wichtige Anforderungen nicht fr\u00fch genug ber\u00fccksichtigt und dadurch Fehler zu sp\u00e4t erkannt werden, insbesondere beim dynamischen Verhalten eines Systems. Basierend auf vielen Entwicklungsprojekten wurde ein kompakter Fragenkatalog (Real-Time Health Check<\/em>) entwickelt, der Schwachpunkte im Entwurfsprozess aufdeckt. Auf dieser Basis k\u00f6nnen Empfehlungen abgeleitet werden, wie das dynamische Verhalten von Echtzeitsystemen besser beherrscht werden kann. Typische Probleme sind: unvollst\u00e4ndige Spezifikation von Echtzeitanforderungen, wenig robuste Architekturen, unvollst\u00e4ndige Betrachtung des Gesamtsystems in fr\u00fchen Designphasen. Vielen erfahrenen Architekten ist die Wichtigkeit dieser Aspekte durchaus bewusst. Trotzdem hat sich gezeigt, dass Timing-Fehler oft zu sp\u00e4t in der Testphase aufgedeckt werden.<\/strong><\/p>\n

Motivation<\/h2>\n

Im Rahmen von Entwicklungsprojekten im Bereich der Echtzeitsysteme, bei denen die INCHRON GmbH als Berater fungierte, entstand die Idee einer Analyse des Entwurfsprozesses. Das Ziel hierbei ist, die Schwachpunkte aufzudecken und herauszufinden, warum Aspekte des dynamischen Verhaltens eines Systems immer wieder so gro\u00dfe Probleme bereiten, obwohl eine geeignete Methodik und entsprechend Tools vorhanden sind. Anhand eines kompakten Fragebogens, dem „Real-Time Health Check“, wird analysiert, inwieweit diese Aspekte w\u00e4hrend des Entwurfs ber\u00fccksichtigt werden.<\/p>\n

Der Fragebogen richtet sich an System- und SW-Architekten, aber auch an Team- und Projektleiter, also allgemein an die Personen, die einen Einblick in den gesamten Entwurfsprozess haben. Idealerweise sollte der Test zu Beginn eines Projekts durchgef\u00fchrt werden, wenn sich in der Vergangenheit gezeigt hat, dass immer wieder Probleme mit dem dynamischen Verhalten aufgetreten sind. Zudem ist der Test dann angeraten, wenn ein Projekt eine hohe technische oder organisatorische Komplexit\u00e4t aufweist. Es liegt dann ein hohes Projektrisiko vor, dass Probleme oder Fehler erst sp\u00e4t im Entwicklungsprozess gefunden werden, wie in [1] und [2] erl\u00e4utert.<\/p>\n

Die Auswertung des Fragebogens liefert ein detailliertes Selbstbild des Entwicklungsprozesses, d.h. eine Antwort auf die Frage: „Wo stehen wir?“. Davon ausgehend k\u00f6nnen anschlie\u00dfend ein Soll-Zustand und entsprechende Ma\u00dfnahmen definiert werden, d.h. die Frage: „Wo wollen wir hin?“. Ziel hierbei ist es, Echtzeitaspekte besser im Entwurfsprozess zu verankern und dadurch das Risiko f\u00fcr zuk\u00fcnftige Projekte zu minimieren.<\/p>\n

Der im Folgenden vorgestellte Test wurde bereits bei mehreren Firmen durchgef\u00fchrt, haupts\u00e4chlich im Bereich Automotive.<\/p>\n

Der Real-Time Health Check<\/h2>\n

Der\u00a0Real-Time Health Check\u00a0<\/em>besteht aus einer kompakten Liste von Fragen zu der Behandlung von dynamischen Aspekten w\u00e4hrend der Systementwicklung. Der vollst\u00e4ndige Fragebogen kann online unter\u00a0www.real-time-doctors.com<\/a>\u00a0eingesehen und ausgef\u00fcllt werden.<\/p>\n

Anhand verschiedener Fragen wird herausgefunden, wann bestimmte Echtzeitaspekte w\u00e4hrend des Entwicklungsprozesses ber\u00fccksichtigt\u00a0 bzw. wann bestimmte Fehler bzgl. des dynamischen Systemverhaltens aufgedeckt werden. Der Fragebogen optimiert sich dabei am V-Modell. F\u00fcr den Entwurf werden die Phasen Design, Implementierung und Test angenommen. Die konkreten Fragen lauten:<\/p>\n

1. In which phase of the development cycle do you recognize the dynamic behavior of your system sufficiently?<\/p>\n

2. In which phase do you identify the root causes for dynamic behavior problems?<\/p>\n

3. In which phase do you consider the whole system including the environment (sensor, actuator, peripherals, busses, networks, etc.)?<\/p>\n

4. In which phase do you find show stoppers that are very expensive to solve?<\/p>\n

5. In which phase do you focus on real-time requirements?<\/p>\n

6. In which phase do you detect the following real-time errors?<\/p>\n

a. Load<\/p>\n

b. Response time<\/p>\n

c. Data consistency<\/p>\n

d. Event chain issues<\/p>\n

e. Jitter<\/p>\n

7. In which phase are change requests for you most problematic?<\/p>\n

8. In which phase do you know that changes will work?<\/p>\n

Typische Fehler beim Echtzeit-Verhalten sind Fehler bzgl. Prozessorlast, Antwortzeiten von Tasks und ISRs (Interrupt Service Routinen), Datenkonsistenz, Wirkketten (z.B. Datenflusslatenzen vom Sensor bis zum Aktuator) und Jitter (z.B. Start-to-Start Jitter von Tasks, ISRs, Funktionen), wie aus Frage 6 ersichtlich. Je sp\u00e4ter solche Fehler aufgedeckt werden, desto aufw\u00e4ndiger und damit teurer wird die Korrektur.<\/p>\n

F\u00fcr den Test suchten sich die Teilnehmer ein repr\u00e4sentatives Entwicklungsprojekt aus. Auf der Basis dieses Entwicklungsprojekts beantworteten sie f\u00fcr jede Frage einzeln, in welcher Phase (Design, Implementierung, Test) das jeweilige Thema behandelt wurde.<\/p>\n

F\u00fcr die Auswertung werden die Antworten unterschiedlich gewichtet und in einem „Radar-Diagramm“ (je Frage eine Radiale) dargestellt. Je gr\u00f6\u00dfer die umschlossene Fl\u00e4che im Diagramm ist, desto h\u00f6her ist das Risiko, Probleme bei der Entwicklung von Echtzeitsystemen zu bekommen. Die Risikobewertung wird grob in „Gr\u00fcn“ („Excellent Real-Time Health“, innerer Kreis), „Gelb“ („Medium Real-Time Health Risk“, mittlerer Kreis) und „Rot“ („High Real-Time Health Risk“, \u00e4u\u00dferer Kreis) eingeteilt.<\/p>\n

Teilnehmer, die den Status „Gr\u00fcn“ erreichen, gehen bereits methodisch vor und setzen geeignete Tools w\u00e4hrend des Entwurfs konsequent ein. Die notwendigen Aufgaben, Artefakte und Rollen sind ein integraler Bestandteil des Entwicklungsprozesses. Diese Teilnehmer kennen i.d.R. ihren Entwurfsprozess sehr genau und wissen, wo sie stehen. In Abb. 1 (siehe\u00a0PDF<\/a>) ist eine Auswertung mit „Excellent Real-Time Health“ zu sehen.<\/p>\n

Der Status „Gelb“ weist darauf hin, dass die Teilnehmer noch gewisse Schwachpunkte in ihren Prozessen haben, meist wissen sie aber nicht genau, wo die Ursachen sind. Dies zeigt sich in der detaillierten Auswertungi m folgenden Abschnitt.<\/p>\n

Auswertung<\/h2>\n

Der Fragebogen wurde bereits von 35 Teilnehmern beantwortet. Auch wenn die Ergebnisse nicht repr\u00e4sentativ sind, zeigen sie doch einige interessante Trends.<\/p>\n

Insgesamt zeigt sich (siehe Abb. 2,\u00a0PDF<\/a>), dass nur 11% der befragten Firmen den Status „Gr\u00fcn“ erreichen. Fast die H\u00e4lfte (46%) hat dagegen ein hohes Risiko.<\/p>\n

Methodisches Vorgehen f\u00fchrt zum Ziel<\/h2>\n

Interessant ist hierbei, dass alle „gr\u00fcnen“ Teilnehmer bereits methodisch vorgehen, entsprechende Tools anwenden und im Entwicklungsprozess verankert haben (Abb. 3, siehe\u00a0PDF<\/a>). Bei den Teilnehmern, die noch keine strukturierte Vorgehensweise etabliert haben, zeigen dagegen fast zwei Drittel (65%) den Status „Rot“, wie in Abb. 4 (siehe\u00a0PDF<\/a>) dargestellt.<\/p>\n

Ein typsisches Beispiel f\u00fcr einen „gr\u00fcnen“ Entwicklungsprozess zeigt Abb. 1 (siehe\u00a0PDF<\/a>). Hier werden Echtzeitaspekte fr\u00fchzeitig und ausreichend ber\u00fccksichtigt und Fehler im dynamischen Verhalten rechtzeitig erkannt und behoben. Die Prozesse zeigen einen hohen Reifegrad.<\/p>\n

Einen typischen Vertreter mit mittlerem Risiko zeigt Abb. 5 (siehe\u00a0PDF<\/a>). Hier kommt es immer noch zu Problemen, das Team ist sich der Problematik aber durchaus bewusst. Mit geeigneten Ma\u00dfnahmen k\u00f6nnen die Prozesse optimiert werden, um den „gr\u00fcnen“ Status zu erreichen.<\/p>\n

Hohes Echtzeitrisiko – es geht auch besser<\/h2>\n

Auch Vertreter mit hohem Risiko (Abb. 6, siehe\u00a0PDF<\/a>) sind sich h\u00e4ufig bewusst, dass das Thema Timing zu sp\u00e4t bzw. nicht ausreichend ber\u00fccksichtigt wird. Bei der Analyse der Gr\u00fcnde, warum der Entwicklungsprozess nicht ge\u00e4ndert wird, sind folgende Punkte besonders h\u00e4ufig aufgetreten:<\/p>\n