Bachelorarbeit - HAW Hamburg

Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science

Bent Mucha

Erstellung eines Mess-Systems zur Latenzzeitmessung von Bluetooth SPP Verbindungen

Bachelorarbeit

Bent Mucha

Erstellung eines Mess-Systems zur Latenzzeitmessung von Bluetooth SPP Verbindungen

Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Angewandte Informatikam Department Informatikder Fakultät Technik und Informatikder Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer : Prof. Dr. rer. nat. Gunter KlemkeZweitgutachter : Prof Dr. rer. nat. Thomas Canzler

Abgegeben am 05. August 2008

Bent Mucha

Thema der Bachelorarbeit Erstellung eines Mess-Systems zur Latenzzeitmessung von Bluetooth SPP Verbindun-gen

StichworteBluetooth, Serial Port Profile (SPP), Latenz, serielle Verbindung, Windows, Funktech-nologie.

KurzzusammenfassungDiese Arbeit behandelt die Erstellung eines geeigneten Latenzzeitenmess-Systems für Bluetooth-SPP-Verbindungen unter Einsatz eines auf Windows basierenden PC. Eine SPP-Verbindung ersetzt in er Regel eine kabelgebundene, serielle Verbindung, wo-durch der Einsatz in der Steuerung von Maschinen, Industrieanlagen, etc. erzielt wer-den kann. Das System soll hierbei den Aufwand für den Aufbau eines Labors umge-hen, das Gelingen soll anhand von geeigneten Tests bewiesen werden.

Bent Mucha

Title of the paperDevelopment and construction of a measuring system to measure the latency of a Bluetooth SPP connection

KeywordsBluetooth, Serial Port Profile (SPP), latency, serial connection, Windows, radio com-munication.

AbstractThis report deals about the construction of an easy to use System for measuring the latencies of a Bluetooth SPP connection under the usage of a windowsbased Com-puter. The SPP connection usually replaces a serial connection over a cable. In this case it is usable for the communication between robots, industrial machines, etc. The system is intended for minimizing the complexity of building up a laboratory. Some tests shall proof the correct functionality afterwards.

INHALTSVERZEICHNIS Abbildungsverzeichnis

EinleitungGrundlagen

AnalyseDesign

TestsVergleich und Evaluierung

FazitGlossar

Quellenverzeichnis

�/83

INHALTSVERZEICHNIS

Abbildungsverzeichnis 06

1 Einleitung 08 1.1Motivation 08 1.2Zielsetzung 10 1.3GliederungderArbeit 10

2 Grundlagen 12 2.1Windows 12 2.1.1MonolithischesSystem(Windows9x,MS-DOS) 12 2.1.2Schichtmodell(WindowsNT,2000,XP,Vista) 14 2.1.3Client/Server(WindowsNT,2000,XP,Vista) 15 2.1.4WindowsNTStrukturmodell 16 2.2Bluetooth–SPPProtokolle&AT-Kommandos 19 2.2.1Frequenzbereich2,4GHz,ISM-Band 20 2.2.2Frequenzsprungverfahren(frequencyhopping) 21 2.2.3DerBluetoothstack 24 2.2.4DasRFCOMMCableReplacementProtocol 26 2.2.5DasSPPProfil(SerialPortProfile) 29 2.2.5.1AktiverVerbindungsaufbau 31 2.2.5.2AkzeptiereneinerVerbindungsanfrage 32 2.2.5.3RegistrierenderverfügbarenDienste 32 2.2.6DieBluetoothhardware 33 2.3DieRS232-Schnittstelle 35 2.3.1Hardware 35 2.3.2SoftwareunterWindows 37 2.4DieStoppuhr(timewatch) 40

3 Analyse 42 3.1AnforderungenandasSystem 42 3.2TestszenarienundAufbau 43 3.3FunktionaleAnforderungen 43 3.4NichtfunktionaleAnforderungen 44

INHALTSVERZEICHNIS Abbildungsverzeichnis

EinleitungGrundlagen

AnalyseDesign

TestsVergleich und Evaluierung

FazitGlossar

Quellenverzeichnis

�/83

INHALTSVERZEICHNIS

4 Design 46 4.1Softwarefunktionen 50 4.1.1BibliothekfürdenZugriffaufdenComPort 50 4.1.2DieStoppuhr 52 4.1.3DieEinmessprozedur 55 4.1.4EingabefensterundAuswertungderDaten 56

5 Tests 58 5.1Messaufbau 58 5.2Durchführung 58 5.3Messergebnisse 60

6 Vergleich und Evaluierung 64 6.1MessungmiteinemLogikanalysator 64 6.2BewertungderSoftware 66 6.3NutzbarkeitmitanderenHerstellern 67

7 Fazit 71 7.1Zusammenfassung 71 7.2Fazit 72 7.3Ausblick 72

8 Glossar 76

9 Quellenverzeichnis 78 9.1Quellenverzeichnis 78 9.2Bilderquellenverzeichnis 79 9.3AT-Befehlssatz 81

ABBILDUNGSVERZEICHNIS �/83

ABBILDUNGSVERZEICHNIS

Kapitel 22.1MonolithischesSystem 132.2Schichtmodell 142.3Client/Servermodell 152.4SchemazudenPrioritätenunterWindows 172.5WindowsNTBlockdiagramm 182.6AufbaueinestypischenPikonetzes 202.7Bluetoothgeräteklassen 212.8SlotbelegungnachTDD 232.9BluetoothProtocolStack 262.10BeispielfüreineTyp2Kommunikation 272.11RFCOMM-Null-Modem-Schema 282.12AufbaudesGAP 302.13EintragimSDPfürdasSPP-Protokoll 322.14BlueEva+C11/G2 332.15BlockschaltbilddesC11/G2EvalBoard 332.16RS232Datenrahmen 372.17SequenzdiagrammComAPI 40

Kapitel 33.1Messaufbau 43

Kapitel 44.1EinfachesKlassendiagrammmitdennötigstenMethoden 484.2Sequenzdiagramm,beschreibtdengrundsätzlichenProgrammablauf 49

Kapitel 55.1AufbauplanundAnschluss-Skizze 585.2AverageWindowsDelaytimebezogenaufdieBlockgröße 595.3LatenzzeitinbeidenRichtungen,Abstandca.30cm 605.4RX/TXtiminginmulti-slaveKonfiguration 615.5LatenzzeitinbeidenRichtungen,Abstandca.8Meter 63

Kapitel 66.1LatenzmessungimGoLogic 646.2LatenzzeitenimVergleich:Master->Slave 65

ABBILDUNGSVERZEICHNIS �/83

ABBILDUNGSVERZEICHNIS

6.3LatenzzeitenimVergleich:Slave->Master 666.4Bluetooth-Konverter,PhoenixContact 686.5LatenzzeitenimVergleich:Phoenixmodule 70

Kapitel 77.1GeschwindigkeitvonRS485bezüglichKabellänge 75

Kapitel 9A.1AT-Befehlssatz 81

�/83

EINLEITUNG

1.1 Motivation

AmAnfangwardieIdee:Wireless.

Den Aufwand der Verkabelung diverser Geräte im Alltag von privaten und indus-triellen Anlagen galt es zu minimieren: Computermäuse, Tastaturen, PDAs, elek-trische Steuerungsanlagen, etc. mussten noch in den 90er Jahren per Kabel verbunden werden. Eine Alternative musste her und wurde sehr bald gefunden, die Idee der kabellosen Verbindung. Während zu Beginn des neuen Jahrtau-sends das Thema Bluetooth noch milde belächelt wurde, es war nicht klar ob sich diese Technik durchsetzen würde, ist diese Technik heute nicht mehr weg-zudenken. Es existiert kaum ein Handy, dass sich nicht über Bluetooth mit dem PDA synchronisieren kann oder gleichzeitig eine drahtlose Verbindung zur Frei-sprecheinrichtung aufzubauen vermag. Bereits im Jahr 2005 wurden pro Woche ca. 5 Millionen Geräte mit Bluetoothfunktion verkauft, Tendenz steigend (2003: 1 Mio./Woche) [GOLEM]. Die Industrie fand schnell Gefallen an der Funktechnik, war sie doch durch höher werdende Stückzahlen sehr günstig und durch das lizenzfreie Frequenzband (siehe Kapitel 2.2.1) ohne Folgekosten.

EsergabensichzudemneueMöglichkeiteninderSteuerungundRealisierungvonRoboternundautonomenTransportfahrzeugen.VorherwurdejedeVerbindungperKabelrealisiert,diesführteleideroftdazu,dassVerbindungendurchhäufigeBewe-gungen (Roboterarme) verschlissen, dadurch anfälliger auf Kabelbrüche wurdenundregelmäßiggetauschtwerdenmussten[ABB].Problematischwarenauchauto-nomeFahrzeuge(automatedguidedvehicles),wiesiebeispielsweise inderDru-ckerei vomAxel-Springer-VerlagzumTransportder tonnenschwerenPapierrolleneingesetztwerden[AGV],dadieSteuerungvonautonomenFahrzeugendurcheineLeitstellebishernurperKabeloderInfraroterfolgenkonnte.DieFahrzeugeinderDruckereinavigiertenderzeitauffesten,vorherdefiniertenRouten,welchefarblichaufdemHallenbodenmarkiertwurden.UnterdenMarkierungenbefandensichnunKabel,welcheeinMagnetfeld induzierten(FloorWire[ROCLA]).DieÜbertragungderAnweisungendurchdieLeitstellekonntenuranbestimmtenPunkten (i.d.R.Endpunkte) via Infrarot übertragen werden, da hier immer der direkte Sichtkon-taktzwischenSenderundEmpfängergewährleistetwerdenmusste.DerEinsatzvonKabelnwarfernerproblematisch,dajederzeitStolpergefahrfürdieMitarbeiter

EINLEITUNGMotivation

Zielsetzung Gliederung der Arbeit

�/83EINLEITUNGMotivation


EINLEITUNG

bestandundauchKabelbruchnichtauszuschließenwar.SchließlichwirdderWir-kungsbereich stark eingeschränkt. Funktechnologie war Anfang der 90er Jahrenichteinsetzbar,esgabkeinVerfahrenzurVermeidungvonStörungen.DieFirmaEricssonwurdeerst1994beauftragt,eineaufFunkwellenbasierendeLösungmitdem Ziel des Kabelersatzes zu finden [WIKI];WLAN wurde erst gegen 1997 fürdiekommerzielleNutzungerschlossen[AW]. InderTheoriestelltdieserSachver-halt(NutzungdesFloorWire)keinProblemdar,jedochkonntedasFahrzeugeinenFehler/StörungaufderStreckenurschwierigandieLeitstellemelden,daeskeinepermanentenDatenverbindungengab.

DurchdenEinsatzvonFunktechnologienkönnendieseProblemeweitestgehendgelöst werden. Bereits heute existiert ein System der Firma SENATechnolo-gies Inc. [SENA],welches imBereichFacilityManagementeine fertigeFunkin-frastrukturmitBluetooth fürautonomeFahrzeugebereitstellt.Theoretisch ließesichmittelsBluetootheineVielzahlvonkabelgebundenenVerbindungendrahtlosrealisieren. Es gäbe, neben den oben aufgeführten Problemen, auch wenigerSchwierigkeiten mit herstellerspezifischen Steckverbindungen. Auch GewichtundKostenfürKabelbäumeinjederArtvonFahrzeugenließensichminimieren.JedochstelltsichfürdenversiertenEntwicklungsingenieureineFrage:Wennmandas Kabel in Steuerungsanlagen, Roboterarmen, etc. ersetzt, wie ändert sichdanndieÜbertragungsgeschwindigkeit?DerKupferdrahtistimmerschnelleralsdieÜbertragungperFunktechnologieimBezugaufdenphysikalischenAufbau.MitwelcherVerzögerungabermussfürdieÜbertragunggerechnetwerden?Istdieseimmergleich,oderhängtdiesvomGerätab?SpieltdieSenderichtungeineRolle? Der Entwickler kann anhand von ermitteltenVerzögerungszeiten schnellerkennen, ob die von ihm einzusetzen beabsichtigte Hardware den von ihmgestelltenAnforderungengenügt.BeispielsweiseistdiedurchschnittlicheReak-tionszeiteinerMaschine,etc.innerhalbeinerbestimmtenZeitvorausgesetzt,derEntwicklerweißabervorhernicht,obdieseVoraussetzungüberhauptmachbarist.EinVertreterkanneinenEndkunden leichtvonseinemProduktüberzeugendasrichtigezusein,wennervorOrtundschnelldenIST-Zustandvorweist,derpositivbeworbenwerdensoll.EinEntwickler,zuständigfürdieProgrammierungder Firmware, kann schneller testen, ob sichVeränderungen in der SoftwarepositivodernegativaufdasLatenzverhaltenausgewirkthaben.Dieortsunabhän-gigeNutzbarkeitlässtvieleEinsatzmöglichkeitenzu,nahezujedeUmgebungist

10/83EINLEITUNGMotivation


EINLEITUNG

nutzbar,speziellsolche,wonurgeringePlatzverhältnissevorherrschen,welchesichinständigerBewegungbefinden(Automobil,Flugzeug,Schiff),oderwoderAufbaueinesweitauskomplexerenSystemsnichtsoleichtmöglichwäre(Indus-trieanlage). Diese und noch weitere Einsatzgebiete sind für das Mess-Systemdenkbar,esgiltalsonuneinSystemzuerstellen,welchesdiegenanntenKrite-rienerfüllenkann.

1.2 Zielsetzung

Ziel istes,einMess-Systemzuerstellen,womitmanschnellundmiteinfachenMitteln die Latenzzeit einer Funkverbindung zwischen zwei Bluetoothmodulenmessenkann.JenesSystemsollaufeinerleichtzubeschaffendenHardwarerea-lisiertwerden.DainFirmenmeistPCsmitWindowssystemanzutreffensind,isthierWindows–basierendaufNT–dieprimäreWahl.ZudemsolldasSystemaufeinemhandelsüblichenLaptopfunktionieren,einEntwicklerkanndamitortsun-abhängigauchbeieinemKunden,ineinemFahrzeug,etc.einMess-SystemzuDemonstrations-odersonstigenZweckenaufbauen.InVerbindungmitEntwick-lungssystemen aber auch generell in der Industrie wird für die Signalverarbei-tung meist eine serielle Schnittstelle verwendet, daher soll das zu erstellendeSystemauchhieraufaufbauen.DiebisherigeMethodeeinsolchesSystemauf-zubauenwarinderRegelmitmehrAufwandundmitumfangreichererHardwareverbunden, die zu bedienen nicht unbedingt einfach oder leicht zu verstehenwar.DieseArbeitbeziehtsichbezüglichderKommandosaufdenGerätepoolderFirmaStollmannE+VGmbH.

1.3 Gliederung der Arbeit

In Kapitel 2wirdzunächstdiefürdieseArbeitverwendeteHardwareundSoft-waredesGesamtsystemsvorgestellt.DieFunktionsweisederBluetoothprotokollesollerläutertwerden,wieauchdasWindowssysteminseinenEigenschaftenmitderseriellenEin-/AusgabeunddenbereitgestelltenFunktionenderWindowsAPI(ApplicationProgramInterface).

11/83EINLEITUNGMotivation


EINLEITUNG

Kapitel 3befasstsichmitderAnalysedeszuErstellendenSystems.Wasmusses können, welche Randbedingungen/Umgebungen sind notwendig oder vor-handen?GibtesbereitsjetztEinschränkungeninderspäterenFunktionalität?

Kapitel 4zeigtdasDesigndernötigenSoftwareundAlternativenbezüglichderErstellung. ImAnschlusswerdendieGrundfunktionenanhandderverwendetenProzedurenerläutert.DiesewerdeneinzelninklusivederÜbergabeparameterundRückgabewertevorgestellt.

Kapitel 5prüftdieFunktionsfähigkeitderSoftwareanhandeinigerTestswiesieauchspäterdurchgeführtwerdensollen.

Kapitel 6vergleichtdieSoftwaremessungmiteinerweitauspräziserenHardware-messungundzeigteventuelleUngenauigkeiten.HierzuwerdeneinigeTestläufemitentsprechenderMesshardwarenachvollzogenunddirektgegenübergestellt.SchließlichsindeinigePraxisanwendungenderBluetoothweltaufgeführt.

Kapitel 7gibteinabschließendesFazitundeinenAusblickaufmöglicheWeiter-entwicklungenderMess-Software.

12/83GRUNDLAGEN Windows NT

Bluetooth – SSP Protokolle & AT-Kommandos

Die RS232-Schnittstelle Die Stoppuhr (timewatch)

GRUNDLAGEN

2.1 Windows NT [WNT, WIKI]

DieersteFragediegeklärtwerdenmusstewar,obdasangedachteMess-Systemauf einem auf Windows basierenden PC überhaupt praktikabel ist – welcheLatenzzeiten ergeben sich bereits für die Ausgabe eines einzelnen ZeichensundwelcheAbfolgenmüssendurchlaufenwerden,bisdasSignalamComPort(serielleSchnittstelle)anliegt?

DerAnwenderhatinderRegelkeinendirektenZugriffaufdieHardwareebenedesGesamtsystems.Diesstellt ein rechthohesMaßanSicherheit fürdasSystemdar, soll doch der Nutzer weitestgehend von den Grundlagen des Betriebssy-stemsgetrenntunddamiteklatanteFehlfunktionen/SchädenamSystemdurchunbeabsichtigte,wieauchbeabsichtigteManipulationenverhindertwerden.DiesistaberwiederumproblematischfürdieVerarbeitungvonAnfragenaneineHard-warekomponente. Zum besserenVerständnis wird zunächst der grundlegendeAufbaueinesWindowssystemsbasierendaufNTerläutert.

Der Aufbau eines Betriebssystems kann zunächst unterschiedlich strukturiertsein.ManunterscheidethierzwischendenmonolithischenSystemen,geschich-teten Systemen und Client/Server Modellen. Betriebssysteme der WindowsFamilie,welcheaufderArchitekturvonNTbasieren (Windows2000,XP,Vista),vereinen die letzen zwei Modelle. Zum besserenVerständnis der UnterschiedewerdenalledreiModelleaufgeführt.

2.1.1 Monolithisches System (Windows 9x, MS-DOS)

IndiesemSystemsinddieProzedurensoangeordnet,dasses jederProzedurerlaubtwird,eineAndereaufzurufen.DiesführtinderRegelzuschnelleremundkleineremProgrammcode,birgt jedochdenNachteil,dassÄnderungenineinerProzedurFehlerinanderenProzedurenerzeugen,oderaufdeckenkönnen.ZudemsindÄnderungenandeneinzelnenProzedurennichtsoschnellmachbar,dahierdergesamteKernelneuerzeugt(kompiliert)werdenmuss,wieesbeispielsweisebeidenAnfängenderLinuxsystemenötigwar.




GRUNDLAGEN

ApplicationProgram

ApplicationProgram

SystemServices

Hardware

OperatingSystemProcedures

UserMode

KernelMode

Abb. 2.1 Monolithisches System

In einem monolithischen System werden Applikationen strikt vom Betriebssy-stemgetrennt.DasBetriebssystemläuftineinemprivilegiertenModus–besserbekannt als „kernel mode“ – mit exklusivem Zugang zu Daten und zur Hard-ware. Jede weitere Applikation läuft im nichtprivilegierten Modus, bekannt als„user mode“. Im user mode werden nur bestimmte Schnittstellen (Interface)zumSystemundzumDatenbereichbereitgestellt.EinAufrufaufSeitendesusermodes resultiert im Normalfall immer in einen Aufruf einer Funktion im kernelmode.DerAufrufendeProzessblockiertnormalerweisesolange,bisderKerneldie Anfrage abgearbeitet hat. Der Aufbau eine monolithischen Systems führtzwarzueinemschnelleremundkompakterenSystem,dieAbsturzsicherheit istjedochkaumgegeben.FällteineKomponenteaus,sokannsienichtneugeladenwerden,dasSystemstürztab.

1�/83GRUNDLAGEN Windows NT



GRUNDLAGEN

2.1.2 Schichtmodell (Windows NT, W2K, XP, Vista)

EntgegendemmonolithischenSystemwerdenhiergrößereProzesseinModulenverpackt.JedesModulunterstützwiederumeinSetvonFunktionen,dievondenanderen Modulen aufgerufen werden können. Allerdings kann ein höher gele-generLayer(Schicht)nurFunktioneneinestiefergelegenenLayersaufrufen.DerVorteilistdieleichtereWartbarkeit(einzelneLayerkönnennormalerweiseausge-tauschtodermodifiziertwerden,ohneÄnderungenandenrestlichenvollziehenzu müssen) und der einfachere Aufbau der Software. Es ist zudem möglichdaskompletteSystem füreineFehlersuchezurLaufzeit zudebuggen,vonderunterstenzuroberstenSchicht.

ApplicationProgram

ApplicationProgram

SystemServices

MemoryandI/ODeviceManagement

UserMode

KernelMode

FileSystem

ProcessorScheduling

Hardware

Abb. 2.2 Schichtmodell




GRUNDLAGEN

2.1.3 Client/Server (Windows NT, W2K, XP, Vista)

DiesesModellhatwenigmitderVernetzungvonSystemenineinemNetzwerkzutun,obwohldieBezeichnungdenGedankenzulässt.DieIdeeist,dasSysteminkleinere Prozesse aufzuspalten, welche jeweils eigene Funktionen bereitstellen(z.B.:Scheduling,Speicherverwaltung,etc.)TheoretischkönntenauchHardware-devicesalsProzessgesehenwerden.ClientundServerProzesselaufenimusermode,wobeiderServerprozess ineinerstetenSchleifeprüft,obeinbeliebigerClient eine Anforderung stellt. Der Client, welcher als weiterer Systemprozess,Applikation,etc.auftretenkann,sendeteineNachrichtandenServer.Diesewirdjedochnichtdirekt versendet, sonderndurchdenMicrokernel empfangenundweitergeleitet.DerServerführtdieAnweisungausundschicktdasErgebnismit-telsMicrokernelandenClientzurück.

ClientApplication DisplayServer

Microkernel

UserMode

KernelMode

Hardware

PEACEThreadsInterface FileServer

Reply

Send

Abb. 2.3 Client/Servermodell

DerVorteildiesesAufbausistdieAusfallsicherheit.Esistjederzeitmöglich,dassein Prozess, egal ob Server oder Client, ausfällt, er kann dann neu gestartetwerden, ohne dass andere Prozesse dies bemerken. Das Betriebssystem istdadurchvorVerklemmungenoderDeadlocksgeschützt.DerClientmusszudemnichtwissen,obundwodergesuchteServerexistiert,esistsomitmöglichdenServerineinemverteiltenSystemlaufenzulassen,derClientmerktauchhiervonwiedernichts.




GRUNDLAGEN

2.1.4 Windows NT Strukturmodell

DieWindowsFamilie–basierendaufNT–,nutztdie letztenzweiModelle.Derkernel mode wird meist „NT executive“ genannt. Das Schichtenmodell kommtnunzumZuge,derKernelwirdindreiSchichtenaufgeteilt:ExecutiveServices,MicrokernelundHardwareAbstractionLayer(HAL).

ExecutiveServices:HierwerdeneineReihevonFunktionenzusammengefasst,diefürdieSpeicherverwaltung,Sicherheit,Ein/Ausgabe,etc.genutztwerden.Dieein-zelnenProzesseinteragierenuntereinandernachdemo.g.Client/ServerModell.

Microkernel:HierfindetdasSchedulingvonThreads,dieBehandlungvonExcep-tions und Interrupts, Synchronisation von Multiprozessorsystemen, etc. statt.DerScheduler isteine Instanz,welchedieverfügbarenRessourcensinnvoll fürdie einzelnen Prozesse zurVerfügung stellt und wieder entzieht. Das Schedu-lingfunktioniertzunächstnachPrioritäten,dievoneinemEntwicklervorgegebenwerden.DiePrioritätstufensind„Niedrig“(Ruhezustand), „WenigeralsNormal“,„Normal“, „Höher als Normal“, „Hoch“ und „Echtzeit“, wobei die Einstellung„Echtzeit“ trotzdesNamenskeinehartenEchtzeitanforderungen ineinemWin-dowssystemermöglichtund inderRegel auchmöglichstwenigenSystempro-zessenvorbehaltenseinsoll.StandardwertistfüralleProgramme„Normal“,diePrioritätkannjedochzumStartoderwährendderLaufzeiteinerApplikationüberden„WindowsTaskManager“verändertwerden.DieApplikationstellthierbeiden„Mutterprozess“dar,von ihmgestarteteweitereProzesse/Threadserbenauto-matischdiePrioritätdesMutterprozesses.DiePrioritätwirdinternalsganzzah-ligerIntegerwertdargestellt.SomithatdiePriorität„Normal“denBasiswert„8“.Der Scheduler kann nach bestimmten internen Algorithmen den Prioritätslevelverändern,abhängigvondemBasiswert.EinzweiterFaktorfürdasSchedulingistdersogenannte„Quantum“Wert.DieserwirdvomSchedulerdynamischver-gebenundbestimmtdieProzessorzeit,welchedemThreadzurVerfügunggestelltwird(Unabhängigdavon,obderThreaddabeiseineAufgabenabarbeitenkann).AufdieseZeithateinEntwicklerkeinenEinfluss,siestellteineunberechenbareGrößedarundesistsomitnichtvorhersehbar,wanneinThreaddieihmbeauf-tragtenBerechnungen/Aufgabenfertigstellt[SCHED].




GRUNDLAGEN

Real-timetimecritical

31

Real-time Levels 16-31

Real-timeidleDynamictimecritical

Real-time Levels 1-15

Dynamicidle

24

1615

10 Usedforzeropagethread–notavailabletoWin32applications

13

10

8

6

4

Real-time

High

AboveNormal

Normal

BelowNormal

Idle

Abb. 2.4 Schema zu den Prioritäten unter Windows

HardwareAbstractionLayer(HAL):DieserLayertrenntdasBetriebssystemvondereigentlichenHardware,agiertals InterfacezurHardwareundschütztsomitdasSystemvorKomplikationenmitderInteraktionselbiger.




GRUNDLAGEN

UserMode

KernelMode

SecuritySubsystem

OS/2Subsystem

WIN32Subsystem

POSIXSubsystem

LogonProcess OS/2Application Win32Application

POSIXApplication

Microkernel

HardwareAbstractionLayer(HAL)

Exe

cutiv

e

Hardware

ExecutiveServices

DeviceDrivers

NetworkDrivers

FileSystems

CacheManager

I/OManager ObjectManager

SecurityReferenceMonitor

ProcessManager

LocalProcedure

CallFacility

VirtualMemoryManager

Abb 2.5 Windows NT Blockdiagramm

NachdemdasBetriebssystemnuninseinemAufbauundseinerFunktionsweiseetwasbekanntist,lässtsichnunabschätzen,woVerzögerungeninderAusfüh-rungeines„einfachen“SchreibprozessesaufdieserielleSchnittstelleaufkommenwerden.DaszuerstellendeMess-Systemmusssich,wiealleweiterenApplikati-onenauch,folgendemAblaufunterwerfen:

Die Applikation ruft für eine Ausgabe an die serielle Schnittstelle die MethodecomWrite()auf.EntwedererfolgtnuneineWeiterleitungderAnfrageaneinSub-systemoderaneine„dynamic-linklibrary“(.dll).InbeidenFällenführtdieszumAufruf der Local Procedure Call Facility (LPC), welche für die Kommunikationaller lokalerSystemprozessenachdemClient/ServerPrinzip zuständig ist.Die




GRUNDLAGEN

Anforderung wird dann zunächst an den I/O Manager weitergeleitet, welcherzuersteineAnfragebeimObjectManager–alleSystemkomponenten,Applikati-onen,etc.werdenunterNTalsObjektdargestelltundmüssensichwährendderInitialisierungsphase beim Object Manager anmelden – durchführt. Der ObjectManager prüft, ob das Zielobjekt (hier: serielle Schnittstelle) überhaupt vor-handenist.DanachmusseineAnfragebeimSecurityReferenceMonitorgestelltwerden,obdasaufrufendeObjekt (hierdieDLL)überhauptdienötigenRechtebesitzt um die anvisierte Aktion auszuführen. Ist soweit alles fehlerfrei erfolgt,erstelltderI/OManagereinsogenanntes„I/Orequestpacket(IRP)“.DieseswirdandenjeweiligenGerätetreiberweitergeleitetundnachErledigungderAufgabeandenI/OManagerzurückgegeben.DieservernichtetdanndasIRPundgibtanseinenAufrufereinenStatuszurück(success/failed).

Anhand der dargestellten Abläufe wird ersichtlich, dass derWeg zur seriellenAusgabenichtohneWeiteresdurchführbarist.BedingtdurchdieverschiedenenAufrufemehrererKomponentenergibtsichdiewindowseigeneLatenzzeit.Dassdiesenichtimmergleichist–bedingtdurchdenSchedulerdesMicrokernels–wirdimVerlaufdieserArbeitnochersichtlich.LetztendlichentscheidetderScheduleranhandderdynamischenPrioritäten,wanneinProzesszurAusführungkommtoderpausierenmuss.

2.2 Bluetooth – SPP Protokolle & AT-Kommandos [WIKI, BT1, BT2, BT3, BT4, BT5]

DernachdemdänischenWikingerkönigHaraldBlåtand(zudeutschBlauzahn,eng-lisch Bluetooth) benannte Funkstandard wurde zu Beginn der 90er ursprünglichvonEricssonnachdemStandard IEEE802.15.1erstellt.DerHauptzweckdieserdrahtlosenKommunikationbestandindemErsatzdesKabelgewirrs,welchessichderzeit schon erheblich vergrößert hatte. Seinerzeit musstenTastaturen, Mäuse,Druckeretc.bereitsperKabelangebundenwerden.MitdemneuaufkommendenTrendDigitalkameras,PDAs,etc.mitdemPCzuverbindenwurdedas Interessean einer zuverlässigen und günstigen Funktechnologie groß. Die Funktechnologieermöglicht es zudem drahtlose Ad-Hoc Pikonetze aufzubauen. Pikonetze sindlokaleNetze,die inderRegelüberkeinegroßeAusdehnungverfügenundkeine




GRUNDLAGEN

Infrastruktur benötigen. Jedes Gerät kann mit bis zu sieben weiteren Geräteninnerhalb des Netzes kommunizieren, wobei es maximal einen Master gebendarf. Daneben besteht auch die Möglichkeit, Geräte in mehreren Pikonetzen zubetreiben, hier allerdings nur Slaves. Der Master kann jedoch auch als Slave ineinemweiterenPikonetzagieren,dabeiwirddasalteNetzunterbrochen.

M

S

S

S

S

S

Abb. 2.6 Aufbau eines typischen Pikonetzes

Im Folgenden werden die Bluetoothspezifikationen und Grundfunktionen grobvorgestellt,weiterhinwirdnäheraufdasfürdasMess-SystemrelevanteProtokollunddieSteuerbefehleeingegangen.

2.2.1 Frequenzbereich 2,4 GHz, ISM-Band

DasBluetooth-Systemwirdimlizenzfreien2,4-GHz-ISM-Band(Industrial,Scien-tificandMedical-Band)betrieben (2.400bis 2.483,5MHz).DasFrequenzbandwirdin79Hochfrequenzkanäleaufgeteilt,welchevon0bis78durchnummeriertsind.SieliegeninAbständenvon1MHzundbeginnenbei2.402MHz.AmAnfangundEndedesBandessindPufferzoneneingerichtet,umländerspezifischeVor-schrifteneinhaltenzukönnen.DahergehtdasrealnutzbareBandvon2.402bis2.480MHz.DieDatenrateliegtbeica.1Mbit/s,wobeidieNettodatenratejenach




GRUNDLAGEN

PaketgrößeunddadurchvariablemOverheadvonStart/Stop-bitsetc.geringerist.BluetoothmodulewerdeninzunächstdreiLeistungsklassenaufgeteilt:

Geräteklasse Ausgangsleistung Max Ausgangsleistung Min. Reichweite

Class 1 100mW 1,00mW ~100m

Class 2 2,5mW 0,25mW ~50m

Class 3 1mW - ~10m

Abb 2.7 Bluetoothgeräteklassen Die Reichweiten hängen jedoch von der Antennenart und der Umgebung ab (Mauern, etc.).

Bluetooth bietet zudem eine Option zurVerschlüsselung (128bit) der Daten an,derAnwenderkannsichhiereineseigensgewähltenSchlüssels(PIN)bedienen,dermindestens4,höchstens16ZiffernoderZeichennachUNICODE8enthaltendarf. Dieser PIN muss neben dem Master auch den Slaves bekannt sein. Derfertige Sitzungsschlüssel für die sichere Übertragung wird schließlich aus demgewählten PIN-Code, einer vom Master erstellten Zufallszahl und der Gerätea-dresseerzeugt,wobeidieZufallszahldenSlavesfürdieEntschlüsselungmitgeteiltwerdenmuss.BeijederneuauftretendenÜbertragungwirddieserneuerzeugt.

2.2.2 Frequenzsprungverfahren (frequencyhopping)

Die Frequenzkanäle werden von den Geräten nach einem bestimmten Algo-rithmus „durchwandert“ (Frequenz-Hopping-Algorithmus oder auch „Hop-Fre-quenz“).DieserAlgorithmusistfür jedesModulvordefiniert,manunterscheidetaberhierbeizwischendemAlgorithmuszumVerbindungsaufbauunddemfürdenregulären Betrieb. Während desVerbindungsaufbaus wird ein statischer Algo-rithmusdurchlaufen,hierwerden lediglich32der78möglichenKanälegenutztumZeitzusparen.Alsersteswerdendie16benachbartenKanäleverwendet:

{f(k – 8), ..., f(k), ..., f(k + 7)},

wobeif(k)=derzumStartzeitpunktderHopsequenzaktuelleKanalist.

DanachdierestlichenKanäle:{f(k + 8), ..., f(k + 15), f(k – 16), ..., f(k – 9)}




GRUNDLAGEN

Die Menge der Kanäle wird in zwei sogenannte „Trains“ unterteilt, die ersteMengestelltdenA-traindar,dieZweitedenB-train.DieAbtastungderTrainswirdständigwiederholt,wobeiinderRegelderTrainalle2,25Sekundengewechseltwird.DieDauerdergesamtenAbtastprozeduristnichtlimitiert,wirdmeistaberauf5Sekundenbegrenzt.WozuaberteiltmandieFrequenzeninTrainsauf?DieswirdanhandeinesrealistischenSzenarioserläutert.EsexistierenzweiModule,AundB,welchebereitsverbundenunddamitsynchronisiertsind.DieVerbindungwirdgetrennt,beideModuledurchlaufennunwiederdie32obenbeschriebenenFrequenzen.WennnuneinModulsicherneutmitdemanderenModulverbindenwill, so ist die Chance nahezu bei 100%, dass es das Gerät auf den benach-barten16Kanälenfindet.DurchdieniegenautaktgleichenQuarze,welchedieFrequenzderHardwarevorgeben,driftennacheinigerZeitdieehemalssynchro-nisiertenModule inderSprungfrequenzauseinander.WerdendieModulenichtvomStromgetrenntoderresettet,dauertesca.2,5Tage,bisdieAbdriftsohochist,dasssichdasZielgerätindenäußerenFrequenzkanälenbefindet.

DerVerbindungsaufbau ist für alleGerätegleichundkannmitdieserMethodeohnehin schon bis zu 10 Sekunden und länger dauern. Hat der Master einenkommunikationsbereiten Slave gefunden, gibt der Master nun seine aktuellenTiming-InformationenfürdenVerbindungsaufbaudemSlavebekannt. IndiesenInformationen sind die vollständige Geräteadresse, die Phase der Hopping-Sequenz,dieSystemzeit,eineZufallszahlunddieClock-Informationenenthalten.MitHilfederClock-InformationundderSystemzeitsynchronisiertsichderSlaveaufdieselbeHop-FrequenzdesMasters.MitHilfederGeräteadresse,derdurchdenMastergeneriertenZufallszahlundderSystemzeitkannderSlavenundenneuen Hop-Algorithmus für die bestehendeVerbindung errechnen. Der grund-sätzlicheBerechnungsalgorithmus ist immergleich,dasErgebnis jedochdurchdieobenangegebenenParameterunterschiedlich.StehtdieVerbindung,sendetder Master ein zur Synchronisation bestimmtes Paket an den Slave, welchesdieserquittiert.ErfolgtdieQuittierung,kannderMasterdavonausgehen,dassder Slave dieTabelle mit den Hop-Frequenzen richtig errechnet hat und nunsynchronmitdemMasterdurchdieKanälespringt.DieKanälewerdenalle625Mikrosekunden(µs)gewechselt,dasergibt1600HopsproSekunde.




GRUNDLAGEN

NachdemTDD-Verfahren (TimeDivisionDuplex)wirddieZuteilungderKanälefestgelegt,dasheißt,dassSenderundEmpfängerabwechselndeineSendebe-rechtigung haben. Der Master nutzt hier immer die geraden, der Slave immerdieungeradenSlots (Zeitfenster).Nach jedemDatenpaket,dasgesendetwird,wartetdasGerätaufeineAntwort.DadurchkanndieBandbreiteameffizientestengenutzt werden, es ist so möglich die Paketgröße zu variieren und somit demUp-undDownstreamverschiedeneBandbreitenzuzuteilen.

625µs

Master

Slave

f(k) f(k+1) f(k+2)

Abb 2.8 Slotbelegung nach TDD

Durch die Frequenzsprünge ist es möglich eine sichere Datenübertragung zuschaffen (derHop-Algorithmus istnurdemMasterunddenverifiziertenSlavesbekannt) und man umgeht das Problem der Störanfälligkeit durch andere fun-kende Geräte in der näheren Umgebung im gleichen Frequenzband. Seit derBluetoothspezifikation2.0wurdediesesVerfahrennochverbessert,dasadaptiveFrequenzhoppingverfahren blendet nun bei Übertragungsfehlern die gestörtenund wohl anderweitig belegten Kanäle zur weiteren Nutzung aus. Der MasterermitteltdiesanhandderAnzahlfehlerhafterPaketeundschlechterSignalstärkeaufderjeweiligenFrequenz.ErblendetnundieseFrequenzausseinerSprungta-belleausundteiltdiesauchdemSlavemit.DieListedernutzbarenFrequenzenkann jedoch nur bis auf eine Mindestgröße von 20 Frequenzen runtergekürztwerden,dasonstdasFrequenzhoppingverfahrensinnloswird.EswurdejedochnichtinderBluetoothspezifikationfestgelegt,wanneinzunächstausgeblendeterKanal wieder freigegeben wird. Dies kann entweder anwenderspezifisch odervomChipherstellerdefiniertwerden,hieristz.B.:einAlgorithmuszuimplemen-tieren,derstetsdieQualitätderKanäletestetundprotokolliert.




GRUNDLAGEN

InjedemZeitfenster(Slot)könnenDatengesendetwerden,wobeiderLinkManagerjenachVerbindungsqualitätentscheidet,welchePaketgrößeaktuellgewähltwird.EsgibtPaketgrößenvon1-Slotbiszu5-Slotundtheoretischmehr.DaderSenderbei einem Mehrslotpaket den Overhead (Start-/Stoppbit, Checksumme, etc.)weglässtumdievolleZeitzummaximalenTransferauszunutzen,kannesjedochbei Datenverlusten zu erheblichen Einbußen bei der Datenrate kommen. DerEmpfängerweißerstmitdemEmpfangdesletztenPakets,oballevorangegan-genenPaketefehlerfreiwaren,oderobeseinenÜbertragungsfehlergab.LeiderkönnennichteinzelnePaketfragmenteerneutgesendetwerden,sondernnurdaskomplettePaket.ProblematischbeiMehrslotpaketenistauch,dassdieFrequenzwährendderÜbertragungnichtgewechseltwird.StörungendesKanalswerden–wieobenbeschrieben–erstnachSendendesPaketesbemerkt.

2.2.3 Der Bluetoothstack

Aus dem genannten Bluetoothstack werden nur die für diese Arbeit wichtigenTeile nachfolgend ausführlicher dargestellt. Der Stack ist das grundlegendeBetriebssystemfüreinBluetoothmodul.

oBluetooth RadioSpezifiziertdasFrequenzband,dieSender-undEmpfängereigenschaften(z.B.Sendeleistung)sowiediegrundlegendenEigenschaftenderFunktechnik.

oBasebandFastallewichtigenTechnologien,wiederAufbauvonPikonetzen,Frequenz-hopping,AdressierungvonweiterenBluetoothgeräten,Systemsicherheit,Feh-lerkorrektur,etc.,werdenimBasisbandimplementiert.

o Link Manager (LM)DerLMsorgtfüreinenreibungslosenVerbindungsaufbauundistverantwortlichfürdieDatensicherheit,Paketgrößeunddie Identifikation.Er ist inderRegeleinTeilderFirmware,welchemitdemChiperworbenwird.




GRUNDLAGEN

o Host Controller Interface (HCI)Das HCI bildet die Schnittstelle zwischen den unteren Protokollschichten(Bluetooth Controller) und den oberen Schichten (Host System), sofern derBluetoothstack nicht exklusiv auf dem Bluetoothchip implementiert ist. DiespezifiziertenBluetoothprotokollegehendamitdurchdiegesamteHardware,wobeidieunterenLayeraufdemChipselbstunddieoberennormalerweiseauf einem anderen System (Coprozessor) liegen. Damit diese getrenntenSysteme miteinander kommunizieren können wird das HCI eingesetzt. DerSinndabeiist,dasssodieoberenProtokollschichtenmitChipsverschiedenerHerstellergenutztwerdenkönnenoder,dassz.B.derHostController indenSleepModusgehenkannumsoStromzusparen.

oLogical Link Control and Adaption Protocol (L2CAP)Protokoll der Sicherungsschicht im Bluetoothschichtenmodell. Passt diehöheren Schichten an die Fähigkeiten des Basisbands an und verbirgt dieÜbertragungsdetails (verbindungslosundverbindungsorientiert).EsstelltdieSchnittstellezwischenhöher liegendenAnwendungsschichtenunddentieferliegendenSchichtenderFirmwaredar.OhnedieseSchichtistzwardergrund-sätzlicheBluetoothbetriebmöglich, jedochohnediewirklichnettenFeatureswie Multi-Protokoll-Übertragung, Ad-Hoc-Netzwerke, etc. In der Abbildung2.3wirddieLagedieserSchichtersichtlich.

oService Discovery Protocoll (SDP)DasSDPlegtdieSichtbarkeiteinesGerätesfestundwelcheDiensteesnachaußen anbieten kann, quasi die „gelben Seiten“ des Bluetooth. Ein näheresBeispielfürsolcheineEintragungfindetsichineinemFolgekapitel.




GRUNDLAGEN

LMP

RFCOMM

SDPTCSBINAT-Comm.WAP

WAE

OBEX

vCard/vCall

HostControllerInterface

UDPTCP

IP

PPP

Baseband

L2CAP

BNEP

IP

UDPTCP

Audio

BlutoothRadio

Abb 2.9 Bluetooth Protocol Stack

2.2.4 Das RFCOMM Cable Replacement Protocol

Das RFCOMM Kabelersatzprotokoll liegt auf dem Hostsystem und stellt demBetriebssystem Dienstleistungen zur Verfügung. Es spielt eine zentrale RollebeiderVerwendungvonBluetooth,daesdiesonstüblichephysikalischeseri-elle Schnittstelle abbildet. Es können durch das RFCOMM bis zu 60 virtuelleSchnittstellen nach dem RS232-Standard mit einer Datenrate von ca. 128kbssimuliert werden. Diese Geschwindigkeit entspricht damit theoretisch zweigebündelten ISDN-Kanälen.EsbietetnachderNormEIA/TIA-232-EzusätzlichHardwarehandshakeundeinemaximaleGeschwindigkeitvon115kbps.DasPro-tokollbasiertaufdemETSIMobilfunkstandardTS07.10umdiePortierbarkeitauf




GRUNDLAGEN

Handys jederzeit zu ermöglichen. Lediglich eine kleine Untermenge ist jedochimplementiert.

EsgibtzweiArtenfürdieKommunikationüberdievirtuelleserielleSchnittstelle:

o Typ1 Kommunikation:PunktzuPunktVerbindungzweiergleichberechtigterGeräte.Typ1GerätesindEndgeräte,alsoMäuse,Drucker,Computer,etc.

o Typ 2 Kommunikation: Gateway-Verbindung, hierdurch wird es PCs ohneeigene Bluetoothmodule ermöglicht, auf entfernteTyp 1 Geräte zuzugreifen.TypischeVertreterdiesesTypssindAccesspointsoderModems,diebeispiels-weiseeinNetzwerkvonGerätenmitentferntenEndgerätenviaBluetoothver-bindet.InderfolgendenGrafikistbeispielsweiseeinPCüberdenGatewaymiteinementferntenEndgerät (Drucker,etc.)verbunden,dernurüberBluetoothzugänglichist.

Endgerät PC,o.ä.Gateway

FunkverbindungphysikalischeVerbindung

Abb. 2.10 Beispiel für eine Typ 2 Kommunikation

Gemäß derTS 07.10 wird für die Kommunikation zwischen zwei Geräten eineNull-Modem-Emulationerzeugt.ImPrinzipsolltedasNull-Modem-Modellimmerfunktionieren,eskannabernichtgarantiertwerden–wieauchbeikabelgebun-denenVerbindungen.DiesistsomitkeineSchwächedesBluetooth,sonderneingenerellesProblemeinerNull-ModemVerbindung.




GRUNDLAGEN

1 FG

TX

RX

RTS

CTS

DSR

Ground

CD

DTR

RI

„on“

„off“

FG

TX

RX

RTS

CTS

DSR

Ground

CD

DTR

RI

„on“

„off“

2

3

4

5

6

7

8

20

22

Abb 2.11 RFCOMM-Null-Modem-Schema

Geräte, die über das RFCOMM verbunden sind, können theoretisch bis zu 60serielleVerbindungen gleichzeitig öffnen. Dies ist jedoch implementierungsab-hängig und daher nicht unbedingt realisierbar (z.B.: muss die Software in derLage sein mehrere RFCOMM Instanzen auf dem Gerät zu erzeugen). Für dieIdentifikationdereinzelnengemultiplextenKanälewirdschließlicheinDataLinkIdentifier(DLCI)verwendet.DerDLCIistTeildesAdressfeldesinnerhalbeinesTS07.10RahmensundbleibtwährendderVerbindungssessionimmergleich.

RFCOMM definiert also ein Protokoll, das – auf Basis derTS 07.10 Spezifika-tion–dieEmulationeinerseriellenSchnittstelleermöglicht.WirddiesesProtokollvoneinemBluetoothstackunterstützt,sobedeutetes imUmkehrschlussnicht,dassauchalleAnwendungen,dieeineserielleSchnittstellenutzen,problemlosmitBluetoothzusammenarbeitenwerden.RFCOMMwirdmeistenseinTeileines




GRUNDLAGEN

Schnittstellentreibers sein, welcher die eigentliche Port-Abstraktion vornimmt.JedeApplikationmusssichzudemüberdasSDPregistrierenbevoresdieseri-elleSchnittstelleverwendenkann.

2.2.5 Das SPP Profil (Serial Port Profile)

InderBluetoothspezifikationsind13verschiedeneProfiledefiniert,teilweiseauf-einanderaufbauend,welchealle imRFCOMMenthaltensind.Dieviergrundle-gendenProfilesind

o GAP (General Access Profile) HierwerdenallgemeineProzedurenfürdieErkennungvonGeräten,denVer-bindungsaufbauunddasVerbindungsmanagementbereitgestellt.EsstelltdasGrundlegendeProfilfürdieFolgendendar.

o SDAP (Service Discovery Application Profile) DiesesProfilbeschreibtgrundsätzlicheFunktionenfürAnwendungen,dieaufdasSDPzugreifenumverfügbareProfile/Protokollezuproklamieren.

o SPP (Serial Port Profile)Profil,welcheszumEinsatzkommt,sobaldBluetoothalsKabelersatzdienensoll.AufSPPbasierenz.B.:dieProfilefürFax-oderLAN-Dienste.

o GOEP (Generic Object Exchange Profile) FürdenAustauschkomplexerDatenobjektekommtdasGOEPzumEinsatz.EsdefiniertdieVerwendungvonOBEXinnerhalbvonBluetoothundimBeson-derendenDateitransferunddieSynchronisationvonDatenobjekten.




GRUNDLAGEN

Dial-upNetworkingProfile

FaxProfile

HeadsetProfile

LANAccessProfile

FileTransferProfile

ObjectPushProfile

SynchronizationProfile

GenericObjectExchangeProfile

SerialPortProfile

ServiceDiscoveryProfile

CordlessTelephonyProfile IntercomProfile

TCS-BIN-basedProfileGenericAccessProfile

Abb 2.12 Aufbau des GAP

Für diese Arbeit wird lediglich das SPP Profil bearbeitet, der normale Umfangder kompletten Profilbeschreibung beträgt alleine in der Kurzfassung aus derBluetoothspezifikation1.1füralle13Profilerund450Seiten.Sinnvollzuerwähnenistjedoch,dassdasGAPimModellganzobeninderProfilhierarchiestehtundalleweiterenProfilemehroderwenigerdirektaufdiesemaufbauen.

Wenn serielle Datenverbindungen ersetzt werden sollen, kommt das Serial PortProfilezumEinsatz.DamitwirddieBasisfürdiemeistenBluetoothanwendungengeschaffen. Alle weiteren Profile verwenden das SPP, außer dasTelefon-Steu-erungs-Profil. Typische Anwendungen, welche die serielle Verbindung nutzenwerden, sind sogenannte „Legacy Application“, also Anwendungen, die bisherübereinenkonventionellenseriellenKanalkommunizierthabenundnunaufderBasisvonRFCOMMeinendrahtlosenDatenaustauschvollziehenkönnen.EinPro-blemwirdhierbereitserkennbar,welchesauchindieserArbeitthematisiertwerdensoll:DieTatsache,dasseineFunkverbindungimmererstaufgebautwerdenmussvoreinemDatenaustauschstehtdembisherigenFallgegenüber,dasseinphysi-kalischesKabelmitdemZusammensteckendieVerbindungbereitsaufgebauthat.




GRUNDLAGEN

EsentstehendadurchnichtnurVerzögerungen,esmussnunauchsichergestelltwerden,dassdieVerbindungzunächsteinmalaufgebautwird.DiehierfürnötigeSoftwareistjenachAnwendungsfallundHardwaredurchausunterschiedlich,dergrundsätzlicheAufbaumitdennötigenFunktionenistjedochimmergleich.

BeiderseriellenVerbindungzweierBluetoothgerätegibtesimmereinenMaster,oderauchInitiator.DiesernimmtdieaktiveRolleindemAufbauderKommunika-tionein.DaszweiteGerät,derSlaveoderAcceptornimmtdagegendiepassiveRolleein.(DieseUnterteilungderVerhaltensweisenwirdimspäterenVerlaufderArbeitnocheinekleine, jedochnichtunwesentlicheRollespielen.)Sicherheits-merkmale,wieAutorisierungoderVerschlüsselungsindimSerialPortProfileopti-onal,müssenjedochbeieinerAnforderungentsprechendverarbeitetwerden.

Für das Serial Port Profile wird nur die Unterstützung von 1-Slot-Datenpa-ketenvorausgesetzt,wodurchdiemaximaleDatenratevon128kbpszustandekommt.Diesistnichtweitertragisch,dientesdochderSicherheit,dassauchbeischlechtemEmpfangmöglichstfehlerfreieTransfersmöglichsind.HöhereDaten-ratensindoptionaljedochmöglichbeiMehrslotdatenpaketen.

Der SPP-Dienst definiert schließlich drei verschiedene Dienstprozeduren: derdurchdenInitiatorgetriebeneaktiveVerbindungsaufbauunddasEinrichtendervirtuellen seriellenVerbindung, die Handlungen des Akzeptors zum AnnehmeneinesVerbindungsaufbausundEinrichtenderseriellenVerbindungundschließlichinwelcherFormderAkzeptorseineDiensteinderSDP-Datenbankhinterlegt.

2.2.5.1 Aktiver Verbindungsaufbau

Der Verbindungsaufbau wird durch eine Anfrage an den SDP nach einembestimmtenDienstinitiiert.MittelsderdortgespeichertenAttributewirdfestgelegt,überwelchenRFCOMMKanaldieVerbindungaufgebautwird.SoweithiermehrereMöglichkeitengegebensind,kannderAnwenderentscheiden,welcheSchnitt-stellezunutzenist.OptionalkannaucheinegesicherteVerbindungangefordertwerden.SchließlichkanneinneuerL2CAPKanalfürdieRFCOMMKommunikationund mit der ausgewählten Kanalnummer der Datenlink für den Datentransfergeöffnetwerden.




GRUNDLAGEN

2.2.5.2 Akzeptieren einer Verbindungsanfrage

FürdieAnforderungeinergesichertenDatenverbindungmussderAkzeptorinderLageseindieVerschlüsselungzuaktivieren.DesWeiterenmusserinderLageseineinenL2CAPKanaleinzurichtenundeineRFCOMMSitzungzuunterstützen.

2.2.5.3 Registrieren der verfügbaren Dienste

AlleApplikationen,dieüberRFCOMMerreichbarsind,müsseninderSDPDaten-bankregistriertwerden,damitandereDevicesKenntnisüberdiefürdenVerbin-dungsaufbaubenötigtenProtokolleerhalten.AnbeieinBeispieleinesEintragsimSDPfürdasSerialPortProfile:

Gegenstand Beschreibung Type Wert AttributID

ServiceClassIDList ServiceClass()

SerialPort

UUID

0x1101

0x0001

ProtocolDescriptorList Protocol0Protocol1

L2CAPRFCOMM

UUIDUUID

0x01000x0003

0x004

ProtocolSpecificParameters Serverkanal Uint8 #Kanalnr.

ServiceName anzeigbarerText String „COM5“ Ggf.Sprach-spezifischerOffset

Abb 2.13 Eintrag im SDP für das SPP-Protokoll

DieinderSpalte„Wert“angegebenenParametersindfürdasSPPimmergleich(bisaufdenServiceNameunddieKanalnummer,LetzterewirddynamischzumStart vergeben, bleibt aber dann statisch). Sie dienen zur Identifizierung derbenötigtenProtokolle.




GRUNDLAGEN

2.2.6 Die Bluetoothhardware [AT]

FürdieseArbeitwurdenzweiHardwaredevicesderFirmaStollmannE+VGmbHeingesetzt.EshandeltsichumzweiBluetoothEvaluation-KitsBlueEva+C11/G2.

Abb 2.14 BlueEva+C11/G2

DiesesindbereitsfürdasSPPvorkonfiguriertundlassensichüberdieRS232-Schnittstelle ansprechen. Das montierte Bluetoothmodul ist ein sogenanntesBlueMod+C11/G2,eshandeltsichhierbeiumeinClass1ModulnachderBlue-toothspezifikation 2.0 von CSR (Cambridge Silicon Radio) mit einem AtmelAT91SAM7.Wie bereits im Kapitel 2.2.3 angesprochen, ist hier der Bluetooth-stackaufgespaltet.AufdemBluetoothchipsinddieunterenProtokollschichtenimplementiert, während die oberen Schichten auf dem Atmelprozessor laufen.VerbundenwerdenbeideModuleüberdasHCI.FüreinenpraxisbezogenenEin-satzwärederAtmelprozessorz.B.ineinemHandy,PDA,etc.implementiert.

C11/G2EvalBoard

HCI

BlueCore04ROM AT91SAM7

Abb. 2.15 Blockschaltbild des C11/G2 EvalBoard




GRUNDLAGEN

Angesteuert wird das Device über sogenannte AT-Befehle. Der AT-BefehlssatzwurdeursprünglichvonderFirmaHayesCommunicationsfürdieeinfacheKon-figuration von Modems entwickelt und ist zu einem Quasi-Industriestandardgeworden.ATbedeutethier„attention“,gefolgtvoneinemBefehl.DergesamteBefehlssatzteiltsichinviergrundlegendeBefehlsklassenauf:

1. Grundlegender Befehlssatz:NachdemATfolgenhierBuchstaben–manchmalauchzusätzlichinVerbindungmitZahlen–z.B.:‚D’für„dial“.OftfolgenhiernochNummern.DervollständigeBefehl fürdenVerbindungsaufbau lautet somitATD{Btadress}.DieBluetootha-dresseistdiedesSlaves,angegebenalszwölfstelligerHexadezimalcode.Gene-rell istzubeachten,dassdieGroß-/Kleinschreibungnichtrelevantist.ImASCIIZeichensatzunterscheidensichgroßeundkleineBuchstabennurdurcheinBitimBitmuster,welchesbeiderZeichenerkennungnichtbeachtetwird.

2. Erweiterter Befehlssatz:DurchdieZugabedesSonderzeichen‚&’nachdemATkannderGrundlegendeBefehlssatzerweitertwerden.EinBeispielisthierAT&FfürdasSetzenderFabrik-einstellungen,wobeiATFdasÜbertragungsformatfestlegt.

3. Herstellerabhängiger Befehlssatz:Diese Befehle beginnen mit ‚\’ oder ‚%’, hierunter verbergen sich proprietäreBefehlederHersteller.

4. RegisterbefehleHiermitkönnendieRegisterselbstbeschriebenwerden.DieSyntaxhatdasMusterS(r)=n,wobei ‚r’dieNummerdesRegistersund ‚n’derneueWertdarstellt.DerBefehlS7=90verändertdenWertdesRegisters#7aufdenWert90.

EinausführlichererAuszugauseineröffentlichenHayesCommandListebefindetsichimAnhang.




GRUNDLAGEN

2.3 Die RS232-Schnittstelle [WIKI, RS232]

2.3.1 Hardware

Eine im Computerhardwarebereich stark verbreitete und bekannte Computer-schnittstelle stellt die in den 1960er Jahren erfundene serielle Schnittstelle RS232 dar. Bis Anfang 2000 war sie immer noch standardmäßig auf allen erwerblichen Mainboards verbaut und ist heute in industriellen Steuerungsanlagen weiterhin vorzufinden. Die Schnittstelle wurde später umbenannt von der EIA-Electronic Industries Alliance zu EIA-232. Die EIA gibt bis heute weltweite Standards unter Anderem für Modemverbindungen frei. Obwohl schon vor einigen Jahren umben-annt, ist der Name „RS232“ unter Anwendern und Entwicklern am meisten verbreitet. Die Umbenennung ist eine Folge mehrerer Erweiterungen und Verän-derungen des Standards, Zusammenschluss der Organisation mit anderen, etc. Somit kann die hier beschriebene Schnittstelle auch RS-232, EIA-232, TIA-232, EIA/TIA-232, ANSI/EIA-232, ANSI/EIA/TIA-232, etc. genannt werden. Die aktu-elle Version lautet korrekt ANSI/EIA/TIA-232-F-1997, wobei das ‚F’ die Version, das Letzte die entsprechende Jahreszahl ist.

DieDatenübertragungerfolgtdurcheineinfachesasynchrones,seriellesVerfahren.

Seriell bedeutet, dass die einzelnen Bits des zu übertragenden Bytes nachei-nanderübereineeinzigeDatenleitunggeschobenwerden.EsgibthierkeineKon-trollleitung,diedemKommunikationspartnermitteilt,wanndasnächsteBitaufdieDatenleitunggeschicktwird.SenderundEmpfängermüssenalsomitexaktdemselbenTaktarbeitenundderSendermussdemEmpfängermitteilen,wanndasersteBitderDatenanfängt.

AlleRS232-Leitungen(mitAusnahmederMasseleitung)arbeitenmitdenSpan-nungspegelnimBereichvon+15V(füreinelogische‚0‘)und-15V(füreinelogi-sche‚1‘).DerBereichzwischen-3Vund+3Vistundefiniert.DerDatenempfängererwartetfüreine0eineSpannungvonüber+3Vundfüreine1eineSpannungvonunter-3V.FürdenSendergilt,dassderSpannungsbereichfürdenAusgangmindestens +/-5V betragen muss, etabliert haben sich +/-12V. Für die Steuer-leitungen (Handshakeleitungen)bedeutetONeinenhohenPegel (+5V ...+15V)undOFFeinennegativenPegel (-5V ... -15V).DasichdieseSpannungspegel




GRUNDLAGEN

nichtbesondersgutmitdenheutzutagemeistverwendetenTTL-Pegeln(Transi-stor-Transistor-Logik)vertragen,werdeninderRegelspezielleTreiberschaltkreiseeingesetzt,umdiesePegelaufTTL-Pegelanzupassen(‚1‘=OFF=5V;‚0‘=ON=0V).SolcheTreiberschaltkreisesindz.B.derMAX232vomMAXIM.Diemaxi-maleDatenübertragungsrateliegtimBereichvon50biszu921.600bps,wobeiGeschwindigkeiten über 115.200 nicht mehr mit der herkömmlichen Schnitt-stellenhardwarerealisierbarsind.DiemaximaleKabellängeistimBezugaufdieBaudratespezifiziert,bei115.200bpsliegtdiemaximaleLängebei1,5Metern.HeutigeTreiberbausteinesindjedochbezüglichderelektrischenLeistungbesserkonstruiert,wodurcheinelängeresKabelsowohltheoretischalsauchpraktischmöglichist.DiegenaueLängeistaberHardwareabhängigundkannnichtanhandderDatenblätterabgeleitetwerden.

Das Übertragungsformat folgt einem festgelegten Muster. Zu Beginn wirdzur Synchronisation das Startbit gesendet, gefolgt von 8 Datenbits (vom LSBzumMSB),demParitätsbit,einemStoppbitundnachkurzerRuheeinweiteresStartbitumdasEndederÜbertragungzudeklarieren.DasParitätsbitdientderFehlererkennungundgibtan,obursprünglicheineungeradeodergeradeAnzahlvon„1“-Bitsgesendetwurde.EsbeziehtsichhierbeinuraufdieDatenbits,dieStart/Stoppbitswerdennichtbeachtet.Beispiel:dasDatenbitmuster0000001bsollübertragenwerden,dasFormatist7E1(siebenDatenbits,geradeParität,einStoppbit).DasParitätsbitfürdieEinstellung„Even“mussnundie„1“enthalten,damitdieGesamtanzahlEinsengeradeist.FürdasBitmuster0000011bistdasParitätsbit nun auf „0“ zu setzen. Im Allgemeinen Gebrauch werden meist fol-gendeEinstellungenverwendet:8Datenbits,noParity,1Stoppbit,inderRegelals8N1abgekürzt.FürdieÜbertragungeinesBytessinddamitmindestens1+8+1„Bitdauern“nötig,woraussichbei115.200Bit/sfürdieNutzdateneinMaxi-maldurchsatzvon92.160Bit/s(=115.200*8/10Bit/s)ergibt.




GRUNDLAGEN

9600 8O1 = 9600 Baud; 8 Datenbits; odd Parity; 1 StopbitASCII„G“=$47=01000111

Sta

rtB

it

LBS

0

Bit

1

Bit

2

Bit

3

Bit

4

Bit

5

Bit

6

MS

E7

odd

Parit

y

Sto

pB

it

Ruh

e

Sta

rtB

it

Ruh

e

SynchronisationDatenlow &high

Check

logisch1

logisch0

1 0 1 1 1 0 0 0 1 0 1 1 1 0

+15V

+ 3V 0V- 3V

-15V

Abb 2.16 RS232 Datenrahmen

2.3.2 Software unter Windows [WINAPI]

Der Industriestandard EIA-232 legt nur den physikalischen Aufbau und denDatenrahmen fest, wie die Schnittstelle zu nutzen ist.Wie die Umsetzung desProtokollsgenaurealisiertwirdkannvonjedemAnwender/Entwicklerselbstent-schiedenwerden.

Die hier eingesetzteBibliothek (alsdynamic link library)wurdebereits vonderFirma Stollmann E+V GmbH entwickelt und für dieses Projekt bereitgestellt.DieKonzeptiondieserBibliothekfolgt inderRegelnacheinemimmergleichenMuster,welchesalleerhältlichenApplikationenmitZugriffaufdieserielleSchnitt-stelle leistenmüssen.DadieseBibliothekselbst zudefinierenmithohemAuf-




GRUNDLAGEN

wand verbunden und eine Erfolgsgarantie nicht gegeben ist, wird hier nur dergrobeFunktionsablaufdargestellt.

DienötigenGrundfunktionenumdieHardwareanzusprechenwerdenbereitsvonderWindowsAPI(applicationprogramminginterface,zudeutsch:„SchnittstellezurAnwendungsprogrammierung“)bereitgestellt(enthalteninderwindows.h,indieserFormjedochnurinW2K,XP,Vista).

o HANDLE WINAPI CreateFile( )Hiermit wird das I/O-Objekt „ComPort“ erzeugt, der Rückgabewert ist einHandle,mitwelchemdaserzeugteObjektangesprochenwerdenkann.Über-gabeparametersindu.a.derNamedesObjektes,dieFunktionsart(read,write,both) und das sharing-attribut (soll hier nur ein einzelner oder mehrfacherZugriffauchvonanderenApplikationenerlaubtsein; fürdenComPortsolltehiernurexklusiverZugrifferlaubtsein).

o BOOL WINAPI WriteFile( )Ausgabefunktion, leitetdieübergebenenDatenandasebenfallsübergebeneHandledesI/O-ObjektesweiterzurAusgabe.

o BOOL WINAPI ReadFile( )Leseprozedur, kann jederzeit ausgeführt werden, um eingehende Daten zulesen.Übergabeparametersindu.a.wiederdasHandledesI/O-ObjektesundeinZwischenpufferinwelchemdieDatenabgelegtwerdensollen.

o BOOL WINAPI DeleteFile( )Hier wird das I/O-Objekt geschlossen, die Hardware für neue Zugriffe frei-gegebenundeineandereApplikationkanneinCreateFile()aufdieHardwarevornehmen.

o BOOL WINAPI SetCommState( )MitHilfedieserMethodekönnendieParametereinesHardwaredevicesgeän-dert werden. In diesem Falle also die Parameter der seriellen Schnittstelle,dassinddieGeschwindigkeit (Baudrate),Polarität sowieAnzahlDaten-undStoppbits.ÜbergebenwerdenbeiAufrufdasHandlevondemI/O-ObjektundeinPointeraufeineStruktur,welchedienötigenParameterangabenbeinhaltet.




GRUNDLAGEN

Esgibtbereits eine fertigeStruktur,die sogenannteDCB-Struktur, hier sindbereitsallenötigenParametervariablenvorhandenundkönnenleichtgeändertwerden.

Die erste Funktion liefert ein Handle auf das angesprochene Objekt. Generellgilt,dassmitdiesenFunktionennichtnurHardwareperipherie(sämtlicheSchnitt-stellen, Festplatten, etc.), sondern auch Dateien, namedpipes (Datenkanal derclient/serverKommunikation),etc.angesprochenwerdenkönnen.DerRückga-bewertisthierentwedereinHandleoderdieFehlermeldungINVALID_HANDLE_VALUE.AllerestlichenFunktionen lieferneinenboolschenWert,entweder0fürFALSEoderungleich0fürTRUE.DergenaueWertimErfolgsfalleistnichtweiterspezifiziert.FüralleFunktionenistdasSchlüsselwort„WINAPI“(Windowsappli-cationprogrammer’sinterfacefunction)vorhanden.EsdeklarierteineFunktion,diedenKonventionenvonWindowsentsprechendübersetztwerdensoll.

DieBibliothekstartetnachErzeugendeserstenI/O-Objektes(hierderComPort)einenThreadmiteinerEndlosschleife.Dieserführt,wennernichtgeradeDatenandieSchnittstelleweiterreicht,fortwährenddieFunktionReadFile()aus.SobaldneueDatenanliegenwerdensiedadurchschnellstmöglicheingelesenundandieHauptapplikation weitergeleitet. DiesesVerfahren wird durch das nachfolgendaufgeführteSequenzdiagrammverdeutlicht.

�0/83GRUNDLAGEN Windows NT



GRUNDLAGEN

C o m A P I T h r e a d W i n d o w s A P I

R e a d F i l e ( )

R e a d F i l e ( )

R e a d F i l e ( )

M a i n T h r e a d

C o m W r i t e ( ) W r i t e F i l e ( )

R e a d F i l e ( )

R e a d F i l e ( )

s e r i a l I n d i c a t i o n P r o c ( )

Abb. 2.17 Sequenzdiagramm ComAPI

LeiderbeinhaltetderComAPIThreadausPerformancegründenkeineKollisions-erkennunginderForm,dasservorderAusführungvonSchreibzugriffenprüft,obdieserielleSchnittstellemitdemVersendenvonDatenbereitsfertig ist ("Pufferleer?"). Ein verfrühter Aufruf überschreibt hierbei einfach alle noch im Sende-puffervorhandenenDaten.

2.5 Die Stoppuhr (timewatch), [WINAPI]

WindowsNT(ebenfallsderRestderaufNTbasierendenWindowsfamilie)besitzteineeinfacheundgleichzeitigpräziseMethodeumZeitenzumessen.DieWin-dowsAPIstelltzweiFunktionenfürdenSystemtimerdesProzessorszurVerfü-gung(ebenfallsenthalteninderwindows.h):

�1/83GRUNDLAGEN Windows NT



GRUNDLAGEN

BOOL QueryPerformanceFrequency(LARGE_INTEGER *lpFrequency);

Diese Funktion ermittelt die Anzahl von Zählschritten (ticks) pro Sekunde. DieCPUzähltproTakteinenCounterhoch,diesstelltdamitdiepräzisesteSystem-zeit dar. Die Anzahl der „ticks“ werden in derVariablen gespeichert, dessenPointerübergebenwurde.DerReturnwertist„0“,wenndieMethodefehlschlug,indiesemFallsteht fürdasSystemkeinpräziserTimerzurVerfügung. Imposi-tivenFallistderReturnwertungleich„0“,dergenaueWertistnichtspezifiziert.

BOOL QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount);

Diese Funktion ermittelt den aktuellen Wert des Counterregisters der CPU.Gespeichert wird dieser wiederum in derVariablen, dessen Pointer übergebenwurde.DerReturnwertfolgtnachdemgleichen,obenbeschriebenenPrinzip.

DieFunktionderStoppuhristvergleichsweisesimpel;dieverstricheneZeitzwi-schen Start und Stopp wird ermittelt, indem zweimal das Counterregister derCPUgelesenundgespeichertwird.DieDifferenzdieserWerte istdieabgelau-fene Zeit in ticks.Teilt man diesenWert nun durch die ticks pro Sekunde, soerhältmandieAnzahlderverstrichenenSekunden.DiesekannmanwiederuminStunden,Minuten,Millisekunden,etc.umrechnen.

�2/83ANALySE Anforderung an das System

Funktionale Anforderung Nichtfunktionale Anforderung

ANALySE

3.1 Anforderungen an das Mess-System

Das fertige Zielsystem hat zur Aufgabe, Latenzzeiten, die in der Funkstreckezwischen zwei Bluetoothmodulen entstehen, zu messen und Beeinflussungendurch das Betriebssystem zu berücksichtigen. Die Einhaltung von bestimmtenZeitenkannfüreinigeAnwendungennichtnursinnvollsondernauchnotwendigsein.AufGrundstärkererVerbreitungundlaufendsinkenderHerstellungskostender Bluetoothtechnologie versucht beispielsweise ein potentieller Kunde eineAnwendung,welchebisherübereinseriellesKabelverlief,nunmitBluetoothzurealisieren.HierhatderKundeeventuellbestimmteÜbertragungszeitenrealisiert,mit denen er für seine Produkte wirbt. Um diesen Standard einzuhalten mussder Kunde zunächst ein Modul finden, welches seine gesetzten Rahmendatenerfüllt. Ein geeignetes Mess-System muss hier die notwendigen Daten liefern,schließlichkannnichtpauschalgesagtwerdenwelcherChipwelcheZeitenein-hält.DieshängtnebenderChiparchitekturauchmitderverwendetenSoftwarezusammen.InsofernkönnendieÜbertragungszeitenzweierbaugleicherModulemitunterschiedlicherSoftwarevoneinanderabweichen,teilweiseauchnursitu-ationsbedingt. Um das spezielle Verhalten eines Bluetoothmoduls herauszu-finden, isteineMessumgebungunverzichtbar.DerAufbaueinesMess-Systemsmitdiversen,präzisenelektronischenMessgerätenistjedochmeistsehrzeitauf-wendig und um eine grobe Einschätzung des IST-Zustandes zu erhalten nichtgeeignet.NichtimmermussderEntwicklerdengenauenMesswertwissen,eineungefähreAngabereichtoftaus.TeilweiseistesauchnichtmöglichdieseWertezuermittelnohnedieentsprechendenGerätezuöffnenumandieSignalleitungenzu gelangen. Das zu erzeugende System soll einem Entwickler mit wenigenHandgriffendieMöglichkeit einerMessungohneMessinstrumente – aufBasisderseriellenSchnittstelle–schaffen.

�3/83ANALySE Anforderung an das System


ANALySE

3.2 Testszenarien und Aufbau

FolgenderAufbauderTestumgebungsollrealisiertwerden:

Sender Empfänger

PC

RS232 RS232

Com1 Com2

Abb. 3.1 Messaufbau

Der PC soll Daten aus dem ASCII-Zeichensatz über eine serielle SchnittstellesendenundaufeinerZweitendieDatenzurückerwarten,wobeidiehierverstri-cheneZeitprotokolliertwird.DerWegverläuftdabeiüberzweiBluetoothmodulewelche mittels Funk verbunden sind. Die maximale Entfernung der Module istdurch die Kabellänge begrenzt. Der Datenaustausch soll in beide Richtungenerfolgenkönnen,wobeidieLängederDatenpakete (1bisnZeichen) frei defi-nierbarsei.Esgilthierbeiauchzutesten,obdieEntfernungzwischendenFunk-moduleneineentscheidendeRollespieltodervernachlässigbarist.

3.3 Funktionale Anforderungen

DasProgrammbautüberdieBluetoothgeräteeinevirtuelle,serielleVerbindungauf.DiesewirdmittelsdesvorhandenenSPP-Protokollsdurchgeführt.DieSoft-ware soll denVerbindungsaufbau komplett selbst bewerkstelligen, die hierfürbenötigtenBluetoothgeräteadressenmüssenvariabeleinstellbarsein.AlsNutz-daten sind hier variable Datenblöcke vorgesehen mit einer frei skalierbarenGröße;derAnwendersollalsojederzeitentscheidenkönnen,wievieleZeichenerversendenwill.DieAuswertungderermitteltenMesswertemussentwedersofortodernachAufforderungausgegebenwerden.DasProgrammbenötigtProzedurenumZeitenzumessenundumaufdieserielleSchnittstellezuzugreifen.AufGrund

��/83ANALySE Anforderung an das System


ANALySE

der durch dasWindowssystem erzeugten Latenzzeiten, die durch das anspre-chenderseriellenSchnittstelleentstehen,musseineEinmessprozedurrealisiertwerden.BedingtdurchdasinKapitel2.1.4beschriebeneVerhaltendesSchedu-lersreichtdieErmittlungeineseinzigenWertesnichtaus.ZwaristesmöglichdieApplikation mit der Priorität „Realtime“ zu starten um Unterbrechungen durchweitereProzessezuunterbindenundstabilereVerzögerungszeitenzuerlangen,spätereTestshaben jedochergeben,dassdieserSachverhaltkeinerleiEinflussaufdiedanachermitteltenVerzögerungszeitenhat.Diesewichen in allenPrio-ritätsstufen voneinander ab. Grund hierfür ist einerseits, dass Windows keinerichtigeEchtzeitbietenkannundandererseits,dassdieProzessorzeitjedesPro-zessesdurchdie„Quantum“ZeitbegrenztistunddamitjederProzessjederzeitin seiner Ausführung unterbrochen werden kann. Die Einmessprozedur mussdaher eine durchschnittlicheVerzögerung ermitteln und in die Auswertung miteinbeziehen.

Auf Grund der bereits in Kapitel 2.3 erwähnten Beschränkung bezüglich derKabellänge inVerbindungmitderBaudratekannfürdenMessaufbauzunächstnur eine Kabellänge von 1,5 Meter für beide Bluetoothmodule berücksichtigtwerdenumdenAbstandzwischendenModulenfüreinelängereFunkstreckezuerweitern.Testshabenzwarergeben,dasseineVerdoppelungderKabellängebeiden hier verwendeten Geräten keine negativen Auswirkungen hatte, jedoch istdiesesVerhaltenwiebereitserwähntnichtgarantiertundnurvonderHardware-qualitätabhängig.EswärezwarmöglichdieBaudratezuverringernumeinegrö-ßereKabellängeunddamiteinengrößerenAbstandzwischendenFunkmodulenzuerreichen,jedochvergrößernsichhierdieLatenzzeitenenorm.

3.4 Nichtfunktionale Anforderungen

Auf Grund der hohen Verbreitung von Windowssystemen, kann man davonausgehen, dass der Arbeitsplatz des Entwicklers in der Regel nicht mit einemEchtzeitsystem oder proprietärem System ausgestattet ist, sondern eher einwindowsbasierendesSystemanzutreffenist.WiebereitsinKapitel2.1erwähnt,hat der Programmierer hier jedoch keinen direkten Zugriff auf die installiertenHardwareperipherien, dieser wird durch den Windowskernel aus Sicherheits-

��/83ANALySE Anforderung an das System


ANALySE

gründenverhindert.EsmusssichalsoeinerfertigenBibliothekbedientwerden,um überhaupt Zugang zur seriellen Com Schnittstelle zu erlangen. Nachteilhierbei ist jedoch,dassderZugriff immerbetriebssystemvermittelt erfolgt.DieZugriffsanforderung wird also zunächst vom user mode an den kernel modeweitergereicht, wo die bereits erwähnte Ablaufprozedur durchlaufen wird, alsoAufruf Local Procedure Call Facility, I/O Manager, Object Manager und Secu-rityReferenceMonitor. LetztendlichentscheidetderScheduler imMikrokernel,wannwelcherProzesszumZugekommt.DurchdieseFaktorenkannvoneinerzeitlich gesicherten Umgebung nicht gesprochen werden. Eigene Messungenhaben jedoch ergeben, dass dieVerzögerung durch dasWindowssystem zwarvariieren,aberimSchnittfürjeweilseinebestimmteAnzahlZeichengleichsind.Die Abweichungen betragen in der Regel zwischen 0 bis 5ms über und unterdemMittelwert.Demnachistessinnlos,dasSystemmiteinerGenauigkeitimµs-Bereichanzulegen,diesesSystemsoll jedochauchnichtdemAnsprucheinesEchtzeitsystems genügen sondern eine schnelle und unkomplizierte Messungermöglichen.TrotzallemsolltedasWindowssystemsowenigparalleleProzessewiemöglichaktivierthaben(z.B.:Mailprogramm,Virenscanner,etc.).DaherwirdauchaufdenEinsatzeinergrafischenWindows-GUIverzichtet.DasProgrammwirddaheralsKonsolenapplikationohneunnötigeProzedurenlaufen.

DerVerbindungsaufbauderGerätesollteeinfachundschnellzubewerkstelligensein, eine lange Einarbeitung soll vermieden werden, um nur eine kurze Mes-sungdurchzuführen.GenerellsolltesichdasSystemnachaußenhinsoeinfachwie möglich darstellen, der Anwender soll sich nicht mit Umgebungsvariablenoder einer langwierigen Installation auseinandersetzen müssen. Die einzigeEinstellung,die füreineMessungnotwendigwird,soll lediglichdasSetzenderBluetoothadressedesSlavessein.

��/83DESIGN Softwarefunktionen

DESIGN

FürdieUmsetzungdesSystemsgibteszweiMöglichkeiten.ZumEinenwäredieRealisierungalsproprietäresSystemdenkbar,wodieBluetoothmoduleaneinedemEntwicklerinhaltlichunbekannteBoxangeschlossenwerden.IndieserBoxkönnteeinkleinerMikroprozessormitkleinemDisplayfürdieMesswertausgabeundBedieninterfacevorhandensein.AlsBetriebssystemkönntehierQNX,MS-DOS, etc. dienen. DerVorteil hierbei wäre zwar für das System vorhersehbareBeeinflussungen der Latenzzeiten, jedoch muss dieses Gerät stets verfügbarsein und extra entwickelt werden. Die Zweite Möglichkeit, welche in dieserArbeit auch verfolgt wird, ist die Realisierung mit einem handelsüblichen PC.DiesewirftzwareinigezulösendeProblemebezüglichschwankenderLatenzenimBetriebssystemauf,jedochisthierbeiderVorteilgegeben,dassdasSystemleichtaufallenPC-kompatiblenGerätenunterWindowsausführbarist.SokannbeispielsweiseeinEntwicklermittelsLaptop jederzeitundräumlichunbegrenzteineschnelleMessungauchbeimKunden,etc.durchführen.DieHardware(PC)sollte in jedem IT-Unternehmen vorhanden sein und müsste somit nicht extraangefertigtwerden.

DieBaudrateaufderseriellenSchnittstellewirdauf115.200bpsfestgesetzt.DiesermöglichteinemöglichstkleineLatenzzeitbeidermaximalenfürdieSchnittstellespezifiziertenGeschwindigkeit,ohnebaulicheVeränderungenvorzunehmen.EineserielleSchnittstellenachRS232kannzwareinemaximaleGeschwindigkeitvon921.600bpsleisten,wasjedochnurunterEinsatzvonUSB-to-RS232Konverternmöglich ist.Konverter vonUSBaufRS232sindzwarweit verbreiteterhältlich,erfahrungsgemäßistdieproblemloseFunktionstüchtigkeitnichtimmergegebenund es ist nicht bekannt ob und inwieweit diese Konverter den Datenverkehrbeeinflussen.DaherwirdderEinsatzselbigerhierzunächstvernachlässigt.

AufeinekompletteTestautomatisierungmussvorerstverzichtetwerden.GrundhierfürsinderstensentstehendeMessfehlersobaldderSendeaufrufwiederholtineinerSchleifeerfolgt.BereitsbeiderRealisierungderEinmessprozedursindhierProblemeaufgetaucht,sodassderwiederholteAufrufineinerSchleifeimmerden gleichen Latenzwert auch bei verschiedenen Systemlasten aufwies, wasnachweislichfalschist.SelbsteinekurzePausemittelsdesAufrufsvon„sleep()“verschafftekeineAbhilfe.Eineleerefor-Schleife,dievon0bis100.000.000zähltschafftezwar fürdieEinmessprozedurAbhilfe, fürdieeigentlichenMessungen


DESIGN

wurde hierauf jedoch nach längerer Überlegung verzichtet. Dies ermöglicht eseinemEntwicklernunjederzeiteinenzeitlichdynamischenAbstandzwischendieMessungenzusetzen,umbeispielweiseaufsichveränderndeUmgebungsvari-ablen(StörungenderFunkstreckedurchHandy,Barriere,etc.)zureagierenoderauchproblemlosdenMessaufbauzwischenzeitlichzuverändern.Zweitenskanneine kompletteTestautomatisierung, also dasTesten aller Senderichtungen mitstetigsteigendenDatenlängen,nichtrealisiertwerden,dadiedurchschnittlicheVerzögerungszeitbereitsunterWindowsnichtkonstantist.Diesesteigtproporti-onalzurDatenlängean,dasgenaueVerhaltenwirdimfolgendenKapitel5(Tests)näherbeschrieben.

DieSoftwarebestehtschließlichausfolgendenwesentlichenTeilen:

1.BibliothekfürdenZugriffaufdenComPort2.DieStoppuhr3.DieEinmessprozedur4.EingabefensterundAuswertungderDaten

DieseTeilewerdenindenspäterfolgendenAbschnittendetailliertbeschrieben.DasUML-DiagrammaufdernachfolgendenSeitezeigtzunächstdieProgrammstrukturdesMess-Systems.

DerAufbauistschlicht,dieDatei„messsystem.cpp“istderzentralePunkt,hierenthaltenistdiemain()undalleweiterenFunktionen.DieHilfsfunktionensindinandereTeileausgelagert,welcheletztendlichaufderWindowsAPIaufbauen.


DESIGN

comapi.h GrundfunktionenderWindowsAPI

+comOpen(pszDeviceName:PCHAR,pszParameter:PCHAR,callBack:PComCallBack, callBackContext:PVOID,*phCom:HCOM):COMENTRY+comClose(hCom:HCOM):COMENTRY

+comWrite(hCom:HCOM,pvBuffer:PBYTE,uBufferLength:UINT):COMENTRY

messsystem.ccp Startmodul

+main(argc:int,argv[]:char*):int+serialIndicationProc(pvContext:PVOID,event:TComEvent,ulStatus:UINT,pvData:PVOID, ulLength:UINT):voidWINAPI+getTime(void):void

-btadress[]:unsignedchar=atd008025085D77\r

timewatch.ccp Stoppuhr

+timeWatchStart(index:int):void+timeWatchCreate(index:int,pszName:PCHAR):BOOL+timeWatchStop(index:int):ULONG+timeWatchReport(mask:int):void

+getAWDT(void):int

timewatch.h GrundfunktionenderWindowsAPI

+reset(void):void+start(void):void+stop(void):void+stopandget(void):ULONG

#startTime:LARGE_INTEGER#endTime:LARGE_INTEGER#delta:LARGE_INTEGER#timeIncrement:LARGE_INTEGER

Abb. 4.1 Einfaches Klassendiagramm mit den nötigsten Methoden


DESIGN

DieWahlderEntwicklungsumgebungfielaufMicrosoftVisualStudio6.0,dasichhierdieEinbindungderbereitsvorhandenenAPIundBibliothekenrechteinfachgestaltete. Die Umsetzung erfolgte in der Programmiersprache C.Vorgestelltwerden alle wesentlichen Funktionen inklusive der Übergabe- und Rückgabe-parameter. Sofern es sinnvoll erschien, wurde ein Beispiel für den jeweiligenMethodenaufruf aufgeführt. Ein Sequenzdiagramm beschreibt eine reguläreStandardsituationschrittweise.

c o m O p e n ( )

C r e a t e F i l e ( )

H A N D L E h C o mH A N D L E h C o m

t i m e W a t c h C r e a t e ( )Q u e r y P e r f o r m a n c e F r e q u e n c y ( & t i m e I n c r e m e n t )

t i m e W a t c h S t a r t ( )Q u e r y P e r f o r m a n c e C o u n t e r ( & s t a r t T i m e )

c o m W r i t e ( )W r i t e F i l e ( )

R e a d F i l e ( )

s e r i a l I n d i c a t i o n P r o c ( )

t i m e W a t c h s t o p () Q u e r y P e r f o r m a n c e C o u n t e r ( & e n d T i m e )

c o m C l o s e ( h C o m ) D e l e t e F i l e ( )

t i m e W a t c h R e p o r t ( )

C o m A P I T h r e a d T i m e w a t c h W i n d o w s A P IMa i n T h r e a d

Abb. 4.2 Sequenzdiagramm, beschreibt den grundsätzlichen Programmablauf

�0/83DESIGN Softwarefunktionen

DESIGN

4.1 Softwarefunktionen

4.1.1 Bibliothek für den Zugriff auf den ComPort

DieBibliothekinihrerGrundfunktionundArbeitsweisewurdebereitsineinemvoran-gegangenenKapitelbeschrieben,hierwerdendienötigenFunktionenaufgezeigt.

Name comOpen()

Übergabeparameter PCHARpszDeviceName,PCHARpszParameter,PComCallBackcallBack,PVOIDcallBackContext,HCOM*phCom

Returnwert HandleaufdasI/O-Objekt

Beschreibung ÖffnetdieserielleSchnittstellefürdieKommunika-tion,übergebenwerdenName,Geschwindigkeit,MethodefüreventsunddenNamenfürdasHandle.

Bsp.:comOpen(„COM1“,“Baudrate=115200“,serialIndicationProc,NULL,&hCom1);

Name comWrite()

Übergabeparameter HCOMhCom,PBYTEpvBuffer,UINTuBufferLength

Returnwert INT

Beschreibung SendeteineZeichenkettevomTypPBYTEmiteinerzudefinierendenLängeandenHandledesI/O-Objekts.DieLängemussnichtmitderLängederZeichenketteübereinstimmen,eswerdennurmaximalAnzahlLängeZeichenausgegeben.(Vor-sichtbeiLänge>pvBuffer.size!!!)

Bsp.:comWrite(hCom1,(PBYTE)„1“,1);


DESIGN

Name comClose()

Übergabeparameter HCOMhCom

Returnwert INT

Beschreibung SchließtdasdemHandlezugehörigeI/O-Objekt.

Bsp.:comClose(hCom1);

Die letzte vorzustellende Methode ist der Eventhandler der seriellen Schnitt-stelle.Dieser istnur indirekteinTeilderBibliothek, lediglichdasVorhandenseinwirdvorausgesetzt.DiefunktionalenInhaltekönnenvomEntwicklerselbstdefi-niert werden. Es werden die von der seriellen Schnittstelle zurückgereichtenEventsausgewertetunddazupassendeAktionenausgeführt(z.B.:stoppenderStoppuhr).DerAufrufselbsterfolgtdurchdenThread,derauchfürdieAufrufederRead-/WriteFile()Funktionenzuständigist.

Name serialIndicationProc()

Übergabeparameter PVOIDpvContext,TComEventevent,UINTulStatus,PVOIDpvData,UINTulLength

Returnwert void

Beschreibung EventhandlerfürdieserielleSchnittstelle,wirdaufgerufen,wenneinEventvomserialControllerObjektausderBibliothekvorliegt.EventssindhiererfolgreichesÖffnen/SchließenderSchnittstelleundeingehendeDaten.


DESIGN

4.1.2 Die Stoppuhr

DieFunktionwurdebereitsinKapitel2.5beschrieben,eswirddieDifferenzzwi-schenzweiZeitpunktenerrechnet.DerStartzeitpunktistdirektvordemSendender Daten, der Stoppzeitpunkt erfolgt direkt im Aufruf der Methode, die dieEvents für den ComPort verarbeitet. Da die Latenzzeiten nie gleich sind, wirdhier fortlaufend der Durchschnitt ermittelt. Der Anwender bestimmt selber, wievieleMessvorgängedurchgeführtwerdendurch jeweilserneutesAusführenderentsprechendenFunktion.

Name TimeWatchCreate()

Übergabeparameter intindexPCHARpszName

Returnwert BOOL

Beschreibung ErzeugteinneuesStoppuhrenobjekt,welchesüberdengewähltenIndexansprechbarist.DerIndexistderPlatzimStoppuhrencontainer,derNameistfreiwählbar.

Bsp.:timeWatchCreate(TW_SLOT_1,„Timer1“);

Name TimeWatchStart()

Übergabeparameter intindex

Returnwert void

Beschreibung SpeichertdieaktuelleProzessorzeit imdurchdenIndexidentifiziertenObjekt(startTime).

Bsp.:timeWatchStart(TW_SLOT_1);


DESIGN

Name TimeWatchStop()

Übergabeparameter intindex

Returnwert void

Beschreibung SpeichertdieaktuelleProzessorzeit imdurchdenIndexidentifiziertenObjekt(endTime).

Bsp.:timeWatchStop(TW_SLOT_1);

Name TimeWatchReport()

Übergabeparameter void

Returnwert void

Beschreibung GibtdenletztenaktuellenVerzögerungswertaufderKonsoleaus.

Bsp.:timeWatchReport();

Name getAWDT()


Returnwert INT

Beschreibung DientzurAbholungdesletztenVerzögerungswerteszurBerechnungdesDurchschnitts.

Bsp.:adt+=getAWDT();


DESIGN

FunktionenderHeaderdatei:

Name reset()


Returnwert void

Beschreibung WirdzuBeginngestartet,ermitteltmit„QueryPerformanceFrequency(&timeIncrement)“dieaktuelleProzessorfrequenz.

Name start()


Returnwert void

Beschreibung Ermitteltmit„QueryPerformanceCounter(&startTime)“denaktuellenWertdesCounterregistersvonderCPU,speichertinderVariablen„startTime“.

Name stop()


Returnwert void

Beschreibung Ermitteltmit„QueryPerformanceCounter(&endTime)“denaktuellenWertdesCounterregistersvonderCPU,speichertinderVariablen„endTime“.


DESIGN

Name get()


Returnwert ULONG

Beschreibung ErmitteltdieDifferenzzwischen„startTime“und„endTime“undrechnetdiesedannvonSekundeninmsum.

4.1.3 Die Einmessprozedur

Direkt nach dem Programmstart wird das System einer Einmessprozedur mitder erforderlichen Mindestdatenlänge von 1 Zeichen unterworfen. Hierbei sollderkleinstedurchschnittlicheVerzögerungswertermitteltwerden,derdurchdasWindowssystem zustande kommt, sobald Daten an die serielle Schnittstellegesendetwerden.DieskannaufzweiWegenerfolgen:

1. Am Ende eines Kabels werden die Leitungen RX undTX mittels geeignetemStecker(sogenannterLoopbackstecker)verbunden.

2.BeideComPortswerdendurchdenZusammenschlussbeiderKabelmiteinemNullmodemadapterverbunden.

BeideWege leistendas selbeErgebnis, eswirddieRound-Trip-Time, alsodieZeit,dieaufdemWegvonderApplikationsebenebiszumKabelendeundzurückabläuft, gemessen. Mehrere Messdurchläufe ergeben dann die Durchschnitts-zeit.DiesewirdspäterbeiderAuswertungvonderGesamtverzögerungszeitdesgesamten Systems abgezogen um die reine Latenzzeit der Bluetoothdevicesinklusive der Funkstrecke zu ermitteln. Die Ermittlung der Durchschnittsverzö-gerungszeit kann jederzeit wiederholt werden, auch mit der jeweils aktuellenDatenlänge (1 bis 200 Zeichen). Auf Grund von Messfehlern musste zwischendeneinzelnenMessungeneineVerzögerung inFormeinerWarteschleifeeinge-setztwerden,ohnediesewürdederMesswertimmer20msbetragen.DerGrundhierfür war bisher nicht ermittelbar, vermutlich spielt hier der Scheduler eineRolle, der die Prioritäten für die laufenden Prozesse dynamisch vergeben undändernkann.


DESIGN

Der Aufruf der Funktion setTime() erfolgt einmalig zum Start, später auch ausdemMenü,danachrekursivdurchdenEventhandler(serialIndicationProc())derseriellenSchnittstelle.DieAnzahlder rekursivenAufrufe istdurcheineVariablebegrenzt(momentan20Wiederholungen).

Name setTime()


Returnwert void

Beschreibung ErmitteltdieVerzögerungszeit,diedurchdasWindowssystemerzeugtwird.

4.1.4 Eingabefenster und Auswertung der Daten

DasHauptprogrammwurde,wiebereitserwähnt,alsKonsolenapplikationrealisiert.DiekleineTextGUIsiehtsoaus:

Bluetoothadressewechseln(0)MessungstartenM->SBlock(1)MessungstartenS->MBlock(2)Systemanlernen(3)MessungstartenM->SByte(4)MessungstartenS->MByte(5)BluetoothSPPaufbauen(6)Reset(7)Blocklaengeaendern(8)Beenden(9)Menue(?)Eingabe:

Die Bezeichner „S“ und „M“ stehen hier für „Slave“ und „Master“. Unter derOption 0 kann die Bluetoothadresse des Slaves neu gesetzt werden. Für dieTestzweckeisthierbereitseineDefaultadresseeingesetzt,daaberdieSoftwareauch füralleDevicesnutzbarseinsollkanndiesewiegesagtneubeschriebenwerden.DieOptionen1und2übertrageneinenZeichenblockdervorherdefi-


DESIGN

niertenLänge(default1),währendbei4und5immergenau1Zeichenübertragenwird.Option3ruftdieFunktionsetTime()aufumdasSystemneuanzulernen,dieaktuellunterderOption8eingestellteLänge isthierbeizubeachten.Dieswarauf Grund steigenderWindowslatenzzeiten inVerbindung mit einer steigendenBlocklängenötig.UnterPunkt6wirdeineneueBluetoothSPPVerbindungaufge-baut,dieserfolgtmittelsdesAT-Befehls„atd{Bluetoothsadresse}“.DieserBefehlsollteauch fürandereGeräte funktionieren,diemittelsAT-Befehlssatzkonfigu-riertwerdenkönnen. ImFallevonOption7wirdeinResetdesSystemsdurch-geführt,dabeiwerdenalleermitteltenWerte,außerderDurchschnittslatenzzeitdes Windowssystems, gelöscht und die Bluetoothverbindung getrennt.Vorherwerden die aktuellen, bis dato ermittelten Durchschnittswerte ausgegeben.Punkt8ändertwieobenangegebendieaktuelleLängedesZeichenblocksauf1bis200Zeichen.WeitereLängenangabensindmomentannichterlaubt,wärenjedochtheoretischohneWeiteresmöglich.Option9schließtdieseriellenPortsundbeendetdasProgramm.DurchEingabedes„?“wirddasMenüausgegeben,dieswarzurbesserenÜbersichtsinnvolleranstattdieAusgabenachjederAktionzuwiederholen.

��/83TESTMessaufbau

Durchführung Messergebnisse

TEST

IndieserSektionwirddieSoftwareeinigenanwendungsbezogenenTestsunter-zogen.DieHardwareistsoweitbekannt,dieverwendetenKomponentenwerdenZwecksderVollständigkeitnochmalsaufgeführt:

oWindowsPCmitWindows2000(NTbasierend)o2Entwicklerboards(BlueEva+C11/G2)mitjeweilseinemmontierten

Bluetoothmodul(Class1)undseriellerRS232-Schnittstelleo2serielleVerbindungskabel,Länge1,5MeteroLoopbacksteckerfürdieEinmessprozeduroKabelverlängerungfürdieseriellenKabelumdieLuftliniezwischen

denModulenzuvergrößern

5.1 Messaufbau

DiezutestendenEntwicklerboardswerdenmitdenKabelndirektandieseriellenSchnittstellen(ComPorts)anCom1undCom2angeschlossen.

Sender Empfänger

PC

RS232 RS232

Com1 Com2

Abb. 5.1 Aufbauplan und Anschluss-Skizzee

5.2 Durchführung

Vor dem Programmstart muss zunächst das Modul am Com1 mit dem Loop-backstecker getauscht werden. Das Programm kann nun aus dem normalenWindowsbetrieb gestartet werden. Nach erfolgreicher Durchführung der Ein-messprozedurerscheintdasMenü,derLoopbacksteckermussnunwiedermitdemvorhergetrenntenModulausgewechseltwerden.FürdieTestoption„Block“

��/83TESTMessaufbau


TEST

mussschließlichnocheinegewünschteBlocklängezwischen1und200Zeicheneingestelltwerden.Zubeachtenistjedoch,dassbeieinerLänge>20ZeichendieErgebnisseverfälschtsind.DasSystemwirdzuBeginnnurmiteinerLängevoneinemZeichenangelernt.Testshabenergeben,dassbeisichändernderBlock-länge die Latenzzeiten innerhalb des Windowssystems steigen (average Win-dowsdelaytimeAWDT,siehenachfolgendeGrafik).FürkorrekteMessergebnisseist ein erneutes Anlernen des Systems nach Änderung der Blocklänge unver-zichtbar.UmdieszuverdeutlichenwurdendieVerzögerungswertedesWindows-systemsjeweilserfasstundgrafischdargestellt:

0

5

10

15

20

25

30

35

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

ms

AWDT AWDT

Abb. 5.2 Average Windows Delay time bezogen auf die Blockgröße

SindsoweitallevorangegangenenEinstellungenkorrekt,kannnundieBluetoothSPPVerbindung zwischen den beiden Modulen aufgebaut werden. Der ErfolgdiesesAufbauswirddurchdieMeldung„CONNECTED!“aufderKonsolequit-tiert,andernfallserfolgtdieMeldung„NOCONNECTION!“.DerAnwenderkannnun über die Menüoptionen die Latenzzeit ausgehend vom Master oder vomSlavemitdenNutzdaten„Byte“ (1Zeichen)oder„Block“ (nZeichen)ermitteln.

�0/83TESTMessaufbau


TEST

Jede Ausführung einer einzelnen Messung ermittelt jeweils einen neuenWert,ausallenwirdfortlaufendderDurchschnittgebildet.

5.3 Messergebnisse

DieersteMessungwurdemiteinerZeichenlängevon1bis200Zeichendurch-geführt,derAbstandzwischendenModulenbetrugca.30cm.Jeweils15Einzel-messungenmitsteigenderBlocklängeinZehnerschrittenwurdenalsGrundlagefürdasfolgendeDiagrammdurchgeführt.DiehierangezeigtenLatenzzeitensindbereits ohne die oben aufgeführtenVerzögerungen desWindowssystems dar-gestellt.DadieBluetoothtechnologienicht festgelegtenLatenzzeitenunterliegtschwankendieVerzögerungszeiten leicht.AnhanddesDiagramms ist trotzdemleichtzuerkennen,dassdieLatenzzeitproportionalzurDatenlängesteigt.

0

5

10

15

20

25

30

35

40

M -> SS -> M

Abstand ~30m

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

ms

Abb. 5.3 Latenzzeit in beiden Richtungen, Abstand ca. 30cm

WeitausgravierenderzeigtsichallerdingsderSachverhalt,dassdieVerbindungzwischendenModulennichtgleichzuseinscheint.DerDatentransfervomSlave



TEST

zumMastererscheinthiergenerelllangsamerzuseinalsumgekehrt.DiesesVer-haltenisthingegennichtaufeinenDefektsondernaufeineplausibleErklärungzurückzuführen.IneinerderunterstenSchichten,demBaseband,isteinesolcheVerzögerungspezifiziert[BT4].Wiebereitsbekannt,kannderMastermitbiszusiebenSlavesineinemPikonetzkommunizieren.UmdieseSlavesgleichermaßenbedienenzukönnenbedarfeshiereinesgeregeltenAlgorithmus.Indiesemfragt(poll)derMasterjedenSlavederReihenachan,obNutzdatenübertragenwerdensollen und übergibt in dem Pollpaket auch den Slot für die Antwort (slave-to-master-slot).DerSlave,welcherimmer–wiealleanderenteilnehmendenSlavesauch–aufdemmaster-to-slave-sloteingehendePaketeannimmt,darfnurindemfürihnbestimmtenslave-to-master-sloteineAntwortgeben.HatderSlavekeineNutzdatenandenMasterzusenden,sowirdzumindesteinNull-Paketgesendetdamit der Master nicht von einem Übertragungsfehler ausgehen muss. SindDaten vorhanden, werden sie in dem für den Slave reservierten Slot gesendet.DerMastergibthierbeiauchdieLängedesPaketesvor(1-,3-oder5-Slotpaket).DiesesPrinzipdientzumEinendergleichmäßigenBehandlungderteilnehmendenSlavesdurchdenMaster,zumAnderenzurVerhinderungvonDatenkollisionen.

Master 1 2 2 1

TX

RX

Slave1

1

RX

TX

Slave2

RX

TX

Abb. 5.4 RX/TX timing in multi-slave Konfiguration



TEST

DerMasterfragtseineSlavesnormalerweise ineinembestimmtenSlotabstandab,dieserwirdinderVariableTPOLLgespeichert.TPOLListeineglobaleInterval-langabe,welchefürverschiedeneAktionengenutztundimLinkManagergesetztwird(u.a.wirdhiermitauchdieZeit(AnzahlSlots)begrenzt,diederMastereinemSlave hintereinander fürTransfers zurVerfügung stellen kann). Jeder Chipher-stellerkanndiesenWertselbstdefinieren,fürdiehierverwendetenModuleliegtdieserbeimaximal25ms(entspricht40Slots) [CSR],dassheißtalso,dassderMasterseinenSlaveca.alle25mserstnachDatenabfragt.[BT4]DiesstelltdenWorstcasedar,derzwarnicht immererreichtwird,diezusätzlicheVerzögerungbeträgtimmerhintrotzdemdurchschnittlichzwischen10msund15ms.Diemaxi-maleGesamtlatenzzeitließesichdamitdurcheineFormeldarstellen:

TMax = TPoll + TWindowslatenz

DenDatenaustauschstelltdasfolgendesSzenariodar:DasMastermodulunter-liegtkeinenBeschränkungenimNetz,esentscheidetselbst,wannessendendarfundwannnicht.EinDatenpaketkannalsoohneRücksichtaufdieanderenTeil-nehmersofortimnächstenSendeslotandenzuadressierendenSlavegesendetwerden. Da dieser immer auf Pakete vom Master horcht nimmt er diese auchsofort entgegen. In der Gegenrichtung sieht dies dann anders aus, der SlavemussaufeineSendeaufforderung (Pollpaket)vomMasterwartenunddarferstdannmitdemSendevorgangbeginnen.EskannalsoderFalleintreten,woderSlaveeinPaketsendenwill,kurznachdemerdemMastersignalisierthateslägenkeineDatenvor.NunmussderSlavedierund25msabwartenumdieDatenlos-zuwerden,dieserhöhtfolglichdieLatenzzeitderÜbertragung.

Die zweite Messung wurde mit den gleichen Parametern wie die vorangegan-gene mit ebenfalls gleichen Umgebungsvoraussetzungen durchgeführt. Ledig-lich die Kabellänge zwischen dem PC und den Geräten wurde vergrößert umdenAbstandzwischendenModulenunddamitdieFunkstreckezuvergrößern.NachdenSpezifikationenfüreineRS232-VerbindungbeträgtdieerlaubteMaxi-mallänge fürserielleVerbindungenbeieinerGeschwindigkeitvon115kbps1,5Meter.EswurdenhierjedochkeinerleiBeeinträchtigungenfestgestellt,Übertra-gungsfehlerdurchdaslangeKabelgabesaugenscheinlichnicht.DieEntfernungzwischendenModulenbetrugsomitca.8MeterbeientsprechenderKabellänge.DieDurchführungentsprachebenfallsderbereitsobengenutztenWeise.



TEST

0

5

10

15

20

25

30

35

40

45

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

mssm

Abstand 8m

ms

Abb. 5.5 Latenzzeit in beiden Richtungen, Abstand ca. 8 Meter

ImVergleich zu der ersten Messung fallen kaum Unterschiede auf, die Kurvenverhaltensichähnlich,dieSteigungistinsgesamtgleich.

��/83VERGLEICH UND EVALUIERUNG Messung mit einem Logikanalysator

Bewertung der Software Nutzbarkeit mit anderen Herstellern

VERGLEICH UND EVALUIERUNG

6.1 Messung mit einem Logikanalysator

IndiesemKapitelwirdeinVergleichzwischendendurchgeführtenTestsausdemvorherigenKapitelmitderSoftwareundTestsmitherkömmlicherMesshardwaredurchgeführt.Mittelsdieser„perHand“durchgeführtenTestssollzudemdieKor-rektheitundFunktionalitätderSoftwarehinsichtlichderAnforderungenausderAnalysegeprüftwerden.

Fürdie „perHandMessung“wirdzusätzlicheHardwarebenötigt.UmmöglichstgenaueDatenzuerhaltenwirdeinkompakterLogikanalysator,derGoLogicvonNCI (www.nci-usa.com),genutzt.Dieserkann theoretischaufbis zu32Kanälenparallelmaximal1MillionPegelwechselaufzeichnenundspeichern.DieTTL-Pegel(Transistor-Transistor-Logik),welcheandenRS232-Treibern(hieristderHardware-bausteingemeint,dieserheißtimAllgemeinenauchTreiber,nichtzuverwechselnmit einem Softwaretreiber) der Entwicklerboards anliegen, sind von den Boardsüberdie I/O-Pinsabgreifbar.DiesstelltdiegenauesteMessmethodedar,dadieKabelstreckevomPCzudenModulenundauchalleVerzögerungendesBetriebs-systemsaußenvorgelassenwerden.FürdieLatenzzeitbestimmungkannaufdergrafischenOberflächederzugehörigenSoftwarederAbstandzwischendenDatenaufderTXLeitungdesSendersundderRXLeitungdesEmpfängersgemessenwerden.DienachfolgendeGrafikveranschaulichtdiesesVorgehen:

Abb. 6.1 Latenzmessung im GoLogic, Genauigkeit: 1/100 ms; braun: TX, rot: RX

Auf Grund der wesentlich höheren Genauigkeit dieser Methode wurde für dieErmittlungderDurchschnittsverzögerungszeitproMessdurchgangnur10anstatt15 Einzelmessungen durchgeführt. Der restliche Ablauf blieb erhalten, ebensodieDatenmengeundArt.DadasGoLogicnichtüberdieMöglichkeitverfügt,dieKabelzuverlängernundsomitdieMessstreckevon8Meternnichtrealisierbarist,wurdelediglichdieTestreihemitkurzemAbstanddurchgeführt.Einstarkver-




ändertesVerhaltenzwischendenMessaufstellungenwirdaufGrunddervoran-gegangenenMessungenbeikurzenDistanzensowiesonichterwartet.

Das Ergebnis für die Master->Slave Richtung zeigt ein besseres Ergebnis wasdieKurvendynamikbetrifft. LegtmannundieermitteltenKurvenbeiderMess-methodenübereinanderzeigtsich,dassdieKurvenunterschiedlichstark„aus-schlagen“,derKurvenverlaufinsgesamtjedochgleichist.

0

5

10

15

20

25

30

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

Master -> SlaveVergleichsmessungSoftwaremessung

ms

Abb. 6.2 Latenzzeiten im Vergleich: Master -> Slave

Die Abweichung der herkömmlichen Methode von der softwaregestütztenMethodeliegenbeimaximal1bis2ms.GrundhierfürwerdenschlichtdiedochteilweiseerheblichenSchwankungenunterworfenenWindowslatenzzeitensein.

DieVergleichsmessunginderSlave->MasterRichtungzeigteinähnlichesBild.




0

5

10

15

20

25

30

35

40

45

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

Slave -> Master VergleichsmessungSoftwaremessung

ms

Abb. 6.3 Latenzzeiten im Vergleich: Slave -> Master

Wesentliches Kennzeichen dieser Messung ist, dass die VergleichsmessungebensoschwanktwiediesoftwaregestützteMethode.Die relativeAbweichungderKurvenuntereinanderistähnlichwieoben,derschwankendeKurvenverlaufbeiderKurvenistaufdenin4.5dargestelltenPollintervalzurückzuführen.

6.2 Bewertung der Software

AnhandderGrafiken lassensichdieMessergebnissebeiderMethodengutverglei-chen.InihrerAussagesinddieKurvenverläufeallerelativgleich,dieabsolutenWerteweichennurgeringfügigvoneinanderab.Diesisttolerierbar,zumalderAufwandunddiedamitverbundeneZeitersparnisbeiderSoftwaremethodegegenüberderHand-arbeitweitausgeringer ist.ZumVergleich:FürdieErmittelungderMessdatenunterZuhilfenahmedererstelltenMess-Softwarewurdenca.30bis40Minutenbenötigt.DieandereMethodeverbrauchtehiereinvielfaches,nämlichca.2,5Stunden,wobeihierdieAnforderungandieKonzentrationsfähigkeitdesAnwenderszudemhöherliegt.




DiegemittelteAbweichungzwischendenKurvenderentsprechendenMethodebeträgt inderRegel1bis2ms, inderSlave-to-MasterRichtungistdiesestel-lenweisehöher.Zurückzuführen istdiesabernichtnuraufdienichtkonstanteVerzögerungszeitdesWindowssystems,sondernauchaufdiestetenSchwan-kungen unterliegende drahtloseVerbindung.Teilweise wird der Effekt dadurchnochverstärkt,inderGrafik5.3istdiesanderPosition(140/29)gutzuerkennen.Speziell in der Slave-to-Master Richtung fallen die Schwankungen in beidenKurven relativ stark aus, hier kommt neben allen vorherigen UngenauigkeitennochderSachverhaltdeszyklischenPollingshinzu(sieheKapitel4.5).

Gutzuerkennenistallerdings,dasseskeineRollespielt,obhierdieMessungenmit einer Genauigkeit im µs-Bereich oder im ms-Bereich liegen. Die SoftwarevermagauchmitgerundetenWertenrespektableErgebnisseimVergleichzurauf-wendigerenMethodezuerzielen.Letztendlichistnochfestzustellen,dassbeideMessmethoden lediglich eine Momentaufnahme liefern können, das genaueLatenzzeitverhaltenkannnichtvorhergesagtwerden.JenachVerbindungsqua-lität, „Luftverschmutzung“ (hoheKonzentrationmehrererGeräte)durchandereDrahtlosfunktechnikenodersonstigenBeeinflussungenkannsichdieLatenzzeitjederzeitverändern.BereitswährendderAufnahmederMessdatenmittelsdesGoLogic kamen teilweise Latenzzeiten von 18 bis 23ms bei einer Blocklängevon150Zeichenvor(Master-to-Slave),wobeiderMittelwertschließlichbeica.21ms lag.EinewirklichstörungsfreieUmgebung istheutzutageabernurnochin einem abgeschirmten Labor darstellbar, dies würde jedoch den Zweck derSoftwareverfehlen.

5.3 Nutzbarkeit mit anderen Herstellern

NebenderFirmaStollmannE+VGmbHgibtesnatürlicheinigeweitereFirmen,dieinderErzeugungvonBluetoothendgerätelösungenaufdemMarktvertretensind.DieMess-SoftwarewurdezwarnurfürdieGerätevonStollmannangefer-tigt,jedochsolltesieprinzipiellauchfüralleweiterenGerätemitseriellerRS232-Schnittstellenutzbarsein.SinndiesesKapitelsisteszuzeigen,dassdieSoftwaredieserAnforderunggerechtwerdenkann.




Als zusätzliche Hardware werden zwei Geräte der Firma Phoenix Contact ver-wendet.PhoenixisteindeutschstämmigerHerstellerfürDatenübertragungster-minalsspeziellfürindustrielleAnlagen,Roboter,etc.DieGeräteverfügenüberjeeineseriellSchnittstellenachRS232/RS485undeinBluetoothmodulderKlasse1 bzw. 2. Ein interner Speicher sichert die Geräteadressen bekannter und alssicher kategorisierter Bluetoothgeräte, die Devices können sich dadurch ohnegesonderte Befehle mit anderen Geräten automatisch verbinden, dies machtdie Option 6 der Software somit für diesen Fall überflüssig.Versetzt man dieModuleindenKonfigurationsmodus,könnendiesejedochauchübereinigeher-kömmliche,sowieproduktspezifischeAT-Befehleangesprochenundkonfiguriertwerden,diesstelltabernichtdenerdachtenRegelbetriebdar.

BILDFEHLTNOCH!

Abb. 6.4 Bluetooth-Konverter, Phoenix Contact

DerrestlicheVerlaufistunverändertzudembereitsbekanntengeblieben,esgibteine,mitderSoftwareerstellteMessreiheundeinedurchdasGoLogicermittelte.DasSystemwirdzunächstwiederangelerntunddannkönnendirektDatenüberdieFunkstreckegesendetwerden.DieModulenutzenhierbeiebenfallsdasregu-läreSPP-Protokoll.

DadieBluetoothgeräte vonPhoenix für einenVerbindungsaufbauauf automa-tischen Aufbau und automatisches Akzeptieren eingestellt werden müssen, istesnichtohneweiteresmöglichherauszufinden,welchesGerätdieMaster-undwelchesdieSlave-Rolleübernimmt.WeiterführendeTestshabenjedochergeben,




dassdieserSachverhaltkeineRollespielt,dieLatenzzeitensind,imGegensatzzudenBlueEva+BoardsvonStollmannE+VGmbH,inbeidenRichtungengleich.Warum das so ist kann nur gemutmaßt werden. Da Phoenix einen anderenBluetoothchip verwendet (NXP, ehemals Philips), kann bereits hier der Unter-schiedkonstruktionsbedingtsein.WeiterhinkanndiesaucheineDesignentschei-dung der Softwareprotokolle seitens von Phoenix sein. Genaueres kann leidernichtermitteltwerden,PhoenixlegtverständlicherweiseseineEnwicklungsdoku-mentationnichtoffendar.AusdiesemGrundwirdhiernureineMessreiheineinerRichtungausgewiesen,fernerhinsolldieseMessreihenurdieKompatibilitätderSoftwaremitGerätenandererHerstellerbelegen.

FürdenMesseinsatzkonntedieSoftwarebereitsihrenerstenVorteilausspielen,die IndustrieproduktevonPhoenixkonntennatürlichkeinegeeignetenKonnek-torenvorweisen,überwelchemanleichtdieSignalefürdieAufzeichnungdurchdasGoLogicabgreifenkönnte.SomitmusstendieGehäusegeöffnet,zerlegtunddieMesspunktedirektandenLötstellenamseriellenSteckerangebrachtwerden.Dies stellte sich Anfangs als sehr fehleranfällig heraus, da die hierfür verwen-detenKlammern leichtabrutschtenundsomitderKontaktverlorenging.DieseFehlerquelle ist bei Einsatz der Softwaremessung nicht vorhanden. Die Gerätewiesen,wieesmeistbeiKomponenten fürdieSteuerung industriellerAnlagenderFallist,bereitsgeeigneteHardwareschnittstellenvor.

�0/83VERGLEICH UND EVALUIERUNG Messung mit einem Logikanalysator



0

5

10

15

20

25

30

35

40

45

Zeichen

1 10 20 30 40 50 60 70 80 90 100

110

120

130

140

150

160

170

180

190

200

Phonix ContactVergleichsmessungSoftwaremessung

ms

Abb. 6.5 Latenzzeiten im Vergleich: Phoenixmodule

DasResultatistdurchauspositiv,dieverschiedenenMessungenzeigeneinsehrähnlichesBildvomKurvenverlauf,wieesbereitsmitdenEntwicklerboardsvonStollmannzusehenwar.ZwarentstehenauchhierAbweichungenzwischendenMessmethodenuntereinander, jedoch sinddiesewiederumbegrenzt.Die soft-waregestützteLösunghatalsonichtnureinweiteresMalihreKorrektheitgegen-überderunterEinsatzdesLogikanalysatorsermitteltenWertebewiesen,sondernauch,dassderEinsatznichtaufeinebestimmte,kleineProduktgruppefestgelegtzuseinscheint.

�1/83FAZIT Zusammenfassung

Fazit Ausblick

FAZIT

7.1 Zusammenfassung

DasGrundthemaderArbeitwardieErstellungeinesMess-SystemsfürBluetoothSPP-Verbindungen.AmAnfangstanddieErläuterungzurMotivationdasSystemzuerstellenunddieDeklarationvonFragestellungen,diedenpositivenAbschlussder Entwicklung verhindern könnten. So war es zu Beginn nicht abzusehen,welcheEinflüssedaszuverwendendeWindowsbetriebssystemaufdasGesamt-verhaltenhabenwürde.

Kapitel 2 führteindiefürdasVerständnisbenötigtenGrundlagenein.HierwurdeeinumfassenderEinblickaufdieinternenAblaufprozedurenundAufbauvoneinemauf Windows NT basierenden Betriebssystem aufgezeigt. Mögliche Problemewurden hier bereits sichtbar, zumal der Hardwarezugriff für jegliche AnwendungeinerbestimmtenAblaufprozedurunterworfenwird,welchezeitlichvomEntwicklernichtvorhersehbarist.WeiterhinwurdeeingroberEinblickindieDrahtlostechno-logieBluetoothgeschaffenundnäheraufdiefürdiezumessendeVerbindungsart,dasSerialPortProfile,eingegangen.DasKapitelschlossmiteinerVorstellungderbenötigtenFunktionenausderWindowsAPIab;diehierdargestelltenHilfsfunkti-onenermöglicheneseinemEntwickleraufzumBeispiel jeglicheComputerhard-wareschnittstellenzuzugreifen,wasihmjasonstvomSystemverwehrtwird.

Kapitel 3definiertezunächstnochmalsdenZweckderzuerzeugendenSoftwareunderläutertedanndiefunktionalen,sowienichtfunktionalenAnforderungenandasSystem.ZudemzeigteesdiedurchdieschwankendenLatenzzeitenentste-hendenGrenzenbezüglichdesSinnvollen.Sowäreesbeispielweisenichtnütz-lichgewesen,dieMessgenauigkeitaufµsaufzulösen.

DasnächsteKapitel (4)befasstesichmitdemDesignderfürdasMess-SystembenötigtenSoftware.DerGesamtaufbausowiedieeinzelnenerzeugtenMethodenwurdendetailliertvorgestellt.AmEndewurdeneinigeTestsinderspätereinzu-setzenden Umgebung durchgeführt. Die Auswertung des erwarteten und desunerwartetenVerhaltens fand hier ebenso statt, sowie auch die Erklärung desPhänomens,dassdieLatenzzeitvomMasterzumSlavekonstantgeringeristalsdieinderGegenrichtung.


Fazit Ausblick

FAZIT

Kapitel 5 befasste sich mit einemVergleich zwischen der erstellten Softwareundeinerweiteren,herkömmlichenMessmethode.DieserVergleichstelltzudemauchdieEvaluierungdar,obdaserzeugteSystemdie inKapitel3gefordertenLösungenumgesetzthatundobdieGrundaufgabe,dieErstellungeinesMess-SystemsfürBluetoothSPP-Verbindungen,erfülltwurde.Ebensowurdegetestet,obdasSystemauchmitanderenGerätenkonkurrierenderHerstellernutzbarist.

7.2 Fazit

Das Ziel, ein System für die Messung von Latenzzeiten in Bluetooth SPP-Ver-bindungenaufeinemWindowssystemkannimHinblickaufdieerzieltenErgeb-nissealserfolgreichgewertetwerden.EntgegendenzuBeginnaufkommendenBefürchtungen,dasBetriebssystemWindowskönntedieErgebnissesoweitver-fälschen,dassdieErgebnisseunbrauchbarwären,bestätigtensichglücklicher-weisenicht.EsexstierenzwarBeeinflussungenderLaufzeitendurchWindows,allerdingswarendiese imDurchschnittstabil,sodassdiesefürdieMessresul-tate herausgerechnet werden konnten. Für die Messgenauigkeit bedeutet diesjedoch,dassdieAuflösungnurimBereichvonMillisekundensinnvollist.

ImBezugaufdieermitteltenMessdatenstelltesichheraus,dassdieerstellteSoft-warenurgeringeUnterschiedezudenmitherkömmlichenMittelngesammeltenDaten aufwiesen. Die Abweichungen der einzelnen Messungen untereinandersindzwarimmervorhanden,jedochzeigtsich,dassdiedurchschnittlichenWertein beiden Methoden zueinander relativ gleich sind. Bereits mit wenigen Mess-werten (hier 15) vermag die Software ähnliche Ergebnisse zu erzielen, wie diepräzisereMessungmittelsLogikanalysator.

7.3 Ausblick

Natürlich kanndieerstellteSoftwarenicht als fertig imSinnedesBedienkom-forts(nichtfunktionaleAnforderungen)angesehenwerden.EsstelltsichnundieFrage, ob nicht doch eineWindows-GUI einsetzbar ist, welche die Bedienungverbessernkönnte.HierkönnteauchdieAuswertungderMessergebnisgrafisch


Fazit Ausblick

FAZIT

erfolgen,denkbarwärehierbereitseineÜbertragung ineineExceltabelleoderproprietäreTabelle/Diagramm.

Weiterhin sinnvoll könnte eineTestautomatisierung sein, wo der gesamte Mess-durchgang einem Algorithmus folgend durchgeführt werden kann. Ein Zusatzan Komfort wäre zudem ein automatisches Auslesen der BluetoothadressendesangeschlossenenSlaves.AlleGeräteverfügeninIhremAT-BefehlssatzübereinKommando,mitwelchemdieeigeneBluetoothadresseundderGerätenamezurückgegebenwerdenkann.MittelsdesBefehls„ATI“gebenalleStollmannpro-dukteihreeigeneGerätebezeichnungwiederalsTextstringzurück.LeideristderAuslesebefehl fürdieBluetoothadressenichtbei allenProduktengleich, somitmüsste erst mittels eines Stringvergleiches das Produkt identifiziert und dannmit dem richtigen AT-Befehl die Bluetoothadresse ausgelesen werden. Für diehier eingesetzten Module wäre dies „AT**BOAD“, die Rückgabe ist wiederumeinTextstring. Andere Hersteller haben sich aber nicht zwangsweise an dieseBefehle gehalten. Obwohl die Anweisung „ATI“ laut AT-Befehlsliste im Anhangeigentlichstandardmäßiggenutztwerdensollte,weichtbeispielsweisePhoenixContact hier vondemSchemaabundnutzt eigenserstellteBefehlsversionen.DieAbfragedesGerätenamensisthiernämlich„AT*AGLN?“.DiesbedeutetalsofürdieImplementierungdiesesFeatures,dassfürdenKomforteineerweiterbareHerstellerdatenbank erzeugt werden müsste, wo der Anwender zunächst denHerstellerdeszutestendenDevicesauswählenmüsste.

EineweiteresinnvolleModifikationwärees,dasSystemaufeinereigenständigenHardwareplattform zu realisieren. Die in dieser Arbeit verwendeten Entwickler-boardswürdensichfüreinePortierungaufdendortplatziertenAtmelprozessoreignen.DieserverfügtbereitsübergenügendLeistungsreservenumzweiHard-waretimer und zwei USARTs, welche direkt an die Schnittstellentreiber ange-schlossensind,zubedienen.SomitkönntedasDevicealsErsatz füreinenPCgenutztwerden.DahierauchderZugriffaufdieHardwaredirekterfolgtunddieAbfolgeauchnichtdurcheinenvorgefertigtenSchedulerreglementiertwird,kanndie verfälschende Latenzzeit im System selbst sehr weit vermindert werden.Selbst wenn weiterhin noch eine solche Latenzzeit auftaucht, so wird dieseimmergleichsein,wasdannauchMessgenauigkeitenindenMikrosekundenbe-reichermöglichenkönnte–obdieseGenauigkeitsinnvollwärelässtsichjedoch

��/83FAZIT Zusammenfassung

Fazit Ausblick

FAZIT

anhandderbereitserfahrenenErgebnissebezüglichderSchwankungen inderBluetoothfunkstreckebezweifeln.AllerdingswäredannderAnsatz, einSystemzuerzeugen,welchesaufeinemLaptopeinsetzbarist,nichtmehrgegeben.

DieletztezuerörterndeErweiterungistsicherlichdieMöglichkeit,dieDistanzzwi-schendenGerätenzuvergrößernumlängereFunkstreckenerzeugenzukönnen.WiebereitserwähntistdieRS232-SchnittstellebezüglichderKabellängebei115kbpsauflediglich1,5Meterfestgelegt.DieskanndurcheineWeiterentwicklungderhiergenutztenSchnittstelleumgangenwerden.InderIndustriehatsichdersogenannte „Profibus“ nach RS485 in der Maschinensteuerung durchgesetzt.ÜberdieseSchnittstellekanneinemaximaleEntfernungvon1200Meternüber-brücktwerden,wobeidieÜbertragungsgeschwindigkeitmaximal10Mbitbetragenkann.DieGeschwindigkeitnimmtjedochbereitsnach15Meternproportionalab,sodass sich folgendes Szenario darstellt:Wenn man davon ausgeht, dass derPCgemäßdemobenbeschriebenenMessaufbaumittigzwischendenModulen(Class 1) platziert ist, ergibt dies bei maximaler Funkdistanz von 100 MeterneineKabellängevon jeweils50Meter.Folglich isteinemaximaleGeschwindig-keitvonca.2,5Mbitmöglich[RS485].ZumVergleich:RS232würdebeigleicherLänge lediglicheineBaudrate von9.600bpsbieten.Allerdings istdieRS485-SchnittstellenichtimgleichenMaßeverbreitetbeziehungsweisevorhandenwieRS232,esistjedochmöglichmitHardwarekonverternvonRS232aufRS485zuarbeiten.Hierbei istallerdingsmithoherWahrscheinlichkeitdavonauszugehen,dassdavondieLatenzzeitenbeeinflusstwerdenundsomitdieseAlternativenurbedingtrealisierbarist.

��/83FAZIT Zusammenfassung

Fazit Ausblick

FAZITC

able

Len

ght

(Met

ers)

10.000

1.000

100

10

10K 100K 1M 10M

BitRate(Bits/Second)

Abb. 7.1 Geschwindigkeit von RS485 bezüglich Kabellänge

��/83GLOSSAR

GLOSSAR

Layer = Schicht

Deadlocks = StillstanddesSystemsdurchz.B.eineEndlosschleife.

EIA/TIA-232-E = NormderElectronicIndustryAssociation/TelecommunicationsIndustry Association zur Nutzung des seriellen Datenports, ehemals RS-232(RS=recommendedstandard).

ETSI Standard TS 07.10= Besser bekannt alsTS 101 369 v6.3.0(GSM 07.10v6.3.01997),hierwurdenStandardsfürdasGSMNetzfestgelegt;daBluetoothbesondersimdrahtlosenTelefoniebereichüberzeugensollte,wolltemanschlichtProblemenausdemWeggehenunddievorhandenenStandardsimgleichenZugumsetzen,obwohldieTechnikenweniggemeinhaben.

UUID = UniversallyUnique Identifier–eindeutiger Identifizierer,bestehendauseiner16ByteZahl,unterteiltinfünfGruppen.

OBEX =(OBjectEXchange);KommunikationsprotokollunddientderDatenübertra-gungzwischenzweiGeräten.OBEXarbeitetimklassischenClient-Server-Modell.EswirdheuteüberwiegendbeiseriellerKommunikation (Bluetooth, Infrarot)zumobilenEndgeräten(PDA,Smartphone)eingesetzt.NachOSI-Modellgehörteszur Sitzungsschicht (Schicht 5) und ist somit transparent zu der tatsächlichenKommunikationsmethode.

UNICODE 8 = FestgelegterZeichensatz,ähnlichwieASCII.

Bluetoothstack =DasgrundlegendeBetriebssystemfüreinBluetoothmodul.

Handle = (engl.)„Henkel“,„Griff“,einnumerischerIdentifikationswertvomTyplong.

LSB = LeastSignificantBit

MSB = MostSignificantBit.

NT (Windows) = NT wurde nach Veröffentlichung auf “New Technology”umgetauft, dies hat aber nur Marketinggründe. Verbreitet ist auch „NetworkTechnology“.DiewahreBedeutungistaber„N-Ten“,hierbeihandeltessichumeinenEmulatorfürWindows.SeinerzeitwurdevonIntelderi860(RISC)Prozessor

��/83GLOSSAR

GLOSSAR

entwickelt (Codename N10), da dieser aber noch nicht verfügbar war mussteman sich eines Emulators bedienen.Windows NT ist also ein Betriebssystem,welchesursprünglich füreineganzanderePlattformentwickeltwurdeundnuneinenEmulatorbeinhaltete[N10].

USART= UniversalSynchronousAsynchronousReceiverTransmitter,erzeugtdenfürdieRS232-SchnittstellebenötigtenDatenrahmen.

��/83QUELLENVERZEICHNIS Quellenverzeichnis

Bilderquellenverzeichnis AT-Befehlssatz

QUELLENVERZEICHNIS

9.1 Quellenverzeichnis

[ABB] ABBStotzKompakt,http://www.industrialnetworks.ch/dateien/ aussteller/abb-ch/2CDC142001B0102.pdf,LetzterZugriff:26.6.

[AGV] http://www.megatech.at/ireds-27445.html,LetzterZugriff:25.6.

[AT] http://www.itwissen.info/definition/lexikon/Hayes-Befehlssatz-Hayes- command-set.html,LetzterZugriff:16.6.

[AW] http://www.informationsarchiv.net/statisch/wlan/geschichte.html, LetzterZugriff:17.6.

[BT1] DasBluetoothhandbuch,JörgF.Wollert,2002,Franzis’

[BT2] Bluetooth1.1–ConnectwithoutcablesSE,JenniferBray&CharlessF Sturman,2002,PrenticeHallPTR

[BT3] http://german.bluetooth.com/Bluetooth/Technology/,LetzterZugriff:28.6.

[BT4] SpecificationoftheBluetoothsystemVersion2.0+EDR

[BT5] Bluetoothaktuell–TechnikundAnwendungen,Prof.Dr.JörgWollert, Elektronik23/2001

[CSR] CSR’sImplementationofHCIonBlueCore,CSR2001

[GOLEM]http://www.golem.de/0505/38239.html,LetzterZugriff:09.06.

[N10] http://wapedia.mobi/de/Windows_NT,LetzterZugriff:9.7.

[ROCLA] http://www.rocla.com,LetzterZugriff:10.6.

[RS232] SerialPortComplete,JanAxelson,2007,LakeviewResearchLLC

[RS485] SerialPortComplete,JanAxelson,2007,LakeviewResearchLLC,S. 88,Abb.6-4

[SENA] http://www.wirelessdevicesolutions.com/solutions/industrialautomation/ case_studies/#wireless_cnc_dnc_network,LetzterZugriff:25.6.

��/83QUELLENVERZEICHNIS Quellenverzeichnis


QUELLENVERZEICHNIS

[SCHED] http://book.itzero.com/read/microsoft/0507/microsoft.press. microsoft.windows.internals.fourth.edition.dec.2004.internal.fixed. ebook-ddu_html/0735619174/ch06lev1sec5.html,LetzterZugriff:21.7.

[WIKI] http://de.wikipedia.org/,LetzterZugriff:20.7.

[WINAPI]http://msdn.microsoft.com/en-us/library/aa363201(VS.85).aspx, LetzterZugriff:18.6.

[WNT] InsideWindowsNT,HelenCuster,1993,MicrosoftPress

9.2 Bilderquellenverzeichnis

Kapitel 2(2.1) [WNT],S.17(2.2) [WNT],S.18(2.3) [WNT],S.19(2.4) [SCHED](2.5) [WNT],S.26(2.6) [BT2]S.9(2.7) [BT2]S.35,[WIKI](2.8) http://nedt.at/docs/bluetooth/fdd.jpg,LetzterZugriff:25.6.(2.9) http://www.rooijen.de/studium/praxis/eins/image002.jpg,LetzterZugriff:13.6.(2.11)http://www.hochschule-bochum.de/fileadmin/media/fb_e/labore/srlab/ uploads/Artikel/200123s050.pdf,LetzterZugriff:13.6.(2.12)http://german.bluetooth.com/NR/rdonlyres/21815114-AFD1-4BB3-81F6- FFD3F4AF8490/986/SPP_SPEC_V12.pdf,LetzterZugriff:13.6.(2.13) [BT1]S.240Tab.56(2.14)EvaluationboardBlueEva+C11/G2,StollmannE+VGmbH,2008(2.16)http://de.wikipedia.org/wiki/EIA-232,LetzterZugriff:11.6.

Kapitel 5(5.4) SpecificationoftheBluetoothsystemVersion2.0+EDR,S.335,Abb.8.6

�0/83QUELLENVERZEICHNIS Quellenverzeichnis


QUELLENVERZEICHNIS

Kapitel 6(6.1) ScreenshotausderGoLogicSoftware(6.4) AbbildPSI-Bluetooth-Konverter,PSI-WL-RS232-RS485/BT,PhoenixContact



QUELLENVERZEICHNIS

9.3 AT-Befehlssatz

AT Attention Achtung

A AnswerImmeditate Sofortantwort

A/ RepeatLastCommand LetztesKommandowiederholen

A: Redial Wahlwiederholung

B Bell/CCITT-Compatibility Bell/CCITT-Kompatibilität

D DialNumber Rufnummerwählen

E EchoCharacters Kommando-Echo

F CommunicationsFormat Übertragungsformat

G Talk Gespräch

H HookSwitchControl Verbindungauflösen

I Inquiry Identifizierung

J Reserved Reservieren

K CallTimer Verbindungszeit

L Loudness Lautstärke

M SpeakerControl Lautsprecherkontrolle

N DialStoredNumber Registerwahl

O Online Online

Q QuitMode Ruhe

S SetRegister Registereinstellen

V ResultCodes Rückmeldungen

X ExtendedResultCodes ErweiterteRückmeldung

Y LongSpaceDisconnect AuslösenmitBreak

Z RecallUserConfiguration Konfigurationsprofilladen

&A AutomaticRateDetection AutomatischeGeschwindigkeits-anpassung

&B DelayedMakeBusy Verzögertes„Busy-Signal“



QUELLENVERZEICHNIS

&C CarrierDetectControl DCD-Optionen

&D DTR-Options DTR-Optionen

&E ErrorCorrection Fehlerkorrektur

&F FactoryConfigurationLoad Werksgrundeinstellung

&G GuardToneSelection Guard-Ton-Wahl

&H HelpCommand Hilfeanfordern

&I ConstantSpeedInterface KonstanteGeschwindigkeit

&J TelephoneJack Anschlussbelegung

&K ModemFlowControl Steuerungsverfahren

&L LeasedLineConnection AnschlussanStromwege

&M Asynchronous/Synchronous Asynchron/Synchron-ModeSelect

&P Make/BreakDialPulseRatio Pulse/CTS-Optionen

&R RTS/CTS-Options RTS/CTS-Optionen

&S DSR-Options DSR-Optionen

&T TestCommands Test-Kommandos

&W WriteConfigurationto KonfigurationspeichernMemory

&X SynchronousTransmitClock Synchron-TaktquelleSource

&Z StoreTelephoneNumber Telefonnummerspeichern

Abb A.1 AT-Befehlssatz: http://www.itwissen.info/definition/lexikon/Hayes-Befehlssatz-Hayes-command-set.html

�3/83VERSICHERUNG DER SELBSTÄNDIGKEIT

VERSICHERUNG DER SELBSTÄNDIGKEIT

Hiermit versichere ich,dass ichdie vorliegendeArbeit imSinnederPrüfungs-ordnungnach§22(4)bzw.§24(4)ohnefremdeHilfeselbständigverfasstundnurdieangegebenenHilfsmittelbenutzthabe.

Hamburg, 05. August 2008

Bent Mucha

Documents

Bachelorarbeit - HAW Hamburg