{"id":8000,"date":"2025-11-29T08:36:24","date_gmt":"2025-11-29T07:36:24","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=8000"},"modified":"2026-02-13T04:59:19","modified_gmt":"2026-02-13T03:59:19","slug":"what-is-your-processor-doing-right-now","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/was-macht-ihr-prozessor-jetzt-gerade\/","title":{"rendered":"What is your processor doing right now?"},"content":{"rendered":"

Techniken zur Messung von Software-Aktivit\u00e4ten in Echtzeit<\/h2>\n

Autor: Ulrich Dreher, iss innovative software services GmbH<\/p>\n

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

Obwohl Debugger, Emulatoren und andere Entwicklungshilfsmittel in den ver\u00adgangenen Jahrzehnten gewaltige Fortschritte gemacht haben, fehlt ihnen eine Funktion, die die Entwicklung, Fehlersuche und Validierung von Echtzeitsyste\u00admen erheblich erleichtern w\u00fcrde: die M\u00f6glichkeit, Software-Events und Ereig\u00adnisse der „realen Welt“ in „harter Echtzeit“ miteinander zu verkn\u00fcpfen.<\/strong><\/p>\n

Dieser Beitrag besch\u00e4ftigt sich damit, diese Schwachstellen zu \u00fcberwinden: Er zeigt Techniken, die die Messung ausgew\u00e4hlter Software-Eigenschaften in Echtzeit erlau\u00adben. Der Schwerpunkt liegt dabei auf der Geschwindigkeit und dem Umfang, in dem Messdaten zur Verf\u00fcgung gestellt werden k\u00f6nnen, die Aussagen \u00fcber Abl\u00e4ufe in der Software erlauben. Mit Hilfe dieser Daten k\u00f6nnen Software-Abl\u00e4ufe dann mit Ereig\u00adnissen der „realen Welt“ in Beziehung gesetzt werden.<\/p>\n

Ein kleines Glossar<\/h2>\n

Im Folgenden werden Begriffe verwendet, die m\u00f6glicherweise nicht allgemein gebr\u00e4uchlich sind. Daher an dieser Stelle ein kleines Glossar:<\/p>\n\n\n\n\n\n\n\n\n
Begriff(e)<\/strong><\/td>\nBedeutung<\/strong><\/td>\n<\/tr>\n
PCB<\/td>\nPrinted Circuit Board – Platine<\/td>\n<\/tr>\n
Target Steuerger\u00e4t<\/td>\nBezeichnet eine Einheit, deren Funktion durch einen Pro\u00adzessor oder Controller und dessen Software dominiert ist. Wobei auf einem „Steuer“ger\u00e4t durchaus auch eine Rege\u00adlung implementiert sein kann.
\nDamit ist ggf.\u00a0Ihr<\/strong>\u00a0Ger\u00e4t gemeint.<\/td>\n<\/tr>\n
physikalisches Ereignis
\nphysikalische Gr\u00f6\u00dfe
\nreale Welt<\/td>\n		bezeichnen in unterschiedlichem Kontext „Dinge“, die sich „anfassen“ bzw. messen lassen.
\nIm Gegensatz dazu ist „Software“ zwar nicht surreal, aber messtechnisch in der Regel nur schwer erfassbar.<\/td>\n<\/tr>\n
(endlicher) Zustandsautomat<\/td>\nbekannt auch unter der englischen Bezeichnung „(finite) state machine“<\/td>\n<\/tr>\n
Echtzeit<\/td>\nwird im folgenden Kapitel noch n\u00e4her betrachtet<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Was ist Echtzeit?<\/h2>\n

„Echtzeit“-Anforderungen sind bei Steuerungs- und Regelungssystemen allgegen\u00adw\u00e4rtig. Die Definition von „Echtzeit“ ist allerdings in erheblichem Ma\u00dfe von der jeweiligen Anwendung abh\u00e4ngig: „Echtzeit“ kann Reaktionszeiten (Zykluszeiten) bezeichnen, die sich um Gr\u00f6\u00dfenordnungen unterscheiden (s. Tabelle 1).<\/p>\n\n\n\n\n\n\n\n
Zykluszeit<\/strong><\/td>\nBeispiele f\u00fcr Anwendungen<\/strong><\/td>\n<\/tr>\n
100 ms<\/td>\nBenutzerschnittstellen, SPS (speicherprogrammierbare Steuerung)<\/td>\n<\/tr>\n
1 – 10 ms<\/td>\n„klassische“ Steuerungssysteme<\/td>\n<\/tr>\n
10 \u00b5s – 200 \u00b5s<\/td>\nFrequenzumrichter („Inverter“) f\u00fcr Synchronmaschinen<\/td>\n<\/tr>\n
< 10 \u00b5s<\/td>\n„Digital Power Supply“ (digital geregelte Stromversorgungen)
\nz.B. ein 1 kW AD\/DC Netzteil mit einer Regelschleife mit 200 kHz<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

Tabelle 1 – Beispiele f\u00fcr unterschiedliche Interpretationen von „Echtzeit“<\/em><\/p>\n

Tabelle 1 f\u00fchrt nur einige wenige Beispiele auf, zwischen den angegebenen Zeitbe\u00adreichen bestehen zudem L\u00fccken. In der Realit\u00e4t tendiert jede Anwendung dazu, das Attribut „echt“ in Bezug auf zeitliche Anforderungen f\u00fcr sich neu zu definieren, wo\u00adbei gerne zwischen „harter“ Echtzeit (Reaktionszeiten bis max. 5 ms) und „weicher“ Echtzeit (Reaktionszeiten > 5 ms) unterschieden wird. Auch die Grenze von 5 ms ist willk\u00fcrlich gew\u00e4hlt – je nach Organisation und Aufgabenstellung mag ein anderer Wert zur Abgrenzung herangezogen werden.<\/p>\n

Wie schon erw\u00e4hnt, haben Emulatoren und Debugger in den letzten Jahrzehnten ge\u00adwaltige Fortschritte hinsichtlich der gebotenen Funktionen und ganz allgemein hin\u00adsichtlich der Verarbeitungsleistung gemacht. Aber eine Funktion zur Verkn\u00fcpfung von Ereignissen der „realen Welt“ und „Software-Ereignissen“ fehlt. Es mag heute den einen oder anderen Debugger geben, der \u00fcber eine (kleine) Zahl digitaler Ein\u00adg\u00e4nge verf\u00fcgt. Wenn es sich allerdings darum handelt, Ereignisse der realen Welt mit Vorg\u00e4ngen in der Software zu korrelieren, ist dies selten ausreichend.<\/p>\n

Und Software-Werkzeuge, die mit hoher Geschwindigkeit Messwerte aufzeichnen k\u00f6nnen, sind auch nicht besonders hilfreich, wenn die aufgezeichneten Daten erst visualisiert werden, nachdem das ausl\u00f6sende Ereignis l\u00e4ngst Geschichte ist.<\/p>\n

Es gibt jedoch einige Techniken – teilweise sehr einfach und trotzdem weitgehend unbekannt – die geeignet sind, die vorstehend beschriebenen L\u00fccken zu f\u00fcllen.<\/p>\n

Nachfolgend sind einige dieser Verfahren beschrieben, die es erlauben, Beziehungen zwischen physikalischen Ereignissen und Software-Abl\u00e4ufen aufzudecken. Sie er\u00adm\u00f6glichen es, Spezifikationen der Software (wie z.B. Interrupt-Latenzen, die Task-Reihen\u00adfolge oder Variablen der Steuerungssoftware) in Echtzeit mess- und damit auswert\u00adbar zu machen. Dies ist eine F\u00e4higkeit, die den bislang vorhandenen Werkzeugen ab\u00adgeht.<\/p>\n

Betrachten wir also einige regelm\u00e4\u00dfig wiederkehrende Fragestellungen und m\u00f6gliche Verfahren, das „Arbeiten“ von Software messbar zu machen, und beurteilen wir, wie gut sie sich zur Beantwortung der gew\u00e4hlten Fragen eignen.<\/p>\n

Die Fragen<\/h2>\n

Nachfolgend sind Abstraktionen einiger Fragen aufgelistet, die in meiner Arbeit im\u00admer wieder gestellt wurden. Anwendungsbeispiele aus der Vergangenheit versuchen, die Fragestellung zu verdeutlichen.<\/p>\n<\/div>\n

<\/div>\n
\n\n\n\n\n\n
„Wie viel Rechenleistung ist eigentlich noch verf\u00fcgbar?“<\/strong><\/p>\n

Eine Frage, die mit sch\u00f6ner Regelm\u00e4\u00dfigkeit auftaucht.<\/p>\n

Eine Episode aus der Entwicklung des Inverters einer PMSM mit einer 20 kHz Stromregelung: Die urspr\u00fcngliche Antwort des zust\u00e4ndigen Entwicklers war „noch eine ganze Menge“.<\/p>\n

Die Anwendung einer der nachfolgend beschriebenen Methoden brachte zu Tage, dass die aktuelle Auslastung der CPU bei 95 % lag. Von diesem Zeitpunkt an war die Prozessorlast unter st\u00e4ndiger Kontrolle.
\nDas Wissen um die Kritikalit\u00e4t der Prozessorlast war der Schl\u00fcssel dazu, dass „\u00fcberraschende“ Probleme im weiteren Verlauf des Projekts deutlich reduziert auftraten.<\/td>\n<\/tr>\n

„Verh\u00e4lt sich meine Regelung wie notwendig und erwartet?“<\/strong><\/p>\n

Ein Beispiel aus der Weiterentwicklung eines Steuerger\u00e4ts der Einspritztechnik: zur Steuerung der Abl\u00e4ufe wurde ein Zustandsautomat implementiert. \u00dcblicher\u00adweise werden Zustandsautomaten in einer einzigen Funktion \u201everortet\u201c, die zyk\u00adlisch oder ereignisgesteuert aufgerufen wird. Sie sind ausgesprochen beliebt, weil sie einfach zu implementieren und ausgesprochen robust sind.<\/p>\n

Im vorliegenden Fall schied die Standardl\u00f6sung aus: die Zust\u00e4nde waren teils zeitgesteuert, teils ereignisgesteuert. Und aufgrund technischer Randbedingun\u00adgen mussten die einzelnen Teile des Zustandsautomaten „in der ganzen Soft\u00adware verstreut“ implementiert werden.<\/p>\n

Die Entwicklung erfolgte mit Hilfe eines Tools, das die Messung und Visuali\u00adsie\u00adrung der Zustandsvariablen erlaubte: die Abfolge war sehr klar 0 \u2192 1 \u2192 2 \u2192 3 \u2192 … \u2192 7 \u2192 0. Abgesehen von einem vorzeitigen Abbruch (\u2026 \u2192 0) musste die Sequenz in immer gleich Reihenfolge durchlaufen werden. Der zeitliche Ablauf allerdings war abh\u00e4ngig vom Eintreten physikalischer Ereignisse. Das Einhalten der korrekten Reihenfolge war am Oszilloskop visuell sehr einfach zu \u00fcberpr\u00fcfen, genau wie die Korrelation mit den physikalischen Ereignissen.<\/td>\n<\/tr>\n

„Warum funktioniert die Software nicht wie sie soll?“<\/strong><\/p>\n

Eine immer wieder gestellte Frage.<\/p>\n

Bei der Entwicklung eines schnellen Messsystems, das die einzelnen Zellen ei\u00adnes Brennstoffzellensystems \u00fcberwachte, wollte der Kunde noch ein paar beson\u00addere „Features“ (Unterabtastung, unterschiedliches Sequencing der Zellen).<\/p>\n

Die Implementierung des „Standardablaufs“ der Messung war einfach. Die Rea\u00adlisierung der zus\u00e4tzlichen Features war dagegen aufgrund komplexerer Abfol\u00adgen und Algorithmen sehr aufw\u00e4ndig. Und schlecht zu debuggen, da die reinen Zahlenwerte nicht sonderlich aussagekr\u00e4ftig waren.<\/p>\n

Das Vorhandensein eines speziellen Entwicklungshilfsmittels (der „histori\u00adschen“ OLDA) half enorm: die entscheidenden Variablen (2 Werte) konnten in Echtzeit visualisiert werden. Wie das „Bild“ dieser beiden Variablen auf dem Oszilloskop aussehen musste, war klar. Ein einziger Durchlauf der Software reichte jeweils zur Beurteilung gut\/schlecht aus.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n
„Verh\u00e4lt sich mein System wie geplant?“<\/strong><\/p>\n

Diese Frage wird ebenfalls mit sch\u00f6ner Regelm\u00e4\u00dfigkeit gestellt (s. erster Punkt).<\/p>\n

Bei der Systemkonzeption wird in der Regel geplant, welche Teilaufgaben in wel\u00adchen Tasks und Prozessen zu implementieren sind. Da nicht alles l\u00e4uft, wie urspr\u00fcnglich geplant, ist eine regelm\u00e4\u00dfige Kontrolle des Status quo von N\u00f6ten. Daf\u00fcr gibt es mittlerweile eine ganze Anzahl von Softwarel\u00f6sungen. Sobald allerdings „Events“ ins Spiel kommen, sto\u00dfen Softwarel\u00f6sungen schnell an ihre Grenzen. Ein unabh\u00e4ngiges Tool, das nur ein absolutes Minimum an Instrumen\u00adtierung ben\u00f6tigt, ist hier von Vorteil.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n
Die „K\u00f6nigsdisziplin“:\u00a0Die Evaluierung von sin\/cos Winkelsensoren.<\/strong><\/p>\n

Aktuell werden zur Winkelerfassung von Synchronmaschinen bevorzugt sin\/cos Winkelsensoren eingesetzt, da diese eine hohe Aufl\u00f6sung bei vergleichsweise geringem Aufwand bieten. Um von den Werten zum Winkel zu gelangen, ben\u00f6\u00adtigt man die Arkustangens-Funktion. Wie das Leben so spielt, hat die Arkustan\u00adgens-Funktion alle 90\u00b0 eine kritische Phase, in der geringe Fehler in den Mess\u00adwerten von Sinus und Kosinus zu gewaltigen Winkelfehlern f\u00fchren. W\u00e4re es nicht sch\u00f6n, die gemessenen Werte kontinuierlich \u00fcberwachen und evtl. mit den physikalischen Messwerten – oder auch mit dem berechneten Winkelwert – ver\u00adgleichen zu k\u00f6nnen?<\/td>\n<\/tr>\n

Zum Abschluss eine zunehmend wichtiger werdende Frage: „Wie wirkt sich eine \u00c4nderung der Hardware-Konfiguration aus?“
\n<\/strong>
\nZu beurteilen sind z.B. Einfl\u00fcsse der Cache-Gr\u00f6\u00dfe, der Cache-Konfiguration, der Verwendung von Inline-Code usw.Im Grunde genommen kann diese Frage durch Verwendung der bereits erw\u00e4hn\u00adten Softwarel\u00f6sungen zur Laufzeitmessung beantwortet werden. Diese erfordern allerdings eine umfangreiche Code-Instrumentierung, die wahrscheinlich die Messwerte verf\u00e4lscht.Ein weniger invasives Messverfahren w\u00e4re w\u00fcnschenswert.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Einige Vorbemerkungen<\/h2>\n

Wenn es um Echtzeitmessungen an „realen“ Objekten geht, taucht umgehend die Frage auf, welche Ressourcen eigentlich zur Verf\u00fcgung stehen, um diese Messungen durchf\u00fchren zu k\u00f6nnen. Um die meisten (wenn vielleicht auch nicht alle) Targets mit einem einzigen Werkzeug unterst\u00fctzen zu k\u00f6nnen, m\u00fcssen die Erwartungen an die Verf\u00fcgbarkeit von Ressourcen auf ein Minimum reduziert werden. Diese Ressourcen sollten gleichzeitig ein Maximum an Geschwindigkeit bieten, um die Messung nicht von dieser Seite her einzuschr\u00e4nken.<\/p>\n

Unter Ber\u00fccksichtigung dieser Einschr\u00e4nkungen bieten sich zwei Alternativen an:<\/p>\n