Bachelorarbeit Automatisierte Energiemodellerstellung mit MSP430 EnergyTrace - of the Embedded Software Systems Group
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Bachelorarbeit
Automatisierte Energiemodellerstellung
mit MSP430 EnergyTrace
Lennart Nicolas Kaiser
23. September 2020
Betreuer
Daniel Friesel, M.Sc.
Prof. Dr. Olaf Spinczyk
Universität Osnabrück
Institut für Informatik
Arbeitsgruppe Eingebettete Softwaresysteme
https://ess.cs.uos.de/
Zusammenfassung
Im Rahmen dieser Bachelorarbeit wurden die Möglichkeiten untersucht mit günstiger
Hardware möglichst akkurate Energiemodelle zu erstellen. Bestehende Lösungen zur Er-
stellung von Energiemodellen beruhen meistens auf selbst entworfener Hardware oder
auf teuren Energiemessgeräten. In dieser Arbeit wurde das MSP430FR5994 LaunchPad
von Texas Instruments verwendet. Dieses LaunchPad hat EnergyTrace verbaut, eine ex-
tra Einheit vor dem Prozessor, die die Energie misst. In dieser Arbeit wurde die Schnitt-
stelle zur Synchronisierung der Energiedaten implementiert. Aus den synchronisierten
Daten wird die durchschnittliche Leistungsaufnahme der Zustände und Transitionen
bestimmt. Im Anschluss wurde geprüft wie die Qualität der erstellten Modelle ist. Der
Modellfehler liegt im Mittel der geprüften Zustände bei 8% und im Maximum bei 500
µW . Wobei der absolute Fehler in Zuständen mit geringerem Energieverbrauch stärker
ins Gewicht fällt.
Abstract
In this Bachelor thesis, the creation of accurate energy models using inexpensive hard-
ware was researched. Existing solutions for creating energy models are mostly based
on self-designed hardware or on expensive energy measuring devices. MSP430FR5994
LaunchPad, produced by Texas Instruments, was used for the purpose of this thesis.
Energy usage is measured by the built-in EnergyTrace unit; this is an additional unit
attached in front of the actual processor. In this thesis the interface for the energy
data synchronization was implemented. Subsequently the average power consumption
of each state and transition is calculated with the synchronization and EnergyTrace
data. Afterwards the quality of the created models was checked. The model error is
8% on average for the tested conditions and a maximum of 500µW with the tested
benchmarks. The absolute error is greater in states with lower energy consumption.
Inhaltsverzeichnis
1. Einleitung 1
2. Grundlagen 3
2.1. Energie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Energiemodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. dfatool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2. MSP430 EnergyTrace++ . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Keysight N6785A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Literatur 11
3.1. MIMOSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. FlockLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. PowerBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. SPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Konzept 15
4.1. Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. UART / Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Barcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Synchronisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Implementierung 19
5.1. Benchmarkerstellung mit dfatool . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Sigrok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Synchronisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Einbindung Auswertung in dfatool . . . . . . . . . . . . . . . . . . . . . 24
5.5. Algorithmen zur Genauigkeitsverbesserung . . . . . . . . . . . . . . . . 25
6. Evaluation 27
6.1. EnergyTrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Benchmarkerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. Synchronisierung mit Logic Analyzer (Zustände) . . . . . . . . . . . . . 32
6.5. Synchronisierung von Transitionen . . . . . . . . . . . . . . . . . . . . . 34
6.6. Vergleich mit anderen LaunchPads . . . . . . . . . . . . . . . . . . . . . 35
6.7. Kürzere Benchmarkdauer . . . . . . . . . . . . . . . . . . . . . . . . . . 36
iInhaltsverzeichnis
6.8. Synchronisierung mit UART/Timer . . . . . . . . . . . . . . . . . . . . 37
6.9. Algorithmen zur Genauigkeitsverbesserung . . . . . . . . . . . . . . . . 37
6.10. Vergleich von Umwelteinflüssen . . . . . . . . . . . . . . . . . . . . . . . 39
6.11. Vergleich mit einer MIMOSA Messung des BME680 . . . . . . . . . . . 40
6.12. Zusammenfassung der Evaluationsergebnisse . . . . . . . . . . . . . . . . 41
7. Zusammenfassung 43
7.1. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A. Anhang 45
A.1. Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Literaturverzeichnis 49
Abkürzungsverzeichnis 51
Abbildungsverzeichnis 53
Tabellenverzeichnis 55
ii1. Einleitung
Eingebettete Systeme sind heutzutage in unserem Alltag überall vertreten. Bei einem
Großteil dieser eingebetteten Systeme werden zur Energieversorgung Akkus oder Bat-
terien verwendet. Beispiele dafür sind Smartphones, Fernbedienungen oder Außensenso-
ren von Wetterstationen. Ein Laden des Akkus beziehungsweise Austausch der Batterien
wird zu einem Zeitpunkt notwendig sein, auch wenn in einigen Fällen Energy-Harvesting
für die Energieversorgung verwendet wird. Um die Laufzeit des Systems zu maximieren
und diese zu bestimmen, sind Informationen über die im System verfügbare und be-
nötigte Energie notwendig. Um Informationen über die benötigte Energie zu erhalten,
bieten sich Energiemodelle an, die die energierelevanten Aktionen des Systems model-
lieren. Die notwendigen Daten für solche Modelle sind nicht immer vollständig in den
Datenblättern der Peripherie dokumentiert. Oft sind grobe Aktionen vermerkt, Kombi-
nationen dieser Aktionen meistens nicht. Deshalb werden diese Energiemodelle mithilfe
von Messungen und Handarbeit erstellt. Die dazu benötigten professionellen Energie-
messgeräte sind oft sehr teuer und nicht zur automatisierten Energiemodellerstellung
konzipiert worden.
Ziel dieser Bachelorarbeit ist die automatische Erstellung von Energiemodellen mit-
hilfe von günstiger COTS(engl. Commercial off-the-shelf, fertig kaufbar) Hardware wie
dem Mikrocontroller MSP430 und einem USB Logic Analyzer. Im Rahmen dieser Ar-
beit werden verschiedene Synchronisierungskonzepte weiterentwickelt und implemen-
tiert. Diese Synchronisierungsverfahren sind in der Lage, den gemessenen Energiewerten
den Zuständen und Transitionen zuzuordnen. Mithilfe dieser Daten und dfatool, einer
Benchmarksoftware, können im Anschluss Energiemodelle erstellt werden.
Es wurden zwei Synchronisierungsverfahren implementiert, die unterschiedliche Hard-
warevoraussetzungen haben. Die erste Variante basiert auf der Kommunikation mit dem
Mikrocontroller MSP430 und Logic Analyzer über einen IO-Pin, über den transferiert
wird, ob sich der Mikrocontroller in einer Transition oder einem Zustand befindet. Die
zweite Variante nutzt ausschließlich einen interner Timer von MSP430, welcher die Dauer
der Transitionen bzw. Zustände misst und diese per UART an den Computer weitergibt.
Im Anschluss werden diese Synchronisierungsverfahren nach verschiedenen Aspek-
ten bewertet. Es wird die Genauigkeit der erstellten Energiemodelle, die Messbarkeit
von Transitionen und die Auswirkungen von Umwelteinflüssen untersucht. Dazu wer-
den Benchmarks (Programme für Vergleichsmaßstäbe), die mithilfe von dfatool und
Graphenbeschreibungen generiert wurden, verwendet. Diese werden analysiert und mit
errechneten Sollwerten oder Daten aus anderen Messreihen verglichen.
Neben der Evaluation des entstandenen Modells wurde außerdem untersucht, wie ge-
nau EnergyTrace arbeitet, da diese Daten als Grundlage für die Energiemodellerstellung
dienen.
1Einleitung Im Folgenden werden in Kapitel 2 zunächst die relevanten Grundlagen, insbesondere in Bezug auf die verwendete Hard- und Software, geschaffen. Im anschließenden Kapitel 3 wird ein Überblick über schon bestehende Arbeiten in diesem Themengebiet gegeben. In Kapitel 4 wird das entworfene Konzept für die in Kapitel 5 gezeigte Implementierung der beiden Ansätze vorgestellt. Eine Auswertung der Messergebnisse und der Funktionalität findet in Kapitel 6 statt. Zuletzt werden die Ergebnisse in Kapitel 7 zusammengefasst und ein Fazit gezogen. 2
2. Grundlagen
In diesem Kapitel werden die Grundlagen für die Messungen und Modellierung von
Energie und Leistung dargestellt. Des Weiteren werden die verwendeten Hard- und
Softwarekomponenten kurz vorgestellt. So werden zunächst die elektrischen Grundlagen
erläutert, im Anschluss in Abschnitt 2.2 eine Einführung in Energiemodelle gegeben.
Zudem wird die verwendete Hard- und Software vorgestellt, in Abschnitt 2.4 der Mi-
krocontroller MSP430 mit EnergyTrace und in Abschnitt 2.5 der zur Synchronisierung
verwendete Logic Analyzer.
2.1. Energie
Um feststellen zu können, wie aussagekräftig die erstellten Energiemodelle sind, wer-
den diese mit realen Messergebnissen bzw. Sollwerten verglichen. Für das Verständnis,
wie die Messungen in dieser Arbeit gestaltet wurden, folgt eine grobe Übersicht der
elektrotechnischen Zusammenhänge.
Zunächst wird der Begriff der elektrischen Leistung erläutert. Leistung P ist ein Pro-
dukt aus Spannung U und Strom I, bzw. ein Quotient aus Energie E und Zeit t.
P =U ·I
Energie ist eine fundamentale Größe in der Elektrotechnik und wird in der SI-Einheit
Joule angegeben. Im klassischen Sprachgebrauch wird Energie verbraucht, physikalisch
korrekt betrachtet wird sie nur umgewandelt, zum Beispiel in Wärme. Ein klassischer
Energiewandler ist ein Elektromotor. Dieser wandelt elektrische Energie in kinetische
Energie(Bewegungsenergie) um. Besitzt der Elektromotor eine Leistung von 100 W und
wird zehn Sekunden in Betrieb genommen, werden 1000 J Energie verbraucht. Um die
verbrauchte Energie zu berechnen, wird zwangsläufig die Zeit benötigt. Bei den meisten
Verbrauchern verändert sich die Leistung mit der Zeit. Wird die Leistung als Funktion
P (t) beschrieben und der Zeitraum von t1 bis t2 betrachtet, gilt
Z t2
E= P (t)dt
t1
für die umgesetzte Energie in diesem Zeitraum. Bei konstanter Leistung vereinfacht sich
die Formel zu
E =P ·t
Die meisten Messgeräte können nur die Spannung messen, weshalb ein Messwider-
stand(engl. Shunt) genutzt werden muss, um die Energie zu messen. Dieser wird mit dem
Verbraucher in Reihe geschaltet. Denn nach dem ohmschen Gesetz erzeugt der Strom-
fluss durch den Widerstand einen proportionalen Spannungsabfall. Der Messwiderstand
3Grundlagen 2.2 muss passend gewählt werden, da die Spannung am DUT(Verbraucher, engl. Device Under Test) verändert wird, sodass diese je nach Widerstand unter der Versorgungs- pannung liegen kann. Diese Spannung kann mit einem Analog-Digital-Wandler gemessen und daraus die verbrauchte Energie berechnet werden. Mit dieser Art der Messung kön- nen nur diskret Messwerte erfasst werden, dass heißt, wenn einzelne Peaks(Spitzen) im Stromverbrauch zwischen den Messungen des Analog-Digital-Wandlers liegen, werden sie nicht erfasst. Bei Funktionsaufrufen, die nur wenige Mikrosekunden lang sein können, ist es wahrscheinlich, diese nicht zu erfassen. Durch einen Analog-Digital-Wandler wird nicht nur die Spannung, sondern auch die Zeit diskretisiert. Ein Analog-Digital-Wandler, kurz ADC(engl. analog-to-digital converter), wandelt eine analoge Spannung in ein digitales Signal um. Dieses kann in einem Mikrocontrol- ler oder in einem Messgerät weiterverarbeitet werden. Mit einem 10-bit ADC können bspw. nur 210 = 1024 verschiedene Spannungswerte gemessen werden. Wenn diese Wer- te auf einen Bereich von 0 bis 5 Volt angewendet werden, entspricht ein ADC-Schritt 5V /1023 ≈ 0,00489V = 4,89mV . Zusätzlich besteht die Möglichkeit mit einer Kondensatorschaltung aus zwei Kon- densatoren eine integrative Messung zu erstellen. Dazu wird immer abwechselnd ein Kondensator geladen, währenddessen der andere die Stromversorgung der DUTs sicher- stellt. Wenn der Kondensator unter eine bestimmte Spannungsgrenze fällt, werden die Rollen der Kondensatoren gewechselt. Diese Wechsel werden intern gezählt und daraus die verbrauchte Energie bestimmt. Da die Kondensatoren komplett analoge, bzw. in- tegrative Bauteile sind, können bei dieser Schaltung Peaks nicht verloren gehen. Diese Technik wird auch bei MSP430 EnergyTrace verwendet. Bei einem Teil der Auswertung wird auf eine Widerstandsschaltung zurückgegriffen, um händisch den Sollwert zu bestimmen. Mit I = UR und P = U ·I lässt sich der Sollwert der Messung errechnen, was sich bei anderen DUTs schwieriger gestaltet. Fertigungs- toleranzen zu Vergleichsmessungen sind auszuschließen, da die Widerstände vorher mit einem Multimeter vermessen werden können. Zum Beispiel ist bei einer Spannung von 3,3V und einem 100Ω Widerstand ist die Stromstärke I = 0,033A bzw. 33mA. Daraus folgt, dass P = 3,3V · 0,033A = 108,9mW . 2.2. Energiemodelle Energiemodelle sind eine Art von Ressourcenmodellen. Diese existieren bereits z.B. für die Verwendung des Stacks. Die Stackressourcen werden aber nach einer gewissen Zeit wieder frei und können neu verwendet werden. In der Energiemodellierung hingegen werden die Energieressourcen endgültig verbraucht und können nicht wiederverwendet werden. 4
2.3 Grundlagen
Abbildung 2.1.: Energiemodell eines RF Sende- und Empfangsmoduls. [1]
Energiemodelle werden zur Prognose und Berechnung des Energieverbrauchs ver-
wendet. Grundsätzlich wird zwischen der Online- und der Offlinemodellierung unter-
schieden. Bei der Onlinemodellierung wird zeitgleich mit der Ausführung des Systems
gemessen und dieses kann dynamisch auf Veränderungen reagieren. Die Offlinemodel-
lierung wird mithilfe von externer Hardware vorgenommen. Der Zugriff auf die Daten
des Prozessors ist dabei nur beschränkt möglich. Die im Folgenden verwendeten Mo-
delle sind Offlinemodelle, da der verwendete Mikrocontroller eine getrennte Einheit zur
Energiemessung besitzt. Außerdem werden die Modelle nicht während einer norma-
len Programmausführung auf dem Mikrocontroller erstellt, sondern mit extra Bench-
marks. Allgemein ist die Erstellung von Benchmarks händisch möglich, aber sehr auf-
wändig. Es ist möglich, die Energiemodellierung bis auf die Instruktionsebene von MCUs
(Microcontroller Unit) herunterzubrechen oder jeden Bitwechsel einzeln zu modellie-
ren. Solche Messungen sind aber mit enormem Aufwand verbunden. Hersteller geben
meistens nur grob an, in welchen Hardwarezuständen wie viel Energie durchschnittlich
verbraucht wird. Hardwarezustände können zum Beispiel der Mess- oder Idlezustand
eines Sensors sein. In diesen Zuständen werden verschiedene Ressourcen, wie CPU Zeit
und Energie benötigt. [3]
Ein häufig verwendetes Modell ist der Priced Timed Automaton, kurz PTA. Ein PTA
ist ein endlicher Automat mit annotierten Kosten und Zeiten. Endliche Automaten be-
sitzen Transitionen und Zustände, sowie einen definierten Startzustand, weshalb sie
sich zur Darstellung von Energiemodellen besonders eignen. Diese können auf Funk-
tionsaufrufe und Hardwarezustände übertragen werden. Transitionen können normale
Funktionsaufrufe, (Hardware-)Interrupts oder zeitgesteuerte Transitionen sein. In Ab-
bildung 2.1 ist ein PTA für einen Funkchip mit den Zuständen IDLE, SLEEP, RX
und TX dargestellt. Des Weiteren ist an den Transitionen des Automaten die Dauer
und der Energieverbrauch vermerkt. Bis eine Transition auftritt, verweilt der Automat
in dem aktuellen Zustand. Der Zustand TX ist zeitgesteuert, d.h. nach einer gewissen
Zeit wechselt der Automat zurück in den IDLE Zustand. Deshalb ist in Zuständen nur
die Leistung angemerkt, die in diesem Zustand benötigt wird. Die verbrauchte Energie
ergibt sich aus der Dauer des Zustandes und der angegebenen Leistung. [1]
5Grundlagen 2.4
Abbildung 2.2.: MSP430FR5994 LaunchPad Development Kit. [6]
2.3. dfatool
dfatool[4] ist ein im Rahmen der Masterarbeit von Daniel Friesel entstandenes Tool, mit-
hilfe dessen Benchmarks generiert und ausgewertet werden können. Anhand von Hard-
warebeschreibungen in Graphenform von Sensoren oder anderen Verbrauchern können
systematisch Ausführungsreihenfolgen erstellt werden. Diese werden auf den Mikrocon-
troller geflasht und danach Peripherie wie das Energiemessgerät MIMOSA angesteuert,
um den Energiebedarf zu messen. Am Ende des Prozesses werden die Dateien in einem
Archiv gespeichert und können analysiert werden. Bei der Analyse werden sowohl Zu-
stände als auch Transitionen und deren Parameterzusammenhang mit den aufgerufenen
Funktionen untersucht.
2.4. MSP430
MSP430 ist eine 16-Bit-RISC-Mikrocontroller Familie von Texas Instruments (kurz TI ).
Die erste Version ist Anfang der 1990er Jahre in Deutschland entwickelt worden. Der Mi-
krocontroller ist auf geringen Stromverbrauch optimiert und dementsprechend gut für
akku- und batteriebetriebene Low-Power-Systeme geeignet. Des Weiteren unterstützt
er verschiedene Low-Power-Modi. Der Prozessor ist mit persistentem Hauptspeicher,
der von TI als FRAM bezeichnet wird, erhältlich. Die Familie wird fortlaufend um
neue Versionen des Prozessors erweitert. Die LaunchPad Varianten des Prozessors bie-
ten Interaktionsmöglichkeiten sowie ausgeführte IO-Pins. Für die LaunchPad Versionen
gibt es BoosterPacks. Diese werden auf die IO Pins aufgesteckt und können weitere
Features, wie Sensoren bzw. Aktoren bereitstellen. Ein Beispiel dafür ist das Infrarot
(IR) BoosterPack-Modul oder, für die Energieversorgung, ein Kraftstofftank/Batterie-
BoosterPack-Modul. [6]
62.4 Grundlagen
Abbildung 2.3.: Schematische Darstellung: MSP430FR5994 LaunchPad Development
Kit. [6]
2.4.1. Hardware
Im Rahmen dieser Bachelorarbeit wird das MSP430FR5994 LaunchPad Development
Kit, kurz MSP430, verwendet (s. Abbildung 2.2). Der MSP430FR5994 ist ein 16 MHz
MCU mit 256KB FRAM, 8KB SRAM, 12-bit ADC, UART/SPI/I2C, Timer und di-
versen IO Pins. Schematisch ist der MCU in Abbildung 2.3 aufgezeigt. Im folgenden
Abschnitt werden die einzelnen Komponenten erläutert.
Das LaunchPad wird standardmäßig über den microUSB Port, via eZ-FET, mit Ener-
gie versorgt. Die auf dem Board verfügbare Programmier- und Debug-Schnittstelle wird
von TI als eZ-FET bezeichnet. Mit einer geeigneten Jumperkonfiguration lässt sich an-
statt dessen eine externe Energiequelle verwenden. Das ist bei der Verwendung von
externen Messgeräten sinnvoll. Über den gleichen microUSB Port wird sowohl die Kom-
munikation von MSP430 EnergyTrace++ bzw. eZ-FET, als auch die des Mikrocontrol-
lers direkt geregelt. Das LaunchPad besitzt zusätzlich einen Super-Cap. Dabei handelt es
sich um einen Kondensator mit einer Kapazität von 0,22F , welcher nach dem Aufladen
das Board mit Strom versorgen kann.
Getrennt vom MCU/MSP430 befindet sich der eZ-FET, dieser stellt die Programmier-
, Debugging- und Evaluationsschnittstelle zum MSP430 bereit. Optisch ist dieser, wie
in Abbildung 2.2 sichtbar, durch eine gestrichelte Linie getrennt. Hier lassen sich per
Jumperkonfiguration einzelne Kommunikationswege blockieren, wie beispielsweise Spy-
bi-Wire, ein JTAG-Protokoll von Texas Instruments, welches statt 4 nur 2 Pins benö-
tigt, als auch die normale serielle Kommunikation (RXD/TXD), wie sie z.B. für UART
verwendet wird. Auch die Stromversorgung über eZ-FET kann komplett deaktiviert
werden, sodass die Einheit vollständig isoliert werden kann. Zusätzlich befindet sich in
7Grundlagen 2.4
dem gestrichelten Bereich das MSP430 EnergyTrace++ Modul, das zur Energiemessung
notwendig ist.
Im unteren Teil des LaunchPads liegt der Prozessor MSP430FR5994 mit zwei Push-
buttons (S1 und S2) und jeweils eine rote und grüne LED. Diese sind durch den Benutzer
frei programmierbar und werden in dieser Arbeit zur Synchronisierung des Energiebe-
darfs benötigt. Des Weiteren werden die IO-Ports links und rechts vom MSP430FR5994
zur Kommunikation mit dem DUT verwendet. Die Buttons, der microSD-Kartenslot
sowie der Super-Cap werden nicht genutzt.
2.4.2. MSP430 EnergyTrace++
MSP430 EnergyTrace++ ist eine von Texas Instruments entwickelte Technologie zur
Energiemessung des angeschlossenen Boards und der Peripherie. Diese ist auf verschie-
denen Development Boards neben dem eZ-FET verbaut.
Ursprünglich wurde EnergyTrace entwickelt, um den reinen Stromverbrauch zu er-
mitteln und Programmierern Code-Analyse hinsichtlich der Energieeffizienz zu erleich-
tern. Die neueren Versionen EnergyTrace+ und EnergyTrace++, letzteres verbaut im
MSP430FR5994 LaunchPad, können zusätzlich zur Strommessung den Prozessor-, sowie
den Systemstatus übermitteln. Im Prozessorstatus ist zusätzlich vermerkt, ob das Gerät
aktiv ist oder sich in einem Low-Power-Zustand befindet. Im Systemstatus ist festge-
halten, welche Peripheriegeräte und System-Clocks aktiv sind. Mithilfe der TI Software
Ultra-Low-Power (ULP) Advisor können Energieeffizienzprobleme erkannt werden. Aus
diesen Ergebnissen können Optimierungen vorschlagen werden. Zusätzlich kann über-
prüft werden, ob sich ein Peripheriegerät, wie ein Sensor, nach einer gewissen Zeit in
einem Low-Power-Zustand befindet.
Traditionell wird Energie mit einem Messwiderstand gemessen, wie in Abschnitt 2.1
erläutert. EnergyTrace++ verwendet eine wechselnde Kondensatorschaltung, welche in
einer integrierenden Messung resultiert. Auf dieses EnergyTrace Konzept hat TI mehrere
Patente angemeldet [9]. Mit einem softwaregesteuerten Gleichspannungswandler(DC-
DC Converter) werden Ladungsimpulse abgegeben. Die Dauer der Impulse ist konstant,
während deren Frequenz der Stromstärke entspricht. Der Debugger kann einzelne Pulse
über die Zeit aufzeichnen und somit den Energieverbrauch ermitteln.
Im Gegensatz zu externen Energiemessgeräten misst EnergyTrace++ zwangsläufig
den Energieverbrauch des Prozessors mit. Die Messpunkte haben eine zeitliche Auflösung
von ca. 3,7 kHz. [7]
Gleichnamig, auch MSP430 EnergyTrace, ist ein Tool von Texas Instruments, das
auf der Entwicklungsumgebung Eclipse basiert und bei längeren Messungen die Nut-
zungsdauer mit bestimmten Batterien prognostizieren kann. Außerdem werden Plots
erstellt welche die Leistung des LaunchPads erkennbar machen. Ein auf GitHub als
Open Source veröffentlichtes Softwareprojekt1 ermöglicht, es die Daten, die über die
USB Schnittstelle gesendet werden, auf ein CLI(engl. Command Line Interface) her-
unterzubrechen, wodurch eine simple Dateiausgabe möglich ist. Ein Softwareprojekt 2
1
https://github.com/carrotIndustries/energytrace-util
2
https://ess.cs.uos.de/git/software/msp430-etv
82.5 Grundlagen
bietet weitere Funktionalität. Dieses Projekt verwendet eine Debugging open-source Li-
brary von TI. Um die Daten später selber mit Python weiterzuverarbeiten, wird auf das
Projekt zurückgegriffen. Die Daten die vom CLI generiert werden, liegen in folgendem
Format vor:
#Timestamp [ us ] Current [ nA ] V o l t a g e [mV] Energy [ nJ ]
50225 0 3291 41000
50504 0 3291 41000
50717 0 3291 41300
50929 0 3291 41300
51143 0 3291 41700
Listing 2.1: Auszug aus einer .etlog Datei
2.5. Logic Analyzer
Abbildung 2.4.: SALEAE-kompatibler Logic Analyzer.
Ein Logikanalysator (engl. Logic Analyzer) kann an einem oder mehreren Eingängen
die Spannung messen und daraus den logischen Wert ermitteln. Diese Daten werden
digital per USB weitergegeben und können grafisch dargestellt werden. Im Gegensatz zu
Oszilloskopen haben diese meist deutlich mehr Eingänge, die jedoch nur digital messen
können. Das heißt, nur diskrete Werte wie falsch(0 ) oder wahr(1 ) werden gemessen.
Teilweise gibt es weitere Bereiche, wie undefiniert, je nach verwendetem Logikgatter.
Mit entsprechender Software, wie PulseView, lassen sich ganze Kommunikationswege
überprüfen, mitlesen bzw. entschlüsseln.
Bei PulseView handelt es sich um eine Software mit grafischer Benutzeroberfläche.
PulseView basiert auf sigrok, einem freien, portablen und quelloffenen Programmpaket,
welches verschiedenste Gerätetypen unterstützt.3
sigrok-cli ist ein CLI für die Verwendung des Logic Analyzers. libsigrok ist eine in C
programmierte shared library. Eine Nutzung dieser Bibliothek durch andere Program-
miersprachen wird beispielsweise durch Java oder Python Bindings ermöglicht.
3
https://www.sigrok.org
9Grundlagen 2.6 SALEAE ist ein großer Hersteller von Logic Analyzern und deren Software. In der folgenden Implementation wird ein SALEAE-kompatiblen Logic Analyzer verwendet, siehe Abbildung 2.4. Dieser unterstützt eine Samplingfrequenz bis zu 24 MHz, besitzt 8 digitale Eingänge und wird per Mini-USB an den Computer angeschlossen. 2.6. Keysight N6785A In einem Teil der Evaluation wird auf das professionelle Energiemessgerät N6785A von Keysight zurückgegriffen, mithilfe dessen die Genauigkeit der von EnergyTrace gemessen Daten überprüft wird. Dies ist ein Modul, welches für die Analyse von Batterieentladung konzipiert wurde. Es besitzt einen programmierbaren Ausgangswiderstand. Zusätzlich kann Strom bzw. Spannung gemessen werden. Die Abweichung der Strommessung beträgt 0,025 % bzw. 100 nA, die der Spannungsmessung 0,025 % bzw. 1,8 mV. Die Frequenz der Datenlog- gerfunktion liegt bei 50 kHz. Das Energiemessgerät besitzt für Messergebnisse einen in- ternen Speicher und es besteht zusätzlich die Möglichkeit, einen externen USB-Speicher mit einer Speicherkapazität bis zu 2GB anzuschließen. Dieses Modul muss in ein Mainframe des MPS (Modular Power System) der Reihe N670x eingesetzt werden. [10] 10
3. Literatur
In diesem Kapitel werden einige Forschungsarbeiten als verwandte Literatur zu dem
Thema dieser Bachelorarbeit vorgestellt.
Es bestehen einige Ansätze und Projekte zum Thema „Automatisierte Energiemodel-
lerstellung“. Unter anderem auch mit akkubasierten Systemen, wie Smartphones und
Laptops, welche meist Energiemessungen für komplette Systeme und nicht für einzelne
Komponenten durchführen.
Des Weiteren existieren Projekte für einzelne Komponenten, wie Funkchips, die auf
selbst entwickelter Hardware basieren. Einige dieser Projekte werden im Folgenden kurz
vorgestellt.
3.1. MIMOSA
MIMOSA (Messgerät zur integrativen Messung ohne Spannungsabfall) ist ein Mess-
gerät, das 2013 an der TU Dortmund von Markus Buschhoff und Christian Günter
entwickelt wurde[2]. Es wurde für hochpräzise Messungen des Energieverbrauchs von
eingebetteten Systemen konzipiert und ermöglicht mit den gemessenen Daten eine prä-
zise Energiemodellerstellung. MIMOSA misst mit einer 16Bit Auflösung und einem
Messbereich bis 50mA. Das bedeutet, ein Energieschritt entspricht ca. 0,8µA. Die zeit-
liche Auflösung liegt bei 100 kHz.
Die Messung erfolgt integrativ mithilfe drei analoger Integratoren. Das bedeutet, dass
der gesamte Stromverbrauch, wie bereits in Abschnitt 2.1 erläutert, vom letzten bis zum
aktuellen Messpunkt aufgezeichnet wird. Der Spannungsabfall durch den Verbraucher
wird durch einen Widerstand kompensiert, welches in einer konstanten Versorgungs-
spannung von 3,6V resultiert. Zusätzlich existiert ein Buzzer-Eingang, mithilfe dessen
Funktionsaufrufe und Zustände übermittelt werden können. In der folgenden Versuchs-
anordnung entspricht der Buzzer-Eingang dem Logic Analyzer.
Die Messdaten können per USB-Schnittstelle an den PC weitergegeben werden, in
dem sie von libmimosa ausgewertet werden. Ein Datensatz besteht aus insgesamt 32
Bits: Messwert(28 Bits), Buzzer(1 Bit), Integratornummer(2 Bits) und ein reserviertes
Bit. libmimosa kann auch die Kalibrierung des Boards vornehmen.
3.2. FlockLab
FlockLab ist ein Testbed (deutsch Prüfstand), das seit 2009 an der ETH Zürich entwi-
ckelt wird und 2013 erschienen ist[11]. FlockLab hat eine GPIO-Überwachung mit einer
Auflösung von 10 kHz und somit bspw. Routingprotokolle überwachen. Die serielle I/O
Schnittstelle kann auch verwendet werden, um ASCII Daten oder andere Nachrichten
11Literatur 3.4 zu übermitteln. Außerdem können auch GPIO Pins durch das Testbed angesteuert wer- den. Die Versorgungsspannung des DUTs kann zwischen 1,8 V und 3,3 V in 100 mV Schritten variiert werden. Am relevantesten ist das Power profiling Feature, welches die Aufnahme des Stromverbrauchs ermöglicht. Das Testbed hat zwei Konfigurations- möglichkeiten, den high-speed oder high-resolution Modus. Im high-speed Modus ist die zeitliche Auflösung 56 kHz, im high-resolution Modus 28 kHz. Standardmäßig wird letz- teres verwendet, da das SNR(Signal-Rausch-Verhältnis) deutlich besser ist. Zur Messung wird eine Shuntwiderstandsschaltung verwendet, dementsprechend er- folgt keine integrative Messung. Der Widerstand ist klein gewählt(150mΩ), welches nur in einem geringen Spannungsunterschied resultiert, deshalb wird vor der Nutzung des ADCs das Signal proportional verstärkt. Durch diesen Widerstand können Ströme bis zu 160mA gemessen werden. Die Spannung wird mithilfe eines ADS1271 ADC Chips digitalisiert. Dieser hat eine Auflösung von 24 Bits, sodass theoretisch ein ADC-Schritt 10nA entsprechen. Die Kommunikation verläuft hier über die USB-Schnittstelle oder per Ethernet. 3.3. PowerBench PowerBench ist ebenfalls ein Testbed, dieses wurde 2008 an der Delft University of Tech- nology entwickelt[5]. PowerBench ist besonders auf Sensornetze(engl. Wireless Sensor Networks, kurz WSN ) spezialisiert. Deshalb kann gleichzeitig der Stromverbrauch von bis zu 24 Verbrauchern vermessen werden. Das heißt, es können gleichzeitig Sende- und Empfangsoperationen gemessen werden. Dieses passiert mit einer Samplingfrequenz von 5kHz und einer Auflösung von 30µA. Es sollte ein Messfehler von < 5 % erreicht werden. Gemessen wird mithilfe von Messwiderständen und ADCs. Hier wurde versucht möglichst günstige Hardware zu verwenden, weshalb auf den Mikrocontroller TNOde (Mica2 clone) zurückgegriffen wurde. Dennoch werden 24 Ein- heiten benötigt, welche 27€ pro Einheit kosten, welche eine Gesamtsumme von 640€ entspricht. Zusätzlich wird aufgrund von spezieller Verkabelung noch eine Stunde Ar- beitszeit pro Einheit benötigt. An jedem Mikrocontroller ist ein externer ADC angeschlossen. Nach dem Messen der Daten werden sie mit einer Node-ID und einem Zeitstempel versehen. Diese Daten werden via USB zu einem modifizierten Linksys NSLU2 Gerät gesendet und gespeichert. Jeder der Nodes (ein MCU) generiert einen Datenfluss von 180 KB/s. Besonders im Fokus stand in diesem Projekt der Fakt, dass mehrere MCUs gleichzeitig vermessen werden und somit ein realistisches Szenario für Sensornetzwerke geschaffen werden kann. 3.4. SPOT SPOT, ein Ansatz auf den Jahr 2007, verfolgt das Ziel, mit einem geringen Budget möglichst genaue Messungen zu erstellen[8]. Gemessen wird hier integrativ, aber im Ge- gensatz zu MSP430 EnergyTrace nicht mit einer wechselnden Kondensatorschaltung, sondern mit einem Voltage-to-frequency converter, einem analogen Wandler von einer 12
3.4 Literatur
Spannung zu einer Frequenz. Diese Frequenz kann mit einen Mikrocontroller digital er-
fasst und der Stromverbrauch ermittelt werden. Die Samplingfrequenz beträgt 10kHz.
Die Auflösung der Messung wird mit < 1µA angegeben, da die Energiemenge ausschlag-
gebend ist und nicht die Taktfrequenz wie bei einem ADC.
Bei diesem Projekt wurde darauf geachtet, mit COTS ICs(Integrated Circuit, Inte-
grierter Schaltkreis) zu arbeiten. Deshalb waren die Kosten geringer als 25$ (im Jahr
2020 ca. 31$). Dennoch ist die Hardware nicht fertig gebaut verfügbar. Diese ist aber für
dauerhaften Einsatz in Live-Systemen bzw. zur Online-Modellierung gedacht und nicht
nur als Testbed-Umgebung.
134. Konzept
Dieses Kapitel erläutert zu Beginn die zwei, bzw. drei grundsätzlichen Ideen zur Energie-
messung mit COTS Hardware. Alle der folgenden Ansätze nutzen MSP430 EnergyTrace
zur Energiemessung und unterscheiden sich lediglich in der Art der Synchronisierung.
Es werden verschiedene Konzepte erläutert und implementiert um zu ermitteln wel-
cher der Lösungsansätze zuverlässige und akkurate Energiemodelle erstellt.
Das Grundproblem besteht darin, dass EnergyTrace nur die Zeitreihe mit gemessenen
Energiewerten zurückgibt, diese stehen in keinerlei Verbindung mit dem Prozessorstatus,
UART oder dem Logic Analyzer. Die Synchronisierung des Datenstroms von Energy-
Trace mit den Transitionen und Zuständen ist das Hauptthema dieser Arbeit. Die dafür
entwickelte Lösung ist, mit Synchronisierungspunkten zu arbeiten, wie in Abschnitt 4.4
vorgestellt.
USB
Computer Logic Analyzer
USB
IO Pin
MSP430 Launchpad
IO Ports / I²C / SPI etc.
Verbraucher
Abbildung 4.1.: Schematische Darstellung des Messaufbaus. Bei der UART/Timer Va-
riante wird der graue Teil nicht verwendet.
Das Konzept dieser Arbeit lässt sich, wie in Abbildung 4.2 dargestellt, in verschiede-
ne Abschnitte gliedern. Der erste Teil bezieht sich auf die Benchmarkerstellung, bei der
Markierungen für die spätere Synchronisierung erstellt werden. Der zweite Teil umfasst
die Datenaufnahme, dort liegt der Fokus hauptsächlich auf der Kommunikation mit dem
Logic Analyzer. Der dritte Teil beinhaltet die Synchronisierung der Daten mit anschlie-
ßender Zuordnung zu den Zuständen und Transitionen. Danach werden die Daten zur
weiteren Analyse dfatool übergeben.
Alle Abschnitte wurden in Python implementiert, sodass sie von dfatool verwendet
werden können. Die folgenden Konzepte basieren auf den existieren Projekten multipass
(Bibliotheksbetriebssystem ohne Scheduling) und den von dfatool generierten Bench-
marks.
15Konzept 4.2
Benchmark-
Datenaufnahme Synchronisierung Zustandsanalyse Auswertung
generierung
Abbildung 4.2.: Strukturerläuterung in Form eines Datenflussdiagramms. Der graue Be-
reich kennzeichnet die existierenden Bereiche des dfatools.
4.1. Logic Analyzer
g() h()
Abbildung 4.3.: Darstellung Synchronisierungssignale (blau) und Funktionsaufrufe
(orange, rot, grün) mit anschließender Wartezeit (Zustände).
Bei diesem Synchronisierungsansatz werden an Funktionsaufrufen im Code, bzw. Tran-
sitionen im Automaten, jeweils Änderungen am Logikpegel vorgenommen. Am Anfang
einer Transition wird der angegebene IO Pin auf HIGH (3,3V ) gesetzt, wenn die Transi-
tion beendet ist, wieder auf LOW (0V), siehe Abbildung 4.3. Diese Transitionen werden
vom Logic Analyzer aufgezeichnet und ebenso wie die EnergyTrace Daten per USB an
den Computer weitergegeben. Eine Darstellung des Aufbaus ist in Abbildung 4.1 zu
sehen.
Im Gegensatz zu den folgenden Varianten wird der Logic Analyzer als externe Hard-
ware benötigt. Dafür hat dieser eine höhere Auflösung und so sind auch Transitionen
zuordenbar. Außerdem wird im Gegensatz zu den anderen Varianten, am Launchpad
der geringste Overhead erzeugt, der die Messung beeinflussen könnte. Die Instruktionen
um einen IO-Pin zu schalten sind nur wenige Prozessorzyklen lang. Implementations-
technisch muss im Gegensatz zu den anderen Varianten, die Schnittstelle zum Logic
Analyzer geschaffen werden.
4.2. UART / Timer
Das Konzept bei diesem Synchronisierungsansatz ist, dass ein Prozessorzähler verwendet
wird. Dieser wird gestartet, wenn ein Zustand oder eine Transition beginnt und am Ende
164.4 Konzept
gestoppt. Im Anschluss werden diese Werte per UART an den Computer übertragen,
daraus entsteht ein Verlauf ähnlich zu Abbildung 4.3.
Im Gegensatz zum vorherigen Ansatz kommt hierbei der Logic Analyzer nicht zum
Einsatz, beide Datenströme werden über die gemeinsame USB Schnittstelle gesendet.
Dies hat zum einen den Vorteil, dass keine externe Hardware benötigt wird, allerdings
ist die Genauigkeit mitunter nicht so vorhanden, wie bei der Verwendung eines Logic
Analyzers. Die Daten, die später dem Synchronisierungsalgorithmus zur Verfügung ge-
stellt werden, müssen zunächst noch angepasst werden, da die Daten, die über UART
transferiert werden, lediglich die Längen der Transitionen und Zustände sind. Außerdem
vergeht zwischen des Stopp- und Startaufrufs des Hardwaretimers Zeit. Diese kann dazu
führen, dass die Synchronisierungsdaten nicht mehr mit den Energiedaten übereinstim-
men. Es könnten auch Schwierigkeiten durch die Ausführungszeit des einzelnen Start-
und Stoppaufrufs entstehen.
4.3. Barcode
Das Konzept der Barcodevariante besteht darin, Informationen zur Codeposition über
Barcodes im Energieverbrauch zu übermitteln. Diese Barcodes können durch das An-
steuern fester Verbraucher, wie den LEDs des LaunchPads, über einen bestimmten
Zeitraum erzeugt werden. Vorteilhaft ist hier, dass keine parallelen Datenströme mit
verschiedenen Zeitstempeln existieren, da sowohl die Synchonisierungsdaten, als auch
die Energiedaten über EnergyTrace gesendet werden. Zusätzlich wird hier, wie bei der
UART/Timer Variante keine externe Hardware benötigt. Gerade bei Transitionen, die
nur wenige Prozessorzyklen bzw. wenige Mikrosekunden lang sind, könnten aber Genau-
igkeitsverluste auftreten. Für die Übertragung der Barcodes wird Zeit benötigt, sodass
diese eindeutig erkennbar sind. Diese Zeit verlängert die Benchmarkausführung im Ge-
gensatz zu den anderen vorgestellten Varianten deutlich.
Diese Methode wird in dieser Arbeit nicht weiter verfolgt, da es vorerst keine sinn-
vollen Vorteile gegenüber der UART Version gibt. Für den Nutzer ist es prinzipiell
irrelevant, welche Daten über den USB-Port versendet werden.
4.4. Synchronisierung
Die Synchronisierung ist notwendig, um Zustände ihrem korrespondierendem Energie-
messbereich zuzuordnen. Die Daten, die vom Logic Analyzer oder UART per USB an den
PC gesendet werden, werden im Folgenden Synchronisierungdaten genannt. Grundidee
der Synchronisierung ist, dass es am Anfang als auch am Ende einen Synchronisierungs-
punkt gibt. Dieser Punkt ist sowohl in der Messung von EnergyTrace als auch in den
Synchronisierungdaten zu erkennen und kann mithilfe fester Verbraucher wie den LEDs
erzeugt werden.
Um diese Erkennung möglichst präzise zu gestalten, sollte sich dieser Punkt von nor-
malen Zuständen abgrenzen. Dies kann mithilfe von drei Faktoren entschieden werden:
Dauer, Energiebedarf und Position. Die Dauer sollte ausreichend gewählt sein, sodass
sie länger ist als die eines Zustands. Der Energieverbrauch sollte möglichst hoch sein, um
17Konzept 4.4 nicht mit einem Zustand verwechselt zu werden. Selbst wenn innerhalb des Benchmarks erneut Stellen als Synchronisierungspunkte erkannt werden, ist dies nicht ausschlag- gebend, da in der Liste der möglichen Synchronisierungspunkte der erste Eintrag als Startpunkt, bzw. der Letzte als Endpunkt gewertet werden kann. Mithilfe des ersten Synchronisierungspunkts ist es möglich, den Versatz, den Star- toffset, am Anfang zu berechnen. Dazu wird die Differenz des Zeitstempels des ersten Synchronisierungspunkts aus EnergyTrace mit dem zugehörigen Zeitstempel des Logic Analyzers bzw. der UART Aufzeichnung gebildet. Diese Differenz wird auf alle Zeit- stempel der Synchronisierungdaten angewendet, um diese passend auf der Zeitachse zu verschieben. Nach einigen Tests der Synchronisierung schien der Drift linear approximierbar zu sein. Mit dem zweiten Punkt ist es möglich, den linearen Drift zu berechnen und damit die Synchronisierungdaten zu stauchen oder strecken. Dazu wird der Zeitbereich zwi- schen den Synchronisierungspunkten in den Synchronisierungdaten mit den Synchro- nisierungspunkten aus EnergyTrace verglichen. Daraus entsteht ein Faktor, der wieder auf alle Zeitstempel der Synchronisierungdaten angewendet werden kann. Damit wer- den diese den Synchronisierungspunkten angeglichen. Dies funktioniert nur bei linearem Drift, wie er in diesem Fall aufgetreten ist. Falls der Drift nicht der Form f (t) = a · t + b folgt, wobei f (t) ein EnergyTrace Timestamp ist, a der Driftfaktor und b der Startoffset, müssten weitere Synchronisierungspunkte eingefügt werden. Zwischen diesen Punkten könnte erneut die Approximation linearen Drifts verwendet werden, da bei kleineren Intervallen eine geringere Abweichung entsteht. Mit dem von dfatool generierten Benchmarkplan kann aufgelöst werden, welcher Zeit- bereich zu welchem Zustand bzw. zu welcher Transition gehört. Dadurch lässt sich die Durchschnittsleistung pro Zustand und Transition errechnen. 18
5. Implementierung
In diesem Kapitel wird die Softwarestruktur inklusive der Implementierung der Konzepte
aus dem vorherigen Kapitel vorgestellt. Diese Arbeit lässt sich, wie im Konzept erwähnt,
in mehrere Bereiche aufteilen, der Benchmarkerstellung, gefolgt von der Datenaufnahme
und schlussendlich die Synchronisierung. Nach der Synchronisierung wird die Auflösung
der Zustände und die Einbindung in dfatool vorgestellt. Abschließend wird erläutert,
welche Algorithmen zur potentiellen Verbesserung entwickelt wurden.
Um während der Programmierung und Auswertung einen Überblick der Synchroni-
sierung zu erhalten, wurde die Möglichkeit eingebaut, die synchronisierten Daten zu
betrachten, inklusive annotierter Zustandsnamen.
Power in Watt
0.0175
1 2 3 With calculated Driftfactor
0.0150
0.0125
0.0100
0.0075
0.0050
0.0025
0.0000
0 2 4 6 8 10 12
time (s)
Abbildung 5.1.: Benchmark nach abgeschlossener Synchronisierung. 1-3 kennzeichnen
die Synchronisierungspunkte.
5.1. Benchmarkerstellung mit dfatool
Grundsätzlich wird bei dfatool ein Timer-Pin zur Synchronisierung bereits unterstützt,
da dieser auch für MIMOSA Messungen benötigt wird. Somit muss an dieser Stelle kein
Generierungscode verändert werden. Die Synchronisierungspunkte am Anfang und Ende
müssen noch hinzugefügt werden.
19Implementierung 5.2
...
ptalog . passTransition (16) ;
ptalog . startTransition () ;
r e s i s t i v e L o a d . switchTo1K0 ( ) ;
ptalog . stopTransition () ;
a r c h . sleep_ms ( 2 0 0 ) ; // P11MW
p t a l o g . dump ( 1 ) ; // n i c h t nach jedem Zustand
...
Listing 5.1: Auszug aus generiertem Benchmark Code.
Das Skript generate-dfa-benchmark.py wird aufgerufen, um mithilfe von dfatool Bench-
marks zu erstellen. Dieses Skript erstellt Benchmarkcode und teilt diesen gegebenenfalls
auf und flasht ihn auf den Mikrocontroller. Ein Ausschnitt des generierten Benchmark-
codes ist in Listing 5.1 zu sehen.
Die Klasse harness.py wurde um die Generierung der Funktion runLASync() erwei-
tert. Diese Funktion wird beim Start und Ende eines Benchmarks ausführt. Um sich
möglichst von anderen Zuständen abzugrenzen, wird ein hoher Energieverbrauch benö-
tigt, welcher durch die gleichzeitige Aktivierung beider LEDs auf dem LaunchPad er-
reicht wird. Diese verbrauchen auf dem verwendeten LaunchPad ca. 14,4mW , aufgrund
von fertigungsbedingten Schwankungen kann dieser Wert auf anderen Launchpads ab-
weichen. Dieser Zustand hält für eine Sekunde an, bevor die LEDs wieder ausgeschaltet
werden. Diese Synchronisierungspunkte sind in Abbildung 5.1 an den Markierungen 1-3
zu sehen.
Am Ende von jeder dfatool Messung entsteht ein Archiv. Dieses Archiv enthält die
Datei ptalog.json, welche den Benchmarkplan und alle Benchmarkeinstellungen um-
fasst, sowie alle von Energytrace erstellten *.etlog Dateien und bei der Verwendung
des Logic Analyzers die logic_output_log_*.json.
In der Datei ptalog.json werden Laufzeiten der Zustände und Transitionen gespei-
chert. Im Fall der Synchronisierung mit dem Timer wird bei Beginn einer Transition oder
eines Zustandes ein extra Hardwaretimer gestartet, mithilfe dessen die Laufzeiten ge-
messen werden können. Während der Übertragung der Daten vom Mikrocontroller zum
Computer kommt es zu einer Übertragungszeit, in der sich der Mikrocontroller nach
Logikpegel noch im vorherigen Zustand befindet. Diese kann mit der Zustandslänge, die
bei der Benchmarkerstellung angegeben wurde, herausgerechnet werden.
205.3 Implementierung
5.2. Sigrok
DataInterface
wird nur bei Messungen
ohne dfatool notwendig
SigrokInterface EnergyInterface
SigrokCLIInterface SigrokAPIInterface
Abbildung 5.2.: Vererbungshierarchie der groben Softwarestruktur bei der Datenauf-
zeichnung.
Die Softwarestruktur, wie in Abbildung 5.2 zu sehen, ist eine Vererbungshierarchie,
wobei DataInterface die Hauptklasse ist. So lassen sich weitere Implementationen in
diese Struktur einbringen. Die Klasse SigrokInterface stellt Einstellungen wie Treiber
und Samplingfrequenz zur Verfügung, die von beiden Subklassen benötigt werden.
Die Daten, die sowohl von sigrok-cli als auch von der API kommen, sind nur aktuelle
Werte, d.h. bei einer Auflösung von 1M Hz wird pro Zeitstempel ein Sample an allen
Eingängen gemessen. Das bedeutet, bei 8 Logic Analyzer Eingängen, fallen pro Sekunde
1M B Daten an. Bei der API Variante wird diese per Callback über neue Datenpakete
informiert und anschließend ausgewertet. Das Stoppen der Messung gestaltet sich bei
der CLI Variante per Linux kill schwierig, die API bietet eine close() Methode. Um
die Datenverarbeitung zu erleichtern und Speicherplatz zu sparen, wird nach Ende der
Datenaufnahme ein simpler Kompressionsalgorithmus angewendet, sodass lediglich die
Zeitstempel gespeichert werden, bei denen sich der Logikpegel ändert. Bei der Vari-
ante mit CLI, wird ein Befehl (s. Listing A.1) ausgeführt und die entstandene Datei
danach ausgewertet. Diese Zeitstempel werden in der Datei logic_output_log_*.json
gespeichert.
5.3. Synchronisierung
Die Synchronisierung ist der wichtigste Teil dieser Arbeit. Diese lässt wie folgt aufteilen:
• Entfernen falscher Timingdaten
• Identifizieren der Synchronisierungspunkte
• Anwendung des Startoffsets auf die Timingdaten
• Anwendung des Drifts auf die Timingdaten
Werden die Logic Analyzer Messung und die EnergyTrace Messung nicht gleichzeitig
gestartet bzw. nicht rechtzeitig vom System gestoppt, werden am Anfang und Ende zu
viele Daten aufgezeichnet. Das passiert, wenn direkt im Anschluss eine Benchmarkwie-
derholung startet und diese bereits Flanken am IO Pin generiert. Diese Daten können
21Implementierung 5.3 in einer geeigneten Konfiguration herausgefiltert werden, indem die Abstände zwischen den Zeitstempeln des Logic Analyzers betrachtet werden. Wenn diese Abstände grö- ßer als das Warteintervall bei Zuständen(bspw. 200ms) und größer als der Start- und Endsynchronisierungspunkt(1000 ms) sind, kann davon ausgegangen werden, dass die Logic Analyzer Messung bereits beendet sein sollte. Alle nachfolgenden Daten werden verworfen. Einen Einfluss auf folgende Messungen hat dieser Vorgang nicht. Dies führt ansonsten zu nutzlosen Daten, da der Algorithmus zum Finden der Synchronisierungs- punkte mit falschen Grundannahmen arbeitet. Danach werden die Daten zunächst zwischengespeichert. Im weiteren Verlauf des Al- gorithmus werden diese Synchronisierungsdaten verändert. Diese rohen, unveränderten Daten werden noch für die Zeitmessung der Transitionen benötigt. Bedingt durch die Architektur gehören die eingefügten Synchronisierungspunkte nicht zum Benchmark und sind deshalb nicht in der ptalog.json enthalten. Deshalb werden diese vor der Auswertung der Timervariante relativ zum ersten bzw. letzten vorhandenen Punkt künstlich eingefügt. Zur Bestimmung der Synchronisierungspunkte innerhalb der Daten von EnergyTrace, werden alle Messpunkte durchiteriert, bis die Synchronisierungspunkte gefunden werden. Der im Folgenden beschriebene Algorithmus ist in Listing 5.2 zu sehen. Für den Algorithmus gibt es maßgebliche Einstellungen, wie die Mindestdauer ei- nes gefundenen Synchronisierungspunkts und die Mindestleistung. Diese Werte sind im diesem Fall self.power_sync_len = 1 und self.power_sync_watt = 0.012. Die Daten von EnergyTrace enthalten den Zeitstempel und die bis zu diesem Zeitstempel verbrauchte Energie. Diese Daten können wie in Listing 5.2 (Zeile 2-5) sichtbar in die Leistung umgerechnet werden. Zunächst wird pro Zeitstempel die vergangene Zeit berechnet, um daraus mithilfe der angegebenen Energie die Leistung zu berechnen. Teilweise ist die verwendete Energie laut EnergyTrace 0J, obwohl Zeit vergangen ist. Deshalb wird dieser Datensatz verwor- fen. In wie weit dies Einfluss auf die Auflösung hat, wird in Abschnitt 6.1 dargestellt. Wenn die Leistung größer als die Mindestleistung ist, wird dieser Zeitstempel als mögli- cher Start eines Synchronisierungspunkts gespeichert. Wenn die Leistung danach gerin- ger als die Mindestleistung ist, wird dieser Zeitstempel als mögliches Ende gespeichert. Wenn nach zwei aufeinanderfolgenden Messpunkten die Leistung immer noch unter der Grenze ist, wird überprüft, ob die Zeitdauer zwischen Start- und Endpunkt größer als die Mindestdauer ist. Falls ja, wird der Synchronisierungspunkt hinzugefügt. Die zwei Messpunkte, die unterhalb der Grenze liegen, werden toleriert, da es zu Ausreißern in den Daten von EnergyTrace kommen kann. In der Liste datasync_timestamps sind Tupel mit potentiellen Synchronisierungs- punkten vorhanden. Der erste Eintrag des Tupels enthält den Startpunkt des möglichen Synchronisierungspunkts, der zweite Eintrag den Endpunkt. Neben dem Energiebedarf und der Zeitdauer der Punkte wurde im Konzept zur Identifizierung die Position er- wähnt. Wie in Abbildung 5.1 sichtbar, sind jeweils der erste Eintrag in der Liste, sowie die letzten beiden, Synchronisierungspunkte. Wenn der generierte Benchmark ebenfalls einen Zustand haben sollte, der über der Mindestleistung und der Mindestdauer liegt, wird dieser nicht mitbetrachtet. 22
5.3 Implementierung
f o r i , e n e r g y t r a c e _ d a t a s e t i n enumerate ( s e l f . energy_data ) :
usedtime = energytrace_dataset [ 0 ] − last_data [ 0 ] # in microseconds
timestamp = e n e r g y t r a c e _ d a t a s e t [ 0 ]
usedenergy = energytrace_dataset [ 3 ] − last_data [ 3 ]
power = u s e d e n e r g y / u s e d t i m e ∗ 10 ∗∗ −3 # i n w a t t s
i f power > 0 :
i f power > s e l f . power_sync_watt :
i f s y n c _ s t a r t i s None :
s y n c _ s t a r t = timestamp
outliers = 0
else :
# Sync p o i n t o v e r or o u t l i e r s
i f o u t l i e r s == 0 :
p r e _ o u t l i e r s _ t s = timestamp
o u t l i e r s += 1
i f o u t l i e r s > s e l f . power_sync_max_outliers :
i f s y n c _ s t a r t i s not None :
i f ( p r e _ o u t l i e r s _ t s − s y n c _ s t a r t ) / 1_000_000 > s e l f .
power_sync_len :
datasync_timestamps . append ( ( s y n c _ s t a r t / 1_000_000
, p r e _ o u t l i e r s _ t s / 1_000_000 ) )
s y n c _ s t a r t = None
last_data = energytrace_dataset
Listing 5.2: Code zum Finden der Synchronisierungspunkte
Zum Ausgleich des Startoffsets wird die Differenz aus Soll- und Istwert auf jeden
Punkt angewendet.
Da bei der Timervariante die Synchronisierungspunkte künstlich erzeugt werden müs-
sen, stimmen bei der Driftberechnung die Dauer dieser Synchronisierungspunkte nicht
unbedingt mit der tatsächlichen Dauer überein. Deshalb werden die in Abbildung 5.1
orange markierten Stellen zur Synchronisierung verwendet, der Endpunkt von 1 und der
Startpunkt von 2.
Da nur die Synchronisierungsdaten verändert werden und nicht die Daten von Ener-
gyTrace, muss auf diese die folgende Formel für die Zeitstempel angewendet werden.
new_timestamp = ((old_timestamp - start_timestamp)* endFactor)+ start_timestamp
Der Code, um den Drift herauszurechnen, ist in Listing 5.3 zu sehen.
d e f a d d D r i f t ( s e l f , input_timestamps , end_timestamp , e n d _ o f f s e t ,
s t a r t _ t i m es t a m p ) :
# Add d r i f t t o d a t a p o i n t s
en dFactor = ( end_timestamp + e n d _ o f f s e t − s t ar t _ t i me s t a m p ) / (
end_timestamp − s t ar t _ t i me s t a m p
)
modified_timestamps_with_drift = [ ]
f o r x i n input_timestamps :
m o d i f i e d _ t i m e s t a m p s _ w i t h _ d r i f t . append (
( ( x − s t a rt _ t i m es t a m p ) ∗ endFactor ) + s ta r t _ ti m e s t a mp
)
return modified_timestamps_with_drift
Listing 5.3: addDrift() Funktion.
23Implementierung 5.5
Energy
0.007
With calculated Driftfactor
0.006
0.005
0.004
200 ms
0.003
0.002
0.001
0.000
6.0 6.1 6.2 6.3 6.4
Abbildung 5.3.: Ein Zustand mit UART Sendevorgang. Der orange markierte Bereich
zeigt die Übertragungszeit, solange verbleibt der Logikpegel im vorhe-
rigen Zustand.
Zur Bestimmung der Leistung pro Zustand bzw. Transition werden die Durchschnitts-
werte der Leistung innerhalb der Intervalle errechnet.
Teilweise werden UART Daten während des Benchmarks zur Synchronisierung an
dfatool geschickt, dies passiert jedoch nicht nach jedem Zustand, siehe Listing 5.1. Das
Verhalten wird im Zeit- und Energiebedarf deutlich, siehe Abbildung 5.3. Beim Aufruf
durch dfatool werden die Einstellungen des Benchmarks ausgelesen, wie die Dauer ei-
nes Zustands. Damit können dann Datensätze ignoriert werden, welche einen Zustand
beschreiben, der länger als die Solldauer ist.
5.4. Einbindung Auswertung in dfatool
Diese Arbeit wird über die Vererbungshierarchie von dfatool eingebunden. Die Bench-
markgenerierung wird in der Datei harness.py eingefügt, indem abgefragt wird, ob die
Option --energytrace=sync gesetzt ist. Die Datei runner.py wurde um eine Subklas-
se von EnergyTraceMonitor erweitert, die Klasse EnergyTraceLogicAnalyzerMonitor.
Diese startet am Anfang der Messung den Logic Analyzer und gibt die generierten Daten
am Ende zurück. Die Datei loader.py wurde um zwei Klassen, EnergyTraceWithTimer
und EnergyTraceWithLogicAnalyzer erweitert. Diese bereiten die Daten auf und geben
sie an die Klasse DataProcessor weiter.
245.5 Implementierung
5.5. Algorithmen zur Genauigkeitsverbesserung
Die Dauer einer Transition liegt meistens bei 40µs, kann diese Dauer aber auch un-
terschreiten. Das Intervall der Datensätze von EnergyTrace ist 3,7kHz1
= 270µs. Ein
Intervall des Logic Analyzers ist ca. 1M Hz = 1µs. Aufgrund dieses starken Unterschieds
1
ist es theoretisch möglich die niedrige Frequenz von EnergyTrace auszugleichen, solan-
ge angenommen wird, dass die Leistung während einer Transition oder einem Zustand
konstant ist. Da ein Datensatz von EnergyTrace immer das Energieverhalten der letzten
270µs wiedergibt, kann die Energie anhand der Synchronisierungsdaten genauer berech-
net werden. Wie in Abbildung 5.4 zu sehen, wird hierfür für die Leistung kurz vor und
nach der Transition des letzten bzw. nächsten Datenpunktes angenommen. Mathema-
tisch betrachtet bleibt das Integral unter der Leistung gleich groß.
20 Ursprüngliche Daten
Veränderte Daten
18 Ursprüngliche Datenpunkte
16
14
Leistung [mW]
12
10
8
6
4
0 2 4 6 8 10 12
Zeit [s]
Abbildung 5.4.: Wirkweise des Algorithmus für Genauigkeitsverbesserung, in grün die
Synchronisierungssignale(z.B. vom Logic Analyzer).
Des Weiteren wurde ein Algorithmus untersucht, der Peaks im Energiebedarf den tat-
sächlichen Transitionen zuordnet, die laut Benchmarkplan noch einige Mikrosekunden
hinter den Peaks liegen sollten.
Diese beiden Algorithmen sind nur rudimentär implementiert worden. Deren Effizienz
bzw. Einsatzkraft wird in der Evaluation geklärt.
25Sie können auch lesen
