Download - Fakultät 06 - Hochschule München

BACHELORARBEIT
Entwicklung eines Loggers zur autonomen
Überwachung und kabellosen Übertragung von
Umgebungsparametern für Crashtest-Dummys
Hochschule München
Fakultät für angewandte Naturwissenschaften und Mechatronik
Studiengang Physikalische Technik
Eingereicht von:
Stefan Roland Kuhn
Matrikelnummer: 05361909
Betreuer:
Dipl.-Ing. Matthias Winkler
Dipl.-Ing. Nikolaus Hofbauer
Erstprüfer:
Zweitprüfer:
Prof. Dr. Ullrich Menczigar
Prof. Dr. Alexander Steinkogler
Tag der Einreichung: 31. Juli 2013

Inhaltsverzeichnis
Kurzfassung
Abstract
iii
iv
1 Einleitung 1
1.1 Crashtests und Dummys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 M=BUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Systemabgrenzung 7
2.1 Kundenanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Funkübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Modularität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Gesetze und Vorschriften . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Funkfrequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Temperatur und Luftfeuchte . . . . . . . . . . . . . . . . . . . . . 9
2.3 Kompatiblität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Zusammenfassung der Rahmenbedingungen . . . . . . . . . . . . . . . . . 11
3 Systemaufbau 12
3.1 Grundaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Logger Basisstation . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Basisstation CrashSoft . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Elektronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Basisstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Komponentenauswahl 17
4.1 Wireless-Tranceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i

Inhaltsverzeichnis
ii
4.2 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Luftfeuchte-Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Temperatur-Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Schaltung 22
5.1 Funkmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1 Messung der Akkuspannung . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2 Anbindung der Sensoren . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.3 Externe Spannungsquelle und Anbindung Inklinometer . . . . . . . 24
5.2 Spannungsversorgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6 Software 26
6.1 Übertragungsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Funkmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Basisstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7 Validierung 30
7.1 Inbetriebnahme des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Strommessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3 Störungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.4 Reichweite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5 Genauigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.6 Vergleich mit Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . 34
8 Fazit und Ausblick 35
Literatur 37
Abbildungsverzeichnis 40
Tabellenverzeichnis 41
Anhang 41
A Bauform 42
B Schaltplan - Digitalteil 43
C Schaltplan - Stromversorgung 44

Kurzfassung
Ziel dieser Arbeit ist es einen Logger zu entwickeln, welcher unabhängig und selbständig
Umgebungsdaten misst. Diese sollen nur zwischengespeichert und regelmäßig kabellos
Übertragen werden. Der Logger wird bei der Vorbereitung von Crashtests bzw. der dort
verwendeten Dummys eingesetzt, um zu überprüfen ob bestimmte Regularien eingehalten
werden. Die zu messenden Daten sind Temperatur, Luftfeuchte und der Winkel, den der
Dummy im Fahrzeugsitz einnimmt. Dazu werden die Grenzen des Systems auf Basis von
Vorschriften und Kundenanforderungen festgelegt. Daraus wird ein System erstellt und in
Hard- und Software umgesetzt. Am Prototyp werden abschließen Tests durchgeführt, um
zu validieren ob dieser wie geplant funktioniert.
iii

Abstract
The objective of this thesis is to develop a logger which measures, stores and transfers
environmental data independently and autonomously. These should stored be only temporary
and transmitted periodically by wireless communication. The logger is used for the
preparation of crashtests or more precisely crashtest-dummys to check whether certain
regulations are fulfilled. The data to be measured are temperature, humidity and the angle
of the dummy in the vehicle seat. For this purpose, limits are set according to established
regulations or customer requirements. From this, a system is created and implemented in
hard- and software. Finally the prototype is tested to validate if it works as intended.
iv

1 Einleitung
Das Ziel von Crashtests ist es Fahrzeuge sicherer zu machen und dadurch Menschenleben
zu retten. Durch gezielte Crashversuche wird die Wirkung auf den menschlichen
Körper untersucht. Dazu werden Crashtest-Dummys mit Sensoren bestückt und in die
Versuchsfahrzeuge gesetzt. Anhand der Auswertung der Messdaten, kann auf die Folgen
für den Menschen zurückgeschlossen werden. Um dies zu ermöglichen müssen die Versuche
vergleichbar sein und es darf keinen Unterschied machen, auf welcher Crashanlage getestet
wird. Die Bedingungen für die Tests müssen deshalb die gleichen sein. Dazu gehören nicht
nur offensichtliche Dinge wie das Verwenden des selben Fahrzeugs und Dummys, sondern
auch Umgebungseinflüsse wie Temperatur und Luftfeuchte.
1.1 Crashtests und Dummys
Die ersten Crashtests wurden vor über 50 Jahren durchgeführt. Damals bereitete die
Beschleunigung und das Lenken des Versuchsfahrzeugs noch erhebliche Probleme. Heute
steht man ganz anderen Herausforderungen gegenüber. Auch die Technik und Versuchsdurchführung
hat sich seitdem extrem verändert. Der Grundsatz hingegen blieb der selbe:
Mehr Sicherheit.
Bei den ersten Versuchen wurden die Fahrzeuge
gegen eine Wand gelenkt. Im Gegensatz zu dem
heutigen Frontal Impact wurde das Fahrzeug nicht
nur teilweise (40 %) gegen die Barriere gerollt,
sondern es traf mit der kompletten Breite darauf.
Auch war die Barriere ein massiver Block und nicht
wie heute ein verformbares Hindernis. Durch Untersuchung
realer Unfälle kamen über die Jahre
weitere Versuchsszenarien hinzu und die bestehenden
wurden angepasst und verbessert. Dabei wurde
z.B. beim Frontal Impact die Trefferfläche auf 40
Abbildung 1.1: Crashtest mit einer
Heißwasserrakete (rechts, karriert) als
Antrieb, die nicht rechtzeitig abbremste.
[1]
% reduziert, da dies in der Realität weit häufiger vorkommt. Die Antriebe entwickelten
sich von ungenauen Seilwinden über Heißwasserraketen (Siehe Abb. 1.1) bis hin zu den
heutigen Antrieben mit Führungsschienen.
Auch die Messtechnik entwickelte sich seither immer weiter. Es wurden aber auch damals
schon die Filmaufnahmen einer Highspeed-Kamera, die Schäden am Fahrzeug und die
Daten der Beschleunigungssensoren ausgewertet. Dies brachte eine viel detaillierte Analyse
als die eines Unfallautos, da der tatsächliche Ablauf genau beobachtet werden konnte.
1

1.1 Crashtests und Dummys 2
Später kamen immer mehr Sensoren am und im Fahrzeug hinzu. Zuerst wurde auch
nur ein Dummy verwendet und die Beifahrer durch Sandsäcke oder Schaufensterpuppen
simuliert. Auch die Dummys wurden immer ausgefeilter und mit mehr und genauerer
Sensorik bestückt. [1, 2, 3]
Bei einem Crashtest wird unter kontrollierten Bedingungen ein möglichst realitätsnaher
Unfall nachgestellt. Dabei wird ein Fahrzeug mit Sensoren versehen und ein oder mehrere
Messpuppen (Crashtest-Dummys) in den Sitzen positioniert, welche wiederum mit Sensoren
bestückt sind. Dieses so vorbereitete Fahrzeug wird dann gegen eine Messwand, ein anderes
Fahrzeug oder über eine Rampe gelenkt. Nachfolgend eine Auswahl an Versuchen:
• Frontal Impact (siehe Abb. 1.2):
Bei einem Frontalaufprall handelt es sich um
einen Zusammenstoß mit einer deformierbaren
Barriere, die dem dynamischen Verhalten eines
Fahrzeuges nachempfunden ist und den Kollisionspartner
darstellt. Dabei trifft das Fahrzeug
versetzt auf die Barriere (40 % Offset). [4]
Abbildung 1.2: Darstellung eines
Frontalaupralls (Rechtslenker). [4]
• Car to Car Side Impact (siehe Abb. 1.3):
Ein Seitenaufprall durch ein anderes Fahrzeug
wird durch eine bewegliche, verformbare Barriere,
die auf die Fahrertür des stehenden Versuchsfahrzeugs
auftrifft, simuliert. [5]
Abbildung 1.3: Darstellung eines
Seitenaufpralls (Rechtslenker). [5]
• Pole Side Impact (siehe Abb. 1.4):
Der Seitenaufprall auf einen Pfahl oder auch
Pfahlaufprall, ist ein Versuch bei dem ein Aufprall
auf einen Baum oder ähnliches simuliert
wird. Dabei wird das Fahrzeug mit geringerer
Geschwindigkeit als bei einem Car to Car Side
Impact auf einen Pfahl zubewegt. [7]
Abbildung 1.4: Darstellung eines
Pfahlaufpralls (Rechtslenker). [6]

1.1 Crashtests und Dummys 3
• Pedestrian Protection (siehe Abb. 1.5):
Beim Fußgängerschutz werden Teilbereichtests
durchgeführt, um die Wiederholbarkeit sicher
zu stellen. Dafür gibt es drei Komponenten
die Unterschenkelform, die Oberschenkelform
und die Kopfform. Für diese werden jeweils die
Schutzwirkungen der Aufprallbereiche untersucht
und ausgewertet. [8]
Abbildung 1.5: Darstellung eines
Fußgängeraupralls. [8]
• Rear Impact:
Der Heckaufprall wird zur Untersuchung des Schutzes vor Wirbelsäulenverletzungen
speziell dem Schleudertrauma verwendet. Dabei trifft entweder eine Barriere, ähnlich
dem Side Impact, auf das Heck des Versuchsfahrzeugs oder das Fahrzeug wird gegen
eine Barriere, wie beim Frontal Impact, gerollt.
• Rollover Test:
Bei einem Überschlagstest wird das Fahrzeug z.B. über eine Korkenzieher-Rampe
gerollt, soll sich dadurch Überschlagen und auf dem Dach zum stehen kommen.
Nicht alle Versuche werden mit einem Fahrzeug durchgeführt, für einige Tests ist es
ausreichend, wenn ein Schlitten mit darauf montierten Komponenten verwendet wird.
Der Schlitten wird dabei kontrolliert beschleunigt und gebremst. Um dabei möglichst
nah an einen Crashversuch bzw. einem realen Unfall heran zu kommen, werden dafür die
Daten eines Versuchs mit Fahrzeug ausgewertet und daraus ein Beschleunigungs- bzw.
Verzögerungsprofil erstellt. Damit können die Kräfte beim Aufprall auf das Fahrzeug
nachgebildet werden. Diese Versuche werden für das Testen von Gurtbändern und Sitzen
verwendet um die viel höheren Kosten eines echten Crashs zu vermeiden und dennoch
vergleichbare Ergebnisse zu bekommen.
Das Kernstück moderner Crashtest bilden die Crashtest-Dummys. Denn durch sie
können die Auswirkungen auf den menschlichen Körper abgeschätzt werden. Dadurch
können Fahrzeuge und deren Sicherheitsmaßnahmen in Schutzklassen eingeteilt werden.
Abbildung 1.6: Mögliches Ergebnis
eines EuroNCAP Crashtests. [4]
Es werden dabei die Schutzwirkungen auf die einzelen
Körperteile (siehe Abb. 1.6) analysiert und
beurteilt.
Der erste Dummy (Abb. 1.7) wurde 1949 für
die US Airforce entwickelt um die Auswirkungen
von Schleudersitzen zu erfassen. Der erste für die
Automobilindustrie wurde hingegen erst 1966 von
den Alderson Research Laboratories entwickelt und

1.2 M=BUS 4
produziert. Das Problem der ersten Dummys war, das keine einheitliche Produktion möglich
war.
Deshalb konnten auch keine vergleichbaren Messergebnisse gesammelt werden. Der nächste
Schritt auf der Leiter zu den heutigen Dummys war 1968 der Hybrid I von GM, der viele
der Probleme der bisherigen Dummys ausmerzen konnte.
Es wurde dann auch der Hybird II und der Hybrid III entwickelt,
wobei der Hybrid III auch noch heute verwendet wird.
Dazu kamen noch mehrere andere Dummys, da die genannten
nur für den Frontalaufprall geeignet sind. Im Gegensatz zu den
ersten Dummys, die nur drei Beschleunigungssensoren verbaut
hatten sind die aktuellen Dummys mit unzähligen Sensoren
bestückt. Dazu gehören auch Kraft- und Momentaufnehmer
um z.B. den Druck auf die Rippen des Dummys und deren
Verdrehung zu messen.
Die Dummys werden in
• Frontal Impact Dummys,
• Side Impact Dummys (SID) und
• Rear Impact Dummys (RID)
unterteilt. Zudem werden die Dummys noch aufgrund ihres
Geschlechtes, ihres Alters und des Gewichts unterschieden. [10,
11]
1.2 M=BUS
Abbildung 1.7: Der
erste Crashtest-Dummy
(Sierra Sam). [9]
Eine bei MESSRING gültige Beschreibung von M=BUS wurde von Christoph Schwager
als Teil seiner Bachelorarbeit verfasst. Der folgende Ausschnitt daraus beschreibt M=BUS
in groben Zügen.
„Das aktuelle M=BUS Datenerfassungssystem der Firma MESSRING stellt ein dezentrales,
explizit für die Anwendung in Crashversuchen entwickeltes, Datenerfassungssystem
dar. Dabei handelt es sich um ein Zweidraht-Bus-System, welches eine
dezentrale Datenerfassung ermöglicht. [. . .] Bei diesen Versuchen werden die Sensoren
an sogenannte Logger angeschlossen. Diese sind über ein Hochfrequenzkabel, das
M=BUS Kabel, miteinander verbunden. Der Bus Master, der in diesem Fall das
Gateway ist, versorgt die Busteilnehmer mit elektrischer Spannung und dient zur
Kommunikation zwischen der hauseigenen Software Crashsoft 3 und den einzelnen
Loggern. [. . .] Durch den einfachen Plug-and-Play Aufbau des Bussystems, durch die
kleine und kompakte Baugröße sowie durch die dezentrale Einsatzmöglichkeit wird
eine maximale Flexibilität bei der Instrumentierung des Unfallversuchs erreicht.“ [12]

1.3 Motivation 5
In Abbildung 1.8 ist eine mögliche M=BUS Messkette ohne Dummy dargestellt. Darauf
sind ein Gateway und mehrere, über M=BUS Kabel verbundene, Logger zu erkennen. Die
Logger befinden sich dabei, im Normalfall, im Inneren des Dummys.
Abbildung 1.8: M=BUS Messkette mit Gateway (links) und InDummy-Loggern (rechts). [11]
1.3 Motivation
Trotz allen Weiterentwicklungen der Dummys konnten einige Probleme noch nicht behoben
werden. Dazu gehört die Temperaturabhängigkeit der Dummys und deren Sensorik. Die
verwendeten Materialien für das „Fleisch“ und die „Knochen“ der Dummys sind teils
extrem temperaturabhängig. Als Beispiel kann der Kopfdrehwinkel der Dummys in einigen
Fällen bis zu 1° (Winkel) pro K (Temperatur) abweichen. Dieses und weitere temperaturabhängige
Probleme stellte Markus Weippert in seiner Diplomarbeit „Untersuchung des
Temperaturverhaltens von Seitenaufpralldummies“[13] fest. Zudem ist es wichtig den Dummy
immer gleich im Fahrzeug zu positionieren, denn auch hier sorgen kleine Abweichungen
für unterschiedliche Messergebnisse.
Wie bei allen Versuchsdurchführungen wird auch bei Crahstests ein hoher Wert auf
Vergleichbarkeit gelegt. Dafür müssen alle Parameter, die die Messergebnisse, beeinflussen
gleich sein. Um dies zu gewährleisten, werden diese Einflüsse gemessen und den Messergebnissen
beigelegt. Zu den Haupteinflüssen zählt dabei die Temperatur. Für vergleichbare
Ergebnisse muss dazu an jeder Position des Dummys die selbe Temperatur herrschen. Da
unterschiedliche Komponenten nicht die selbe Zeit benötigen um eine Temperatur anzu-

1.4 Ziel 6
nehmen muss der Dummy eine längere Zeit bei einer bestimmten Temperatur aufbewahrt
werden, um1 eine konstante, über den Dummy gleiche Temperatur zu gewährleisten. Ein
weiterer wichtiger Einfluss ist die Positionierung des Dummys im Sitz des Fahrzeuges.
Bisherige Messsysteme, die diese Umgebungsparameter bestimmen, sind groß und
umständlich zu verkabeln. Deshalb soll ein Messystem entwickelt werden, dass die vor dem
eigentlichen Versuch zu überwachenden Parameter aufnimmt. Das zu entwickelnde System,
im weiteren Logger genannt, soll kompakt und möglichst ohne Verkabelung einsetzbar
sein. Es soll die Temperatur und Luftfeuchte über einen längeren Zeitraum messen und
einen einfachen Zugriff zu den gemessenen Daten bereitstellen. Dafür wird ein Logger
benötigt, der die Messdaten selbständig aufnehmen und speichern kann. Es muss eine
ständige Überwachung gewährleistet werden, um schnell reagieren zu können, sollte sich
der Dummy in den Stunden vor dem Test nicht in den Spezifikationen liegen.
1.4 Ziel
Das Ziel dieser Arbeit ist das Entwickeln eines Loggers, der die Umgebungsdaten bei einem
Crashtest aufnehmen und speichern kann. Dafür muss zuerst festgestellt werden, welche
Randbedinungen der Logger zu erfüllen hat. Danach wird der Systemaufbau festgelegt und
auf dessen Basis die Hard- und Software entwickelt und die dafür benötigten Komponenten
ausgesucht. Zuletzt wird ein Prototyp gefertigt und geprüft, ob er den Anforderungen
entspricht oder Fehler bei der Entwicklung aufgetreten sind.

2 Systemabgrenzung
In diesem Kapitel werden die Anforderungen an das Produkt besprochen. Dazu gehören
Überlegungen zu Gesetzgebung, Kundenanforderungen und Kompatibilität zu bereits
bestehenden Systemen.
2.1 Kundenanforderungen
2.1.1 Funkübertragung
Da der Dummy fünf Stunden vor dem Crashversuch (siehe 2.2.2) in einem bestimmten Temperaturbereich
liegen muss, um vergleichbare Ergebnisse zu erhalten, soll die Temperatur
ständig gemessen und gespeichert werden. Um zu überprüfen, ob sich der Dummy außeroder
innerhalb des Temperaturbereichs befindet, muss bei allen Konkurrenzprodukten
der Logger per Kabel mit einer Basisstation verbunden werden, um die Messdaten vom
Speicher herunterzuladen. Viel komfortabler wäre es, wenn die Messdaten jeder Zeit über
eine Software zur Verfügung gestellt würden. Dadurch wird lästiges Verkabeln der Sensoren
entfallen und Arbeitszeit gespart. Ein weiterer Vorteil davon ist, dass schon weit vor dem
Crashversuch erkannt wird, wenn der Dummy nicht in den geforderten Parameter liegt.
Dadurch können entsprechende Maßnahmen ergriffen werden.
Daher soll der Logger die gemessenen Daten regelmäßig kabellos an eine Basisstation
übermitteln.
2.1.2 Laufzeit
Der Logger soll möglichst lange ohne Eingriff betrieben werden können. Dabei muss aber
ein Kompromiss aus den Abmaßen des Energiespeichers und dessen Kapazität getroffen
werden. Der Stromverbrauch ist abhängig von den verwendeten Komponenten und somit
kann noch keine Aussage über die benötigte Kapazität getroffen werden. Deshalb wird die
Laufzeit vorerst auf zwei Monate festgelegt, da dies den üblichen Wartungsintervallen der
Messring Systeme entspricht. [11]
2.1.3 Modularität
Da der zu entwickelnde Logger alle Umgebungsparamter bzw. alle Parameter die zur
Einrichtung des Dummys notwendig sind erfassen soll, muss dieser modular gestaltet
werden. Es muss daher einfach möglich sein, für andere Versionen des Loggers, den Logger
7

2.2 Gesetze und Vorschriften 8
um zusätzliche Funktionen zu erweitern. So soll es in späteren Versionen möglich sein, die
Winkelposition der einzelnen Körperteile in Echtzeit anzuzeigen.
2.2 Gesetze und Vorschriften
2.2.1 Funkfrequenzen
Das zu Entwickelnde Produkt muss weltweit einsetzbar sein. Dazu ist es notwendig die
Vorschriften für die nutzbaren Frequenzen der jeweiligen Länder, zu kenTnen. Für das
Betreiben von Hochfrequenz-Geräten gibt es die ISM-Bänder (Industrial, Scientific and
Medical Band). Dies sind Freqenzbereiche die frei, ohne teure und aufwändige Lizensierung
verwendet werden dürfen. Die ISM-Bänder werden von der International Telecommunication
Union festgelegt und im 5. Artikel der Radio Regulations festgehalten. [14] Die
Vorschriften für die ISM-Bänder gelten weltweit, sind aber in Regionen eingeteilt für die
unterschiedliche Regelungen gelten. Diese Regionen sind:
• Region 1:
Europa, Afrika, Vorderasien (ohne Iran), Russland, Georgien, Armenien, Aserbaidschan,
Kasachstan, Turkmenistan, Usbekistan, Tadschikistan, Kirgisistan, Mongolei
• Region 2:
Nord- und Südamerika, Karibik, Grönland, Hawaii
• Region 3:
Australien, Neuseeland, Ozeanien und Asien ohne die unter Region 1 genannten
Länder Asiens
Zudem gibt es noch eine Unterteilung in gänzlich freie Frequenzen (nach RR 5.150) und
Frequenzen, für die ein Genehmigung, der zuständigen Autorität für das Gerät benötigt
wird (RR 5.138). Die durch ISM abgedeckten und somit wählbaren Frequenzen sind in
Tabelle 2.1 aufgeführt. [14]
Tabelle 2.1: Übersicht über die ISM-Bänder. [14]
Frequenzband Typ Region
6765 - 6795 kHz RR 5.138 weltweit
13553 - 13567 kHz RR 5.150 weltweit
26957 - 27283 kHz RR 5.150 weltweit
40.66 - 40.77 MHz RR 5.150 weltweit
433.05 - 434.79 MHz RR 5.138 Region 1
902 - 928 MHz RR 5.150 Region 2
2400 - 2500 MHz RR 5.150 weltweit
weiter auf der nächsten Seite

2.2 Gesetze und Vorschriften 9
2.2.2 Temperatur und Luftfeuchte
Fortsetzung Tabelle 2.1
Frequenzband Typ Region
5725 - 5875 MHz RR 5.150 weltweit
24 - 24,25 GHz RR 5.150 weltweit
61 - 61.5 GHz RR 5.138 weltweit
122 - 123 GHz RR 5.138 weltweit
244 - 246 GHz RR 5.138 weltweit
Im Gegensatz zu den Funkfrequenzen ist die Vorbereitung und das Einhalten von unterschiedlichen
Parametern, wie der Temperatur, nicht weltweit einheitlich geregelt. Es gibt
viele Institutionen die Vorschriften für Crashtests herausgeben. Die Wichtigsten sind
• Euro NCAP (European New Car Assessment Programe, Europa),
• U.S. NCAP (Vereinigte Staaten),
• IIHS (Insurance Institute for Highway Safety, Vereinigte Staaten),
• Latin NCAP (Latein Amerika und Karibik),
• JNCAP (Japan),
• C-NCAP (China),
• KNCAP (Korea),
• ASEAN NCAP (Vereinigung südostasiatischer Staaten),
• ANCAP (Australien und Neuseeland)
• ECE (Economic Commission for Europe, Europa),
• FMVSS (Federal Motor Vehicle Safety Standard, Vereinigte Staaten) und
• EG (Europäische Gemeinschaft, Europa). [11]
Im weiteren wird sich nur auf den Euro NCAP und C-NCAP bezogen, da sie zu den
strengsten Programmen zählen. In den NCAP Protokollen wird eine Temperatur von 20°
C bis 22° C vorgeschrieben. Die Temperatur des Dummy muss bis 5 Stunden vor dem Test
eine in diesem Bereich liegende Temperatur angenommen haben. Die Luftfeuchte muss
dabei in einem Bereich von 20% bis 70 % relativer Luftfeuchte liegen. [15, 16, 17]
Die Genauigkeit der Sensoren wird in DIN ISO 6487 [18] festgelegt. Sie wird auf ein
Drittel der Toleranz des Messbereiches festgelegt. Somit gilt für die Genauigkeit des

2.3 Kompatiblität 10
Temperatursensors:
Temperaturbereich = 20.0 °C − 22.0 °C
⇒ Toleranz = ±1 K
⇒ Genauigkeit = ±0.33 K
Um für zukünftige Anpassungen der Genauigkeit noch Luft zu haben und sich höhere
Genauigkeiten besser verkaufen wird deshalb eine höhere Genauigkeit als von der ISO
6487 gefordert gewählt (ca. ein drittel). Somit beträgt die gewünschte Genauigkeit ±0.1 K.
Bei der Luftfeuchte wird analog dazu vorgegangen. Die von der ISO 6487 geforderte
Genauigkeit liegt bei 8 % relativer Luftfeuchte und die gewünschte bei 3 % relativer
Luftfeuchte.
2.3 Kompatiblität
Das zu entwickelnde Produkt soll zu dem bestehenden System von MESSRING kompatibel
sein. Dazu gehört die Eingliederung in das M=BUS-System sowie das Verwenden von
ähnlichen, bereits in anderen Produkten verwendeten Komponenten. Auch das Funksystem
soll sich möglichst einfach in bestehende Infrastruktur integrieren lassen. Zudem soll die
Datenerfassung auch über die M=BUS Software durchgeführt werden. Außerdem muss
darauf geachtet werden, dass das Profil der anderen In-Dummy-Messtechnik entspricht.
Dabei ist zu beachten, dass bei der Verwendung in einem Dummy, der Platz beschränkt
ist und deshalb auf möglichst kleine Abmaße geachtet werden muss. Die vorgegebenen
Maße für das Befestigungsprofil sind in Anhang A angegeben.

2.4 Zusammenfassung der Rahmenbedingungen 11
2.4 Zusammenfassung der Rahmenbedingungen
In diesem Abschnitt werden die in genannten Anforderungen nochmals zur besseren
Übersichtlichkeit zusammengefasst.
• Kundenanforderungen:
– Funkübertragung:
Aufgrund der einfacheren Handhabung und ständigen Überwachbarkeit sollen
die Logger ihre Messdaten regelmäßig über Funk übertragen.
– Laufzeit:
Die Laufzeit soll ca. zwei Monate betragen.
– Modularität:
Der Logger soll das einfache hinzufügen und entfernen von Modulgruppen und
Sensoren erlauben.
• Gesetze und Vorschriften:
– Frequenzen:
Die verwendete Frequenz muss in einem der ISM-Bänder (siehe Tab. 2.1) liegen.
– Temperatur:
Die Temperatur muss bis 5 Stunden vor dem Crashtest im Bereich von 20° C
bis 22° C liegen. Die gewünschte Genauigkeit der Sensoren beträgt mindestens
±0.1 K.
– Luftfeuchte:
Die Luftfeuchte muss 5 Stunden vor dem Test in einem Bereich von 20% bis 70
% relativer Luftfeuchte liegen. Die gewünschte Genauigkeit beträgt mindestens
±3 % relativer Luftfeuchte.
• Kompatiblitäten:
– Befestigungsprofil:
Das Befestigungsprofil muss den Angaben in Anhang A entsprechen.
– M=BUS:
Der Logger muss zu dem bestehend M=BUS-System kompatibel sein.
– Kabellose Übertragung:
Die Messdaten müssen über die Messring Datenerfassung gesammelt werden
können.

3 Systemaufbau
In diesem Kapitel werden die Grundüberlegungen für den Systemaufbau getroffen. Um
den Logger entwickeln zu können, ist es notwendig zuerst das Gesamtsytem, in dem der
Logger eingesetzt wird, zu betrachten. Aus der daraus gewonnen Übersicht kann der grobe
Aufbau des Loggers erstellt werden. Die in diesem Kapitel getroffen Überlegungen stellen
die Basis für die weitere Entwicklung dar.
3.1 Grundaufbau
Der Grundaufbau bildet die Grundlage für die weiteren Abschnitte dieses Kapitels. Es
werden die Anwendungsfälle analysiert und daraus ein einfach erweiterbares System
erdacht.
Dabei entspricht der einfachste Anwendungsfall, dem Vorhandensein von nur einem
Dummy, der sich immer im selben Raum befindet. Dies wird aber eine seltene Ausnahme
darstellen. Meist werden mehrere Dummys verwendet, die sich in unterschiedlichen Räumen
oder sogar unterschiedlichen Gebäuden befinden und sich zwischen diesen bewegen. Es
wird vorkommen, dass an dem Dummy in Gebäude A Versuche durchgeführt werden,
dieser aber in Gebäude B kalibriert und überprüft wurde. Dieses Beispiel ist in Abbildung
3.1 für mehrere Gebäude und Dummys (Logger) dargestellt.
Abbildung 3.1: Mögliche Konfiguration einer größeren Crashanlage mit
mehreren Gebäuden.
12

3.2 Kommunikation 13
Somit kann es durch die räumliche Trennung zu Problemen mit der Reichweite der
kabellosen Übertragung kommen. Diese kann nur in einem kleinen Bereich (einem oder
mehreren angrenzenden Räumen) sichergestellt werden. Um dies zu umgehen können
mehrere Repeater verwendet werden, die das Funksignal weiterreichen und somit die
Reichweite erhöhen. Dies ist nur innerhalb eines Gebäudes möglich und stößt bei der
Kommunikation zwischen Gebäuden an seine Grenzen. Deshalb wurde ein System gewählt,
bei dem mehrere Basisstationen eingesetzt werden können. Dadurch ist es auch weiterhin
möglich die Reichweite mit Repeatern zu erhöhen. Um die Daten dennoch zentral verwalten
zu können, wird eine weitere Schnittstelle benötigt die dies verwaltet. Da bei den Systemen
von Messsring immer ein Softwarepaket (CrashSoft) mit Datenbank vorhanden ist, wird
dieses als Verwaltungsprogramm verwendet.
Dadurch ist eine hohe Skalierbarkeit möglich, die sich vom einfachsten System bis hin
zu einem komplexen mit mehreren Gebäuden erstreckt.
3.2 Kommunikation
Die Kommunikation zwichen den Dummys und der Basisstation, sowie die zwischen der
Basisstation und dem zentralen Verarbeitungsprogramm (CrashSoft) sind Kernfunktionen
des Systems. Ihr gilt daher besonderes Augenmerk.
3.2.1 Logger ↔ Basisstation
Die Basisstation und der Logger verbinden sich und kommunizieren miteinander kabellos.
Da die Dummys nicht fest an eine Position (Raum/Gebäude) gebunden sind, sondern sich
zwischen diesen bewegen können, muss es möglich sein diesen Wechsel zu erkennen. Zudem
soll Verbinden und Erkennen neuer Teilnehmer ohne Eingreifen möglich sein.
Aufgrund der Möglichkeit, dass der Empfang verloren gehen kann (z.B. beim Wechsel des
Gebäudes) müssen die Messdaten auf dem Logger zwischengespeichert werden bis wieder
eine Verbindung zu einer Basisstation aufgenommen werden kann. Zudem müssen die
Messdaten bei einem Abschalten aufgrund niedriger Akkuspannung in einem nichtflüchtigen
Speicher (einem Speicher der keine Stromversorgung benötigt, um die Daten zu speichern)
abgelegt werden. Dies schützt vor Verlust der Messdaten, wenn keine Übertragung möglich
ist und der Akku nicht mehr genügend Kapazität besitzt, um das System zu betreiben.
3.2.2 Basisstation ↔ CrashSoft
Um die Basisstation und CrashSoft zu verbinden sollte ein System verwendet werden,
welches keine zusätzliche Installation benötigt. Hier bietet sich die Eingliederung in das
Firmennetzwerk über LAN oder WLAN an.
Da die Basisstationen einen festen Platz besitzen und sich nicht bewegen können, ist
keine dynamische Erkennung vonnöten. Die vorhandenen Basisstationen werden einmal
bei CrashSoft registriert und es muss nichts weiter daran geändert werden. Auch bei der

3.3 Elektronik 14
Übertragung zwischen CrashSoft und einer Basisstation kann es zu Problemen kommen, sei
es durch ein entferntes Ethernetkabel oder durch ein Softwareupdate. Um zu verhindern,
dass die Messdaten verloren gehen, müssen die gesammelten Messdaten der Logger auf
der jeweiligen Basisstation zwischengespeichert werden.
3.3 Elektronik
In diesem Abschnitt wird auf den groben Aufbau der Elektronik eingegangen. Die Entwicklung
der Schaltung erfolgt hingegen in Kapitel 5.
3.3.1 Logger
Der Logger setzt sich aus zwei Systemen zusammen. Dem Funkmodul und dem Inklinometer-
Modul. Der Logger mit kenntlich gemachter Unterteilung der Module, ist in Abbildung
3.2 dargestellt.
Abbildung 3.2: Aufbau des Loggers.
Das Inklinometer besteht aus einem Beschleunigungssensor, einem Mikrocontroller und
der Anbindung an den M=BUS. Die M=BUS-Anbindung und der Mikrocontroller sind
Standardelemente bei den übrigen M=BUS-Teilnehmern und können einfach übernommen
werden. Dieses System ist so gestaltet, dass das Anbinden des Beschleunigungssensors

3.3 Elektronik 15
ohne weitere Probleme möglich ist. Es muss somit nur das Funkmodul entwickelt und die
Schnittstelle zwischen beiden Modulen festgelegt und eingebunden werden. Diese können
miteinander kommunizieren um z.B. Konfigurationseinstellungen auszutauschen. Die Module
bestehen selbst wiederum aus einer Verwaltungseinheit (dem Mikrocontroller), einer
Schnittstelle nach außen und den jeweiligen Sensoren. Die Aufgaben der Mikrocontroller
sind
• die Kommunikation mit der Außenwelt über die jeweiligen Tranceiver,
• das Steuern der Sensoren,
• das Aufnehmen und Zwischenspeichern der Messdaten.
Über die Schnittstellen zwischen den einzelnen Komponenten und auch den zwei Teilsystemen
wird an dieser Stelle noch keine Aussage getroffen, da diese von den verwendeten
Bauteilen abhängig ist (siehe dazu Kap. 5). Die Kommunikation nach außen ist durch die
kabellose Übertragung und den M=BUS bereits zum Teil vorgegeben.
3.3.2 Basisstation
Die Basisstation ist das System, welches die Logger mit CrashSoft verbindet und für den
Datenaustausch zuständig ist. Der Aufbau der Basisstation ist in Abbildung 3.3 dargestellt.
Abbildung 3.3: Aufbau der Basisstation anhand ihrer Basisfunktionen.
Die Anforderungen an diese Komponente sind
• die einfache Anbindung an ein bestehendes Firmennetzwerk,
• die kabellose Kommunikation mit den Loggern,

3.3 Elektronik 16
• das automatische Erkennen der Logger und
• das Zwischenspeichern der Messdaten
Um dies zu ermöglichen, wird mindestens ein Wireless-Transceiver, ein Ethernet-Transceiver
und ein Mikrokontroller oder ähnliches zur Verarbeitung der Daten benötigt. Durch die
Auswahl des Wireless-Transceivers im nächsten Kapitel konnte die Entwicklung einer
Basisstation umgangen werden, da diese vom Hersteller des Transceivers bereits angeboten
wird.

4 Komponentenauswahl
In diesem Kapitel werden die recherchierten Komponenten (Wireless-Tranceiver, Temperaturund
Luftfeuchte-Sensor) verglichen und der beste für diese Anwendung ausgewählt.
4.1 Wireless-Tranceiver
Bei der Wahl eines geeigneten Tranceivers wird auf folgende Eigenschaften geachtet:
• Weltweit einsetzbar
Bei der Kabellosen Übertragung von Informationen muss darauf geachtet werden,
dass diese Übertragung auch in einem erlaubten Frequenzband (siehe Tabelle 2.1)
durchgeführt wird.
• Niedriger Stromverbrauch
Da das System mehrere Monate (siehe Kap. 2.1.2) unabhängig von einer externen
Stromquelle arbeiten soll, muss vor allem der Wireless-Tranceiver so wenig Strom
wie möglich verbrauchen.
• Ausstattung
Ein nicht unerheblicher Punkt ist die Ausstattung des Moduls. Um nicht unnötig
viel Zeit in die Entwicklung eines Funkprotokolles investieren zu müssen, sollte dies
bereits von dem Hersteller in Form einer API mitgeliefert werden. Zudem sollte der
Tranceiver die Möglichkeit bieten Peripherie (die Sensoren) direkt, ohne zusätzlichen
Mikrocontroller, anzubinden. Ein zusätzlicher Controller würde den Stromverbrauch
zusätzlich erhöhen. Von Vorteil wäre zudem, wenn es vom Hersteller bereits eine
fertige Infrastruktur bestehend aus Empfangsstation und Repeatern (Verstärkern)
geben würde.
17

4.1 Wireless-Tranceiver 18
4.1.1 Vergleich
Die in näherer Auswahl stehenden Transceiver werden in Tabelle 4.1 gegenüber gestellt
und in den nachfolgenden Abschnitten werden deren Vor- und Nachteile aufgezeigt.
Tabelle 4.1: Die Wireless-Tranceiver im direkten Vergleich. [19, 20, 21, 22]
Enocean STM 300 Panasonic PAN8550 Chipcon CC2400 Synapse SM200
Stromverb. [Sleep] 0.2 µA 2.5 µA 1.5 µA 0.37 µA
Stromverb. [Idle] k.A. 5 mA 1.2 mA k.A.
Stromverb. [RX] 33 mA 21 mA 23 mA 20.5 mA
Stromverb. [TX] 24 mA 23 mA 19 mA 22.5 mA
Frequenz 868, 902 MHz 868, 908 MHz 2.4 GHz 2.4 GHz
Protokoll Ja Ja Nein Ja
Ausstattung befriedigend gut ungenügend sehr gut
Enocean STM 300 [19]
Einsatzbereich: Auf der Herstellerseite wird mit weltweit möglichem Einsatz bei 868 MHz
und 902 MHz geworben. Da diese aber nicht über den ISM Standard abgedeckt werden,
ist diese Aussage nicht zutreffend. Diese Frequenzen sind viel mehr für den Einsatz in den
USA und Europa gedacht.
Stromverbrauch: Die Wireless-Tranceiver von Enocean wurden besonders für einen möglichst
geringen Energiebedarf entwickelt. Sie sind, vor allem, als energieautarke Systeme,
die sich selbst mit Hilfe von Engery Harvesting versorgen, gedacht. Das ist aufgrund des
Einsatzbereiches aber nicht möglich.
Ausstattung: Es können externe Sensoren über digitale I/O’s und A/D-Wandler mit
dem Transceiver verbunden werden. Es fehlt lediglich die mögliche Anbindung über die
Standardbuse SPI und I 2 C, was die Sensorauswahl weiter einschränkt. Enocean verfügt
über ein eigenes Übertragungsprotokoll, welches auch über eine mitgelieferte API verfügbar
ist.
Panasonic PAN8550 [20]
Einsatzbereich: Der Einsatzbereich des Panasonic PAN8550 unterscheidet sich kaum von
dem des Enoceans STM 300. Die verwendeten Bänder liegen ebenso bei 868 MHz und 908
MHz, was den weltweiten Einsatz, durch die unterschiedlichen Regularien der einzelnen
Regionen bzw. Länder, verhindert.
Stromverbrauch: Das Ziel dieses Produktes ist ebenso eine stromsparende Funkübertragung
für Sensordaten zu ermöglichen.

4.1 Wireless-Tranceiver 19
Ausstattung: Auch der PAN8550 verfügt über eine API die ein Übertragungsprotokoll
beinhaltet. Er verfügt ebenso wie der STM 300 über mehrere digitale I/O’s und A/D-
Wandler über den externe Sensoren angebunden werden können. Zusätzlich stellt das
Modul eine SPI Schnittstelle zum Anbinden externer Sensoren bereit.
Chipcon CC2400 [21]
Einsatzbereich: Der Chipcon CC2400 ist besonders gut für den weltweiten Einsatz geeignet.
Aufgrund des verwendeten 2,4 GHz Bandes, darf der CC2400 ohne besondere Vorkehrungen
weltweit eingesetzt werden.
Stromverbrauch: Dieses Modul ist ebenso auf geringen Stromverbrauch ausgelegt und
befindet sich im selben Bereich wie die bisher vorgestellten Wireless-Tranceiver. Da
zusätzlich zu dem Transceiver noch ein Mikrocontroller notwendig ist, wird sich der
Stromverbrauch im Gegensatz zu den anderen Modulen erhöhen.
Ausstattung: Bei dem CC2400 handelt es sich um einen reinen Tranceiver, d.h. es wird
ein zusätzlicher Mikrocontroller benötigt. Zudem existiert auch keine API die ein Übertragungsprotokoll
bereit stellen würde. Da dieses Modul eine Standardkomponente bei allen
M=BUS Teilnehmern ist, um die kabelgebundene Kommunikation zu bewerkstelligen,
könnte man aber auf das bereits bestehende Protokoll zurückgreifen.
Synapse SM200 [22]
Einsatzbereich: Der SM200 sendet und empfängt wie der Chipcon CC2400 im 2,4 GHz
Band und ist deshalb auch ohne weiteres weltweit einzusetzen.
Stromverbrauch: Der Stromverbrauch dieses Tranceivers liegt im Allgemeinen unter denen
der Konkurrenz Produkte.
Ausstattung: Synapse liefert mit dem SM200 einen vollwertigen Mikrocontroller in Kombination
mit einem Transceiver. Der Mikrocontroller beherrscht SPI sowie I 2 C besitzt diverse
I/O Pins und A/D-Wandler. Synapse stellt nicht nur eine API mit Übertragungsprotokoll
sondern auch eine Python Bibliothek zur Verfügung (Python ist eine objektorientierte
Programmiersprache). Mit dieser Bibliothek kann in Verbindung mit den USB-Modulen
von Synapse jedes Gerät mit den Funkmodulen kommunizieren. Dazu ist nur ein System
notwendig, welches über einen USB-Port verfügt und Python lauffähig ist. Zudem gibt es
auch eine Empfangsstation, die vollständig konfiguriert werden kann und über Ethernet
erreichbar ist. Dadurch entfällt das Entwickeln einer solchen.

4.2 Sensoren 20
4.1.2 Ergebnis
Auf Basis, der am Anfang des Kapitel genannten Kriterien, wurde der SM200 von Synapse
ausgewählt, da er nicht nur einen niedrigen Stromverbrauch hat und problemlos weltweit
einsetzbar ist, sondern weil er dazu noch eine durchdachte Ausstattung und Infrastruktur
mitbringt. Darunter fällt eine bereits vorhandene Basisstation und eine Software die neue
Netzwerkteilnehmer automatisch erkennt. Zudem gibt es auch USB-Transceiver, die als
kostengünstige Repeater verwendet werden können.
4.2 Sensoren
Für die Auswahl der Sensoren sind folgende Kriterien entscheidend:
• Genauigkeit:
Es soll eine möglichst hohe Genauigkeit erzielt werden. Der Temperatursensor muss
mit einer Genauigkeit von ±0.1 K und der Luftfeuchtesensor mit einer Genauigkeit
von ±3 % relativer Luftfeuchte messen. (siehe Kap. 2.2.2)
• Niedriger Stromverbrauch:
Da diese Sensoren auch ohne externe Stromversorgung betrieben werden, ist eine
besonders geringe Stromaufnahme gewünscht.
• Kalibrierung:
Ein besonders wichtiger Punkt ist die herstellerseitige Kalibrierung. Die Sensoren
selbst zu kalibrieren ist ein aufwendiges Verfahren, das möglichst vermieden werden
soll.
4.2.1 Luftfeuchte-Sensor
Die Luftfeuchtesensoren sind meist zusätzlich mit einem Temperatursensor ausgestattet.
Dieser ist für unsere Anwendung aber zu ungenau und kann deshalb nicht verwendet werden.
Die relevanten Daten sind in Tabelle 4.2 für die zu vergleichenden Modelle aufgeführt.
Tabelle 4.2: Die Feuchtesensoren im direkten Vergleich. [23, 24, 25, 26]
HYT-939 HYT-221 SHT75 SHT25
Stromverb. [Idle] < 1 µA < 1 µA < 1 µA 0.15 µA
Stromverb. [Messen] < 22 µA < 22 µA < 1 mA < 0.3 mA
Unsicherheit [Feute] ±1.8% r.L. ±1.8% r.L. ±1.8% r.L. ±1.8% r.L.
Unsicherheit [Temp] ±0.2 K ±0.2 K ±0.3 K ±0.3 K
Anbindung I 2 C I 2 C 2-Wire I 2 C
Abmaße [lxbxh] (10x10x5) mm (15x10x5) mm (20x5x3) mm (3x3x1) mm

4.2 Sensoren 21
Neben den oben genannten Punkten stellen sich auch die Abmaße als zu beachtendes
Kriterium heraus. Im Gegensatz zu den anderen Bauteilen gibt es bei den verglichenen
Modellen für die Luftfeuchtemessung teils große Unterschiede in den Abmaßen. Im Bezug
auf die Maße hebt sich der „SHT25“ eindeutig hervor. Bei der Genauigkeit gilt für alle
Komponenten, dass sie im Bereich ±1.8% r.L. liegen. Vergleicht man die Stromaufnahme,
so liegen die beiden „HYT“ während einer Messung um eine bis zwei Größenordnungen
vorne. Da die Zeit für eine Messung im Vergleich zur Standby-Zeit gering ist, fließt der
Standby-Verbrauch viel stärker in den Gesamtverbrauch ein. Deshalb und aufgrund der
kleinen Abmaße wurde der „SHT25“ ausgewählt. [23, 24, 25, 26]
4.2.2 Temperatur-Sensor
Auch der Temperatur-Sensor muss den weiter oben genannten Kriterien entsprechen. In
Tabelle 4.3 sind die Sensoren der engeren Auswahl aufgeführt. Es wurde der TSYS01
aufgrund des niedrigsten Stromverbrauch ausgewählt. Zudem wird er im Gegensatz zu
den anderen Sensoren über I 2 C und nicht ein eigenes 1-Wire Protokoll angesprochen und
spart somit Implementierungsarbeit. [27, 28, 29]
Tabelle 4.3: Die Temperatursensoren im direkten Vergleich. [27, 28, 29]
TSic 506F TSYS01 TSic 716
Stromverb. [Idle] k.A. 0.14 µA 45 µA
Stromverb. [Messen] 35 µA 12.5 µA k.A.
Unsicherheit ±0.1 K ±0.1 K ±0.07 K
Anbindung 1-Wire SPI/I 2 1-Wire

5 Schaltung
Die in Abschnitt 3.3.1 getroffenen Überlegungen zum Aufbau des Loggers, werden in diesem
Kapitel in einer Schaltung umgesetzt. Dabei wird auf die Beschaltung der in Kapitel 4
ausgewählten Komponenten, auf die Stromversorgung und die Schnittstelle zum Modul
zur Beschleunigungsmessung eingegangen.
5.1 Funkmodul
Die zentrale Komponente des Funk-Moduls ist der Wireless-Tranceiver bzw. der enthaltene
Controller. Dieser muss
• die Spannung des Akkus ermitteln,
• erkennen ob eine externe Spannungsversorgung angeschlossen ist,
• die Messdaten der Sensoren erhalten und zwischenspeichern,
• mit dem Mikrocontroller des Inklinometer-Moduls und der Basisstation kommunizieren.
Zudem müssen die einzelnen Komponenten mit Spannung versorgt werden.
Um die Funktionsweise und die Vernetzung besser zu verstehen, wird im Folgenden die
Schaltung vereinfacht angenommen. Es wird deswegen die Beschaltung zur Konfiguration
des Tranceivers und der Sensoren nicht näher beschrieben. Dazu gehören die Resetleitungen,
Anschlüsse für das Programmierinterface und das Einstellen der Betriebsmodi der Sensoren.
Der vereinfachte Schaltplan ist in Abbildung 5.1 dargestellt, der vollständige Plan kann in
Anhang B gefunden werden.
5.1.1 Messung der Akkuspannung
Der Grund für das Messen der Akkuspannung ist, dass dadurch auf die Restkapazität
des Akkus geschlossen werden kann. Somit kann bei niedriger Kapazität gewarnt und die
Messdaten auf einen nicht flüchtigen Speicher abgelegt werden.
Die Messung erfolgt über einen einfachen Spannungsteiler (siehe dazu Abbildung 5.1
oben links) bestehend aus den beiden Widerständen R3 und R4. Die Spannung wird
mit einem AD-Wandler gemessen und vom Controller des Tranceivers verarbeitet. Um
den Stromverbrauch nicht unnötig zu erhöhen, wird der Spannungsteiler nur bei einer
Messung mit dem Akku verbunden. Zudem wird verhindert, dass über Leckströme im
22

5.1 Funkmodul 23
Tranceiver der Stromverbrauch zusätzlich erhöht Swird. Umgesetzt wird dieser Schalter
durch zwei hintereinander geschaltete MOSFET’s. Der FET der direkt vom Controller
angesprochen wird, ist ein n-Kanal MOSFET, der bei Anlegen einer Spannung an das Gate
die Verbindung zwischen Drain und Source öffnet. Dadurch wird das Gate des zweiten,
einem p-Kanal MOSFET, auf GND gezogen. Nun kann Strom durch den MOSFET fließen
und mit dem AD-Wandler die Akkuspannung gemessen werden.
5.1.2 Anbindung der Sensoren
Für die Kommunikation mit den Sensoren wurde I 2 C gewählt, da dies beide Sensoren
beherrschen. Zusätzlich ist, dass nur zwei Leitungen benötigt werden, von Vorteil. Dieser
Vorteil kommt vor allem zu tragen, wenn auch externe Sensoren verbunden werden. Es
müssen so nur insgesamt vier Leitungen verbunden werden und es können beliebig viele
Sensoren angeschlossen werden. In Abbildung 5.1 ist nur die Spannungsversorgung und
die Verbindung mit dem BUS dargestellt. Für das Betreiben des I 2 C-Bus ist es notwendig
die beiden Leitungen über einen PullUp-Widerstand auf High zu setzen.
Die Datenleitung wird als SDA und die Taktleitung als SCL bezeichnet und in der
Abbildung auch so gekennzeichnet. Die beiden Kondensatoren an der Versorgungsleitung
gleichen hochfrequente Schwingungen aus und sorgen für eine gleichmäßigere Spannung.
Beide Sensoren sind so konfiguriert, dass sie
• die internen Sensoren verwenden und
• die Datenübertragung über den I 2 C-BUS erfolgt.
Die dafür benötigte Beschaltung wurde den jeweiligen Datenblättern [22, 23, 29] entnommen
und ist im vollständigen Schaltplan aufgeführt.
Abbildung 5.1: Der vereinfachte Schaltplan des Funkmoduls.

5.2 Spannungsversorgung 24
5.1.3 Externe Spannungsquelle und Anbindung Inklinometer
Um zu erkennen ob eine externe Spannungsquelle angeschlossen ist, wird diese auf 3.0 V
geregelt und mit einem PIN des Tranceivers verbunden. Durch Überprüfung des Pegels an
diesem PIN wird erkannt ob eine externe Spannungsversorgung angeschlossen ist.
Da der Tranceiver und MCU des Inklinometers nur als Master betrieben werden kann,
und ein Multi-Master Betrieb zusätzlichen Aufwand bedeutet, werden die beiden Module
über I 2 C und nicht SPI verbunden.
5.2 Spannungsversorgung
Die Spannungsversorgung stellt dem System die benötigten 3,0 V zur Verfügung. Dazu
wird die Akkuspannung bzw. die externe Spannung umgewandelt. Als interne Stromquelle
wird ein Litium-Polymer-Akku verwendet, dessen Spannung zwischen 2,5 V und 4,2 V liegt.
Die externe Spannungsquelle liefert hingegen 20 V. In Abbildung 5.2 ist die Schaltung
vereinfacht dargestellt. Dabei wurde die Beschaltung der Spannungsregler zu einem Block
zusammengefasst. Der vollständige Schaltplan ist in Anhang C zu finden. Die externe
Spannung wird über einen Schaltregler zuerst auf 4 V geregelt. Diese werden dann über
einen weiteren linear Regler auf 3 V gesenkt. Die Eingangsspannung wird entweder über
den Schaltregler (externe Quelle) oder den Akku bereit gestellt. Der Akku wird dabei nur
belastet, sollte keine externe Spannung anliegen.
Abbildung 5.2: Der vereinfachte Schaltplan der Spannungsversorgung.

5.2 Spannungsversorgung 25
Die Akkuladeschaltung ist in Abbildung 5.2 links unten zu erkennen. Diese wird über
ein PWM-Signal (Ein über den Mikrocontroller erzeugbares Rechtecksignal) gesteuert, um
den Strom auf den Akku zu begrenzen. Bei Anlegen einer externen Spannung sperrt der
p-Kanal MOSFET die Verbindung zwischen den 4 V und dem Akku. Über das PWM-Signal
kann der n-Kanal FET geöffnet werden und ermöglicht so das Laden des Akkus. Da nur 4
V zur Verfügung stehen kann der Akku auch nicht über 4 V geladen werden. Dies dient
der Sicherheit, da Lithium-Ionen Akkus sehr anfällig sind und zu hohe Spannungen zur
Zerstörung des Akkus führen. Zudem wird dadurch die Zahl der Lade- und Entladezyklen
erhöht.
Die 4 V aus der externen Quelle betreiben auch einen zweiten Spannungsregler, der dem
Inklinometer-Modul die Versorgungsspannung zur Verfügung stellt. Bei Akkubetrieb ist
diese standardmäßig aus, kann aber bei Bedarf zugeschaltet werden. Bei Betrieb über eine
externe Quelle wird das Inklinometer-Modul immer mit Spannung versorgt.

6 Software
Dieses Kapitel beschreibt den Aufbau und die Funktionsweise der Software näher. Zuerst
wird auf das Übertragungsprotokoll eingegangen, da sich die Funktionsweise der
Basisstation und des Funkmoduls damit leichter erklären lässt.
6.1 Übertragungsprotokoll
Zwischen dem Funkmodul und der Basisstation müssen einige Informationen, als der
Logger-Status bezeichnet, zusätzlich zu den Messdaten übertragen werden. Der Logger-
Status beinhaltet
• die Logger-ID (bzw. Dummy-ID),
• der Ladestand des Akkus,
• der Zeitstempel der letzten Übertragung sowie
• die Abstände zwischen den Messungen.
Da die Funkmodule sich die meiste Zeit im Standby befinden und nur kurz, für einige
Millisekunden, zum Messen aufwachen, ist es der Basisstation nicht möglich die Funkmodule
zu erreichen. Deshalb sendet das Funkmodul, in regelmäßigen Abständen ein Signal an die
Basisstation, dass es jetzt aktiv und bereit für eine Übertragung ist. Eine Übertragung
erfolgt wie in Abbildung 6.1 zu erkennen.
Beim Eintreffen des Signals, dass der Logger aktiv ist, entscheidet die Basisstation, was
als nächstes zu tun ist. Zuerst wird der Status des Loggers abgefragt. Dies erfolgt dadurch,
dass das Funkmodul aufgefordert wird die Statusinformationen zu übertragen. Darauf
reagiert der Logger, wie von der Basisstation gewünscht, und überträgt diese. Nach dem
Empfangen der Informationen an der Basisstation werden diese für spätere Weiterverarbeitung
zwischengespeichert. Danach überprüft die Basisstation, ob die Konfiguration
des Loggers geändert werden soll, z.B. Ändern der Zeit zwischen den Messungen. Sollte
dies der Fall sein, wird die Änderung dem Logger übermittelt, welcher dementsprechend
handelt. Liegt keine Änderung vor, wird automatisch zum nächsten Schritt übergegangen,
dem Abfragen der Messdaten. Die Basistation fragt dazu die gewünschten Messdaten ab
und der Logger antwortet mit den gewünschten Daten. Die Messdaten werden ebenso für
die spätere Weiterverarbeitung zwischengespeichert. Da die Datenmenge, die pro Paket
übertragen wird, begrenzt ist, wird dies solange wiederholt bis alle gewünschten Daten
26

6.1 Übertragungsprotokoll 27
übertragen wurden. Um überprüfen zu können wie lange die letzte Übertragung her ist,
wird die aktuelle Zeit gesendet, vom Logger gespeichert und zu Beginn der nächsten
Übertragung übermittelt. Zuletzt wird immer eine Nachricht an den Logger gesendet, die
ihm mitteilt das die Übertragung abgeschlossen ist und er wieder in Standby gehen kann.
Abbildung 6.1: Der Ablauf einer Übertragung zwischen Basisstation
und einem Logger.

6.2 Funkmodul 28
6.2 Funkmodul
Das Funkmodul ist im Prinzip einer Statemachine aufgebaut. Dabei durchläuft das Programm
zyklisch immer wieder die Hauptfunktion (die Statemachine). In dieser Funktion
wird der aktuelle Status (State) untersucht und entsprechend gehandelt. Die Status werden
nacheinander abgefragt und dann in entsprechende Funktionen gesprungen. Am Ende der
jeweiligen Funktion wird der Status für den nächsten Durchlauf gesetzt. Die Status und
ihre Aufgaben sind:
• Messen:
Wenn der Status auf Messen gestellt ist, wird den Sensoren mitgeteilt, dass sie das
Messen beginnen sollen. Danach wird der Status auf „Speichern“ gesetzt.
• Speichern:
In diesem Status werden die Messdaten von den Sensoren abgefragt und auf dem
Controller zwischengespeichert. Der Status wird auf „None“ gesetzt.
• Senden:
Hier wird das Senden eingeleitet, es werden alle zum Senden benötigten Parameter
gesetzt und ein „Aufgewacht“ an die Basisstation gesendet. Für den nächsten
Durchlauf wird der Status auf „Warten“ gesetzt.
• Warten:
Dieser Status wird solange beibehalten bis die Übertragung abgeschlossen ist oder
abgebrochen wird. Danach wird der Status auf „Schlafen“ gesetzt.
• Schlafen:
Sollte keine externe Spannung angelegt sein wechselt das Funkmodul in den Stanby-
Modus bis zur nächsten Messung. Der Status wird auf „None“ gesetzt.
• None:
Dieser Status wird immer aufgerufen wenn kein anderer zutrifft. Es wird überprüft, ob
gemessen oder gesendet werden soll. Die Überprüfung erfolgt, indem die verstrichene
Zeit zwischen senden bzw. messen betrachtet wird. Sollte diese über dem eingestellten
Wert liegen wird der Status für den nächsten Durchlauf wird entsprechend auf
„Messen“ oder „Senden“ gesetzt. Der Status wird auf „Schlafen“ gesetzt, wenn keins
von beiden zutrifft.
Sobald der Logger den Status „Senden“ bzw. „Warten“ eingenommen hat, ist der weitere
Ablauf von der Basisstation abhängig (siehe 6.1).

6.3 Basisstation 29
6.3 Basisstation
Die Basisstation handelt nur aufgrund von äußeren Einflüssen. Darunter fällt
• die Anfrage von CrashSoft und
• die Mitteilung, dass der Logger bereit für die Übertragung ist.
Dafür müssen beim Start der Software erst einige Dinge eingestellt werden. Dazu gehört
die Initialisierung des Synapse Interfaces zur Kommunikation mit dem Funknetzwerk.
Sobald dies erledigt ist, wechselt das Programm in eine Endlosschleife und wartet auf
oben genannte Ereignisse. Dabei lauscht es auf Nachrichten über Funk oder LAN. Sollte
ein Ereignis eintreten, werden die zugehörigen Funktionen aufgerufen und das Ereignis
entsprechend behandelt. CrashSoft steuert dabei die Basisstation und sendet Befehle, die
die Basisstation ausführen soll. Folgende Befehle sind möglich:
• GET_DATA_MODULES:
Sende die ID der Module, von denen Daten vorliegen, an CrashSoft zurück.
• GET_MODULE_INFO:
Sende den Status des angegebenen Loggers. Dazu gehört z.B. der Akkustatus oder
der Zeitpunkt der letzten Kommunikation.
• GET_MEASUREMENTS:
Sende die zwischengespeicherten Messdaten des gewünschten Loggers an die Basisstation.
• DELETE_MEASUREMENTS:
Lösche die angegebenen Messdaten von der Basisstation.
• SET_CONFIG:
Ändere die jeweiligen angegebenen Konfigurationsparameter.
Bei der Kommunikation mit einem Logger verhält sich die Basisstation umgekehrt und
steuert diese. Dabei wird immer der Status des Loggers abgefragt und entsprechend
reagiert. Zusätzlich wird überprüft, ob Konfigurationsbefehle von CrashSoft vorliegen, die
übertragen werden sollen. Im Normalfall werden nach Übertragen des Status die Messdaten
vom Logger angefordert und gespeichert.

7 Validierung
In diesem Kapitel wird der, mit Hilfe der vorherigen Kapiteln, entwickelte Prototyp vorgestellt
und getestet. Der Prototyp ist in in Abbildung 7.1 zu erkennen. Das Platinenlayout
wurde von einer externen Firma aus dem Schaltplan (siehe Kap. 5) erstellt. Daraus wurde
dann die Platine gefertigt und bestückt.
7.1 Inbetriebnahme des Prototyps
Unter die Inbetriebnahme des Logger fällt das Überprüfen der Grundfunktionen. Das
bedeutet das Überprüfen der Widerstände und Spannungen sowie das testen der Software.
Zuerst erfolgt das optische Überprüfen auf offensichtliche Fehler. So konnte nur festgestellt
werden, dass die Kontakte für den Akku nicht vorhanden sind (gelbe Flächen rechts in
Abbildung 7.1b). Der Grund hierfür ist, dass die Platine starr und nicht, wie für die
fertige Platine geplant, beweglich gefertigt wird. Der flexible Teil der Platine hat weniger
Schichten als der starre und somit sind die Kontakte unter weiteren Schichten begraben.
Durch Abtragen der darüber liegenden Schichten werden die Kontakte freigelegt um dort
eine Spannung anzulegen.
(a) von oben
Abbildung 7.1: Platine des Prototyps.
(b) von unten
Bei Überprüfung der Spannungen stellt sich heraus, dass die 3.0 V für die Versorgung des
Funkmoduls nicht bereit gestellt werden. Der Grund hierfür ist ein falsches Bauteil. Dabei
handelt es sich um die Überwachungsschaltung, die überprüft, ob die Eingangsspannung
über 3.0 V liegt, um eine Tiefentladung des Akkus zu verhindern. Der Ausgang des Bauteils
(STM1061N30WX6F) benötigt einen zusätzlichen Pull-Up Widerstand um das Signal am
On/Off-Pin des Spannungsreglers auf High zu setzen und ihn dadurch richtig zu betreiben.
Der Ausgang des STM ist Open-Drain, was bedeutet, dass er bei zu niedriger Spannung
am Eingang, die Spannung am Ausgang „floatend“ d.h. nicht definiert ist und somit nicht
30

7.2 Strommessung 31
bestimmt werden kann ob der Spannungsregler an- oder abgeschaltet sein soll. [30]
Das Aufspielen der Software funktioniert problemlos. Das Übertragen der Temperatur
und Luftfeuchte an die Basisstation funktioniert wie gewünscht und auch das gleichzeitige
Betreiben mehrerer Logger bereitet keine Schwierigkeiten.
7.2 Strommessung
Der Stromverbrauch wird mit Hilfe eines Oszilloskops (Tektronix TDS 3054) und einem
Multimeter (Agilent 3458A) bestimmt. Dazu muss der Strom und die Zeitspanne, über die
dieser Strom fließt, gemessen werden. Es ist wichtig, die genaue Zeitdauer des jeweiligen
Vorgangs zu ermitteln. Damit kann nicht nur die Zeitspanne sondern auch der Strom über
einen Shunt-Widerstand bestimmt werden. Als Shunt-Widerstand wurde ein Widerstand
mit 200 Ω und einer Unsicherheit von ± 1% verwendet. Somit konnte der Strom (1 V =
5 mA) und die Zeit direkt am Oszilloskop abgelesen werden. Der Standby-Strom wurde
mit einem Multimeter genauer bestimmt.
Für die Berechnung des durchschnittlichen Verbrauchs wird wegen der Übersichtlichkeit
eine normale Sendeperiode gewählt. Die Dauer dieser Zeitspanne beträgt t 0 = 900 s.
Es wird in dieser Zeit zehn mal gemessen und einmal gesendet. In Tabelle 7.1 sind die
Ergebnisse aus der Messung dargestellt.
Tabelle 7.1: Ergebnisse aus der Strommessung.
t in ms I in mA
Messung 9.8 4.4
Übertragung 210 13.3
Standby — 0.083
Der durchschnittliche Verbrauch wird dabei wie folgt berechnet.
2t gesamt = Anzahl · t (7.1)
t Standby = t 0 − (t ges,Messung + t ges,Übertragung )
t 0
(7.2)
I = I · tges
(7.3)
t 0
10 · 9.8 ms
⇒ I ges = 4.4 mA ·
900 · 10 3 ms
1 · 210 ms
+ 13.3 mA ·
900 · 10 3 ms
+ 0.083 mA · 900 · 103 ms − (10 · 9.8 ms + 1 · 210 ms)
900 · 10 3 (7.4)
ms

7.3 Störungen 32
Daraus ergeben sich für den gesamten durchschnittlichen Verbrauch 87 µA. Anhand der
Ergebnisse aus Tabelle 7.2 ergibt sich, dass der Standby 95% des gesamten Verbrauches
beträgt.
Tabelle 7.2: Durchschnittler Stromverbrauch.
I in µA
I Messung 0.48
I Übertragung 3.1
I Standby 83
I ges 87
Somit beträgt die Laufzeit bei einem idealen 150 mAh Akku ca. 72 Tage und liegt
damit in den spezifizierten zwei Monaten. Da der Akku nur auf 4 V geladen wird und mit
Selbstentladung gerechnet werden muss, wird ein 180 mAh bis 200 mAh Akku verwendet.
7.3 Störungen
Die Übertragung über den M=BUS, wie auch die Funkübertragung erfolgt auf dem 2.4 GHz
Band. Da die Komponenten, die für die Übertragung zuständig sind, sehr nah beieinander
liegen, muss überprüft werden, ob sie sich gegenseitig beeinflussen. Dazu werden gleichzeitig
über beide Wege Daten übertragen. Um zu überprüfen, ob die original Daten angekommen
sind, werden diese unverändert zurück geschickt und mit den ursprünglich Gesendeten
verglichen. Sollte das Datenpacket nicht dem ursprünglich Gesendetem entsprechen, wird
ein Fehlerzähler erhöht. Da die normale Übertragung ohne mögliche gegenseitige Beeinflussung
Fehler beinhaltet, wird auch eine Messung ohne durchgeführt. Die Ergebnisse
werden miteinander verglichen und dadurch bewertet. Es werden zudem auch Messungen
mit unterschiedlichen Entfernungen zur Basisstation durchgeführt, um bei verschiedenen
Signalstärken zu testen. Für die Messungen wird der Logger mit einem M=BUS-Gateway
verbunden, das wiederum über einen PC angesteuert wird. Auf dem Computer läuft ein
Programm, welches die Daten sendet und beim Empfangen auswertet. Die Versuche für
die Unterschiedlichen Entfernungen werden und mit an- und abgeschaltetem Funkmodul
durchgeführt.
Die Messergebnisse sind in Tabelle 7.3 aufgeführt. Es werden Messungen in 1 m Entfernung
und 5 m Entfernung durchgeführt. Zudem wird eine Messung durchgeführt, bei
der der Logger in einem Dummykopf verbaut wird. Der Dummykopf besteht vollständig
aus Metall und schirmt das Funksignal fast vollständig nach außen hin ab. Die über
M=BUS übertragenen Daten wiederholen sich zyklisch und bestehen aus sich immer um
eins erhöhenden Hex-Zahlen. Die Funkdaten sind hingegen zufällig generiert.

7.4 Reichweite 33
Tabelle 7.3: Fehler bei der Übertragung.
Entfernung 1 m Entfernung 5 m In Dummykopf, 5 m Ohne Funk
Dauer der Messung 56 min 53 min 46 min 48 min
Gesendete Pakete 132277 105852 89382 96028
Fehler 41 45 24 33
Fehler pro Paket 3,10 ‰ 4,25 ‰ 2,69 ‰ 3,44 ‰
Fehler pro Minute 0.73 min −1 0.85 min −1 0.52 min −1 0.69 min −1
Die Messungen zeigen das davon ausgegangen werden kann, dass kein Zusammenhang
zwischen den Fehlern und der Funkübertragung besteht. Die niedrigste Fehlerquote ist während
des Tests im Dummykopf aufgetreten. Dabei wird zugleich die höchste Sendeleitung
erwartet und somit das größte Störpotential. Dies entspricht aber nicht den Messdaten.
Diese zeigen, dass die Fehlerraten unabhängig vom Funksignal schwanken.
7.4 Reichweite
Zur Bestimmung der Reichweite werden im Firmengebäude mehrere Messpunkte ausgewählt
und die Signalstärke an diesen bestimmt. Die Signalstärke wird über das mitgelieferte
Verwaltungsprogramm der Wireless-Transceiver von Synapse gemessen. Die Messergebnisse
und die Messpunkte sind in Tabelle 7.4 bzw. Abbildung 7.2 zu erkennen.
Tabelle 7.4: Signalstärke (absteigend geordnet).
Messpunkt Basis A B C D E G F
Signalstärke in % 96 44 23 16 14 6 1 0
Entfernung in m 0 6 13 15 23 19 24 37
Abbildung 7.2: Gebäudeplan für Reichweitenmessung.

7.6 Vergleich mit Systemanforderungen 34
7.5 Genauigkeit
Die Temperatur und Luftfeuchte wird in einem klimatisierten Labor gemessen. In diesem
Labor werden Kalibrierungen durchgeführt und deshalb müssen diese dort gemessen und
gespeichert werden. Die gemessenen Daten des Loggers werden mit den des Raumes abgeglichen.
Dabei wurde ein Problem festgestellt, wodurch die gemessene Temperatur deutlich
von der Umgebungstemperatur abweicht. Der Temperaturunterschied beträgt ca. 20 K.
Der Grund hierfür ist, die sich unter dem Temperatursensor befindliche GND-Fläche. Diese
besteht aus Kupfer und ist im Gegensatz zum Trägermaterial der Platine gut wärmeleitend.
Nach dem Abschleifen der Schichten unterhalb des Sensors wird annähernd (±1 K) die
richtige Temperatur gemessen. Die gemessene Luftfeuchte stimmt hingegen mit der des
Raumes überein und sind aufgrund der herstellerseitigen Kalibrierung vertrauenswürdig.
Die Messungen erfolgten auf Grund der Probleme rein qualitativ und müssen nach
Beheben des Fehlers wiederholt werden.
7.6 Vergleich mit Systemanforderungen
In Tabelle 7.5 wird der Vergleich zwischen Ist- und Soll-Zustand dargestellt.
Tabelle 7.5: Vergleich von Ist- und Soll-Zustand (Dunkelblau: In Ordnung; Hellblau: Noch
nicht vollständig Implementiert; Rot: Fehler, der behoben werden muss).
Anforderung Soll-Zustand Ist-Zustand
Funkübertragung Ja Ja
Akkulaufzeit ca. zwei Monate > zwei Monate bei 150 mAh
Modular Ja Ja
ISM-Band Ja Ja
Temperatur Genauigkeit ±0.1 K ca. 20 °C zu viel
Luftfeuchte Genauigkeit ±3.0% r.L. ±1.8% r.L.
M=BUS Anbindung Ja Hardware vorhanden

8 Fazit und Ausblick
Bei der Untersuchung des Prototypen konnten einige Fehler in der Software gefunden
und behoben werden. Dazu gehörten kleine Fehler im Übertragungsprotokoll und der
Zwischenspeicherung der Messdaten auf dem Logger. Die Fehler die an der Hardware
gefunden wurden sind:
• Schutz vor Tiefentladung des Akkus
Es wurde ein falsches Bauteil verbaut, weshalb der Spannungsregler nicht richtig abund
angeschaltet wird. Dies kann durch Austausch des Open-Drain Voltage-Monitors
mit einem Push-Pull Voltage-Monitor behoben werden.
• Temperatur wird zu hoch gemessen
Der Temperatursensor befindet sich über einer wärmeleitenden GND-Schicht, weshalb
dieser eine erhöhte Temperatur misst. Durch Abschleifen der unter dem Sensor
liegenden Schichten konnte dies behoben werden. Ob die Ursache nur die GND-
Fläche oder die gesamte Platine ist, muss noch überprüft werden.
Bis auf die oben genannten Ausnahmen funktioniert das Produkt, wie in den Randbedingungen
festgelegt. Währen dem Testen stellte sich zudem heraus, das ein
• An/Aus-Schalter
für den Transport oder längeres Aufbewahren sinnvoll ist. Zusätzlich vereinfacht dies
das Testen der Hard- und vor allem Software. Bei der Implementierung dessen muss
darauf geachtet werden, dass dieser nicht durch die hohe Belastung von Crashtests
ausgelöst wird.
Für den vollen Funktionsumfang muss nachfolgendes noch in der Software implementiert
werden.
• Die Kommunikation mit CrashSoft.
• Die Kommunikation mit dem Inklinometer-Modul.
• Das Auslesen und Senden der Beschleunigungsdaten des Inklinometer-Moduls über
M=BUS.
Zudem wurde von Kunden, denen das Produkt präsentiert wurde, gewünscht den Standort
des Dummys bestimmen zu können. Dies ist dank der entworfenen Struktur und des
35

8 Fazit und Ausblick 36
Funkprotokolls ohne weiteres möglich. Dazu muss nur überprüft werden an welcher
Basisstation der Logger zuletzt angemeldet war.
Da für die aufgetretenen Probleme bereits Lösungsansätze vorhanden sind und für den
vollen Funktionsumfang nur die bestehende Software angepasst werden muss, kann der
Logger wie geplant Ende 2013 in Produktion gehen.

Literatur
[1] September 1959: Erster Crashtest bei Mercedes-Benz. url: http://media.daimler.
com/dcmedia/0-921-657486-49-1228592-1-0-0-0-0-0-11701-614318-0-1-
@ac.clink170084_3842-0-0-0-0.html (besucht am 10. 06. 2013).
[2] Beim ersten Crashtest gab es fast einen Toten. url: http://www.welt.de/motor/
article4489160/Beim- ersten- Crashtest- gab- es- fast- einen- Toten.html
(besucht am 10. 06. 2013).
[3] Christian Bangemann. 50 Jahre Crashtest bei Mercedes. url: http://www.automotor-und-sport.de/news/50-jahre-crashtest-bei-mercedes-1415514.html
(besucht am 10. 06. 2013).
[4] Erklärung des Frontalaufpralls. url: http://www.euroncap.com/tests/frontimpact.
aspx (besucht am 10. 06. 2013).
[5] Erklärung des Seitenaufpralls. url: http://www.euroncap.com/Content- Web-
Page/106f41f7- d486- 46bf- bfbc- 80fb4c79f679/car- to- car- side- impact.
aspx (besucht am 10. 06. 2013).
[6] Andrew Ambrazevich. Тесты Euro NCAP: крушим все! url: http://news.wse.
by/articles/testi_euro_ncap_krushim_vse.html (besucht am 10. 06. 2013).
[7] Erklärung des Pfahlaufpralls. url: http://www.euroncap.com/Content- Web-
Page / 90769bbc - bb74 - 4129 - a046 - e586550c3ece / pole - side - impact . aspx
(besucht am 10. 06. 2013).
[8] Erklärung des Fußgängeraufpralls. url: http://www.euroncap.com/Content-Web-
Page/ed4ad09d-1d63-4b20-a2e3-39192518cf50/pedestrian-protection.aspx
(besucht am 26. 07. 2013).
[9] The „Sierra Sam“ Story. url: http://research.ncl.ac.uk/nsa/sam.html
(besucht am 10. 06. 2013).
[10] The History of Crash Test Dummies. url: http://inventors.about.com/od/
sstartinventions/a/SierraSam.htm (besucht am 10. 06. 2013).
[11] Messring Mitarbeiter. „Interne Firmendokumentation“. Diverse Dokumentationen
zu Messringprodukten.
[12] Christoph Schwager. Entwicklung einer M=BUS Pro Anbindung für IEPE-Sensoren.
Diplomarbeit. 2012.
[13] Markus Weippert. Untersuchung des Temperaturverhaltens von Seitenaufpralldummys.
Diplomarbeit. 2005.
37

Literatur 38
[14] Radio Regulations. International Telecomunication Union, 2012.
[15] SIDE IMPACT TESTING PROTOCOL. Bd. 6.0. Euro NCAP, 2012.
[16] POLE SIDE IMPACT TESTING PROTOCOL. Euro NCAP, 2011.
[17] C-NCAP Management Regulation. C-NCAP, 2012.
[18] DIN ISO. „ISO 6497:2010 Road vehicles – Measurement techniques in impact tests –
Instrumentation“. In: ISO/TC 22/SC 12 Passive safety crash protection systems.
2010.
[19] Datenblatt Enocean STM 300. url: http : / / www . enocean . com / de / enocean _
module/STM_300_Data_Sheet_Nov12_05.pdf (besucht am 24. 04. 2013).
[20] Datenblatt Panasonic PAN8550. url: http://www.panasonic.com/industrial/
components/pdf/PAN8550.pdf (besucht am 24. 04. 2013).
[21] Datenblatt Chipcon CC2400. url: http : / / www . khalus . com . ua / kh / data /
components / chipcon / data / CC2400 / CC2400 _ Data _ Sheet _ 1 _ 2 . pdf (besucht
am 24. 04. 2013).
[22] Datenblatt Synapse SM200. url: http://www.synapse-wireless.com/documents/
products/Synapse-RF-Engine-SM200P81-SM200PU1-RF200P81-RF200PU1-Data-
Sheet.pdf (besucht am 24. 04. 2013).
[23] Datenblatt Sensirion SHT25. url: http://www.sensirion.com/fileadmin/user_
upload / customers / sensirion / Dokumente / Humidity / Sensirion _ Humidity _
SHT25_Datasheet_V2.pdf (besucht am 24. 04. 2013).
[24] Datenblatt Sensirion SHT75. url: http://www.sensirion.com/fileadmin/user_
upload / customers / sensirion / Dokumente / Humidity / Sensirion _ Humidity _
SHT7x_Datasheet_V5.pdf (besucht am 24. 04. 2013).
[25] Datenblatt IST AG HYT-939. url: http://www.hygrochip.com/fileadmin/user_
upload/Produkte/Sensorelemente/Digitale_Feuchtesensoren/HYT_939/IST_
939/EN_HYT939_201109.pdf (besucht am 24. 04. 2013).
[26] Datenblatt IST AG HYT-221. url: http://www.hygrochip.com/fileadmin/user_
upload/Produkte/Sensorelemente/Digitale_Feuchtesensoren/HYT_221/IST_
221/EN_HYT221_201109.pdf (besucht am 24. 04. 2013).
[27] Datenblatt IST AG TSic 506F. url: http : / / www . ist - ag . com / eh / ist - ag /
resource.nsf/imgref/Download_IST_TSic_50xF_DE_V4.1.pdf/$FILE/IST_
TSic_50xF_DE_V4.1.pdf (besucht am 24. 04. 2013).
[28] Datenblatt IST AG TSic 716. url: http : / / www . ist - ag . com / eh / ist - ag /
resource.nsf/imgref/Download_nTSic716.pdf/$FILE/nTSic716.pdf (besucht
am 24. 04. 2013).
[29] Datenblatt Measurement Specialties TSYS01. url: http://www.meas-spec.com/
downloads/TSYS01_Digital_Temperature_Sensor.pdf (besucht am 24. 04. 2013).

Literatur 39
[30] Datenblatt STMicroelectronics STM1061N30WX6F. url: http://www.st.com/
web/en/resource/technical/document/datasheet/CD00065467.pdf (besucht
am 27. 06. 2013).

Abbildungsverzeichnis
1.1 Crashversuch mit Heißwasserraktenantrieb. . . . . . . . . . . . . . . . . . 1
1.2 Frontalaufprall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Seitenaufprall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Seitenaufprall mit einem Pfahl. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Fußgängeraufprall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Ergebnis eines EuroNCAP Crashtests. . . . . . . . . . . . . . . . . . . . . 3
1.7 Der erste Dummy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.8 M=BUS Messkette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Beispielkonfiguration einer Crashanalge. . . . . . . . . . . . . . . . . . . . 12
3.2 Aufbau des Loggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Aufbau der Basisstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Vereinfachter Schaltplan des Funkmoduls. . . . . . . . . . . . . . . . . . . 23
5.2 Vereinfachter Schaltplan der Spannungsversorgung. . . . . . . . . . . . . . 24
6.1 Ablauf einer Übertragung zwischen Basisstation und Logger. . . . . . . . 27
7.1 Platine des Prototyps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Gebäudeplan für Reichweitenmessung. . . . . . . . . . . . . . . . . . . . . 33
40

Tabellenverzeichnis
2.1 Übersicht über die ISM-Bänder. [14] . . . . . . . . . . . . . . . . . . . . . 8
4.1 Die Wireless-Tranceiver im direkten Vergleich. [19, 20, 21, 22] . . . . . . . 18
4.2 Die Feuchtesensoren im direkten Vergleich. [23, 24, 25, 26] . . . . . . . . . 20
4.3 Die Temperatursensoren im direkten Vergleich. [27, 28, 29] . . . . . . . . . 21
7.1 Ergebnisse aus der Strommessung. . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Durchschnittler Stromverbrauch. . . . . . . . . . . . . . . . . . . . . . . . 32
7.3 Fehler bei der Übertragung. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.4 Signalstärke (absteigend geordnet). . . . . . . . . . . . . . . . . . . . . . . 33
7.5 Vergleich von Ist- und Soll-Zustand (Dunkelblau: In Ordnung; Hellblau:
Noch nicht vollständig Implementiert; Rot: Fehler, der behoben werden muss). 34
41

A Bauform
A
B
C
D
E
F
1
2
3
4
A
B
8
36,4
A
B
42
39
34
33,2
20
16
1 2 3 4
5
6
7
8
B-B
Z
10:1
A
B
Z
0,1
A-A
C
D
E
Freimasstoleranz
general tolerance Massstab
ISO 2768-mH
Scale
Masse / mass
0,004 kg
- - - -
- - - -
- - - -
2:1
- - - -
- - - -
Schutzrechte nach ISO 16016.
MSG-Code
a Anpassung an Platinen - -
All rights reserved according to ISO 16016.
- Ind. Änderung / modification Datum Name
Halbzeug/material
Oberfläche/surface coating
PA
-
Benennung / part name
Unterteil
Bottom
gez./design 23.07.13 C. Schwager
gepr./check 23.07.13 S. Kuhn
Zeichnungs Nr. Änd.Ind.
drawing no
Revision
Bezeichnung / description
M=BUS Inclinometer
ZF22529 a
M=BUS Inclinometer 1 Blatt/sheet: von/of 1 A3
N:\Proj..\\x-Produkte\MBUS\Messtechnik\Inclinometer\ProE
18
20
25
25
28
16
23,4
0,5x45°(2x)
1x45°(4x)
6
8,85
1,7
3,5
2,2
1,6
5
1,5
R 1 (12x)
R 1,6 (4x)
R 1,5(12x)
R 1,1(8x)
42

B Schaltplan - Digitalteil
43

C Schaltplan - Stromversorgung
44

Erklärung der Selbstständigkeit
Hiermit erkläre ich gemäß § 35 Abs. 7 der Rahmenprüfungsordnung für Fachhochschulen
in Bayern, dass ich die vorliegende Arbeit selbständig verfasst, noch nicht anderweitig
für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel
benutzt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.
, den
Stefan Kuhn