TEMP LSVA Entwicklungskit DE€¦ · FTP-Servers legt diesen Ort fest, per Default ist dies...

$: TEMP LSVA Entwicklungskit DE€¦ · FTP-Servers legt diesen Ort fest, per Default ist dies C:\copssh\home\\WebService.) Die technische Beschreibung dieses$
BT-Services

Anwendung

Services

Anwendung- und Schnittstellenbeschreibung

und Schnittstellenbeschreibung

1 Vorwort

Seite 2

Copyright © 2009 Eidgenössische Zollverwaltung (EZV) – Alle Rechte vorbehalten.

Weitergabe, sowie Vervielfältigung dieser Unterlage, Verwertung und Mitteilung ihres Inhaltes sind nicht gestattet, soweit

nicht ausdrücklich zugestanden. Zuwiderhandlungen verpflichten zu Schadenersatz. Alle Rechte vorbehalten,

insbesondere für den Fall der Patenterteilung oder Gewährung von Muster- und Modellschutz.

Eidgenössische Zollverwaltung (EZV)

Oberzolldirektion

Abteilung LSVA

Monbijoustrasse 91

3003 Bern

Marken

«emotach» ist eine registrierte Marke der Eidgenössischen Zollverwaltung (EZV). Die übrigen Bezeichnungen in dieser

Schrift können Marken sein, deren Benutzung durch Dritte für deren Zwecke die Rechte der Inhaber verletzen können.

Hersteller

Hersteller der in dieser Dokumentation behandelten Software ist

Siemens Schweiz AG

Freilagerstrasse 40

8047 Zürich

Projekt: emotach CH-OBU-2

Dokument: Anwendung- und Schnittstellenbeschreibung BT-Services emotach

Ausgabedatum: Juli 2012

Ident-Nummer: N/A

2.1 Übersicht emotach BT-Services

Seite 3

Inhaltsverzeichnis

1 Vorwort ............................................................................................................................. 5

2 Systembeschreibung ........................................................................................................ 6

2.1 Übersicht emotach BT-Services ............................................................................ 6

3 Service-Beschreibungen................................................................................................... 8

3.1 Deklaration über Mobiltelefon ................................................................................ 8 3.1.1 Ablauf ........................................................................................................ 8

3.2 Image-Übertragung ............................................................................................... 9 3.2.1 Übersicht ................................................................................................... 9 3.2.2 Ablauf Kommunikation emotach - emotachDirect Image-Server ............. 10 3.2.3 Elektronische Deklaration mit dem OZD-Server ..................................... 11

3.3 NMEA-Streaming ................................................................................................ 12

3.4 LSVA-Zusatznutzenprotokoll ............................................................................... 12

4 Entwicklungsdokumente ................................................................................................. 14

4.1 emotach Bluetooth-Services................................................................................ 14 4.1.1 Anwendungsfälle ..................................................................................... 14 4.1.2 Bluetooth Profile und Einstellungen ........................................................ 44 4.1.3 Statusmeldung LSVA Datenimages ........................................................ 52

4.2 Technische Beschreibung Webservice emotachDirect ....................................... 55 4.2.1 GetEmptyImage ...................................................................................... 55 4.2.2 PutDeklImage ......................................................................................... 56 4.2.3 WSDL-Spezifikation ................................................................................ 57

4.3 Verwendung von LSVA-Chipkarten ..................................................................... 59 4.3.1 Funktionale Beschreibung der LSVA-Chipkarte ...................................... 59 4.3.2 Technische Beschreibung ....................................................................... 59 4.3.3 Eingesetzte Chipkarten ........................................................................... 62 4.3.4 Vorschriften ............................................................................................. 62

5 Entwicklungskit ............................................................................................................... 63

5.1 Auflistung und Beschreibung des Lieferumfangs ................................................ 63

5.2 emotach Montage ................................................................................................ 63 5.2.1 Abdeckung Anschlussfeld demontieren .................................................. 63 5.2.2 Anschlusskabel anschliessen ................................................................. 64

5.3 Strom- und Signalanschluss ................................................................................ 64 5.3.1 emotach Tachosimulation (V-Signal) ...................................................... 65

5.4 Erzeugungen von Testdaten ............................................................................... 66

5.5 emotach Bedienung ............................................................................................ 66

5.6 Emotach Gerätezustand ...................................................................................... 68

5.7 Beschreibung der Testdaten ............................................................................... 69 5.7.1 Backup-Datenbank ................................................................................. 69 5.7.2 Logeinträge des mitgelieferten emotachs ............................................... 69

5.8 Demoprogramm für Imageaustausch über Bluetooth .......................................... 71 5.8.1 Systemanforderungen ............................................................................. 71 5.8.2 Funktionierende BT-Adapter ................................................................... 71 5.8.3 Anschluss BT-Adapter ............................................................................ 71 5.8.4 Bedienung BT-Demoprogramm .............................................................. 72 5.8.5 Aufbau Entwicklungsumgebung .............................................................. 72 5.8.6 Source-Code BT-Demoprogramm .......................................................... 77

1 Vorwort

Seite 4

5.9 Vorbereitungen emotach und emotachDirect für die Deklaration über den Image-Service 78

5.10 Funktionstest ........................................................................................... 79

6 Ansprechstellen .............................................................................................................. 81

7 Anhang ........................................................................................................................... 82

7.1 Begriffe und Abkürzungen ................................................................................... 82

7.2 Referenzen .......................................................................................................... 83

7.3 History 84


Seite 5

1 Vorwort

Dieses Dokument soll dem Leser eine Übersicht über die verschiedenen BT-Services

geben und ihm ermöglichen BT-Services des emotach zu nutzen.

Lieferanten von Zusatzgeräten und Anwendungsentwickler sollen anhand der

Schnittstellenbeschreibungen in die Lage versetzt werden, eigenen Applikationen zur

Nutzung der BT-Services zu entwickeln. Zur Unterstützung der Entwicklung kann zusätzlich

ein sogenanntes Entwicklungskit bei der OZD beantragt werden.

Aufbau des Dokuments:

Kapitel 2 gibt einen kurzen Überblick über die verschiedenen Services, Schnittstellen und

deren Einsatz.

In Kapitel 3 und 4 werden die Schnittstellen detailliert beschrieben.

Kapitel 5 beschreibt das Entwicklungskit.

Die Referenzen sowie ein Abkürzungsverzeichnis ist im Kapitel 7 zu finden.

Bitte beachten Sie, dass jederzeit technische Änderungen im System eingefügt werden

können, welche in diesem Entwicklungskit evtl. noch nicht abgebildet sind. Alle Angaben

sind daher ohne Gewähr.

2 Systembeschreibung

Seite 6

2 Systembeschreibung


Das Diagramm gibt einen Überblick über die Schnittstellen und Kommunikationsprotokolle

vom emotach bzw. emotachDirect, welche benötigt werden um die BT-Services des

emotach zu nutzen.

Abbildung 1 – Übersicht emotach Bluetooth-Dienste

Die folgenden Dienste werden angeboten:

Deklaration über Mobiltelefon: Austausch von Deklarationsdaten über ein

Mobiltelefon

Dieser Service erlaubt die synchrone Übertragung von Deklarationsdaten zwischen

dem emotach und dem emotachDirect mit Hilfe eines Mobiltelefons. Dabei dient ein

handelsübliches Standard Mobiltelefon als Bluetooth-Modem, über welches das

emotach eine direkte FTP-Verbindung zum emotachDirect aufbauen kann

(Schnittstelle 3).

Dieser Service eignet sich typischerweise für Fahrzeuge mit wechselndem Standort

oder für Fahrzeuge welche sich im Ausland befinden, weil mit diesem Service das

Nachsenden von Chipkarten für die Deklaration entfallen kann.

Die Anforderungen an das Mobiltelefon sind in 3.1 beschrieben. Eine Liste von

kompatiblen Mobiltelefonen ist auf der Homepage www.emotach.ch/bt-services

verfügbar.

Zur Nutzung diese Services muss keine Entwicklungsarbeit geleistet werden.

Flotten-management-

system

Mobil-

telefon

SFTP-Client OBEX FTP-Server

OBEX FTP-Client Kundenapplikation SOAP-Client

emotachDirect

Internet

Bluetooth Bluetooth

LSVA Internet

emotach

Cli

en

t/S

erv

er

Arc

hit

ektu

r fü

r d

en

kart

en

losen

Im

ag

eau

sta

usch

Bluetooth

23

1

Board- computer

Bluetooth 5

4

SFTP-Server Web-Server


Seite 7

Image-Übertragung: Austausch von Dekarationsdaten über eine indirekte Verbindung.

Dieser Service erlaubt die asynchrone Übertragung von Daten zwischen dem emotach

und dem emotachDirect.

Um diesen Service zu nutzen muss eine Applikation entwickelt werden, welche als

Gateway zwischen dem emotach und dem emotachDirect dient, wobei der Gateway

auf einem Rechner innerhalb (oder in unmittelbarer Nähe) des Fahrzeuges installiert

wird.

Dieser Service eignet sich typischerweise zur Integration in ein

Flottenmanagementsystem. Die Kommunikation zwischen Gateway und emotach

erfolgt bei diesem Service über Bluetooth mit dem OBEX-FTP Protokoll (Schnittstelle

2). Für die Kommunikation mit emotachDirect benutzt der Gateway den Web-Service

auf dem Imageserver von emotachDirect (Schnittstelle 1). Die zur Nutzung dieses

Dienstes benötigten Schnittstellen sind in 4.1.1.1 und 4.2 beschrieben.

Dieser Service wird im Kapitel 3.2 genauer beschrieben.

Alternativ kann die Schnittstelle 2 auch über Chipkarten gelöst werden. Informationen

zum Lesen und Schreiben von LSVA-Chipkarten sind im Kapitel 4.3 beschrieben.

NMEA-Datenstreaming: Periodische Ausgabe von GPS-Daten.

Das NMEA-Datenstreaming ermöglicht dem Fahrzeughalter GPS-Daten vom emotach

für sein Flottenmanagementsystem im Fahrzeug zu nutzen.

Bei aktiviertem NMEA-Datenstreaming werden periodisch Meldungen über die

Bluetooth-Schnittstelle (5) vom emotach ausgegeben.

Die zur Nutzung dieses Services benötigte Schnittstelle ist in 4.1.1.2 beschrieben. Im

Wesentlichen stehen die folgenden Informationen zur Verfügung:

GPS Positionsdaten mit Zeit, Datum, Geschwindigkeit, Genauigkeit

Dieser Service und die verwendeten Protokolle sind standardisiert und können mit

handelsüblichen Standartgeräten (z.B. Navigationssystem, Notebook etc) und

Standerdsoftwaretools (z.B. Kartenmaterial) verwendet werden. Zur Nutzung diese

Services muss keine Entwicklungsarbeit geleistet werden.

LSVA-Zusatznutzenprotokoll: Periodische Ausgabe von LSVA-Daten.

Das Zusatznutzenprotokoll ermöglicht einem Fahrzeughalter Daten vom emotach für

sein Flottenmanagementsystem im Fahrzeug zu nutzen. Das LSVA-

Zusatznutzenprotokoll enthält nebst GPS Positionsdaten weitere LSVA-spezifischen

Daten.

Bei aktiviertem Zusatznutzenprotokoll werden periodisch Meldungen über die

Bluetooth-Schnittstelle (4) vom emotach ausgegeben. Die zur Nutzung dieses

Dienstes benötigte Schnittstelle ist in 4.1.1.3 beschrieben.

Im Wesentlichen stehen die folgenden Informationen zur Verfügung:

Erfassungszustand und Zusammenzüge

Daten eines allfällig deklarierten Anhängers

GPS Positionsdaten mit Zeit, Datum, Geschwindigkeit

emotach Gerätezustand

Für die Nutzung dieses Dienstes muss der Fahrzeughalter eine zusätzliche

Entwicklungsarbeit leisten.

3 Service-Beschreibungen

Seite 8


3.1 Deklaration über Mobiltelefon

Bluetooth und GPRS/UMTS dienen als Übertragungsmedium für die FTP-Kommunikation.

Durch diese Kommunikationsarchitektur wird das emotachDirect-Kommunikationsnetzwerk

bis auf das emotach erweitert.

Die Verbindung zur emotachDirect-Software wird über einen GPRS/UMTS-Serviceprovider

über das Internet aufgebaut.

3.1.1 Ablauf

Der Ablauf der Kommunikation ist den folgenden drei Punkten beschrieben. Den Ablauf der

Kommunikation auf den verschiedenen Protokollschichten sehen Sie über die folgende

Grafik.

1. Bluetoothverbindung zwischen emotach und Mobiltelefon.

2. GPRS Verbindung über das Bluetooth DUN Profil (Dial-Up Networking Profile) zu

einem Internet Service Provider. Die für die GPRS Verbindung benötigten

Verbindungsparameter (APN, username, password) werden mit Hilfe von AT Befehlen

zum Mobiltelefon übertragen.

3. FTP Verbindung über TCP/IP zwischen emotach und Image-Server

Abbildung 2 – Netzwerktopologie und Verbindungsebenen

3.2 Image-Übertragung

Seite 9


Die Kommunikation zwischen dem emotach und einem Kommunikationspartner geschieht

über Auftragsimages (allgemein Datenimage), woraufhin das emotach je nach Auftrag eine

Antwortmeldung (Meldungsimage) erzeugt. Diese Images sind in einem speziellen LSVA-

Datenformat. Rund um diesen Service werden die folgenden Aufträge benötigt:

Deklaration:

Zum Auslesen der Deklarations- und Zustandsdaten des emotach. Das emotach

erzeugt im Gutfall eine Deklarationsmeldung mit Logeinträgen und eine emotach-

Zustandsmeldung.

BT-Konfiguration temporär setzen:

Setzt die BT-Konfiguration temporär für die Dauer während dem die Karte im emotach

gesteckt ist und startet einen BT-Service.

BT-Konfiguration setzen:

Setzt die BT-Konfiguration für einen Service dauerhaft bis sie wieder geändert wird.

Dadurch kann der Service auch manuell gestartet werden.

3.2.1 Übersicht

Abbildung 3 – Gesamtübersicht

Der Fahrzeughalter hat die Möglichkeit, eine Applikation zu entwickeln, um

Deklarationsaufträge und -meldungen zwischen dem emotach und dem emotachDirect

Datenbank zu übertragen.

Der Datentransfer mit dem emotach erfolgt über Bluetooth. Die Bluetooth-Schnittstelle ist im

Kapitel 4.1.1.1 beschrieben.

Der Datentransfer in Richtung emotachDirect erfolgt über eine Web-Service Schnittstelle

(SOAP / https). Diese Schnittstelle erlaubt den Bezug von Deklarationsauftragsimages

sowie das Ablegen von Deklarationsmeldungsimages in die emotachDirect Datenbank.

Der emotachDirect Web-Service ist als „ISAPI Extension“ in IIS integriert und läuft auf dem

emotachDirect Image-Server.

Die Daten (Images), die zwischen der Kundenapplikation und dem Web-Service

ausgetauscht werden, sind temporär in der Datenablage auf dem Image-Server abgelegt.

Diese Daten werden regelmässig durch den Deklarationsservice (Bestandteil der

emotachDirect Software) mit der emotachDirect Datenbank synchronisiert.


Seite 10

Die Kommunikation auf Protokollebene sehen Sie in der folgenden Abbildung. Dabei sieht

man, dass die zu entwickelnde Software gegenüber beiden Kommunikationspartnern als

Client auftritt.

Abbildung 4 – Protokollstack Image-Übertragung

3.2.2 Ablauf Kommunikation emotach - emotachDirect Image-Server

Bei der elektronischen Kommunikation zwischen dem Image-Server und dem emotach

verhalten sich beide als Server, das heisst, diese werden nie die Kommunikation selber

initiieren. Die Kommunikation wird über die Kundenapplikation gemacht, welche die Rolle

des Clients für beide Seiten übernimmt.

Die Applikation muss sicherstellen, dass sie jeweils den Deklarationsauftrag vom Image-

Server neu bezieht, damit die Datenübertragung vom OZD-Server zum emotach nicht

unterbrochen wird.

Der Ablauf sieht wie folgt aus:

• Die Kundenapplikation holt sich mittels Aufruf des Webservice GetEmptyImage

vom Image-Server den Deklarationsauftrag als Image für das gewünschte

Fahrzeug.

Die technische Beschreibung dieses Service befindet sich unter 4.2.

• Die Kundenapplikation schickt nun über Bluetooth das erhaltene Image an das

emotach.

Die technische Beschreibung dieser Schnittstelle befindet sich unter.4.1.

• Das emotach verarbeitet den Deklarationsauftrag.

• Die Kundenapplikation holt über Bluetooth die Deklarationsmeldung als Image

vom emotach.

Die technische Beschreibung dieser Schnittstelle befindet sich unter 4.1.

• Die Kundenapplikation schickt mittels Aufruf des Webservice PutDeklImage die

Deklarationsmeldung als Image an den Image-Server. Die Deklarationsmeldung

wird durch den Webservice auf dem FTP-Server abgelegt. (Die Installation des

FTP-Servers legt diesen Ort fest, per Default ist dies C:\copssh\home\<FTP

Benutzername>\WebService.)

Die technische Beschreibung dieses Service befindet sich unter 4.2.


Seite 11

Folgendes Sequenzdiagramm zeigt den Ablauf noch bildlich:

Sequenzdiagramm für Imageaustausch über die Kundenapplikation

Mit diesem Ablauf hat nun die Kundenapplikation den Deklarationsauftrag vom

emotachDirect Image-Server geholt und diesen durch das emotach verarbeiten lassen. Das

Resultat, die Deklarationsmeldung hat die Applikation danach zurück auf den

emotachDirect Image-Server geschickt.

Für die komplette elektronische Deklaration fehlt nun die Verarbeitung der Meldung durch

emotachDirect.

3.2.3 Elektronische Deklaration mit dem OZD-Server

Der Deklarationsservice kopiert nun periodisch die erhaltene Deklarationsmeldung der

Datenablage des Image-Servers in die Datenbank.

Je nach Konfiguration der Applikation, entweder beim Start von emotachDirect und/oder

nach einer bestimmten Zeit, wird die Datenbank nach neuen Deklarationsmeldungen

gesucht ([2] Abschnitt 3.3).

Wenn nun neue Deklarationsmeldungen vorhanden sind, wird der Fahrzeughalter von

emotachDirect informiert ([1] Abschnitt 4.3.5). Er bekommt eine Ansicht von allen noch nicht

verarbeiteten Deklarationsmeldungen und kann diese im Stapel oder Einzeln verarbeiten.

Die Deklarationsmeldungen werden dabei den Deklarationsperioden der entsprechenden

Fahrzeuge zugewiesen.

Am Schluss ruft der Fahrzeughalter auf der emotachDirect die Funktion

„Deklarationsmeldungen übermitteln“ auf ([1] Abschnitt 4.3.3), welche folgende

Webservices der OZD aufruft:


Seite 12

• Schicken der noch nicht versendeten Deklarationsmeldungen

• Verarbeitungsstatus der Deklarationsperioden der Fahrzeuge prüfen

• Prüfen ob es neuere Deklarationsaufträge gibt und diese gegebenenfalls holen.

Die verschiedenen Stati werden anschliessend im emotachDirect nachgeführt. Die

Resultate werden im emotachDirect im Übermittlungsprotokoll festgehalten.

3.3 NMEA-Streaming

Das emotach bietet zusätzlich die Möglichkeit die Ausgabe von GPS-Daten über die

NMEA-0183 Datensätze GPRMC und GPGSA zu aktivieren. Die GPS-Daten können von

externen Geräten, die sich mit dem emotach über die BT-Schnittstelle erfolgreich

verbunden haben und die NMEA-0183 Datensätze GPRMC und GPGSA unterstützen,

verwendet werden. Das emotach unterstützt NMEA 0183 Datensätze gemäss Ver. 2.3 des

NMEA-0183-Standards.

Die Datensätze werden dabei als ASCII-Text übertragen.

Weitere Informationen zum NMEA Standard sind auf www.nmea.org verfügbar.

Das emotach bietet für das NMEA-Streaming einen SPP-Server an. Dieser Server

verwendet als ServiceClassID die für SPP definierte Standard UUID, damit

Navigationssysteme darauf zugreifen können.

Aus Protokollsicht sieht dies folgendermassen aus:

Abbildung 5 – Profile-Stack des SPP-Protokolls.

Das SPP Protokoll basiert auf dem RFCOMM Protokoll und ist eine serielle Schnittstelle.

Die Schnittstellenspezifikation ist im Kapitel 4.1.1.2 beschrieben.

3.4 LSVA-Zusatznutzenprotokoll

Das LSVA-Zusatznutzenprotokoll ist ein eigens für das LSVA-System entwickeltes

Protokoll. Dabei wurde das Protokoll so definiert, dass es gleich funktioniert wie das NMEA-

Streaming. Einzig der Datensatz, welche übertragen wird, ist unterschiedlich zum NMEA-

Streaming, da neben den GPS-Daten zusätzliche LSVA spezifische Daten über das

3.4 LSVA-Zusatznutzenprotokoll

Seite 13

Fahrzeug und den Deklarationszustand des emotach übertragen werden. Die Datensätze

werden dabei als ASCII-Text übertragen.

Das emotach bietet für das Streaming des LSVA-Zusatznutzenprotokolls einen SPP-Server

an. Dieser Server verwendet als ServiceClassID die für dieses Zusatznutzenprotokoll

definierte UUID, damit eine eigen entwickelte Applikation darauf zugreifen kann.

Der Protokollaufbau entspricht dem des NMEA-Streaming.

Die Schnittstellenspezifikation ist im Kapitel 4.1.1.3 beschrieben.

4 Entwicklungsdokumente

Seite 14


4.1 emotach Bluetooth-Services

4.1.1 Anwendungsfälle

Im Folgenden werden die Kommunikationsmöglichkeiten zwischen dem emotach und den

Kommunikationspartnern über Bluetooth festgelegt.

Die in den Anwendungsfällen erwähnten Timeouts entsprechen dem aktuellen Stand und

können während dem Betrieb geändert werden.

4.1.1.1 Übertragung von LSVA Datenimages

Abbildung 6 – Kommunikationspartner für LSVA-Datenimages

Die Datenimages können über BT übertragen werden.

Die Übertragung wird in Form von Paketen durchgeführt. Es wird dazu das Profil OBEX-

FTP (siehe Kapitel 4.1.2) verwendet.

Die Abbildung 8 zeigt das Sequenzdiagramm für den Imageaustausch. Durch eine

Chipkarte oder über das HMI (siehe Benutzeranleitung emotach) wird der Dienst auf dem

emotach gestartet.

Wird die Kommunikation über eine Chipkarte konfiguriert, müssen die PIN und die BT-

Adresse des Kommunikationspartners (Kundenapplikation) bekannt sein. Die PIN dient zur

Authentisierung und Verschlüsselung der Übertragung. Die BT-Adresse wird benötigt um zu

überprüfen, ob sich die richtige Gegenstelle mit dem emotach verbindet.

Bei der Konfiguration übers HMI muss die PIN eingegeben werden. Nach

Verbindungsaufbau muss der Benutzer übers HMI die BT-Adresse der Gegenstelle

bestätigen. Die bestätigte BT-Adresse wird dann mit der Konfiguration gespeichert.

Unabhängig von der Art der Konfiguration muss bekannt sein, ob ein Wiederaufbau der

Verbindung nach einem Abbruch erwünscht ist. Falls dies gewünscht ist, wird der Dienst

automatisch wieder gestartet, nachdem die Verbindung beendet wurde und das emotach ist

für eine neue Verbindung bereit.

Auf dem emotach wird ein BT-FTP-Server gestartet, der auf den Imageaustausch

spezialisiert ist. Für diesen Dienst gibt es einen Service Record. Es wird eine eigene

ServiceClassID (siehe Kapitel 4.1.2.3 SDP - Service Discovery Protocol) für diesen Dienst

verwendet. Damit wird der Gegenstelle ermöglicht, sich gezielt auf einen BT-FTP-Server

zum Imageaustausch zu verbinden.

Nachdem auf dem emotach der Dienst aktiviert wurde, kann die Gegenstelle nach Geräten

und dem Service Record für den Imageaustausch suchen. Anschliessend ist sie in der Lage

eine Verbindung zum emotach aufzubauen. Bei dem Aufbau fordert das emotach die

Gegenstelle zum Pairing (Authentisierung über die PINs) auf. Das emotach überprüft nach

erfolgreichem Aufbau, ob der Kommunikationspartner die erwartete BT-Adresse hat. Wenn

dies nicht der Fall ist, muss das emotach die Verbindung wieder abbrechen.


Seite 15

emotach Application Kundenapplikationemotach APIUser

activate BT

BT image exchange

start BTFTP-Server

register SDP entry

start FTP-Server

own UUID for LSVA-Image

inquiry

response

service search

response

(set discoverable)

FTP connect request

response

connection established

get conn. Device ID

response

FTP get file

FTP put file (Image)

responseFile (Image)

process File

FTP put file (status message)

FTP get file

File (status message)

.

.

.

.

.

.

needed Data:

- UUID

- name of service

response

FTP put file (image response)

disconnectdisconnect

deactivate BT

unregister SDP entry

close FTP-Server

(set undiscoverable)

stop BT image exchangeclose BTFTP Server

needed Data:

- Device ID to allow

connections from ??

activate BT

established

acceptAndOpen

acceptAndOpen

.

.

.

.

.

.

exit condition

not statisfied

exit condition

is statisfied

close FTP-Server

start FTP-Server

pairing

PIN request

PIN

File (image response)

FTP get file

response

only if image

response exists

Abbildung 7 – Sequenzdiagramm Austausch von LSVA-Datenimages


Seite 16

Das emotach wartet nach erfolgreichem Verbindungsaufbau darauf, dass die Gegenstelle

ein Image in Form einer Datei (Image_Auftrag.bin) überträgt (FTP-PUT). Ist das emotach

noch nicht bereit, um eine Datei zu empfangen oder zu senden, lehnt sie die Abfrage ab. In

diesem Fall ist die Anfrage zu wiederholen (Polling). War die Übertragung erfolgreich, wird

das Image ausgewertet.

Anschliessend wird eine Datei mit Statusmeldungen (Status_Meldung.bin) bereitgestellt.

In dieser Statusmeldung sind alle Meldungen der Imageprüfung und Verarbeitung enthalten

(s. Kapitel 4.1.3).

Wenn das Image nicht bearbeitet werden konnte, weil es nicht lesbar oder nicht gültig war,

wird eine entsprechende Fehlermeldung in die Statusmeldung geschrieben.

Der Kommunikationspartner muss immer zuerst diese Statusmeldung abholen (FTP-GET).

Die Statusmeldung gibt an, ob es eine Imagemeldung gibt.

Ist dies der Fall, wird die Imagemeldung anschliessend in einer Datei (Image_Meldung.bin)

bereitgestellt.

Der Kommunikationspartner muss in diesem Fall nach der Statusmeldung diese Datei

abholen (FTP-GET).

Dieser Austausch kann beliebig häufig erfolgen.

Eine bestehende Verbindung wird normalerweise nicht vom emotach getrennt, sondern von

der Gegenseite, die auch die Verbindung aufgebaut hat.

Der Parameter „Server Neustart“ gibt dem emotach an, ob ein Wiederaufbau der

Verbindung nach einem Abbruch gewünscht ist.

Die folgende Tabelle zeigt den genauen Ablauf mit allen Varianten und Ausnahmen. In der

Tabelle wird jeweils vom Run-Modus des emotach gesprochen. Dieser Run-Modus erkennt

man am eingeschalteten Display. Es gibt verschiedene Situation, wo dieser Run-Modus

verlassen wird (zum Beispiel, um in den Sleep-Zustand zu gehen).

Bei den Alternativabläufen wird jeweils der Normalschritt angegeben und anschliessend mit

einem Punkt der aktuelle Schritt im Alternativablauf. Ein Beispiel für die Normalschritte 2-4

mit dem Alternativablaufschritt 3 würde folgendermassen aussehen: 2V4.3.

Use Case Name Übertragung von Imagedateien über die Bluetooth-Schnittstelle

Annahmen Die Abbruchbedingung, welche bestimmt, ob der Dienst neu gestartet wird oder nicht, ist nicht erfüllt, wenn: a) der Dienst durch den Imageauftrag "BT-Konfiguration temporär setzen" auf der Chipkarte gestartet wurde, „Server-Neustart“ gesetzt ist und die Karte noch nicht gezogen wurde. b) der Dienst über das HMI-Menü "Aufträge" oder über den Imageauftrag "BT-Konfiguration setzen" gestartet wurde, „Server-Neustart“ gesetzt ist und „Kein Neustart“ an HMI noch nicht ausgewählt wurde.

Vorbedingungen Vorbedingung Verhalten bei Verletzung

1 emotach läuft und ist vollständig aufgestartet

Übertragung von Imagedateien über BT wird nicht gestartet.

2 Fahrzeug befindet sich im Stillstand (gemäss Tacho).

Übertragung von Imagedateien über BT wird nicht gestartet. Meldungsnummer 7001

3 Wenn der Private Parameter „Image über BT nur bei Zündung“ (siehe [1] Abschnitt 4.1.5) gesetzt ist, muss die Zündung eingeschaltet sein.

Übertragung von Imagedateien über BT wird nicht gestartet. Fehlermeldung am HMI: Meldungsnummer 7000 oder 7132

4 Imagekommunikation wird über Auftragsimage (Chipkarte) aktiviert („BT-Konfiguration temporär setzen“). Dienst, PIN, BT-Adresse der Gegenstelle und „Server

Übertragung von Imagedateien über BT wird nicht gestartet. (Es muss entweder Vorbedingung 4, 5, 6 oder 7 erfüllt sein.)


Seite 17

Neustart“ werden als Parameter mit übergeben.

5 Imagekommunikation „Aufträge“ wird übers HMI gestartet. Die Konfiguration kann übers HMI oder über einen Imageauftrag erfolgt sein. Es muss mindestens der Dienst, PIN und „Server Neustart“ konfiguriert sein.

Übertragung von Imagedateien über BT wird nicht gestartet. Entsprechende Fehlermeldung wird am Display angezeigt: Meldungsnummer 7139 (Es muss entweder Vorbedingung 4, 5, 6 oder 7 erfüllt sein.)

6 Imagekommunikation „Deklaration“ wird über das HMI oder die BT-Taste gestartet. Der Deklarationsdienst ist für den direkten Austausch von Imagedateien konfiguriert (nicht für den Austausch über ein Mobiltelefon) und PIN und BT-Adresse sind konfiguriert. Die Konfiguration kann nur mit einem Imageauftrag erfolgen. Der Parameter „Server Neustart“ wird in diesem Fall nicht konfiguriert. Der Wert wird auf FALSE gesetzt. Anmerkung: Über das Menü „Deklaration“ wird der selbe Dienst gestartet wie beim Drücken der BT-Taste.

Übertragung von Imagedateien über BT wird nicht gestartet. Fehlermeldung am HMI (Meldungsnummer 7140) (Es muss entweder Vorbedingung 4, 5, 6 oder 7 erfüllt sein.)

7 Imagekommunikation wird über Auftragsimage aktiviert („BT-Konfiguration setzen“ mit Parameter „Automatischer Start“ gesetzt). Dienst, PIN, BT-Adresse der Gegenstelle, und „Server Neustart“ werden als Parameter mit übergeben.

Übertragung von Imagedateien über BT wird nicht gestartet. (Es muss entweder Vorbedingung 4, 5, 6 oder 7 erfüllt sein.)

8 Übertragung von Imagedateien ist nicht bereits gestartet (auch nicht mit anderer Gegenstelle)

Übertragung von Imagedateien über BT wird nicht gestartet. Anzeige einer entsprechenden Fehlermeldung am Display: Meldungsnummer 7003

9 Keine Imageverarbeitung aktiv Übertragung von Imagedateien über BT wird nicht gestartet. Anzeige einer entsprechenden Fehlermeldung am Display: Meldungsnummer 4081

10 Es ist kein Dienst mit der gleichen BT-Adresse aber unterschiedlicher PIN gestartet und wartet auf einen Verbindungsaufbau

Übertragung von Imagedateien über BT wird nicht gestartet. Entsprechende Fehlermeldung wird am Display angezeigt: Meldungsnummer 7144

Ausnahmen / Varianten Ausnahme Reaktion

1 Gegenstelle verbindet sich nicht mit emotach nach einem gewissen Timeout (aktuell 10 Minuten). Gilt nur beim Start der Kommunikation über HMI (inkl. BT-Taste) und Start durch Auftragsimage "BT-Konfiguration setzen" (Vorbedingung 5, 6 oder 7).

Siehe Alternativablauf

2 Chipkarte wird gezogen während keine Verbindung besteht. Gilt nur für den Start durch "BT-Konfiguration temporär setzen" (Vorbedingung 4)


3 Der Dienst wird übers HMI abgebrochen, während keine



Seite 18

Verbindung besteht. Gilt nur wenn Imageaustausch übers HMI-Menü "Aufträge" oder über den Auftrag "BT-Konfiguration setzen" aktiviert wurde (Vorbedingungen 5 und 7).

4 Der Dienst wird übers HMI abgebrochen, während keine Verbindung besteht. Gilt nur wenn Imageaustausch übers HMI-Menü „Deklaration“ oder über die BT-Taste aktiviert wurde (Vorbedingungen 6).


5 Gegenstelle nicht erlaubt Siehe Alternativablauf

6 Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 6


7 Fehler bei der Prüfung oder Verarbeitung des Images


8 Gegenstelle hat Statusmeldungen nicht angefordert nach einem gewissen Timeout (aktuell 2 Minuten) oder Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 8 oder 9.


9 Gegenstelle hat Meldungsimage nicht angefordert nach einem gewissen Timeout (aktuell 2 Minuten) oder Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 10 oder 11.


10 Kein Meldungsimage erstellt. (Kein Fehler, nur Variante.)


11 emotach verlässt Run Modus und Abbruchbedingung ist nicht erfüllt.




13 Fahrzeug fährt an (Fahrt gemäss Tacho) und Abbruchbedingung ist erfüllt.


14 Fahrzeug fährt an (Fahrt gemäss Tacho) und Abbruchbedingung ist nicht erfüllt.


15 Parameter, dass die Zündung eingeschaltet sein muss, ist gesetzt, und Zündung wurde ausgeschaltet und Abbruchbedingung ist erfüllt.


16 Parameter, dass die Zündung eingeschaltet sein muss, ist gesetzt, und Zündung wurde ausgeschaltet und Abbruchbedingung ist nicht erfüllt.


17 Nicht regulärer Verbindungsabbau durch Gegenstelle während Normalablauf Schritt 8..11 und Abbruchbedingung ist nicht erfüllt.


18 Nicht regulärer Verbindungsabbau durch Gegenstelle während in Normalablauf Schritt 8..11 und Abbruchbedingung ist nicht erfüllt


19 Regulärer Verbindungsabbau durch Gegenstelle in Normalablauf Schritt 6 und Abbruchbedingung ist erfüllt


20 Regulärer Verbindungsabbau durch Gegenstelle in Normalablauf Schritt



Seite 19

6 UND Abbruchbedingung ist NICHT erfüllt

Normalablauf Aktion Bemerkung

1 Starten des BT-FTP-Server für den Imageaustausch (extra ServiceClassID)

2 Warten auf eingehende Verbindung Annahme: Gegenstelle startet Verbindungsaufbau zum BT-FTP-Server.

3 Paarung der Geräte mit der PIN aus der Konfiguration.

Nur bei der ersten Verbindung zwischen zwei Geräten nötig oder wenn die PIN aus der Konfiguration nicht mehr mit der PIN der Paarung übereinstimmt (siehe Kapitel 4.1.2.2). Ist das Pairing nicht erfolgreich wird dieser Schritt wiederholt, bis das Pairing erfolgreich war (korrekte Authentifizierung durch korrekte PIN), oder das Timeout (aktuell 10 Minuten) abgelaufen ist.

4 Warten, dass sich die Gegenstelle mit BT-FTP-Server verbindet.

Annahme: Gegenstelle hat sich erfolgreich mit BT-FTP-Server verbunden.

5 Prüfung der BT-Adresse der Gegenstelle.

Ist die BT-Adresse nicht konfiguriert, muss der Benutzer die Gegenstelle übers HMI bestätigen und die Prüfung wird nicht durchgeführt. Ist die BT-Konfiguration vollständig (mit BT-Adresse) konfiguriert, wird auch keine Bestätigung angezeigt. Die Adressprüfung benötigt ca. 200 ms. Annahme: Prüfung OK

6 FTP-Server wartet auf Datei (Image_Auftrag.bin) mit korrektem Dateinamen der Gegenstelle.

Datei mit falschem Dateinamen kann nicht auf den FTP-Server geschrieben werden. Annahme: Gegenstelle hat Datei übertragen

7 Prüfung und Verarbeitung des Images und Statusmeldung erstellen.

Annahme: Prüfung und Verarbeitung OK

8 Statusmeldung (Status_Meldung.bin) auf FTP-Server ablegen und warten bis diese durch die Gegenstelle angefordert wird.

Annahme: Gegenstelle fordert Statusmeldung „Status_Meldung.bin“ an (FTP-GET).

9 Datei mit Statusmeldungen (Status_Meldung.bin) zur Gegenstelle übertragen.

In der Statusmeldung muss angegeben werden ob ein Meldungsimage erstellt wurde.

10 Meldungimage „Image_Meldung.bin“ auf FTP-Server ablegen und warten bis dieses durch die Gegenstelle angefordert wird.

Nur wenn ein Meldungsimage erstellt wurde. Annahme: Gegenstelle fordert Meldungsimage „Image_Meldung.bin“ an (FTP-GET).

11 Meldungsimage „Image_Meldung.bin“ zur Gegenstelle übertragen.

12 Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) auf dem FTP-


Seite 20

Server löschen.

13 Weiter mit Schritt 6 Wiederholung der Schritte 6 - 12 beliebig häufig möglich.

Alternativabläufe

(1) Gegenstelle verbindet sich nicht mit emotach nach einem gewissen Timeout (aktuell 10 Minuten). Gilt nur beim Start der Kommunikation über HMI (inkl. BT-Taste) und Start durch Auftragsimage "BT-Konfiguration setzen" (Vorbedingung 5, 6 oder 7). Während Normalablauf Schritt 2 - 4 möglich.

Aktion Bemerkung

2...4.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 7004 oder 7133

2...4.2 BT-FTP-Server schliessen, auch wenn der Parameter „Server-Neustart“ gesetzt ist. BT-Modul auf Non-Discoverable und Non-Connectable stellen.

BT-Modul nur auf Non-Discoverable und Non-Connectable stellen, wenn keine weiteren BT-Server laufen.

(2) Chipkarte wird gezogen während keine Verbindung besteht. Gilt nur für den Start durch "BT-Konfiguration temporär setzen" (Vorbedingung 4) Während Normalablauf Schritt 2 - 4 möglich.

Aktion Bemerkung

2...4.1 Es erscheint nur bedingt eine Fehlermeldung.

Meldungsnummer 8277

2....4.2 BT-FTP-Server wird geschlossen. BT-Modul auf Non-Discoverable und Non-Connectable stellen.

BT-Modul nur auf Non-Connectable und Non-Discoverable stellen, wenn keine weiteren BT-Server laufen.

(3) Der Dienst wird übers HMI abgebrochen, während keine Verbindung besteht. Gilt nur wenn Imageaustausch übers HMI oder über den Auftrag "BT-Konfiguration setzen" aktiviert wurde Während Normalablauf Schritt 2 - 4 möglich. Anmerkung: Bei synchroner Anzeige Abbruch nur über ESC möglich, bei asynchroner Anzeige nur über BT-Start/Stop Menü möglich.

Aktion Bemerkung

2...4.1 Es erscheint bedingt eine Fehlermeldung.

Meldungsnummer 8277

2...4.2 BT-FTP-Server wird geschlossen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(4) Der Dienst wird übers HMI abgebrochen, während keine Verbindung besteht. Gilt nur wenn Imageaustausch übers HMI „Deklaration“ oder über BT-Taste aktiviert wurde (Vorbedingungen 6). Während Normalablauf Schritt 2 - 4 möglich. Anmerkung: Abbruch in diesem Zustand nur über ESC-Taste möglich (synchrone Anzeige aktiv)

2...4.1 Die synchrone Anzeige, dass auf eingehende Verbindung gewartet

Keine Meldungsausgabe


Seite 21

wird beendet, es gibt keine weitere Meldung.

2...4.2 BT-FTP-Server wird geschlossen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(5) Gegenstelle nicht erlaubt Aktion Bemerkung

5.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 7006 oder 7134

5.2 Verbindung schliessen.

5.3 Weiter mit Schritt 2. Server wartet erneut auf eingehende Verbindung.

(6) Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 6

Aktion Bemerkung

6.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 7007 oder 7135

6.2 BT-FTP-Server wird geschlossen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


6.3 Wenn Abbruchbedingung nicht erfüllt, Ausgabe der Meldung 7007 und weiter mit Schritt 1. Wenn Abbruchbedingung erfüllt, Ausgabe von Meldung 7007 und Use-Case abbrechen.

Meldungsnummer 7007

(7) Fehler bei der Prüfung oder Verarbeitung des Images

Aktion Bemerkung

7.1 Statusmeldung (inkl. Fehlercode, siehe Kapitel 4.1.3) erstellen. Weiter mit Schritt 8.

Fehlermeldungen werden am HMI ausgegeben

(8) Gegenstelle hat Statusmeldungen nicht angefordert nach einem gewissen Timeout (aktuell 2 Minuten) oder Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 8 oder 9.

Aktion Bemerkung

8.1..9.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 7009 oder 7136

8.2..9.2 Verbindung wird getrennt (falls noch vorhanden) und BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin und Image_Meldung.bin) löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen. Wenn die Abbruchbedingung nicht erfüllt ist, weiter in Normalablauf Schritt 1, sonst Use-Case abbrechen


(9) Gegenstelle hat Meldungsimage nicht angefordert nach einem gewissen Timeout (aktuell 2 Minuten) oder Verbindungsabbruch gemäss Kapitel 4.1.2.2 in Normalablauf Schritt 10 oder 11.

Aktion Bemerkung

10.1.11.1 Fehlermeldung am HMI ausgeben Meldungsnummer 7010 oder 7137

10.2..11.2 Verbindung wird getrennt (falls noch vorhanden) und BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen. Wenn die Abbruchbedingung nicht



Seite 22

erfüllt ist, weiter in Normalablauf Schritt 1, sonst Use-Case abbrechen.

(10) Kein Meldungsimage erstellt. (Kein Fehler, nur Variante)

Aktion Bemerkung

10.1 Schritt 10 und 11 des Normalablaufs werden übersprungen. Weiter mit Schritt 12.

(11) emotach verlässt Run Modus und Abbruchbedingung erfüllt.

Aktion Bemerkung

während Normalablauf 1.. 12 möglich.

Details zu den Abbruchbedingungen siehe Annahme

1 ... 12.1 Verbindung wird getrennt (falls vorhanden) und BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(12) emotach verlässt Run Modus und Abbruchbedingung ist nicht erfüllt.

Aktion Bemerkung

Während Normalablauf 1 - 12 möglich.


1V12.1 Verbindung wird getrennt (falls vorhanden) und BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


1 V 12.2 Wenn der Run Modus wieder erreicht wird: weiter mit 1

(13) Fahrzeug fährt an (Fahrt gemäss Tacho) und Abbruchbedingung erfüllt.

Aktion Bemerkung




1...12.2 Verbindung wird getrennt (falls vorhanden) und BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(14) Fahrzeug fährt an (Fahrt gemäss Tacho) und Abbruchbedingung nicht erfüllt.

Aktion Bemerkung



1...12.1 Fehlermeldung am HMI ausgeben Meldungsnummer 7011 oder 7131




Seite 23

1...12.3 Wenn das Fahrzeug wieder im Stillstand (gemäss Tacho) ist: weiter mit Schritt 1

(15) Parameter, dass die Zündung eingeschaltet sein muss, ist gesetzt, und Zündung wurde ausgeschaltet und Abbruchbedingung erfüllt.

Aktion Bemerkung

Während Normalablauf Schritt 1 - 12 möglich.





(16) Parameter, dass die Zündung eingeschaltet sein muss, ist gesetzt, und Zündung wurde ausgeschaltet und Abbruchbedingung nicht erfüllt.

Aktion Bemerkung



1...12.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 7012 oder 7132.



1...12.3 Wenn die Zündung wieder eingeschaltet wurde: weiter mit Schritt 1

(17) Nicht regulärer Verbindungsabbau durch Gegenstelle während Normalablauf Schritt 8..11 und Abbruchbedingung ist erfüllt. (Kein Neustart)

Aktion Bemerkung

8...11.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 4009 oder 4010.

8...11.2 BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) soweit vorhanden löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(18) Nichtregulärer Verbindungsabbau durch Gegenstelle während Normalablauf 8..11 und Abbruchbedingung ist nicht erfüllt. (mit Neustart)

Aktion Bemerkung Details zu den Abbruchbedingungen siehe Annahme

8...11.1 Verbindung schliessen.

8...11.2 Weiter mit Schritt 2. Server wartet erneut auf eingehende Verbindung.

(19) Regulärer Verbindungsabbau durch Gegenstelle in Normalablauf Schritt 6 und Abbruchbedingung ist erfüllt.

Aktion Bemerkung


Seite 24

(Kein Neustart) 6.1 Fehlermeldung am HMI ausgeben. Meldungsnummer 8201 und 8202

6.2 BT-FTP-Server wird geschlossen. Die Dateien (Image_Auftrag.bin, Image_Meldung.bin und Status_Meldung.bin) soweit vorhanden löschen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(20) Regulärer Verbindungsabbau durch Gegenstelle in Normalablauf Schritt 6 und Abbruchbedingung ist nicht erfüllt (mit Neustart)

Aktion Bemerkung

6.1 Fehlermeldung am HMI ausgeben Meldungsnummer 8201

6.2 weiter mit Schritt 2 Server wartet auf eingehende Verbindung.

4.1.1.2 Übertragung von NMEA-Daten

emotach Navigationssystem

Abbildung 8 – Kommunikationspartner NMEA-Daten

Für Daten, die aus dem emotach gestreamt werden, wird das SPP-Profil (siehe Kapitel

4.1.2.3) verwendet. Auf dieser Protokollschicht werden die Daten byteweise übertragen.

NMEA-Daten werden unidirektional vom emotach zu anderen Komponenten übertragen.

Streaming von NMEA-Daten können vom emotach an die Kundenapplikation, und an

handelsübliche Navigationssysteme übertragen werden.

Dieser Dienst kann über einen Laptop genutzt werden (siehe Screenshot).


Seite 25

Abbildung 9 – Dienstauswahl beim Verbindungsaufbau

Die Ausgabe kann anschliessend einfach über das Hyperterminal ausgelesen werden.

Die Ausgabe kann von der emotachDirect durch einen Imageauftrag konfiguriert und

gestartet werden.

Dabei ist zu unterscheiden, ob der Dienst durch den Auftrag "BT-Konfiguration temporär

setzen" oder "BT-Konfiguration setzen" gestartet wird. Im zweiten Fall verhält sich das

emotach wie beim Starten des Dienstes über HMI und man muss den Dienst manuell

starten.

Die Ausgabe kann auch übers HMI gestartet werden.

Die Konfiguration muss vorher über einen Imageauftrag (siehe [1] Abschnitt 4.1.5) oder

übers HMI eingegeben werden.

Das emotach bietet für das NMEA-Streaming einen SPP-Server an. Dieser Server

verwendet als ServiceClassID die für SPP definierte UUID, damit Navigationssysteme

darauf zugreifen können.

Die Gegenstelle (Kundenapplikation oder Navigationssystem) kann nun eine Verbindung zu

diesem Server aufbauen. Sobald dies geschehen ist, sendet das emotach die NMEA-

Daten.

Die Authentisierung und Verschlüsselung erfolgt optional.

Es kann sich immer nur eine Gegenstelle auf einen Server verbinden.

Die Abbruchbedingungen sind die gleichen, wie in Kapitel 4.1.1.1 beschrieben.


Seite 26

eotach Application Receiveremotach APIUser

output NMEA data

activate BT

start SPP-ServerUUID for SPP

activate BT

create SDP entry

send NMEA data

deactivate BTclose SPP-Server

disconnectconnection closed

.

.

.

.

.

.

inquiry

response

service search

response

SPP connect request

responseconnection established

open output stream

response

acceptAndOpen

.

.

.

.

.

.

deactivate BT

unregister SDP entry

(set undiscoverable)

exit condition

not statisfied

exit condition

is statisfied

close SPP-Server

pairing

PIN request

PIN

only if encryption

is required

Abbildung 10 – Sequenzdiagramm Streaming von NMEA-Daten

Folgende Tabelle zeigt die Kommunikation im Detail. In der Tabelle wird jeweils vom Run-

Modus des emotach gesprochen. Dieser Run-Modus erkennt man am eingeschalteten

Display. Es gibt verschiedene Situation, wo dieser Run-Modus verlassen wird (zum

Beispiel, um in den Sleep-Zustand zu gehen).





Seite 27

Use Case Name Streaming von NMEA-Daten und des LSVA-Zusatznutzenprotokolls über die Bluetooth-Schnittstelle

Annahmen Die Abbruchbedingung, welche bestimmt, ob der Dienst neu gestartet wird oder nicht, ist nicht erfüllt, wenn: a) der Dienst durch den Imageauftrag "BT-Konfiguration temporär setzen" auf der Chipkarte gestartet wurde, „Server-Neustart“ gesetzt ist und die Karte noch nicht gezogen wurde. b) der Dienst über das HMI oder über den Imageauftrag "BT-Konfiguration setzen" gestartet wurde, „Server-Neustart“ gesetzt ist und „Kein Neustart“ an HMI noch nicht ausgewählt wurde.


1 NMEA-Streaming oder LSVA-Zusatznutzenprotokoll wird durch Auswahl einer gespeicherten BT-Konfiguration übers HMI gestartet. Die Konfiguration kann über einen Imageauftrag oder übers HMI erfolgt sein.

Fehlermeldung am HMI: Meldungsnummer 7142 oder 7143 Übertragung wird nicht gestartet. (Es muss entweder Vorbedingung 2, 3 oder 4 erfüllt sein.)

2 NMEA-Streaming oder LSVA-Zusatznutzenprotokoll wird über einen Imageauftrag "BT-Konfiguration temporär setzen" gestartet.

Übertragung wird nicht gestartet. (Es muss entweder Vorbedingung 2, 3 oder 4 erfüllt sein.)

3 NMEA-Streaming oder LSVA-Zusatznutzenprotokoll wird über den Imageauftrag „BT-Konfiguration setzen“ gestartet.

Übertragung wird nicht gestartet. (Es muss entweder Vorbedingung 2, 3 oder 4 erfüllt sein.)

4 Für NMEA-Streaming: NMEA-Streaming darf nicht bereits gestartet sein.

Fehlermeldung am HMI: Meldungsnummer 7062

5 Für LSVA-Zusatznutzenprotokoll: LSVA-Zusatznutzenprotokoll darf nicht bereits gestartet sein.

Fehlermeldung am HMI: Meldungsnummer 7076

6 Es wartet kein Dienst mit der gleichen BT-Adresse wie der zu startende Dienst aber andere PIN als der zu startende Dienst, auf einen Verbindungsaufbau

Übertragung von NMEA-Daten bzw. des LSVA-Zusatznutzenprotokoll über BT wird nicht gestartet. Entsprechende Fehlermeldung wird am Display angezeigt: Meldungsnummer 7144


1 Gilt nur beim Start über HMI, beim Start durch Imageauftrag "BT-Konfiguration setzen": Gegenstelle verbindet sich nicht mit emotach nach einem gewissen Timeout (aktuell 10 Minuten).


2 Gilt nur beim Start durch Imageauftrag "BT-Konfiguration temporär setzen" auf Chipkarte: Chipkarte wird gezogen während keine Verbindung besteht.


3 Gilt nur beim Start über HMI, beim Start durch Imageauftrag "BT-Konfiguration setzen": Der Dienst wird übers HMI abgebrochen, während keine Verbindung besteht.


4 Gegenstelle nicht erlaubt Siehe Alternativablauf

5 Verbindung wird getrennt (Verbindungsabbruch gemäss Kapitel 4.1.2.2 oder Schliessen der Verbindung durch die Gegenstelle) und Abbruchbedingung ist nicht erfüllt.



Seite 28

6 emotach verlässt Run Modus und Abbruchbedingung ist erfüllt.





1 Starten des BT-SPP-Servers.

2 Warten auf eingehende Verbindung Annahme: Gegenstelle startet Verbindungsaufbau.

3 Paarung der Geräte mit der PIN aus der Konfiguration. (Nur bei entsprechender Konfiguration)

Nur bei der ersten Verbindung zwischen zwei Geräten nötig oder wenn die PIN aus der Konfiguration nicht mehr mit der PIN der Paarung übereinstimmt (siehe Kapitel 4.1.2.2). Ist das Pairing nicht erfolgreich wird dieser Schritt wiederholt, bis das Pairing erfolgreich war (korrekte Authentifizierung durch korrekten PIN), oder das abgelaufen ist.

4 Warten, dass sich die Gegenstelle mit dem BT-SPP-Server verbindet.

Annahme: Gegenstelle hat sich erfolgreich mit BT-SPP-Server verbunden.

5 Prüfung der BT-Adresse der Gegenstelle

Bei der Konfiguration des Imageaustauschs über HMI muss der Benutzer die Gegenstelle (BT-Adresse + Name) übers HMI bestätigen. Annahme: BT-Adresse stimmt mit der Konfiguration überein oder BT-Adresse wurde am HMI bestätigt

6 Server startet mit Streaming der NMEA-Daten oder LSVA-Zusatznutzenprotokoll

7 Warten auf Beenden der Verbindung durch die Gegenstelle

Annahme: Gegenstelle beendet Verbindung und Abbruchbedingung erfüllt.

8 BT-SPP-Server wird geschlossen. BT-Modul auf Non-Discoverable und Non-Connectable stellen.


Alternativabläufe

(1) Gilt nur beim Start über HMI, beim Start durch Imageauftrag "BT-Konfiguration setzen": Gegenstelle verbindet sich nicht mit emotach nach Timeout (aktuell 10 Minuten). Im Normalablauf Schritt 1-4 möglich.

Aktion Bemerkung

1..4.1 Fehlermeldung am HMI . Meldungsnummer 7063 oder 7077

1...4.2 BT-SPP-Server schliessen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(2) Gilt nur beim Start durch Imageauftrag "BT-Konfiguration temporär setzen" auf Chipkarte: Chipkarte wird gezogen während keine Verbindung besteht Im Normalablauf Schritt 1-4 möglich.

Aktion Bemerkung

1...4.1 Fehlermeldung am HMI. Meldungsnummer 8278 / 8279



(3) Gilt nur beim Start über HMI, Aktion Bemerkung


Seite 29

beim Start durch Imageauftrag "BT-Konfiguration setzen": Der Dienst wird übers HMI abgebrochen, während keine Verbindung besteht. Im Normalablauf Schritt 1-4 möglich.

1...4.1 Es erscheint nur bedingt eine Fehlermeldung.

Meldungsnummer 8278 oder 8279



(4) Gegenstelle nicht erlaubt Aktion Bemerkung

5.1 Fehlermeldung am HMI. Meldungsnummer 7065 oder 7079

5.2 Verbindung schliessen.

5.3 Server wartet erneut auf eingehende Verbindung. Weiter mit 2.

(5) Verbindung wird getrennt (Verbindungsabbruch gemäss Kapitel 4.1.2.2 oder Schliessen der Verbindung durch die Gegenstelle) und Abbruchbedingung ist nicht erfüllt.

Aktion Bemerkung

3...7.1 Server wartet auf eingehende Verbindung. Weiter mit 2.

(6) emotach verlässt Run Modus und Abbruchbedingung ist erfüllt.

Aktion Bemerkung

Während des gesamten Ablaufs möglich.


1...7.1 Verbindung trennen (falls vorhanden) und BT-SPP-Server schliessen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


(7) emotach verlässt Run Modus und Abbruchbedingung ist nicht erfüllt

Aktion Bemerkung



1...7.1 Verbindung trennen (falls vorhanden) und BT-SPP-Server schliessen. BT-Modul auf Non-Connectable und Non-Discoverable stellen.


1...7.2 Wenn der Run Modus wieder erreicht wird: weiter mit 1

emotach NMEA Daten

Die folgenden NMEA-Datensätze werden vom emotach bereit gestellt. Felder zu denen

der GPS-Empfänger zeitweise keine Werte liefern kann oder vom Empfänger nicht

Unterstützt werden, bleiben leer.

GSA – GPS DOP and active satellites:

1 2 3 14 15 16 17 18

| | | | | | | |

$GPGSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x*hh<CR><LF>

1) Selection mode

A – auto

M – manual


Seite 30

2) Mode

1 – no fix

2 – 2D fix

3 – 3D fix

3) ID of 1st satellite used for fix

4) ID of 2nd satellite used for fix

...

14) ID of 12th satellite used for fix

15) PDOP in meters (wird nicht ausgegeben)

16) HDOP in meters

17) VDOP in meters (wird nicht ausgegeben)

18) checksum

RMC – Recommended Minimum Navigation Information

13

1 2 3 4 5 6 7 8 9 10 11 12|

| | | | | | | | | | | | |

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,A*hh<CR><LF>

1) UTC Time

2) Status

A – valid navigation data

V – not valid navigation data

3) Latitude

4) N or S

5) Longitude

6) E or W

7) Speed over ground, knots

8) Track made good, degrees true

9) Date, ddmmyy

10) Magnetic Variation, degrees

11) E or W

12) Mode (Der GPS-Empfänger des emotach arbeitet im Autonomous Mode)

- A: Autonomous

- D: DGPS

- E: DR

13) Checksum

4.1.1.3 Streaming vom LSVA-Zusatznutzenprotokoll

Abbildung 11 – Kommunikationspartner LSVA-Zusatznutzenprotokoll

Das Streaming des LSVA-Zusatznutzenprotokolls erfolgt im Wesentlichen wie das

Streaming der NMEA-Daten (siehe Kapitel 4.1.1.2).

Die einzige Ausnahme ist, dass für den Server eine eigene ServiceClassID (siehe Kapitel

4.1.2.3 SDP - Service Discovery Protocol) vergeben wird.

Die Authentisierung und Verschlüsselung erfolgt optional.


Seite 31

Dieser Dienst ist über Standardtools nur mit dem BT-Stack von Toshiba auszulesen. Über

diesen kann über folgende Schritte eine Verbindung hergestellt werden und anschliessend

über das Hyperterminal ausgelesen werden.

Abbildung 12 – Auswählen des Benutzerdefinierten Modus bei den Verbindungseinstellungen

Es soll der Benutzerdefinierte Modus gewählt werden.

Abbildung 13 – Dienst wird ausgewählt


Seite 32

Der LSVA-Zusatznutzenprotokoll-Dienst soll ausgewählt werden.

Abbildung 14 – COM-Port wird ausgewählt.

Es muss eine COM-Port Zuordnung gemacht werden. In diesem Beispiel ist dies COM40.

Abbildung 15 – Verbindungsaufbau mit dem emotach


Seite 33

Die Verbindung muss nun mit dem konfigurierten emotach hergestellt werden.

Abbildung 16 – Ausgabe des Zusatznutzenprotokolls über das HyperTerminal

Das Zusatznutzenprotokoll kann nun mit dem Hyperterminal ausgelesen und interpretiert

werden.

Es ist zu unterscheiden, ob der Dienst durch den Auftrag "BT-Konfiguration temporär

setzen" oder "BT-Konfiguration setzen" gestartet wird. Im zweiten Fall verhält sich das

emotach wie beim Starten des Dienstes über HMI und man muss den Dienst manuell

starten.

Die Ausgabe kann auch übers HMI gestartet werden.

Die Konfiguration muss vorher über einen Imageauftrag (siehe [1] Abschnitt 4.1.5) oder

übers HMI eingegeben werden.

Das Sequenzdiagramm und die Tabelle sind die gleichen wie beim NMEA-Streaming und

sind im Kapitel 4.1.1.2 zu finden.

Ausgabeformatierung des LSVA-Zusatznutzenprotokolls

Die Ausgabe der Daten erfolgt nach folgenden Grundsätzen:

1. Die Ausgabe des LSVA-Zusatznutzenprotokolls erfolgt als ASCII-Text. Umlaute

werden durch „?“ ersetzt.

2. Jedes Datenelement aus der obigen Tabelle wird in einer eigenen Zeile dargestellt.

Elemente von zusammengesetzten Datentypen (z.B. Strukturen) werden durch

Kommas getrennt. Ausgegeben werden immer die aktuellen Werte der

Datenelemente unabhängig davon, ob sie reale Werte (z.B. Anhängerdaten) oder die

Defaultwerte enthalten. Jede Zeile wird mit CR (0x13) LF (0x10) abgeschlossen.

3. Rationale Zahlen werden mit Dezimalpunkte ausgegeben (z.B. 3.5 anstelle von 3,5)

4. Bitsets werden als Hexadezimalzahlen ausgegeben

5. Hexadezimalzahlen werden ohne führende "0x" in UpperCase-format [0V9, A V F]

ausgegeben z.B. 3F


Seite 34

Datentypen für das Zusatznutzenprotokoll

Allgemeine Information:

Die Ausgabe erfolgt als ASCII-Text.

StammNummer:

Vorzeichenloser 4-Byte Integer, 0 = Stammnummer nicht gesetzt,

Interpretiert muss immer von rechts nach drei Zahlen über die gesamte Zahl ein Punkt

eingefügt werden. Beispiel: 1.234.567.890 oder 123.456.789

Wertebereich: 0 - 4'294'967’294

Struktur ATA-Passagen:

ATA-Nummer, Vorzeichenloser 1 Byte Integer, Wertebereich 0 – 255

ATA-Zähler, Vorzeichenloser 2 Byte Integer, Wertebereich 0 - 65'535

Struktur Zusammenzüge:

Die Struktur Zusammenzüge setzt sich durch folgende Elemente zusammen:

Kilometer Total, Kilometerstand in 1 km Auflösung, Vorzeichenloser 3 Byte

Integer, Wertebereich: 0 km – 16'777'215 km

Kilometer Inland, Kilometerstand in 1 km Auflösung, Vorzeichenloser 3 Byte

Integer, Wertebereich: 0 km – 16'777'215 km

LSVA-Leistung, LSVA Leistung in Tonnen mal km (Auflösung 0.01 tkm 100 =

1 tkm, Vorzeichenloser 4 Byte Integer, Wertebereich 0 – 42'949'672,95 tkm

Liste von ATA-Passagen, Formatierung 1. Element = Anzahl Elemente in der

Liste, Durch Komma getrennt die Unterstrukturen

Status Erfassung:

Dieses Element ist ein Bitset mit 8 Bits. Folgende Bedeutung haben die einzelnen Bits:

Bit 0: nicht dokumentiert




Bit 4: Gerätestatus rot, 0 = Nein, 1 = Ja

Bit 5: Deklarierter Anhängerzustand, 0 = OFF, 1 = ON

Bit 6: Deklarierter Grenzzustand, 0 = Ausland, 1 = Inland


Dieses Element wird als hexadezimale Zahl ohne „0x“ übertragen und muss gemäss

der obigen Definition interpretiert werden.

Status Emotach:

Dieses Element ist ein Bitset mit 8 Bits. Folgende Bedeutung haben die einzelnen Bits:

Bit 0: Stamm- und Vertragsdaten geladen, 0 = Nein, 1 = Ja

Bit 1: Fixer Wert 0

Bit 2: GPS-Antenne, 0 = intern, 1 = extern

Bit 3: DSRC-Antenne, 0 = intern, 1 = extern

Bit 4: Gerätestatus gelb, 0 = Nein, 1 = Ja

Bit 5: Defekt, 0 = Nein, 1 = Ja

Bit 6: Tiefer Batteriezustand, 0 = Nein, 1 = Ja

Bit 7: Fixer Wert 0

Dieses Element wird als hexadezimale Zahl ohne „0x“ übertragen und muss gemäss

der obigen Definition interpretiert werden.


Seite 35

Vertrag ATA:

Das Element Vertrag ATA ist eine 4 Bit Enumeration. Folgende Bedeutung haben die

einzelnen dezimalen Werte:

Wert 0: ATA pflichtig

Wert 1: nicht ATA pflichtig

Wert 2: ATA befreit

Wert 3 – 14: unbenutzt

Wert 15: ATA nicht definiert

Es wird einer dieser dezimalen Werte übermittelt.

Vertrag LSVA:

Das Element Vertrag LSVA ist eine 4 Bit Enumeration. Folgende Bedeutung haben die

einzelnen dezimalen Werte:

Wert 0: LSVA pflichtig

Wert 1: nicht LSVA pflichtig

Wert 2: LSVA befreit

Wert 3: Pauschale LSVA

Wert 4 – 14: unbenutzt

Wert 15: LSVA nicht definiert

Es wird einer dieser dezimalen Werte übermittelt.

Gesamtgewicht des Anhängers:

Diese Struktur setzt sich folgendermassen zusammen:

Bit 0-12: Gewicht des Anhängers, Gewicht in 10 kg Einheiten (0 – 81.91t,

abgerundet, Der Wert 81.91t hat die spezielle Bedeutung, dass das Gewicht

grösser 81.91t ist.

Bit 13: unbenutzt

Bit 14: Auflieger?, 0 = Nein, 1 = Ja

Bit 15: Ersatz Deklaration?, 0 = Nein, 1 = Ja

Die Übertragung ist Kommasepariert inkl. dem unbenutzten Bit 13, wo immer 0

übertragen wird! Ein Beispiel wäre 1240, 0, 1, 0

Herkunft:

Die Herkunft beschreibt die Herkunft des Anhängerdatensatzes. Dieses Element ist

eine 1 Byte Enumeration. Die einzelnen Werte haben folgende Bedeutung:

Wert 0: nicht definiert

Wert 1: emotach

Wert 2: emotachDirect

Wert 3: OZD

Werte 4-255: unbenutzt

Anhängerdaten Privat:

Diese Struktur setzt sich aus folgenden Elementen zusammen:

Vertrag ATA, siehe Struktur

Vertrag LSVA, siehe Struktur

Kontrollschild, String von 10 Zeichen, Zugelassene Zeichen sind : 0-9, A-Z, a-z,

ä ö ü, # und Space (hex 20)

Gesamtgewicht des Anhängers, siehe Struktur

Ländercode, 1-3 stelliger Text als Ländercode


Seite 36

Stammnummer, siehe Element StammNummer

Herkunft,

Freie Anhänger Nummer, Vorzeichenloser 2 Byte Integer, Wertebereich 0-999.

Wenn die Freie Anhänger Nummer nicht vorhanden ist wird „---“ ausgegeben.

Alle diese Werte werden durch Komma getrennt. Wenn kein Anhänger deklariert ist,

gibt es eine Default-Ausgabe, wo überall 0 ist. Dies sieht folgendermassen aus:

0, 0, , 0, 0, 0, 0, CH, 0, 0, 0

Checksumme:

Die Checksumme ist ein 2 Byte Integer und wird hexadezimal übertragen.

Die Checksumme wird gemäss CCITT-CRC 16 mit folgenden Parametern berechnet:

• Parameters CCITT CRC-16

• Degree of polynomial r: 16

• Polynomial G(x): 0x1021

• Initial value: 0x0000

• Output XOR mask: 0x0000

• Reflect input byte: no bit order within one byte (normal: MSB first)

• Reflect output CRC: no bit order within one byte

• Augment with zeroes: no read out of the feedback shift register directly after the last message bit has been shifted in, or after

trailing zeroes have been shifted in (augmentation with zeroes)

Die Checksumme wir über den Bereich beginnend mit SOH bis und mit ETX berechnet.

Zusatznutzenprotokoll-Daten

Folgende Tabelle zeigt die Daten für das Zusatznutzenprotokoll:

Datenelement Definition Beispiel

Startzeichen Header (SOH) SOH; 0x01 gemäss ASCII-Codetabelle

-

Meldungstyp Text "LSVA2-Zusatznutzenprotokoll"

Kennung LSVA2-Zusatznutzenprotokoll-Meldung

LSVA2-Zusatznutzenprotokoll

Version Meldungsstruktur Version der Meldungstruktur, für allfällige Erweiterungen der Meldung. Diese Meldungstruktur hat die Version 1.0.

Führende Nullen werden nicht dargestellt, d.h. anstelle von 001.003 wird 1.3 dargestellt.

1.0

Länge Meldung Länge in Bytes zwischen STX bis ETX (ohne STX und ETX)

153

Gerätenummer Vorzeichenloser 4-Byte Integer, Wertebereich: 0 A 4'294'967'295

2002031

Startzeichen Daten (STX) STX; 0x02 gemäss ASCII-Codetabelle

-


Seite 37

Datum/Zeit Format yyyy.MM.dd, hh:mm:ss

Datum und Uhrzeit durch Komma getrennt. Die Ausgabe erfolgt in Schweizer Lokalzeit

2008.04.30, 13:08:00

km-Stand emotach Kilometerstand in 100m Auflösung mit Punkt als Trennzeichen Wertebereich: 0,0 km A 1'677’721,5 km

8111.0

km-Stand Tageszähler Tageskilometer-Zähler mit 100 Meter Auflösung

Wertebereich 000.0 – 999.9

110.9

Zusammenzüge Siehe Struktur Zusammenzüge. Die Elemente der Struktur werden durch Komma separiert in einer Zeile als ASCII-Text dargestellt.

In dem Beispiel rechts, enthält das Strukturelement ATAPassagen 2 ATA Zähler > 0: ATANr 3 hat den Zählerwert 5 und ATANr 7 den Zählerwert 4)

111, 111, 0.00, 2, 3, 5, 7, 4

Stammnummer Vorzeichenloser 4-Byte Integer, 0 = Stammnummer nicht gesetzt,

Interpretiert muss immer von rechts nach drei Zahlen über die gesamte Zahl ein Punkt eingefügt werden.

Wertebereich: 0 - 4'294'967’294

12345

Statuspaket Erfassung Siehe Element Status Erfassung 20

Statuspaket emotach Siehe Element Status Emotach 04

Zustand Zündkontakt An=1/Aus=0 1

Daten des deklarierten Anhängers

Siehe Struktur Anhängerdaten Privat

Das Beispiel rechts zeigt einen LSVA- und ATA-pflichtigen Anhänger mit 12,4 t mit dem Kennzeichen BB CH 1111 und der Stammnummer 12345

0, 0, BB CH 1111, 1240, 0, 0, 0, CH, 12345, 0, 0

Geschwindigkeit (Tacho) Momentangeschwindigkeit in km/h, Vorzeichenloser 1 Byte Integer, Wertebereich 0 – 255

93

GPS-Positionsdaten Koordinaten Lat, Lon in Dezimalgraddarstellung mit 5 Stellen nach dem Komma bezogen auf den WGS84 Ellipsoid, HDOP [0.0..50.0] und Höhe in [m] gerundet ohne Nachkommastellen

Wenn keine gültige GPS-Position vorliegt, enthält die Ausgabe:

0.0, 0.0, 0.0, 0

48.08751, 8.44851, 1.0, 781

Endzeichen Meldung (ETX) ETX; 0x03 gemäss ASCII-Codetabelle

-


Seite 38

Checksumme Checksumme gemäss CCITT-CRC16 in Hex.

Siehe Element Checksumme.

24A3

Das folgende Beispiel enthält einen kompletten LSVA-Zusatznutzenprotokolldatensatz,

wie sie vom emotach ausgegeben wird:

LSVA2-Zusatznutzenprotokoll 1.0 153 2002031 2008.04.30, 13:08:00 8111.0 110.9 111, 111, 0.00, 2, 3, 5, 7, 4 12345 20 04 1

0, 0, BB CH 1111, 1240, 0, 0, 0, CH, 12345, 0, 0

93 48.08751, 8.44851, 1.0, 781 24A3

V nicht darstellbare Steuerzeichen

4.1.1.4 Deklaration über Mobiltelefon

Abbildung 17 – Kommunikationspartner Modemverbindung

Das emotach kann Deklarationsimages (Auftrag und Meldung) mit einer emotachDirect

über ein Mobiltelefon austauschen. Dieser kartenlose Austausch von Images erfolgt über

eine direkte FTP-Verbindung zwischen dem emotach und dem Image-Server der

emotachDirect, wo ein FTP-Server installiert werden kann. Das Mobiltelefon wird über BT

angeschlossen und wird als GPRS-Modem benutzt. Somit können Deklarationsauftrags-

Images aus dem FTP-Repository des Image-Servers geholt werden, sowie

Deklarationsmeldungs-Images im selben FTP-Repository abgelegt werden

Die Verbindung zwischen dem emotach und Mobiltelefon erfolgt über das Bluetooth Profil

DUN (siehe Kapitel 4.1.2.3). Die Verbindung zu emotachDirect wird über einen

Serviceprovider über das Internet aufgebaut.


Seite 39

Das emotach versucht eine DUN-Verbindung aufzubauen. Mittels dem APN (Access

Point Name) und ggf. Benutzernamen und Passwort wird über Bluetooth der Access

Point des Service Providers auf dem Mobiltelefon konfiguriert und anschliessend eine

Verbindung dorthin aufgebaut.

Darauf aufbauend wird eine PPP-Verbindung zum Access Point erstellt.

Die emotachDirect bietet auf dem Image Server einen SSH-FTP Server an, deren

Funktionalität dem SSH File Transfer Protocol http://tools.ietf.org/html/draft-ietf-secsh-

filexfer-13 entspricht.

Bei Verbindungsaufbau wird der FTP-Server nicht authentisiert. Der vom Server

übermittelte Public Key wird automatisch akzeptiert. Das emotach authentisiert sich beim

Server über Benutzernamen und Passwort.

Nach dem Verbindungsaufbau holt das emotach mit FTP GET die Imagedatei mit dem

Deklarationsauftrag vom Server. Anschliessend wird das Image verarbeitet und die

Statusmeldung und eine eventuelle Deklarationsmeldung mit PUT auf den Server geladen.

Ob eine Deklarationsmeldung erstellt wurde oder nicht, kann aus der Statusmeldung

herausgelesen werden (inklusive Fehlercode).

Namensgebung der Dateien

Die Imagedatei mit dem Deklarationsauftrag wird eindeutig benannt, damit

unterschiedliche emotach auf den gleichen Server zugreifen können. Das Schema für

den Namen ist wie folgt: [Stammnummer] + "_Dekl_Auftrag".

Hier ein Beispiel: 0123456789_Dekl_Auftrag.

Die Imagedatei mit der Deklarationsmeldung sieht wie folgt aus:

[Stammnummer] + "_Dekl_Meldung_" + [Zeitstempel]

Wobei der Zeitstempel aus je zwei Stellen für Jahr, Monat, Tag, Stunde, Minuten und

Sekunden besteht (yymmddhhmmss).

Beispiel: 0123456789_Dekl_Meldung_070529143056

Wenn anstatt der Deklarationsmeldung eine Statusmeldung (kein Image) mit einem

Fehlercode hochgeladen wird, wird die Datei wie folgt benannt:

[Stammnummer] + "_Status_" + [Zeitstempel]

Beispiel: 0123456789_Status_070529143056

Die Stammnummer besteht immer aus 10 Zeichen; ggf. werden Nullen vorangestellt.


Seite 40

eotach Application Mobile Phone Service Provider

Bluetooth activated

and visible or

already paired with

OBU

emotach API

create BTDUN connection

User

Create BTDUN Connection

create BTDUN connection

established

create GPRS connection


create connection

create PPP connection

connected (<local IP>, <remote IP>)


closedisconnect ppp

disconnect BTDUN

OK

done

deactivate BT

needed data:

- channel

- apn

- (username + password)

Image-Server

von emotachDirect

start

SSH-FTP-Server

open

File (Image)File (Image)

process File

response

close

response

close

FTP put File (Image)FTP put File (Image)

FTP get File (Image)

open SSH-FTP-Connection

FTP get File (Image)

pairing

PIN request

PIN

Sequenzdiagramm Verbindung über Mobiltelefon

Folgende Tabelle zeigt die Kommunikation im Detail. In der Tabelle wird jeweils vom Run-

Modus des emotach gesprochen. Dieser Run-Modus erkennt man am eingeschalteten

Display. Es gibt verschiedene Situation, wo dieser Run-Modus verlassen wird (zum

Beispiel, um in den Sleep-Zustand zu gehen).





Seite 41

Use Case Name Übertragung der Deklaration über ein Mobiltelefon


1 Keine Imageverarbeitung aktiv Deklaration über Mobiltelefon wird nicht gestartet. Anzeige einer entsprechenden Fehlermeldung am Display: Meldungsnummer 4081.

2 Es ist kein Dienst mit der gleichen BT-Adresse aber unterschiedlicher PIN gestartet und wartet auf einen Verbindungsaufbau

Deklaration über Mobiltelefon wird nicht gestartet. Entsprechende Fehlermeldung wird am Display angezeigt: Meldungsnummer 7144

3 Dienst noch nicht gestartet Deklaration über Mobiltelefon wird nicht gestartet. Anzeige einer Fehlermeldung am HMI (Meldungsnummer 7122)

4 Kein BT-DUN Verbindungsabbau aktiv

Deklaration über Mobiltelefon wird nicht gestartet. Anzeige einer Fehlermeldung am HMI (Meldungsnummer 7145)

Eingehende Informationen Information Bemerkung

1 BT-Konfiguration

Ergebnisse Ergebnis Bemerkung

1 Auftragsimage empfangen, verarbeitet und das Meldungsimage wieder zurückgesendet.


1 BT-DUN-Verbindung kann nicht aufgebaut werden (z.B. Gegenstelle bietet den DUN-Dienst nicht an oder Verbindungsabbruch gemäss Kapitel 4.1.2.2)


2 Fehler beim Aufbau der SSH-FTP-Verbindung (z.B. Gegenstelle schliesst Verbindung oder Verbindungsabbruch gemäss Kapitel 4.1.2.2) oder FTP-Server nicht vor Timeout (z.Z. 30s) gefunden


3 Fehler beim SSH-FTP-GET (z.B. Gegenstelle schliesst Verbindung, physikalischer Verbindungsabbruch gemäss Kapitel 4.1.2.2 , Dateiname falsch, Dateiname schreibgeschützt, Disk full, Übertragung nicht vor Timeout (z.Z. 5Min) beendet)


4 Imageauftrag kann nicht verarbeitet werden


5 Es wird keine Imagemeldung für den heruntergeladenen Auftrag erstellt. (Keine Ausnahme, nur Variante)


6 Fehler bei FTP-PUT der Deklarationsmeldung (z.B. Gegenstelle schliesst Verbindung oder Verbindungsabbruch gemäss Kapitel 4.1.2.2)


7 Fehler bei FTP-PUT der Statusmeldung (z.B. Gegenstelle schliesst Verbindung oder Verbindungsabbruch gemäss Kapitel 4.1.2.2)


8 Fahrzeug fährt an. Siehe Alternativablauf

9 emotach verlässt Run Modus. Siehe Alternativablauf

10 Abbruch durch den Benutzer Siehe Alternativablauf


1 BT-DUN-Verbindung mit Gerät aus Abfrage des PINs nur bei der ersten


Seite 42

der Konfiguration aufbauen. Paarung der Geräte mit der PIN aus der Konfiguration.

Verbindung zwischen zwei Geräten nötig oder wenn die PIN aus der Konfiguration nicht mehr mit der PIN der Paarung übereinstimmt (siehe Kapitel 4.1.2.2). Ist das Pairing nicht erfolgreich wird dieser Schritt wiederholt, bis das Pairing erfolgreich war (korrekte Authentifizierung durch korrekte PIN). Meldungsnummer 8220 (nach Aufbau der DUN-Verbindung)

2 SSH-FTP-Verbindung zum Server der emotachDirect aufbauen.

Meldungsnummer 8221 (nach Aufbau der SSH-FTP-Verbindung)

3 FTP-GET mit entsprechendem Dateinamen (siehe Kapitel 4.1.1.1).

Deklarationsauftrag wird heruntergeladen. Meldungsnummer 8286 (Nach Herunterladen des Imageauftrages)

4 Prüfung und Verarbeitung des Images und warten auf Meldungsimage oder Statusmeldung

Annahme: Meldungsimage wurde erstellt

5 FTP-PUT mit entsprechendem Dateinamen

Deklarationsmeldung und/oder Statusmeldung (siehe Kapitel 4.1.3) wird hochgeladen.

6 Löschen der heruntergeladenen Dateien auf dem emotach

7 Schliessen der SSH-FTP-Verbindung

Meldungsnummer 8225 (Nach dem Schliessen der SSH-FTP-Verbindung)

8 Schliessen der BT-DUN Verbindung Meldungsnummer 8224 (nach dem Schliessen der DUN-Verbindung)

Alternativabläufe

(1) BT-DUN-Verbindung kann nicht aufgebaut werden (z.B. Gegenstelle bietet den DUN-Dienst nicht an oder Verbindungsabbruch gemäss Kapitel 4.1.2.2)

Aktion Bemerkung

1.1 Fehlermeldung am HMI. Abbruch des Use Cases

Meldungsnummer: 7123

(2) Fehler beim Aufbau der SSH-FTP-Verbindung (z.B. Gegenstelle schliesst Verbindung oder Verbindungsabbruch gemäss Kapitel 4.1.2.2 oder FTP-Server nicht vor Timeout (z.Z. 30s) gefunden)

Aktion Bemerkung

2.1 Fehlermeldung am HMI. Meldungsnummer: 7126

2.2 Weiter mit 8

(3) Fehler beim SSH-FTP-GET (z.B. Gegenstelle schliesst Verbindung, physikalischer Verbindungsabbruch gemäss Kapitel 4.1.2.2 , Dateiname falsch, Dateiname schreibgeschützt, Disk full, Übertragung nicht vor Timeout (z.Z. 5Min) beendet).

Aktion Bemerkung

3.1 Fehlermeldung am HMI

Meldungsnummer: 7127

3.2 Weiter mit 7

(4) Imageauftrag kann nicht verarbeitet werden

Aktion Bemerkung

4.1 Statusmeldung gemäss Kapitel 4.1.3 mit entsprechendem Dateinamen

Fehlermeldungen der Imageverarbeitung resp.


Seite 43

erstellen Auftragsverarbeitung werden ausgegeben. Statusmeldung mit Fehlercode wird hochgeladen.

4.2 Weiter mit 5.

(5) Es existiert keine Imagemeldung für den heruntergeladenen Auftrag. (Keine Ausnahme, nur Variante)

Aktion Bemerkung

4.1 Statusmeldung gemäss Kapitel 4.1.3 mit entsprechendem Dateinamen erstellen.

Statusmeldung) mit Code für die erfolgreiche Verarbeitung wird hochgeladen.

4.2 Weiter mit 5.

(6) Fehler bei FTP-PUT der Deklarationsmeldung (z.B. Gegenstelle schliesst Verbindung oder physikalischer Verbindungsabbruch gemäss Kapitel 4.1.2.2

Aktion Bemerkung

5.1 Fehlermeldung am HMI. Meldungsnummer 7129

5.2 Weiter mit 6.

(7) Fehler bei FTP-PUT der Statusmeldung (z.B. Gegenstelle schliesst Verbindung oder Verbindungsabbruch gemäss Kapitel 4.1.2.2)

Aktion Bemerkung

5.1 Fehlermeldung am HMI. Meldungsnummer: 7130

5.2 Weiter mit 6.

(8) Fahrzeug fährt an (Fahrt gemäss Tacho)

Aktion Bemerkung


1...8.1 Fehlermeldung am HMI. Meldungsnummer: 7131

1...8.2 Bei Normalablauf 1 weiter mit 8. Bei Normalablauf 2 weiter mit 7. Bei Normalablauf 3 -5 weiter mit 6. Bei Normalablauf 6 - 8 weiter mit dem darauf folgenden Schritt im Normalablauf.

(9) emotach verlässt Run Modus. Aktion Bemerkung

Während des gesamten Ablaufs möglich

1...8.1 Bei Normalablauf 1 weiter mit 8. Bei Normalablauf 2 weiter mit 7. Bei Normalablauf 3 -5 weiter mit 6. Bei Normalablauf 6 - 8 weiter mit dem darauf folgenden Schritt im Normalablauf.

(10) Abbruch durch den Benutzer Aktion Bemerkung


Seite 44

(a) 1V5.1 Meldung am HMI Meldungsnummer 8291

(b) 1V5.2 Bei Normalablauf 1 weiter mit 8. Bei Normalablauf 2 weiter mit 7. Bei Normalablauf 3 -5 weiter mit 6.

Anmerkung: Ein Abbruch im Normalablauf 1 bewirkt keinen Abbruch des DUN-Verbindungsaufbau. Die DUN-Verbindung wird im Hintergrund weiter aufgebaut. Erst wenn die Verbindung aufgebaut ist wird sie sofort wieder geschlossen. Dieses Vorgehen ist notwendig, da ein Abbruch des Aufbaues der DUN-Verbindung zu Problemen auf der Gegenstelle führen kann.

4.1.2 Bluetooth Profile und Einstellungen

4.1.2.1 Bluetooth Version

Im emotach ist ein Bluetooth-Modul eingebaut, das eine Service- und Daten-Schnittstelle

zur Verfügung stellt. Dieses ist in der Version 1.2 ausgeführt und ermöglicht eine maximale

Übertragungsrate von 1Mbit/s.

4.1.2.2 Bluetooth Modi und Einstellungen

Der Protokollstack für Bluetooth bietet Funktionen zur Authentifizierung und

Verschlüsselung der Verbindung. Diese werden beim Verbindungsaufbau ausgehandelt.

Paarung / Authentisierung

Bei der ersten Verbindung von zwei Bluetooth-Geräten können diese zur gegenseitigen

Authentisierung miteinander gepaart werden. Dazu muss auf den beiden Geräten eine

übereinstimmende PIN vorhanden sein.

Diese PIN wird der emotach über ein Image mit der Konfiguration der BT-

Kommunikation zusammen mit der BT-Adresse der Gegenstelle mitgeteilt oder er wird

über das HMI eingegeben.

Bei der Paarung wird nach der PIN-Eingabe ein gemeinsamer Verbindungsschlüssel

vereinbart. Dieser Verbindungsschlüssel bleibt auf den Geräten für zukünftige

Verbindungen gespeichert, so dass die Paarung nicht erneut durchgeführt werden

muss.

Das emotach löscht den Verbindungsschlüsselwenn die Konfiguration nur temporär

gültig ist, die Konfiguration gelöscht wird oder die Basis (BT-Adresse und/oder PIN) für

das Pairing geändert wurde.

Die PIN für die Authentisierung darf zwischen 4 und 15 Stellen haben.

Es dürfen nur die Zahlen 0-9 benutzt werden.

Es ist möglich für die verschiedenen Diensten unterschiedliche PINs für die gleiche

Gegenstellen-Adresse (BT-Adresse) zu definieren. Wenn eine neue PIN verwendet

wird löscht das emotach die schon vorhandene Paarung, damit eine neue Paarung

stattfinden kann.

Um die Liste der gepaarten Geräte aktuell zu halten, werden einige Sonderfälle

berücksichtigt, die in den folgenden Unterkapiteln behandelt werden.


Seite 45

Verbindungsaufbau mit Dienst ohne konfigurierte BT-Adresse

Dieses Kapitel beschreibt das Verhalten beim Verbindungsaufbau eines Dienstes

mit einer BT-Konfiguration mit PIN aber ohne BT-Adresse.

Dieser Fall ist sowohl beim Verbindungsaufbau bei nur einem wartenden Dienst,

als auch beim Verbindungsaufbau zu 2 wartenden Diensten gültig.

Wird ein Dienst auf dem emotach gestartet, der in der Konfiguration keine BT-

Adresse enthält, so muss der User die Verbindung via HMI noch akzeptieren.

Szenario 1: zur Gegenstelle bestand noch keine Paarung, User akzeptiert die

Verbindung.

Beim Verbindungsaufbau muss eine Paarung durchgeführt werden. Ist die

Verbindung aufgebaut muss der User die Verbindung mit der Gegenstelle noch

bestätigen.

Bei positiver Bestätigung bleibt die aufgebaute BT Verbindung weiter bestehen,

und die BT-Adresse der Gegenstelle bleibt in der Pairingliste.

Szenario 2: zur Gegenstelle bestand noch keine Paarung, User akzeptiert die

Verbindung nicht.

Beim Verbindungsaufbau muss eine Paarung durchgeführt werden. Ist die

Verbindung aufgebaut muss der User die Verbindung mit der Gegenstelle noch

bestätigen.

Bei negativer Bestätigung wird die BT-Verbindung wieder abgebaut und die

Paarung mit der Gegenstelle wird wieder aus der Liste entfernt.

Szenario 3: zur Gegenstelle bestand bereits eine Paarung mit der gleichen PIN,

User akzeptiert die Verbindung nicht.

Da bereits eine Paarung mit der Gegenstelle mit der gleichen PIN vor dem

Verbindungsaufbau vorhanden war, wird beim Verbindungsaufbau keine Paarung

mehr durchgeführt. Der User muss die Verbindung nur Bestätigen.

Bei positiver Bestätigung bleibt die aufgebaute BT Verbindung weiter bestehen.

Bei negativer Bestätigung wird die aufgebaute BT Verbindung wieder geschlossen.

In beiden Fällen bleibt die Paarung mit der Gegenstelle erhalten.

Szenario 4: zur Gegenstelle bestand bereits eine Paarung mit einer anderen

PIN, User akzeptiert die Verbindung nicht.

Da die bereits bestehende Paarung mit der Gegenstelle mit einer unterschiedlichen

PIN durchgeführt wurde, wird vor dem Verbindungsaufbau die Paarung für die

Gegenstelle gelöscht. Für den Verbindungsaufbau muss eine neue Paarung

durchgeführt werden und der User muss die Verbindung bestätigen.

Bei positiver Bestätigung bleibt die aufgebaute BT Verbindung weiter bestehen, die

Paarung mit der Gegenstelle wird mit der neuen PIN in den Paarungszustanddaten

dem emotach eingetragen.

Bei negativer Bestätigung wird die aufgebaute BT Verbindung wieder geschlossen.

Die Paarung der Gegenstelle mit der alten PIN wird wieder in den

Applikationsdaten hergestellt.


Seite 46

Verbindungsaufbau eines wartenden Dienstes

Bemerkung: In den folgenden Szenarien wird das Pairing für den Fall behandelt in

dem nur ein Dienst auf den Verbindungsaufbau wartet.

Szenario 1:

Besteht schon eine Verbindung zu einem Dienst von einer Gegenstelle und wird

eine weitere zu dieser Gegenstelle aufgebaut werden, findet dies ohne neue

Paarung (mit der PIN des ersten Dienstes) statt.

Szenario 2:

Besteht schon eine Paarung mit einer anderen PIN zu der Gegenstelle, aber keine

aktive Verbindung zu dieser Gegenstelle, so löscht das emotach diese Paarung vor

dem Start der Verbindung.

Szenario 3:

Besteht schon eine Paarung mit der gleichen PIN zu der Gegenstelle, aber keine

aktive Verbindung zu dieser Gegenstelle, so findet keine neue Paarung statt. Mit

dieser Paarung wird dann die Verbindung aufgebaut.

Wird beim Prüfen der BT-Adressen nach dem Verbindungsaufbau erkannt, dass es

sich um die Verbindung zu einer falschen Gegenstelle handelt, wird die Verbindung

wieder abgebaut (siehe Kapitel 4.1.1) und die Liste der gepaarten Geräte wieder

auf den Zustand vor dem Verbindungsaufbau gebracht. Das Prüfen der Adresse

geht nicht länger als 200 ms.

Verbindungsaufbau bei mehreren Diensten

Vorbedingungen:

mehr als ein Dienst wartet auf den Aufbau der Verbindung durch die

Gegenstelle

in der Pairingliste gibt es noch keine BT-Adresse, die mit einer BT-Adresse

aus den Konfigurationen der auf einen Verbindungsaufbau wartenden Dienste

übereinstimmt

Die folgende Tabelle enthält die möglichen Kombinationen von BT-Adresse und

PIN bei zwei auf einen Verbindungsaufbau wartenden Diensten.

Eigenschaften der wartenden Dienste (DienstX enthält

in seiner zugehörigen Konfiguration die Adresse der

GegenstelleX und der PINX für die Paarung)

Behandlung

Konfiguration von Dienst1 und Dienst2 haben

unterschiedliche BT-Adresse und gleiche PIN

Siehe Szenario 1

Konfiguration von Dienst1 und Dienst2 haben

unterschiedliche BT-Adresse und unterschiedliche PIN

Siehe Szenario 2

Konfiguration von Dienst1 und Dienst2 hat gleiche BT-

Adresse und gleiche PIN

Siehe Szenario 3

Konfiguration von Dienst1 und Dienst2 hat gleiche BT-

Adresse und unterschiedliche PIN

Nicht möglich, Start des

zweiten Services wird mit

Fehlermeldung

abgebrochen.


Seite 47

Szenario 1: (Gegenstelle1 ≠ Gegenstelle2, PIN1 = PIN2 = PIN)

So lange beide Dienste auf den Verbindungsaufbau warten, wird Gegenstelle1

bzw. Gegenstelle2 nur dann verbunden, wenn sich diese mit der PIN

authentifizieren.

Bei allen anderen Verbindungsversuchen (z.B. Verbindungsversuch mit anderer

PIN oder anderer Gegenstelle) wird nicht reagiert, und weiter auf einen gültigen

Verbindungsaufbau gewartet.

Sobald der erste Dienst verbunden ist, und nur mehr ein Dienst auf den

Verbindungsaufbau wartet, gelten die normalen Verbindungsbedingungen für nur

einen wartenden Dienst.

Szenario 2: (Gegenstelle1 ≠ Gegenstelle2, PIN1 ≠ PIN2)

So lange beide Dienste auf den Verbindungsaufbau warten, wird Gegenstelle1 nur

dann verbunden, wenn sich diese mit PIN1 authentifiziert bzw. Gegenstelle2 nur

dann verbunden, wenn sich diese mit PIN2 authentifiziert.

Bei allen anderen Verbindungsversuchen (z.B. Verbindungsversuch mit anderer

PIN oder anderer Gegenstelle) wird nicht reagiert, und weiter auf einen gültigen

Verbindungsaufbau gewartet.

Sobald nur mehr ein Dienst auf den Verbindungsaufbau wartet, gelten die

Verbindungsbedingungen für nur einen wartenden Dienst.

Szenario 3: (Gegenstelle1 = Gegenstelle2, PIN1 = PIN2)

Es gelten dieselben Regeln wie für Szenario1.

Verschlüsselung

Zum Schutz der Datenübertragung zwischen den Bluetooth-Geräten kann eine

Verschlüsselung aktiviert werden.

Dazu wird von einem Gerät eine Aufforderung zum Wechsel in den verschlüsselten

Modus gesendet. Das andere Gerät bestätigt dies oder lehnt die Aufforderung ab und

beendet die Verbindung.

Sicherheitsmodus

Bluetooth kennt drei unterschiedliche Sicherheitsmodi: Modus 1, 2 und 3. Im Modus 1

werden keine Sicherheitsmechanismen wie Authentisierung und Verschlüsselung

verlangt, im Modus 2 werden Sicherheitsmechanismen abhängig von den Protokollen

auf höherer Ebene verlangt und im Modus 3 werden die Sicherheitsmechanismen für

alle Verbindungen verlangt.

Das emotach verwendet den Modus 2. Andere Geräte können so z.B. über SDP auf die

Service Records ohne Authentisierung und Verschlüsselung zugreifen. Wenn aber ein

Imageaustausch über BT-FTP erfolgt, müssen sich die beiden Geräte vorher

Authentisieren und Verschlüsselung benutzen.

Master/Slave Switch und parallele Verbindungen

Das emotach kann als Master mit maximal 6 Geräten verbunden sein. Zusätzlich kann

sie noch als Slave mit einem Gerät verbunden sein.

Das emotach kann zweimal als Slave je eine Verbindung halten (ergibt zusammen zwei

Verbindungen).

Wenn das emotach bereits zwei Verbindungen als Slave hält, kann von aussen keine

weitere Verbindung aufgebaut werden.

(Das emotach wäre im ersten Schritt dieser Verbindung Slave und sie kann nur für zwei

Verbindungen die Rolle des Slaves einnehmen.)


Seite 48

Da das emotach sich mit vielen Geräten verbinden kann (Geräte mit der

emotachDirect, Mobiltelefon und Navigationsgeräten), versucht sie immer Master einer

Verbindung zu sein.

Wenn die Gegenstellen also eine Verbindung zum emotach aufbauen, versucht das

emotach immer einen Master / Slave Switch durchzuführen um Master zu sein.

Die Geräte mit der emotachDirect, müssen den Master/Slave Switch erlauben.

Bei Geräten wie dem Mobiltelefon und dem Navigationsgerät ist unbekannt, ob sie

auch als Slave arbeiten. Daher kann es sein, dass neben einer Verbindung zu einem

der genannten Geräte keine weitere Verbindung aufgebaut werden kann.

Wenn es zwei Verbindungen gibt, bei denen das emotach die Slave Rolle einnimmt,

muss eine dieser Verbindungen geschlossen werden. Es wird immer die Deklaration

übers Mobiltelefon abgebrochen (sofern sie besteht) und nicht wieder automatisch

gestartet. Der Wiederaufbau muss manuell erfolgen, da bei dieser Verbindung immer

das Mobiltelefon in der Nähe sein muss und auch meist die Verbindung vom emotach

aufs Mobiltelefon an diesem bestätigt werden muss.

Es können mehrere unterschiedliche Anwendungsfälle parallel laufen (sofern sie sich

nicht behindern, wie oben beschrieben). Es können aber keine zwei gleichen

Anwendungsfälle parallel laufen.

Stromsparmodi: Hold, Sniff and Park

Das emotach unterstützt alle drei Stromsparmodi. Das emotach aktiviert von sich aus

jedoch nur den Sniff Modus.

Verbindungseigenschaften

Verbindungsaufbau:

Die Gegenstelle muss bei einem automatischen Start des Verbindungsaufbaus pollend

überprüfen, ob die OBU wieder bereit für einen Verbindungsaufbau ist. In der

Startphase ist nach dem Aktivieren des BT-Moduls der Dienst evtl. nicht sofort zur

Herstellung der Verbindung bereit. Die Gegenstelle muss in diesem Fall die

Dienstsuche nach einigen Sekunden wiederholen.

Verbindungsabbruch:

Eine bestehende BT-Verbindung wird grundsätzlich versucht zu halten. D.h. eine kurze

Unterbrechung der Übertragung auf der Luftschnittstelle in der Verbindungsschicht

bewirkt nicht unmittelbar einen Abbruch der Verbindung auf einer höheren Schicht.

Ein kurzzeitiger Unterbruch (beispielsweise durch das Verlassen der

Kommunikationszone) wird bis zu 20 Sekunden toleriert. D.h. wenn die

Kommunikationszone innerhalb dieser Zeit wieder erreicht wird, bleibt eine bestehende

Verbindung erhalten und die Übertragung kann fortgesetzt werden.

Eine länger andauernde physikalische Unterbrechung wird im Kapitel 4.1.1 als

Verbindungsabbruch bezeichnet.

Das emotach kann nicht unterscheiden, ob der Timeout aufgrund des Ablaufs eines

Timeouts oder aufgrund der physikalischen Unterbrechung (nach 20 Sekunden)

ausgelöst wurde.


Seite 49

4.1.2.3 Bluetooth Profile für die Kommunikation

Die in diesem Kapitel beschriebenen Profile stehen zur Verfügung.

L2CAP – Logical Link Control and Adaption Protocol

Allen Profilen liegt das L2CAP-Profil zugrunde. Es regelt und verwaltet die

Kommunikation mit den höheren Schichten.

GAP – Generic Access Profile

Bietet Grundfunktionen für jedes Bluetooth-Gerät, wie Sicherheits-, Sichtbarkeits- und

andere Modi. Dieses Profil bietet Möglichkeiten den User Friendly Name des Geräts zu

setzen, andere Geräte zu suchen und auch deren Namen zu erfragen.

Sobald auf das emotach die entsprechenden Parameter gesetzt wurden, wird der user

friendly name aus der emotach -ID, der Stammnummer und dem Kennzeichen

bestehen.

Der BT User Friendly Name kann nur durch das emotach selber innerhalb der

vorgegebenen Parameter verändert werden.

Das Format für den BT User Friendly Name sieht wie folgt aus:

OBU KS [aaaaaaaaaa] ST [bbbbbbbbbb] SR [ccccccc]

OBU:

Kennzeichnet das BT-Gerät als emotach.

KS:

Nach "KS" und einem Leerzeichen folgt das KontrollSchild des Fahrzeugs in eckigen

Klammern eingeschlossen. Vor Verarbeitung der ersten Deklaration hat das emotach

noch keine Stammdaten und damit auch kein Kennzeichen.

aaaaaaaaaa:

Kontrollschild, variable Länge, maximal 10 Stellen, optional

ST:

Nach "ST" und einem Leerzeichen folgt die Stammnummer der emotach in eckigen

Klammern eingeschlossen. Die Angabe dieses Wertes ist optional und wird nur im

emotach -Zustand "Bereit für Inbetriebnahme" oder "In Betrieb" angegeben.

bbbbbbbbbb:

Stammnummer, variable Länge, maximal 10 Stellen, Werte zwischen 1 und

4294967294, optional

SR:

Nach "SR" und einem Leerzeichen folgt die Seriennummer des emotach in eckigen

Klammern eingeschlossen. Die Angabe dieses Wertes ist zwingend.

ccccccc:

Seriennummer, feste Länge von 7 Stellen, Werte zwischen 2000000 und 2999999


Seite 50

Die Daten werden immer in der genannten Reihenfolge im Namen angegeben. Wenn

bestimmte Daten noch unbekannt sind (z.B. Kontrollschild und Stammnummer vor der

Inbetriebnahme) werden nur die bekannten Daten angezeigt. Auch die Kennungen

(z.B. KS) und eckigen Klammern der unbekannten Daten werden nicht angezeigt. Die

Seriennummer ist immer bekannt und muss daher immer im Namen enthalten sein.

Format ohne Kontrollschild und Stammnummer:

OBU SR [ccccccc]

Format ohne Kontrollschild:

OBU ST [bbbbbbbbbb] SR [ccccccc]

Format ohne Stammnummer:

OBU KS [aaaaaaaaaa] SR [ccccccc]

Beispiel für einen Namen mit allen Daten (Kennzeichen = ZH-522 802, Stammnummer

= 111222333, Seriennummer = 2002005):

OBU KS [ZH-522 802] ST [111222333] SR [2002005]

Beispiel für einen User Friendly Name ohne Kontrollschild und Stammnummer

(Seriennummer = 2002215):

OBU SR [2002215]

Wenn auf emotach keine Bluetoothkommunikation aktiviert wurde, ist Bluetooth im

Non-Discoverable und im Non-Connectable Mode. Bevor ein Server gestartet wird, wird

sie in Connectable und General-Discoverable Mode gesetzt.

SDP – Service Discovery Protocol

Wenn ein Bluetooth-Gerät Dienste anbietet, können diese in Service Records

beschrieben werden. In diesem Service Record steht beispielsweise eine

ServiceClassID, eine UUID für den angebotenen Dienst. Für Standarddienste gibt es

definierte ServiceClassIDs, für eigene Dienste können eigene IDs definiert werden. Im

Service Record steht auch, über welche Protokolle und Profile der Dienst erreichbar ist.

Bei SPP wird beispielsweise noch der Channel angegeben, unter dem der Dienst

erreichbar ist. Ein Name und eine Beschreibung des Dienstes können ebenfalls

angegeben werden.

Das SDP beschreibt, wie Dienste auf anderen Geräten gesucht werden können.

Für die auf dem emotach sind folgende ServiceClassIDs definiert:

FTP-Server für die Übertragung von Imagedateien:

d7776e68-bb5a-11db-a819-00300508d43a

SPP-Server für das Streaming von NMEA-Daten (Standardwert):

00001101-0000-1000-8000-00805f9b34fb

SPP-Server für das Streaming vom LSVA-Zusatznutzenprotokoll:

77445e66-d90f-1000-abb2-00300508d43a


Seite 51

Wichtig!

Vor jedem Verbindungsaufbau muss der aktuelle Channel des Dienstes abgefragt werden,

da die Channel der Dienste nicht fix sind. Die Channel werden in Abhängigkeit der

Startreihenfolge vergeben.

SPP – Serial Port Profile

Das SPP nutzt Bluetooth als eine Art Kabelersatz. Es wird eine herkömmliche serielle

Verbindung simuliert, die das RFCOMM-Protokoll verwendet.

DUN – Dial-up Networking Profile

Das DUN nutzt das Serial Port Profile zur Kommunikation. Es wird eine

Modemverbindung erstellt. Dazu werden AT-Kommandos über die zugrunde liegende

serielle Verbindung gesendet und von der Gegenstelle interpretiert. Darauf lässt sich

eine PPP-Verbindung aufbauen, über die eine TCP/IP-Verbindung zur Verfügung steht.

GOEP – General Object Exchange Profile

Das GOEP ist ein allgemeines Austauschprofil für Daten. Es ist unabhängig von der

zugrunde liegenden Übertragungsschicht. Deshalb kann es sowohl auf SPP, als auch

TCP/IP aufsetzen und bietet eine Client-Server-Beziehung zum Austausch von Daten.

Darauf aufsetzend ist das Profil OBEX-FTP definiert. Es ermöglicht die Übertragung

von Dateien zwischen zwei Geräten.

Benutzung des File Transfer Profile (FTP) für das emotach

Die Übertragung der LSVA-Imagedateien und die Übertragung des SW-Updates erfolgt

über das BT File Transfer Profile (FTP). Auf emotach läuft dabei ein FTP-Server. FTP

wird mit den in diesem Kapitel beschriebenen Einschränkungen benutzt. Damit ist es

nicht möglich, dass sich ein BT-FTP-Client einer Standardapplikation mit dem emotach

verbindet.

Verbindungsaufbau:

Auf dem emotach läuft der FTP-Server. Auf dem emotach gibt es auch einen

entsprechenden Service Record mit einer bestimmten ServiceClassID (siehe Profil

SDP). Die Gegenstelle ist somit ein Client. Der Client kann mit Hilfe des Service

Records die Kanalnummer ermitteln und dann eine SPP-Verbindung zum Server

aufbauen. Anschliessend schickt er eine CONNECT Anfrage an den Server. Die

Header des Befehls werden auf dem Server nicht ausgewertet. Insbesondere wird ein

Target Header, der auf Folder Browsing gesetzt ist, nicht ausgewertet. Es wird dem

Client nie gezeigt, welche Dateien sich auf dem emotach befinden.

Die CONNECT Anfrage wird im Erfolgsfall mit dem Response Code 0xA0 beantwortet.

Übertragung von Dateien

Nach dem Verbindungsaufbau werden Dateien ausgetauscht. Der Client muss dafür

PUT und GET Anfragen senden. Die Abfolge der Übertragung der Dateien (inkl.

Dateinamen), ist in den entsprechenden Use Cases im Kapitel 4.1.1 beschrieben.

PUT-Operation:

Die PUT-Anfrage des Clients muss den Name Header beinhalten, wobei der Name

dem im Kapitel 4.1.1.1 genannten Namen entsprechen muss. Zusätzlich muss der


Seite 52

Length Header gesetzt sein. Die Daten werden im Body/End of Body Header

übermittelt.

Es ist nur möglich Dateien bis zur einer bestimmten Grösse auf das emotach zu

übertragen. Wenn die Angabe im Length Header diese Grösse bereits überschreitet,

wird die Anfrage abgelehnt (Code 0xC3, "Forbidden"). Der Empfang der Datei wird

immer abgebrochen, wenn die im Length Header angegebene Grösse erreicht ist.

Der Server sendet eine PUT Antwort auf die Anfrage. Diese Antwort enthält den

Response Code 0x90 ("Continue") oder 0xA0 ("OK, Success") bei Erfolg. Im Fehlerfall

ist der Response Code 0xC3 ("Forbidden"), wenn der Server nicht auf eine PUT

Anfrage mit dem entsprechenden Namen wartet oder Name und/oder Length Header

nicht definiert sind oder der Length Header auf 0 gesetzt wurde. Wenn bei der

Bearbeitung der Anfrage ein interner Fehler aufgetreten ist, wird der Response Code

auf 0xD0 ("Internal Server Error") gesetzt.

GET-Operation:

Der Client kann mit einer GET-Anforderung die Datei anfragen. Dafür muss er den

Name Header entsprechend setzen.

Der Server sendet daraufhin eine GET Antwort, mit Response Code, Name Header

und im Erfolgsfall auch die angeforderte Datei im Body/End of Body Header. Im

Erfolgsfall ist der Response Code 0x90 ("Continue") oder 0xA0 ("OK, Success"). Im

Fehlerfall ist der Response Code 0xC4 ("Not Found"), wenn der Server nicht auf eine

GET Anfrage mit entsprechendem Namen wartet. Der Response Code ist 0xC0 ("Bad

Request"), wenn die GET Anfrage keinen Name im Header enthält.

Empfohlenes Verhalten der Gegenstelle bei PUT und GET Anfragen:

Eine PUT oder GET Anfrage an den Server auf das emotach ist immer nur dann

erfolgreich, wenn das emotach bereit ist eine Datei zu senden oder zu empfangen.

Wenn das emotach also z.B. noch damit beschäftigt ist, ein Image auszuwerten, kann

sie noch keine Statusmeldung zurückschicken.

Es wird daher empfohlen, dass die Gegenseite bei jeder Anfrage pollt. Das bedeutet,

dass sie innerhalb kurzer Abstände Anfragen an das emotach sendet, bis eine

erfolgreich ist, ein Fehlercode empfangen wurde oder die maximale Wartezeit der

Gegenstelle erreicht wurde (Timeout). Dies wird sowohl für die PUT als auch GET

Anfragen empfohlen (auch für die erste Anfrage nach einem Verbindungsaufbau).

Da die Verarbeitungszeiten verschiedener Aufträge unterschiedlich sind, muss die

Gegenseite berücksichtigen, dass die Dauer für die gepollt werden muss bis eine

Antwort bereitgestellt wird, ebenfalls variieren kann.

In Ausnahmesituationen kann die Verarbeitung bis zu 90 Sekunden dauern. Im

Normalfall ist mit einer Verarbeitungszeit von weniger als 10 Sekunden zu rechnen.

Ordner zum Datenaustausch:

Das emotach hat nur einen Ordner zur Verfügung, um dort die Dateien, die über BT-

FTP ausgetauscht werden, zu speichern. In diesem Ordner dürfen keine Unterordner

angelegt werden. Die SETPATH Anfrage wird vom Server auf das emotach nicht

unterstützt.

4.1.3 Statusmeldung LSVA Datenimages

Bei der Imageübertragung werden Statusmeldungen für die Übertragung von LSVA-

Datenimages in einer Datei vom emotach an die Gegenstelle übertragen.


Seite 53

Diese Statusmeldung besteht immer aus der Seriennummer und aus der Stammnummer,

wenn diese bereits gesetzt wurde. Das Ziel einer solchen Statusmeldung ist, dem Client

mitzuteilen, ob überhaupt eine Image-Rückmeldung kommt und falls nicht, mit welchen

Fehlern das emotach abgebrochen hat.

Wenn das Image gelesen werden konnte, werden die Aufträge mit ihren IDs aufgelistet.

Wenn bei der Verarbeitung eines Auftrags kein Fehler auftrat, steht nur die ID zwischen den

<auftrag> Tags.

Wenn ein Fehler auftrat, wird der Fehler mit ID und mit dem Text der Fehlermeldung (Zeile

1-5, jeweils mit Leerzeichen getrennt), die am HMI angezeigt wird, angegeben.

Die Sprache der Fehlermeldung entspricht der fürs HMI auf das emotach konfigurierten

Sprache.

Wenn das Image als Ganzes nicht gelesen werden konnte, weil z.B. die Header Signatur

fehlerhaft ist, wird der Fehler direkt angegeben und die <auftrag> Tags entfallen.

Die Statusmeldung enthält immer den Tag <imagemeldungfollows>, der angibt, ob nach der

Statusmeldung noch eine Imagemeldung zur Verfügung gestellt wird.

Die Statusmeldung ist im XML-Format mit der Zeichenkodierung ISO-8859-1 (entspricht

LATIN-1).

Hier die Definition der Statusmeldung:

<?xml version=“1.0“ encoding=“iso-8859-1“?>

<obuImage>

<stammnummer>[stammnummer]</stammnummer>

<seriennummer>[seriennummer]</seriennummer>

<error>

<id>[ImageErrorId]</id>

<txt>[Fehlermeldung]</txt>

</error>

<auftrag>

<id>[Auftrag1ID]</id>


</auftrag>

<auftrag>


<error>

<id>[ErrorId1]</id>


</error>

</auftrag>

<auftrag>


<error>

<id>[ErrorId2]</id>


</error>

</auftrag>

<imagemeldungfollows>“FALSE“</imagemeldungfollows>

</obuImage>


Seite 54

Beispiel für eine Statusmeldung für ein Image mit 3 Aufträgen, die alle erfolgreich

ausgeführt werden konnten:


<obuImage>

<stammnummer>34567</stammnummer>

<seriennummer>678967</seriennummer>

<auftrag>

<id>0x0102</id>

</auftrag>

<auftrag>

<id>0x0103</id>

</auftrag>

<auftrag>

<id>0x0117</id>

</auftrag>


</obuImage>

Hier ein Beispiel für eine Statusmeldung für ein Image mit 3 Aufträgen, wobei der erste

erfolgreich verarbeitet wurde, der zweite und dritte jeweils mit einem Fehler abgebrochen

wurden.

Beim ersten Fehlerfall (2. Auftrag) wird ein Fehlertext mitgeliefert, im zweiten Fehlerfall (3.

Auftrag) wird kein Fehlertext mitgeliefert.


<obuImage>



<auftrag>

<id>0x0102</id>

</auftrag>

<auftrag>

<id>0x0103</id>

<error>

<id>17</id>

<txt>Auftrags CRC ist nicht korrekt</txt>

</error>

</auftrag>

<auftrag>

<id>0x0117</id>

<error>

<id>86</id>

</error>

</auftrag>


</obuImage>

Beispiel für fehlerhafte Headersignatur im Image:

4.2 Technische Beschreibung Webservice emotachDirect

Seite 55


<obuImage>



<error>

<id>4711</id>

<txt>HeaderSignatur nicht korrekt</txt>

</error>

<imagemeldungfollows>”FALSE”</imagemeldungfollows>

</obuImage>


emotachDirect stellt zwei Funktionen via ein Web-Service (SOAP) zur Verfügung.

Die Methode „GetEmptyImage“ erlaubt den Bezug des letzten gültigen

Deklarationsauftrag-Images für ein bestimmtes Fahrzeug. Die Methode „PutDeklImage“

ermöglicht es, ein Deklarationsmeldung-Image in die emotachDirect Datenbank zu

übertragen.

Folgende Rahmenbedingungen gelten:

• Als Protokoll wird HTTPS verwendet.

• Für alle Funktionen wird eine Authentifizierung benötigt via Basic-Authentication

(Username, Passwort).

4.2.1 GetEmptyImage

Beschreibung

Liest das letzte gültige Deklarationsauftrag-Image für ein Fahrzeug aus der emotachDirect

Datenbank.

Parameter IN

Stammnummer Stammnummer des Fahrzeugs als unsigned int

Parameter OUT

GetEmptyImageResult Abfragestatus

Image Deklarationsauftrag-Image als Byte64-Array (vorhanden

wenn GetEmptyImageResult OKAY ist)

Abfragestatus

Status Beschreibung

OKAY Die Operation wurde fehlerfrei durchgeführt.

NO_IMAGE Für die angegebene Stammnummer ist kein Deklarationsauftrag-

Image in der emotachDirect Datenbank vorhanden.

FZ_UNKNOWN Die angegebene Stammnummer existiert nicht in der emotachDirect

Datenbank.

NOT_EDEKL emotachDirect ist nicht für die elektronische Deklaration konfiguriert.

ERROR Es trat ein unerwarteter Fehler auf.


Seite 56

4.2.2 PutDeklImage

Beschreibung

Schreibt das Image einer Deklarationsmeldung in die emotachDirect Datenbank.

Parameter IN

Image Deklarationsmeldung-Image als Byte64-Array

Parameter OUT

PutDeklImageResult Abfragestatus


Seite 57

Abfragestatus

Status Beschreibung

OKAY Die Operation wurde fehlerfrei durchgeführt.

FZ_UNKNOWN Die angegebene Stammnummer existiert nicht in der

emotachDirect Datenbank. Das Image konnte nicht

gespeichert werden.

NOT_EDEKL emotachDirect ist nicht für die elektronische Deklaration

konfiguriert. Das Image konnte nicht gespeichert werden.

IMG_ERROR Das übermittelte Image ist ungültig.

IMG_SIZE_ERROR Die Grösse des übermittelten Images ist ungültig.

IMG_ERR_NO_DEKL Das übermittelte Image ist keine Deklarationsmeldung.

IMG_ERROR_CRC Der CRC des übermittelten Images ist falsch.

ERROR Es trat ein unerwarteter Fehler auf.

WRONG_WRITE_DATE Dieser Wert wird in der aktuellen Version nicht verwendet.

4.2.3 WSDL-Spezifikation

Die nachfolgende WSDL-Spezifikation enthält die komplette Beschreibung des Web-

Services. Dieses WSDL kann auf der CD im Ordner WSDL unter dem Dateinamen

emotachDirect.wsdl gefunden werden. Die Default-Location im Tag soap-adress im

Paramater location muss bei der Verwendung dieses WSDLs an die eigene Umgebung

angepasst werden.

<?xml version=“1.0“ encoding=“utf-8“ ?>

<definitions

xmlns:http=“http://schemas.xmlsoap.org/wsdl/http/“ xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“ xmlns:s=“http://www.w3.org/2001/XMLSchema“ xmlns:tns=“http://www.siemens.ch/lsva/fzhsw“ xmlns:soapenc=“http://schemas.xmlsoap.org/soap/encoding/“ xmlns:tm=“http://microsoft.com/wsdl/mime/textMatching/“ xmlns:mime=“http://schemas.xmlsoap.org/wsdl/mime/“ targetNamespace=“http://www.siemens.ch/lsva/fzhsw“ xmlns=“http://schemas.xmlsoap.org/wsdl/“> <types>

<s:schema elementFormDefault=”qualified” targetNamespace=”http://www.siemens.ch/lsva/fzhsw”>

<s:element name=”GetEmptyImage”> <s:complexType>

<s:sequence>

<s:element minOccurs=”1” maxOccurs=”1” name=”Stammnummer” type=”s:unsignedInt” />

</s:sequence> </s:complexType> </s:element>

<s:element name=”GetEmptyImageResponse”> <s:complexType>

<s:sequence>

<s:element minOccurs=”1” maxOccurs=”1” name=”GetEmptyImageResult” type=”tns:IrDeklStatus” />

<s:element minOccurs=”0” maxOccurs=”1” name=”Image” type=”s:base64Binary” />

</s:sequence>

</s:complexType>

</s:element>

<s:simpleType name=”IrDeklStatus”> <s:restriction base=”s:string”> <s:enumeration value=”OKAY” /> <s:enumeration value=”NO_IMAGE” />

<s:enumeration value=”FZ_UNKNOWN” /> <s:enumeration value=”NOT_EDEKL” />

<s:enumeration value=”IMG_ERROR” /> <s:enumeration value=”IMG_ERR_NO_DEKL” /> <s:enumeration value=”IMG_SIZE_ERROR” />

<s:enumeration value=”WRONG_WRITE_DATE” /> <s:enumeration value=”IMG_ERROR_CRC” />


Seite 58

<s:enumeration value=”ERROR” /> </s:restriction> </s:simpleType>

<s:element name=”PutDeklImage”> <s:complexType>

<s:sequence>

<s:element minOccurs=”0” maxOccurs=”1” name=”Image” type=”s:base64Binary” />

</s:sequence>

</s:complexType>

</s:element>

<s:element name=”PutDeklImageResponse”> <s:complexType>

<s:sequence>

<s:element minOccurs=”1” maxOccurs=”1” name=”PutDeklImageResult” type=”tns:IrDeklStatus” /> </s:sequence>

</s:complexType>

</s:element>

</s:schema>

</types>

<message name=”GetEmptyImageSoapIn”> <part name=”parameters” element=”tns:GetEmptyImage” />

</message> <message name=”GetEmptyImageSoapOut”> <part name=”parameters” element=”tns:GetEmptyImageResponse” />

</message> <message name=”PutDeklImageSoapIn”> <part name=”parameters” element=”tns:PutDeklImage” />

</message> <message name=”PutDeklImageSoapOut”> <part name=”parameters” element=”tns:PutDeklImageResponse” />

</message>

<portType name=”IrDeklarationSoap”> <operation name=”GetEmptyImage”> <documentation>Get a declaration request from the FZHSW database</documentation> <input message=”tns:GetEmptyImageSoapIn” /> <output message=”tns:GetEmptyImageSoapOut” /> </operation>

<operation name=”PutDeklImage”> <documentation>Put a declaration response into the FZHSW database</documentation> <input message=”tns:PutDeklImageSoapIn” /> <output message=”tns:PutDeklImageSoapOut” /> </operation>

</portType>

<binding name=”IrDeklarationSoap” type=”tns:IrDeklarationSoap”> <soap:binding transport=http://schemas.xmlsoap.org/soap/http style=”document” /> <operation name=”GetEmptyImage”> <soap:operation

soapAction=http://www.siemens.ch/lsva/fzhsw/GetEmptyImage style=”document” /> <input>

<soap:body use=”literal” /> </input>

<output>

<soap:body use=”literal” /> </output>

</operation>

<operation name=”PutDeklImage”> <soap:operation

soapAction=”http://www.siemens.ch/lsva/fzhsw/PutDeklImage” style=”document” />

<input>

<soap:body use=”literal” /> </input>

<output>

<soap:body use=”literal” /> </output>

</operation>

</binding>

<service name=”IrDeklaration”>

4.3 Verwendung von LSVA-Chipkarten

Seite 59

<documentation>Fzhsw Web Service Interface</documentation> <port name=”IrDeklarationSoap” binding=”tns:IrDeklarationSoap”> <soap:address

location=”https://localhost/IrDeklaration.asmx” /> </port>

</service>

</definitions>


Für die Deklaration können auch LSVA-Chipkarten verwendet werden. Dieses Kapitel

beschreibt den Aufbau der LSVA-Chipkarten und deren Inhalt.

4.3.1 Funktionale Beschreibung der LSVA-Chipkarte

Die Struktur sowie der Inhalt der Images ist unabhängig vom für die Übertragung

verwendeten Datenkanal / -medium.

Jede LSVA-Chipkarte enthält einen Chipkartenheader genannten Datenblock mit

Informationen zur Chipkarte. Dieser ist unabhängig vom allenfalls auf der Chipkarte

gespeicherten Image (wobei immer maximal EIN Image pro Chipkarte erlaubt ist).

Im System LSVA werden nur Chipkarten mit klar definierten Eigenschaften verwendet.

Damit Chipkarten mit den definierten Eigenschaften automatisch erkannt und verarbeitet

werden können, werden chipkartenspezifische Informationen elektronisch auf dem Chip

gespeichert. Diese den einzelnen physischen Datenträger beschreibenden Informationen

stehen in einem vom Image unabhängigen Datenblock, dem Chipkartenheader.

Der Chipkartenheader wird bei der Herstellung der Chipkarte geschrieben und darf nicht

gelöscht oder überschrieben werden.

Der Chipkartenheader hat immer dieselbe feste Grösse.

Folgende funktionalen Elemente sind im Chipkartenheader enthalten:

Information zur Speichergrösse der Karte

Eindeutige Identifikation der Chipkarte

Information zum Aussehen der Chipkarte

Information zum Zeitpunkt der Erstellung der Chipkarte

4.3.2 Technische Beschreibung

Die Byte-Reihenfolge (Byte Order) im Chipkartenheader und im Image ist Little Endian. Es

wird also das niedrigstwertige Byte an der niedrigsten Speicheradresse ablegen.

Die in den nachfolgenden Tabellen aufgeführten Integer-Werte sind alle vorzeichenlos und

positiv.

Auf einer Chipkarte ist das Image unmittelbar nach dem Chipkartenheader (Adressen

0x0000 – 0x003F) platziert, d.h. das Image beginnt an der Adresse 0x0040 der Chipkarte.

Das Image hat eine variable Grösse, welche im Datenelement „Groesse“ (siehe

Kap.4.3.2.2) des Images angegeben ist.

4.3.2.1 Chipkartenheader

Die in dieser Tabelle angegebenen Adressen beziehen sich auf die Chipkarte.


Seite 60

Start / End

Adresse

(Hex)

Daten

Länge

(Byte)

Datenelement Bezeichnung

Beschreibung / Funktion

Wertebereiche

0000 – 0000 1 ATR_H1 = INT1 Pseudo ATR:

Codiert nach ISO7816. Definiert primär die

Grösse der verwendeten Chipkarte (z.B. 8, 16,

32, 64 oder 128 Kbyte). Detailaufbau s. unten.

Die ATR_H2 ENUM Werte bezeichnen die

Kartengrösse in kByte und jeweils in

Klammern den maximalen Write Zyklus in

Byte, siehe auch Detailaufbau weiter unten.

0001 – 0001 1 ATR_H2 = INT1 ENUM

„8KB (32B)“ (59),

„16KB (32B)“ (67),

„32KB (32B)“ (75),

„64KB (32B)“ (83),

„8KB (64B)“ (187),

„16KB (64B)“ (195),

„32KB (64B)“ (203),

„64KB (64B)“ (211),

0002 – 0002 1 ATR_H3 = INT1

0003 – 0003 1 ATR_H4 = INT1

0004 – 0007 4 CK_Nr = INT4 Chipkarten-Nummer:

(0 .. 4‘294‘967‘295)

Wert 0 = undefiniert

0008 – 0009 2 Layout = INT2 CK-Layout:

(0 V 65‘535)


Wert 100 = Deklaration

000A – 0015 12 -- nicht dokumentiert

0016 – 0019 4 Stammnummer = INT4, Stammnummer:

(0 .. 4‘294‘967‘295)


001A – 003F 38 -- nicht dokumentiert

Detail-Aufbau des Pseudo-ATR:

Die folgende Tabelle zeigt den Detail-Aufbau des Pseude-ATR:

ATR H1

b7 b6 b5 b4 b3 b2 b1 b0

1 0 0 0 0 0 0 0

Protokolltyp: 1000 = I2C-Bus RFU Nach ISO definiert

ATR H2

b7 b6 b5 b4 b3 b2 b1 b0

0=32Byte

1=64Byte

x x x x 0 1 1

max. Write

Zyklus

0111 = 8Kbyte, 1000 = 16Kbyte, 1001 = 32Kbyte V Länge der Dateneinheiten in Bits: 2

=> 8bit Datenlänge = 011

ATR H3

b7 b6 b5 b4 b3 b2 b1 b0

0 0 0 1 0 0 0 0


Seite 61

ISO 7816-4

ATR H4

b7 b6 b5 b4 b3 b2 b1 b0

0 0 0 0 0 0 0 0

0: DIR nicht

vorhanden

kein Zeiger auf DIR

4.3.2.2 Image

Die in dieser Tabelle angegebenen Adressen beziehen sich auf das Image:

Start / End

Adresse

(Hex)

Daten

Länge

(Byte)

Datenelement Bezeichnung

Beschreibung / Funktion

Wertebereiche

0000 – 0001 2 Erkennung = INT2 Erkennung: Wert hex 0200 = dezimal 512

(Kennzeichnet das Image als LSVA-II Image)

0002 – 0005 4 -- Nicht dokumentiert

0006 – 0009 4 Groesse = INT4 Groesse: Wertebereich 0 .. 4‘294‘967‘295

Die Groesse beinhaltet die Gesamtgrösse des

aktuellen Images in Bytes

000A – 008C 131 -- Nicht dokumentiert

008D – 008D 1 EmpfaengerTyp = INT1 Dient zur Kennzeichnung des Empfängertyps im

Image-Header

Wert 0= IS-LSVA

Werte 3 und 8 = OBU

Wert 4 = FZHSW

Übrige Werte = nicht dokumentiert

Wertebereich 0 .. 255

008E – 0091 4 -- Nicht dokumentiert

0092 – 0095 4 EmpfaengerID2 = INT4 EmpfängerID2:

bei einem Auftrag an die OBU enthält dieses Feld die

Stammnummer oder den Wert 0

Wertebereich 0 .. 4‘294‘967‘295

0096 – 0096 1 AbsenderTyp = INT1 Dient zur Kennzeichnung des Absenderstyps im

Image-Header

Wert 0= IS-LSVA

Werte 3 und 8 = emotach

Wert 4 = emotachDirect

Übrige Werte = nicht dokumentiert

Wertebereich 0 .. 255

0097 – 009A 4 -- Nicht dokumentiert

009B – 009E 4 AbsenderID2 = INT4 Absender ID2:

bei einer Meldung der OBU enthält dieses Feld die

Stammnummer

Wertebereich 0 .. 4‘294‘967‘295


Seite 62

009F – 058F 1275 -- Nicht dokumentiert

0590 - Ab hier Aufträge bzw. Meldungen

4.3.3 Eingesetzte Chipkarten

Im System LSVA werden Standardspeicherchipkarten gemäss ISO 7816-1 und ISO 7816-2

mit einer Speicherkapazität zwischen 8kByte und 64kByte eingesetzt, welche mit Chips der

Hersteller Atmel oder Microchip bestückt sind.

Es handelt sich um synchrone I2C Speicherkarten ohne weitere Logik.

4.3.4 Vorschriften

Folgende Vorschriften beim Beschreiben und Speichern von LSVA-Chipkarten müssen

eingehalten werden.

4.3.4.1 Beschreiben von LSVA-Chipkarten

Der Chipkartenheader darf nicht verändert werden!

Das zu speichernde Image darf nur auf eine dafür vorgesehene Chipkarte geschrieben

werden. Für die Deklaration mittels Fahrzeughalter-Software ist ausschliesslich die

Chipkarte Deklaration vorgesehen. Die Chipkarte kann über das Datenelement Layout

im Chipkartenheader elektronisch identifiziert werden.

Der Adressat eines Images muss zu der auf der Chipkarte aufgedruckten

Stammnummer passen. Die Stammnummer identifiziert ein Fahrzeug im System LSVA

eindeutig. Der die aufgedruckte Stammnummer kann über das Datenelement

Stammnummer im Chipkartenheader elektronisch identifiziert werden.

Vor dem Beschreiben einer Chipkarte muss sichergestellt werden, dass das Image auf

der Chipkarte Platz hat.

4.3.4.2 Speichern von LSVA-Chipkarten

Es darf nur das Images einer Chipkarte gespeichert werden. Der Chipkartenheader

darf also nicht (mit-)gespeichert werden.

5.1 Auflistung und Beschreibung des Lieferumfangs

Seite 63

5 Entwicklungskit

5.1 Auflistung und Beschreibung des Lieferumfangs

Der Lieferumfang des Entwicklungskits beinhaltet folgende Komponenten:

emotach inkl. Benutzerhandbuch

CD emotachDirect

CD Entwicklungskit

Benutzerhandbuch BT-Services (PDF)

Benutzerhandbuch emotach (PDF)

Datenbank-Backup für emotachDirect (inkl. Images)

Bluetooth-Demoprogramm für den Imageaustausch

Entwicklungsumgebung inkl. Sourcedateien für Bluetooth-Demoprogramm

1 Set Chipkarten

2x Deklaration

2x Private Anhängerliste

2x Private Auslesung

2x Private Konfiguration

4x Anhänger/Auflieger

1 Gerätehalter

5.2 emotach Montage

5.2.1 Abdeckung Anschlussfeld demontieren

Abbildung 18 – Abdeckung Anschlussfeld demontieren

5 Entwicklungskit

Seite 64

Hinweis

Die Abdeckung des Anschlussfeldes ist nur aufgesteckt, nicht geschraubt. Die

Befestigungsschrauben befinden sich im mitgelieferten Zubehörbeutel.

Abdeckung Anschlussfeld des emotach abnehmen:

1. Abdeckung Anschlussfeld leicht nach aussen ziehen (Pos. 1),

2. dann nach oben abnehmen (Pos. 2).

5.2.2 Anschlusskabel anschliessen

Abbildung 19 – Anschlusskabel an emotach anschliessen

1. Anschlusskabel (Pos. 1) in Stecker A (Pos. 2) des Anschlussfeldes des emotach

einstecken.

Hinweis

Achten Sie darauf, dass der Stecker korrekt einrastet und damit ein dauerhafter Kontakt

gewährleistet ist.

Wichtig!

Die Batterie und der Akku dürfen nicht herausgenommen werden, da das emotach

ansonsten in einen Fehlerzustand geht.

5.3 Strom- und Signalanschluss

Das folgende Schema zeigt den elektrischen Anschluss an die emotach.

5.3 Strom- und Signalanschluss

Seite 65

Abbildung 20 – Übersicht über den elektrischen Anschluss an die emotach.

Der Stromanschluss des emotach soll für das Entwicklungskit folgendermassen

angeschlossen werden:

Masse Minus (31).

Dauerstromversorgung +9 VV+32 V DC (30).

Plus geschaltet via Zündschloss (15). Der Anschluss kann als Vereinfachung an den

Dauerstrom (grau) geschlossen werden.

v-Impulsausgang. Das Signal wird für die Simulation einer Fahrt benötigt. Der

Anschluss an ein Signal gemäss Kapitel 5.3.1 wird empfohlen.

Anhängererkennung: Der Anschluss wird für das Entwicklungskit nicht benötigt.

Grenztaste: Der Anschluss wird für das Entwicklungskit nicht benötigt.

Wichtig!

Bitte belassen Sie das emotach während dem Gebrauch wenn möglich am Strom, damit

die Batterie nicht unnötig belastet wird. Ein Batteriewechsel kann nicht selbst durchgeführt

werden!

5.3.1 emotach Tachosimulation (V-Signal)

Der Wegimpulsausgang des Tachographen wird zur Distanzerfassung verwendet.

Der Eingang ist für Wegimpulssignale aus dem Tachographen ausgelegt.

Die Vorgaben für den Signaleingang werden eingehalten:

Rechtecksignal:

Vlow = 0VV3V

Vhigh = 4.5VV36V

5 Entwicklungskit

Seite 66

Impulsweite:

T > 0.1msec

Frequenz:

fmax = 3kHz

Eingangswiderstand:

R > 10 kΩ

5.4 Erzeugungen von Testdaten

Wenn Sie mehr Logeinträge benötigen, können diese selbst erzeugt werden.

Folgendermassen werden neue Logeinträge erzeugt:

Der Logeintrag Status Gerät wird jede Nacht (wenn Gerät in Betrieb) erzeugt oder

wenn das emotach an einem neuen Tag in Betrieb geht.

Der Logeintrag Periodenende wird beim ersten Logeintrag Status Gerät nach

einem Montatswechsel erzeugt.

Der Logeintrag Deklaration wird nach jeder Verarbeitung einer Deklaration erzeugt.

Der Logeintrag Anhänger an bzw. Anhänger ab kann selbst erzeugt werden. Eine

Beschreibung dazu finden Sie unter [3] Kapitel 5.2 und 5.3. Nach dem Anhängen bzw.

Abhängen wird für den Logeintrag zusätzlich eine Fahrt benötigt.

5.5 emotach Bedienung

Bedien- und Anzeigeelemente

Tastenbeschreibung des emotach.

1) OK-Taste

2) BT-Taste

3) Bluetooth-Status

Allgemeiner Hinweis

Das HMI des emotach ist während der Fahrt (V-Impuls) gesperrt.

Die BT Verbindung zu einer Gegenstelle funktioniert nur bei einem stehenden

Fahrzeug.

3

2

1

5.5 emotach Bedienung

Seite 67

BT-Taste konfigurieren

Die BT-Taste (2) am emotach kann für einen Bluetooth-Dienst (Image-Übertragung und

Deklaration über Mobiltelefon) konfiguriert werden. Hierzu muss eine entsprechende

Chipkarte „Private Konfiguration“ (BT-Taste konfigurieren) mit Hilfe des emotachDirect

erstellt werden.

1) Erstellen Sie mit Hilfe des emotachDirect die entsprechende Chipkarte zur

Konfiguration der BT-Taste (2).

2) Stecken Sie die Chipkarte in den Kartenschacht des emotach.

3) Es erscheint eine Abfrage, ob der Auftrag verarbeitet werden soll. Drücken Sie

die OK-Taste (1). Anschliessend erscheint ein Hinweis auf dem Display des

emotach Hinweis Auftrag erfolgreich ausgeführt.

4) Zum Starten des BT-Dienstes drücken Sie die BT-Taste (2).

Im Display des emotach erscheint folgender Text: BT-Deklaration Dienst

gestartet Warten auf eingehende Verbindung.

Das emotach wartet auf eingehende Verbindungen und die Bluetooth-Statusanzeige

(3) blinkt. Wird die Gegenstelle erkannt und im Falle der Kommunikation über

Mobiltelefon eine Verbindung zum FTP-Server erfolgreich aufgebaut, leuchtet die

Bluetooth-Statusanzeige (3) permanent und ein Signalton wird als Bestätigung

ausgeben.

BT Dienste konfigurieren und manuell starten

Die Konfiguration der BT-Dienste und das manuelle Starten dieser wird im [3] im

Kapitel 7.6 bzw. Kapitel 7.8 beschrieben.

Fehlermeldungen Allgemein

Folgende allgemeinen Fehlermeldungen können in Verbindung mit der emotach

erscheinen. Die Ursachen und die Massnahmen sind in der folgenden Tabelle

beschrieben.

Nummer Meldung Ursache Massnahme

7140 Fehler BT-Deklaration

Der gewählte

Dienst ist nicht

konfiguriert.

BT-Taste (2) ist nicht

konfiguriert

Mit emotachDirect die

Chipkarte „Private

Konfiguration“ mit BT-

Taste konfigurieren

erstellen und im emotach

verarbeiten

7120 Fehler BT-Deklaration:

Übertragung nicht

möglich, Fahrzeug fährt.

BT-Taste (2) funktioniert nur

bei stehendem Fahrzeug

Fahrzeug entsprechend

der Verkehrsituation

anhalten und BT-Taste (2)

erneut betätigen.


Partner Verbindet sich

nicht

Gegenstelle hat sich

innerhalb eines Timeouts

nicht verbunden.

BT-Konfiguration der

Gegenstelle prüfen


Übertragungsfehler

Gegenstelle hat keine Datei

übertragen nach einem

Timeout.


Gegenstelle prüfen


Übertragungsfehler

Gegenstelle hat Datei mit

Statusmeldungen nicht

angefordert nach Timeout.


Gegenstelle prüfen

5 Entwicklungskit

Seite 68

Fehlermeldungen Chipkarte

Nummer Meldung Ursache Massnahme

4006 Fehler Chipkarte: Karte

wurde vorzeitig entfernt

Chipkarte vorzeitig aus dem

emotach gezogen.

Kurz warten, Chipkarte

nochmals stecken,

Vorgang wiederholen.

Ansonsten neue Chipkarte

verwenden.

4011 Fehler Chipkarte: Nicht

lesbar

Chipkarte defekt oder falsch

eingesteckt. (Chipkarte

verdreht, falsche Seite

eingesteckt).

Chipkarte korrekt

einstecken.

Chipkarte mit

emotachDirect prüfen.

4028 Fehler Datenprüfung:

Ungültiger Wert

Die zu übernehmenden

Daten konnten aus

Plausibilitätsgründen nicht

übernommen werden.

Eingegebene Daten im



Falsches emotach

Chipkarte ist im falschen

emotach (Gerätenummer).

Passende Chipkarte

verwenden.

Chipkarte mit



Nicht für emotach

Chipkarte ist nicht für das

emotach bestimmt.

Diese Fehlermeldung

erscheint beispielsweise,

wenn eine Chipkarte

Deklaration zum zweiten Mal

verwendet wird.

Passende Chipkarte

verwenden.

Chipkarte mit



Falsches Fahrzeug

Chipkarte ist im falschen

Fahrzeug (Stammnummer).

Passende Chipkarte

verwenden.

Chipkarte mit



Gültigkeit abgelaufen

Das Gültigkeitsdatum der

Chipkarte ist abgelaufen.

Chipkarte neu erstellen.

5.6 Emotach Gerätezustand

Das emotach kann während dem Betrieb mit dem Entwicklungskit in einen Fehlerzustand

kommen. Dies kann folgende verschiedene Gründe haben:

Es wurde eine längere Fahrt (ca. 1h) simuliert und der Gerätezustand ist gelb:

Man muss kurz einen Impuls auf die Anhängererkennung geben (Anschluss an

Dauerstrom). Der Gerätezustand ändert sich danach wieder zu grün.

Das emotach wurde stark bewegt und der Gerätezustand ist gelb:

Das emotach schreibt einen Logeintrag „Fahrt ohne Tacho“, welchen man einsehen

kann. Um diesen Zustand zu verlassen, muss man kurz einen V-Impuls geben. Der

Gerätezustand ändert sich danach wieder zu grün.

5.7 Beschreibung der Testdaten

Seite 69

Das emotach wurde längere Zeit ohne Strom betrieben und der Gerätezustand ist gelb:

Wenn die Batterie einen Schwellwert unterschreitet wird ein Logeintrag „Batterie

wechseln“ geschrieben. Sie sollten das emotach am Strom betreiben und sich mit der

OZD in Verbindung setzen.

Falls das emotach durch eine andere Ursache in einen Fehlerzustand gerät, sollten Sie sich

mit der OZD in Verbindung setzen. Die Ansprechstellen finden Sie dafür im Kapitel 6.

5.7 Beschreibung der Testdaten

• Backup-Datenbank für emotachDirect (Siehe 5.7.1)

DB_Backup.bak

• Test emotach 701.083.969 mit Logeinträge (Siehe 5.7.2)

5.7.1 Backup-Datenbank

Fahrzeugliste

Die Datenbank enthält 3 Fahrzeuge die mittels Deklarationsauftrag in die Applikation erfasst

worden sind. Die Mehrheit der Stammdaten dieser Fahrzeuge ist ausgefüllt:

Stammnummer Kontrollschild Land Interne Bezeichnung

701.083.957 CH Fahrzeug 1

701.083.969 BE 700 001 CH Fahrzeug 2, Test emotach

701.083.970 CH Fahrzeug 3

Jedes dieser Fahrzeuge hat einen Deklarationsauftrag in der Datenbank. Jeder dieser

Aufträge adressiert das emotach über die Stammnummer. Bei der ersten Verarbeitung

einer Deklarationsmeldung, erfährt das emotachDirect die Seriennummer und bietet deren

Erfassung an (eigener Dialog).

Anhängerliste

Die Datenbank enthält 2 Anhänger die manuell in emotachDirect erfasst worden sind:

Stammnummer Typ Kontrollschild Interne Nummer Gewicht

444.555.666 Anhänger XY 321654 456 6.7t

444.555.667 Anhänger XY 321655 457 7.2t

Hinweis

Die Zugangsdaten und das Login für die Webservices der OZD wurden aus der Datenbank

entfernt. Die Kommunikation zwischen emotachDirect und der OZD ist mit dieser Backup-

Datenbank nicht möglich.

5.7.2 Logeinträge des mitgelieferten emotachs

Die Deklarationsmeldung, welche das mitgelieferte emotach bei der Verarbeitung des

Auftrags generiert, enthält folgende Logeinträge:

5 Entwicklungskit

Seite 70

Logeintrag Km-Stand

Anhänger ab 1530.0

Einfahrt CH Autor 1525.0

Anhänger an 1523.0

Anhänger ab 1520.0

Anhänger an 1518.0

Anhänger ab 1515.0

Ausfahrt CH Autor 1510.0

Anhänger an 1507.0

Initialisierung 1500.0

Halter Plomb. 1500.0

ASF Plombierung 1500.0

Inbetriebnahme 1500.0

Startup 0.0

Diese Logeinträge werden durch folgende Schritte erzeugt:

Nr. Schritt Logeintrag Km-Stand

1 Test-emotach mit Stammnummer

701.083.969 und Km-Stand 1500km mit

dem emotachService in Betrieb nehmen

Startup

Inbetriebnahme

ASF Plombierung

Halter Plomb.

0.0

1500.0

1500.0

1500.0

2 emotach mit Stamm- und Vertragsdaten

initialisieren

Initialisierung 1500.0

3 Chipkarte Anhängerliste auf dem

emotach einlesen und die Liste

übernehmen

-

4 Fahrt 7km

Anhänger XY 321654 anhängen

Anhänger an 1507.0

5 Fahrt 3km

Karte Zollamt einlesen und verarbeiten.

Anschliessend Knopf CH drücken. Das

grüne Licht der Taste geht aus

Ausfahrt CH Autor 1510.0

6 Fahrt 5km

Anhänger abhängen

Anhänger ab 1515.0

7 Fahrt 3km


Anhänger an 1518.0

8 Fahrt 2km

Anhänger abhängen

Anhänger ab 1520.0

9 Fahrt 3km


Anhänger an 1523.0

10 Fahrt 2km

Karte Zollamt einlesen und verarbeiten.

Anschliessend Knopf CH drücken. Das

grüne Licht der Taste geht an

Einfahrt CH Autor 1525.0

11 Fahrt 5km

Anhänger abhängen

Anhänger ab 1530.0

5.8 Demoprogramm für Imageaustausch über Bluetooth

Seite 71

Der Km-Stand kann beim mitgelieferten emotach abweichen. Zusätzlich können im Laufe

der Zeit zusätzliche Logeinträge entstehen, welche hier nicht aufgeführt sind.


5.8.1 Systemanforderungen

Folgende Systemanforderungen sind für das BT-Demoprogramm eines Imageaustauschs

notwendig:

Eines der folgenden Microsoft Windows Betriebssysteme:

Windows Vista Home Premium oder Vista Business

Windows XP Home oder Windows XP Professional mit installiertem Service Pack 2

(SP2) oder höher

Minimum 250 MB freier Speicherplatz

CD-ROM Laufwerk für den Zugriff auf das Installationsmedium

Die Systemanforderungen für das emotachDirect sind im Handbuch des emotachDirect

beschrieben.

5.8.2 Funktionierende BT-Adapter

Mit den folgenden BT-Adaptern wurde die Installation des Standard-Treibers von Microsoft

getestet und diese funktionieren mit dem BT-Demoprogramm:

MSI Star Key 2.0 Bluetooth Adapter

D-Link DBT-122 USB Bluetooth Adapter

Targus ACB20EU Bluetoothadapter 2.0

Belkin Bluetooth USB-Adapter, 100 Meter

Andere BT-Adapter sollten grundsätzlich auch verwendet werden können, es muss einfach

sichergestellt sein, dass der Standard Bluetooth-Treiber von Microsoft verwendet wird. Evtl.

muss die mitgelieferte Datei siemensbth.inf im Ordner Tools angepasst werden.

5.8.3 Anschluss BT-Adapter

Um einen BT-Adapter zu installieren gehen Sie wie folgt vor:

1. Stecken Sie den BT-Adapter in eine USB-Buchse. Das Betriebssystem erkennt das

neue Gerät und startet automatisch die Installationsroutine.

2. Es erscheint ein Dialog, in dem Sie auswählen müssen, von welchem Ort ein

passender Treiber für das neue Gerät bezogen werden soll. Aktivieren Sie hier die

Option Software von einer Liste oder bestimmten Quelle installieren (für

fortgeschrittene Benutzer), und klicken Sie auf Weiter.

5 Entwicklungskit

Seite 72

3. Aktivieren Sie im folgenden Dialog die Option Folgende Quelle ebenfalls

durchsuchen, und wählen Sie den Ordner Tools auf der CD-ROM. In diesem Ordner

befindet sich die benötigte Datei siemensbth.inf. Bestätigen Sie Ihre Auswahl

durch einen Klick auf Weiter.

4. Die Software wird daraufhin installiert.

5.8.4 Bedienung BT-Demoprogramm

Im Ordner ‚BT-Demoapplication’ auf der CD-ROM finden Sie das BT-Demoprogramm.

Dieses Demoprogramm ist für die Konsole erstellt worden und kann nur über die Konsole

bedient werden.

Das Demoprogramm wird für den Imageaustausch mit einem emotach verwendet.

Das Programm wird folgendermassen aufgerufen: btdemo.exe [Parameter]

Parameter

Parameter Beschreibung

--help Mit diesem Parameter geben Sie die Hilfe aus.

-d

--device

Mit diesem Parameter kann die eigene MAC-Adresse des Bluetooth-

Adapters ausgelesen werden. Mit Hilfe dieser Adresse kann in der

emotach die Konfiguration gesetzt werden.

-i

--inq

Mit diesem Parameter wird eine Suche nach Bluetooth-Geräten

gestartet und in der Konsole ausgegeben.

-s

--send

Mit diesem Parameter kann ein Auftragsimage an eine emotach

gesendet werden und das Antwortimage geholt werden.

Die weiteren Parameter müssen im folgenden Format eingegeben

werden: [MAC-Adresse inkl. Doppelpunkte] [PIN] [Pfad und Dateiname

des Auftragsimage] [Pfad und Dateiname für das Speichern der

Statusmeldung] [Pfad und Dateiname für das Speichern der Image-

Meldung]

Die Pfadnamen können entweder relativ oder absolut sein.

Beispiel: btdemo –s 00:0a:3a:5c:32:12 123456 auftrag.img

statusmeldung.xml imagemeldung.img

Wichtig!

Der Bluetooth-Adapter sollte immer schon vor dem Gebrauch des BT-Demoprogramms

angeschlossen werden!

5.8.5 Aufbau Entwicklungsumgebung

Verwendete Tools

Folgende Tools und Libraries wurden für die Entwicklung verwendet:

MinGW (Public-Domain Lizenz, kann als Buildtool frei verwendet werden)

Buildumgebung mit Compiler


Seite 73

Cmake (BSD-Lizenz)

Konfiguration der Buildumgebung

Microsoft SDK (Microsoft-Lizenz, kann unverändert frei benutzt werden)

Programmbibliothek für Bluetooth Funktionen

Obex-FTP (LGPL)

Programmbibliothek für OBEX-FTP Funktionen

MinGW

Es wurde die MinGW Version 5.1.4 verwendet. Da über den Installer jeweils die

Version nicht gewählt werden kann, wurde für die Version 5.1.4 eine ZIP-Datei erstellt,

welche einfach an einem Ort entpackt werden muss. Diese Datei finden Sie im Ordner

Tools unter dem Namen mingw-5.1.4.zip.

Erstellen Sie im Ordner C:\ einen Ordner MinGW und entpacken Sie diese ZIP-Datei in

diesen Ordner. Damit ist MinGW bereits auf Ihrem Rechner installiert.

Um MinGW wieder zu entfernen, müssen Sie einfach diesen Ordner C:\MinGW von

Ihrem System löschen.

In diesem Beispiel wurde dieser Pfad verwendet. Wenn Sie einen anderen Pfad

wählen, müssen Sie evtl. in einigen Schritten andere Werte eintragen.

Cmake

Es wurde Cmake Version 2.6.4 verwendet. Den Installer zu dieser Version finden Sie

im Ordner Tools unter dem Namen cmake-2.6.4-win32-x86.exe.

Installieren Sie Cmake mit der nachfolgenden Anleitung:

Installation starten

Bitte starten Sie den Installationsassistenten mit der mitgelieferten Datei und klicken

Sie sich durch den Wizard bis Sie zu den Installationsoptionen kommen.

Bei den Installationsoptionen sollten Sie den Punkt Add Cmake to the system PATH

for all users wählen und anschliessend mit Weiter bestätigen.

5 Entwicklungskit

Seite 74

Wählen der Installations Optionen

Zielordner wählen

Nun müssen Sie den Zielordner für die Installation wählen. Standardmässig wird

C:\Program Files\Cmake 2.6 vorgeschlagen. Für diese Installationsanleitung wurde

der Standardpfad gewählt. Es können bei einem anderen Pfad evtl. weitere Schritte

nötig werden, welche in dieser Installationsanleitung nicht beschrieben sind.

Wählen des Zielordners für die Installation

Microsoft SDK

Da nur ein sehr kleiner Teil des Microsoft SDK verwendet wird, sind diese Dateien auf

dieser CD-ROM enthalten. Damit erspart man sich einen Download des SDK. Dieser


Seite 75

Auszug des SDKs befindet sich im Ordner Source BT-Demoapplication libraries

mssdk auf der CD-ROM.

Das gesamte SDK kann mit dem Installationsprogramm setup.exe, welches sich im

Ordner Tools auf der CD-ROM befindet, installiert werden.

Obex-FTP

Für die Übertragung via Obex-FTP wird die gleichnamige Library Obex-FTP Version

0.22 verwendet. Weitere Informationen zu dieser Bibliothek finden Sie unter:

http://dev.zuckschwerdt.org/openobex/wiki/ObexFtp Diese Library ist bereits

vorkompiliert im Ordner Source BT-Demoapplication libraries obex-win32

vorhanden.

Konfiguration MinGW

Damit mit MinGW kompiliert werden kann, muss der Ordner bin, welcher in den

Installationsordner von MinGW installiert wurde in die Systemvariable Path

übernommen werden. Wenn der Standardzielordner für die Installation verwendet

wurde, ist dies C:\MinGW\bin.

Die Systemvariable kann man folgendermassen anpassen. Unter Systemsteuerung

muss man System auswählen. In diesem Dialog, welcher sich öffnet, muss man auf

die Lasche Erweitert gehen und dort hat es einen Button mit dem Namen

Umgebungsvariablen.

Ansicht, wo die Einstellungen der Umgebungsvariablen

Nun öffnet sich ein Dialog, wo die Path-Variable bearbeitet werden kann. Am Ende

kann mit ;[PFAD] der Pfad ergänzt werden. Wenn der Standardinstallationspfad

verwendet wurde, ist dies ;C:\MinGW\bin.

5 Entwicklungskit

Seite 76

Erweitern der Path-Variable mit dem MinGW-Installationsordner

Kompilieren des Demoprogrammes

Über eine Konsole – hier wird command.exe verwendet – kann die BT-

Demoapplikation nun konfiguriert und kompiliert werden. Kopieren Sie zuerst den Inhalt

des Ordners Source BT-Demoapplication in ein Verzeichnis, auf welchem Sie

Schreibrechte besitzen. Starten Sie über Start Ausführen cmd eingeben und OK

drücken die Konsole und navigieren Sie in das Verzeichnis, in welches Sie den Ordner

kopiert haben und navigieren Sie in den Unterordner application.

In diesem Verzeichnis können Sie mit dem Befehl cmake –G“MinGW Makefiles“ die

Applikation konfigurieren. Dadurch werden die Makefiles für die MinGW-

Entwicklungsumgebung erstellt. Dies kann eine kurze Zeit dauern.


Seite 77

Konfigurieren des BT-Demoprogramms

Nun kann mit dem Befehl mingw32-make das BT-Demoprogramm kompiliert werden.

Diese Warnung, welche erscheint, ist von der MS SDK-Library und kann ignoriert

werden, da diese Warnung nichts mit der Funktionalität zu tun hat..

Ausführen des Make-Befehls auf der Konsole.

Nun befindet sich im Ordner src im Source-Verzeichnis (Verzeichnis application) eine

Datei btdemo.exe. Diese Datei ist in diesem Ordner nicht ausführbar, da sie noch

Programmbibliotheken benötigt, welche im gleichen Ordner sein müssen. Deshalb

kann man die Datei in den Ordner Source BT-Demoapplication bin kopieren, wo

sie die Programmbibliotheken bereits befinden.

5.8.6 Source-Code BT-Demoprogramm

Der Source-Code zum Demoprogramm befindet sich auf der CD-ROM im Verzeichnis

Source BT-Demoapplication im Unterverzeichnis src in der Datei main.cpp. Die

Dokumentation zum Source-Code ist direkt im Code beschrieben und wird hier nicht weiter

ausgeführt.

5 Entwicklungskit

Seite 78

Auf der CD im Verzeichnis Source BT-Demoapplication befinden sich folgende Source-

Files:

application

src

CmakeLists.txt (Wird von Cmake für das Erstellen der Makefiles benötigt.)

main.cpp

CmakeLists.txt (Wird von Cmake für das Erstellen der Makefiles benötigt.)

bin (OBEX-FTP Bibliotheken für die Ausführung des Demoprogramms)

libraries (Bibliotheken, welche mit dem Demoprogramm gelinkt werden)

5.9 Vorbereitungen emotach und emotachDirect für die Deklaration über den Image-Service

Bevor die elektronische Kommunikation (Image-Übertragung) zwischen dem emotach und

dem emotachDirect Image-Server überhaupt funktioniert, müssen beide Seiten zuerst

vorbereitet werden, bzw. Daten zur Verfügung haben.

Vorbereitung emotachDirect

Nach der Installation der emotachDirect Applikation ist die Datenbank, bis auf die

Konfigurationsdaten, leer. Die Applikation kennt noch keine Fahrzeuge. Nun müsste der

Anwender zuerst seine Daten in die Datenbank füllen, dies wurde für das Entwicklungskit

bereits durchgeführt und steht als Datenbank-Backup im Ordner DB-Backup unter dem

Namen DB_Backup.bak zur Verfügung. Inhalt dieser Datenbank ist unter 5.7.2

beschrieben. Abschnitt 4.2 aus [2] beschreibt wie ein Backup eingespielt wird. Die

Datenbank soll dabei ersetzt und nicht gemischt werden.

Ohne diese Backup-Datenbank würde der Fahrzeughalter sich zuerst einen Benutzer

konfigurieren, die Daten (Benutzername und Passwort) dazu erhält der Fahrzeughalter von

der OZD ([1] Abschnitt 6.3.1). Anschliessend würde er das Fahrzeug in die Applikation

erfassen, zum Beispiel mit einem Deklarationsauftrag für dieses Fahrzeug. Der

Fahrzeughalter würde anschliessend das erfasste Fahrzeug dem erstellten Benutzer

zuordnen und sich bei der OZD mittels Webservice einen Deklarationsauftrag für das

Fahrzeug holen ([1] Abschnitt 4.3.4). Die Applikation würde den geholten Auftrag in die

Datenbank stellen. Dies wurde alles in der mitgelieferten Datenbank gemacht.

Um die Kommunikation mit der Kundenapplikation zu ermöglichen muss ein FTP-Server

sowie die emotachDirect Web-Services nach [2] Abschnitt 6 installiert werden.

Aus Sicherheitsgründen wird dem Fahrzeughalter empfohlen, diese Komponenten (FTP-

Server und IIS), auf einem PC in einer DMZ zu installieren, da dieser PC im Betrieb aus

dem Internet erreichbar sein muss. Für die Entwicklung der Kundenapplikation ist die

Verbindung zum Internet nicht zwingend, der PC mit der Kundenapplikation sollte lediglich

in der Lage sein, die emotachDirect Web-Services zu erreichen.

Diese emotachDirect Web-Services können mittels einer Testapplikation wsclient.exe im

Installationspackage des emotachDirect im Verzeichnis webserviceclient angesprochen

werden (siehe [2] Abschnitt 6.2). Damit ist es möglich die Verbindung zu prüfen sowie

Deklarationsaufträge holen und Meldungen zu schicken.

5.10 Funktionstest

Seite 79

Der Fahrzeughalter konfiguriert nun in der emotachDirect Applikation den

Deklarationsservice und startet den Service ([2] Abschnitt 3.3). Spätestens nach Ablauf des

konfigurierten Scan-Intervalls legt der Deklarationsservice den geholten Deklarationsauftrag

aus der Datenbank mittels SSH-FTP in die Datenablage des Webservice-Servers. Der

Fahrzeughalter schreibt noch eine Chipkarte „Private Konfiguration“ mit einem Auftrag

„Bluetooth-Image“ mit der BT-Konfiguration wie das emotach mit der Kundenapplikation

kommunizieren kann ([1] Abschnitt 4.1.5.2). Sie benötigen für das Erstellen dieser Karte

einige Informationen, welche nachfolgend beschrieben sind.

Die BT-Adresse des eigenen Bluetooth-Adapters finden Sie über den Geräte-Manager. Im

Geräte-Manager hat es einen Punkt Bluetooth Radios, wo nach dem Aufklappen der

Bluetooth-Adapter aufgelistet wird. Über die Eigenschaften kann über das Menü Erweitert

die BT-Adresse abgefragt werden. Die BT-Adresse darf nur aus den Zeichen A-F (in

Grossbuchstaben) und den Zahlen 0-9 bestehen und muss 12 Zeichen lang sein.

Die PIN können sie selbst wählen. Bitte notieren Sie sich die gewählte PIN, da diese in

einem nächsten Schritt wieder benötigt wird.

Die Flags Server-Neustart und Automatischer Start sollten dabei auf Ja stehen. Die

genaue Bedeutung vom Flag Server-Neustart finden Sie im Kapitel 4.1.1.1. Automatischer

Start bedeutet, dass der Dienst direkt nach Verarbeiten der Karte gestartet wird.

Hinweis

Chipkartenimages können auch als Datei (Image) gespeichert werden. Sehen Sie dazu [1],

Abschnitt 4.2.2.

Eine Übersicht über die Privaten Konfigurationen finden Sie unter [1] Kapitel 4.1.5.

Vorbereitung emotach

Das emotach wird in Betrieb genommen und mit Daten, wie unter 5.7.2 beschrieben, gefüllt

ausgeliefert. Es muss auf dem emotach die erstellte Chipkarte „Private Konfiguration“ mit

dem Auftrag „Bluetooth-Image“ eingelesen und verarbeitet werden.

Im Kapitel 5.5 wird die Bedienung des emotach und damit das manuelle Starten des

Dienstes beschrieben.

Nun sind beide Seiten für die Kommunikation vorbereitet.

Um nun eine Kommunikation gemäss Kapitel 3.2 durchzuführen, stehen dem Entwickler ein

Web-Service Testclient ([2] im Abschnitt 6.2) und ein BT-Demoprogramm (Kapitel 5.8.4) zur

Verfügung.

5.10 Funktionstest

Folgend ist ein kurzer Funktionstest aufgelistet. Dieser Funktionstest ist ohne

Vorbereitungen und Konfigurationen beschrieben. Die Beschreibung des Services ist in

Kapitel 3.2 zu finden.

1. Mittels Webservice Testclient den Deklarationsauftrag über den Webservice

GetEmptyImage vom Image-Server holen

5 Entwicklungskit

Seite 80

2. Mittels BT-Demoprogramm die Verbindung zum emotach aufbauen und das Image an

das emotach senden

3. Deklarationsauftrag vom emotach verarbeiten lassen

4. Die vom BT-Demoprogramm geholte Deklarationsmeldung mit dem Webservice

Testclient über den Webservice PutDeklImage an den Image-Server senden.

Nun wird das emotachDirect die Deklarationsmeldung nach einer konfigurierten Zeit

abholen und anzeigen.

5.10 Funktionstest

Seite 81

6 Ansprechstellen

Für Fragen, Anregungen und Kritik steht Ihnen die OZD unter der folgenden Email Adresse

zur Verfügung: [email protected]

Die aktuellste Ausgabe dieser Dokumentation, sowie auch zusätzliche Informationen sind

auf der Homepage www.emotach.ch/bt-services verfügbar.

7 Anhang

Seite 82

7 Anhang

7.1 Begriffe und Abkürzungen

BSD-Lizenz

Die Berkeley Software Distribution Lizenz ist eine von der Universität von Kalifornien,

Berkeley, entwickelte Lizenz für freie Software.

BT

Bluetooth

DMZ

Netzwerkort (Demilitarized Zone) für Server, welche von intern wie auch von extern

Zugriff haben sollten

DUN

Bluetooth-Profile, Dial-Up Networking Profile

emotach

On Board Unit für die LSVA

emotachDirect

Fahrzeughaltersoftware

ETX

End of Text – Steuerzeichen markiert das Ende einer Nachricht

FTP

File Transfer Profile

GAP

Bluetooth-Profile, Generic Access Profile

GOEP

Bluetooth-Profile, General Object Exchange Profile

GPGSA

NMEA-Datensatz, SA=satellites active – enthält die Nummern der verwendeten

Satelliten und Informationen über die Genauigkeitswerte (DOP)

GPRMC

NMEA-Datensatz, Recommended Minimum Sentence C – empfohlener NMEA

Minimumdatensatz

GPS

Global Positioning System – ein Satellitennavigationssystem

HMI

Human Machine Interface

7.2 Referenzen

Seite 83

L2CAP

Bluetooth Protokoll, Logical Link Control and Adaption Protocol

LGPL

Die Lesser General Public Licence ist eine von der Free Software Foundation

entwickelte Lizenz für Freie Software.

LSVA

Leistungsabhängige Schwerverkehrsabgabe

NMEA

National Marine Electronics Association

NMEA-0183 Standard

Übertragungsstandard im maritimen Bereich für die Bereitstellung von

Navigationsdaten an andere Geräte

OBEX

Object Exchange

SDAP

Service Discovery Application Profile

SOH

Start of Heading – Steuerzeichen markiert den Beginn einer Bytefolge

SPP

Bluetooth-Profile, Serial Port Profile

SSH-FTP

FTP über Secure Shell

STX

Start of Text – Steuerzeichen markiert den Anfang einer Nachricht

7.2 Referenzen

[1] Benutzerhandbuch emotachDirect, Ausgabe Oktober 2010

[2] Administrationshandbuch Einzelplatz emotachDirect, Ausgabe Oktober 2010

[3] Benutzerhandbuch emotach, Ausgabe Juni 2010

7 Anhang

Seite 84

7.3 History

Ausgabe Änderung Datum

September 2009 1. Version 30.09.2009

Oktober 2009 Kleinere Korrekturen im gesamten Dokument 27.10.2009

November 2009 Grafik in Kapitel 3.1.1 korrigiert,

Anpassung im Kapitel 5.5

04.11.2009

Juni 2010 Informationen zu LSVA-Chipkarten aufgenommen: • Kapitel 2.1 ergänzt • neues Kapitel. 4.3 erstellt

Korrekturen in Kapitel 4.1.1.2: • Meldungsnummer in Alternativablauf 2 korrigiert • emotach NMEA Daten: GGA entfernt, GSA

präzisiert

Präzisierung in Kapitel 4.1.2.3, SDP: • Hinweis bezüglich Channelnummer und

Verbindungsaufbau aufgenommen

17.06.2010

März 2011 Anpassung WSDL in Kapitel 4.2.3.

Präzisierung in Kapitel 4.1.1.2 bei Verbindungseigenschaften

Anpassung der Tabellen in Kapitel 4.1.1.1 und 4.1.1.4

Präzisierung in Kapitel 4.3.3

16.03.2011

Juli 2011 Änderung in Kapitel 3.2.2 aufgrund System-änderung:

• Keine Bestätigungsabfrage am emotach

Korrektur in Kapitel 4.1.1.3:

• ASCII-Steuerzeichen SOH, STX und ETX in den Beispieldaten Zusatznutzenprotokoll korrekt dargestellt

Referenzen in Kapitel 7.2 aktualisiert

Kleinere Korrekturen im gesamten Dokument

21.06.2011

Juli 2012 Ergänzung in Abbildung 1 –

Präzisierung in den Kap. 4.1.1.2, 4.1.1.4 und 4.1.2.3

Fehlendes Element „Mode“ in NMEA RMC in Kap. 4.1.1.2 ergänzt

Datenelement „Freie Anhänger Nummer“ in Kap. 4.1.1.3 präzisiert

Vereinfachung in Kap. 4.1.2.2

Anzahl CK Anhänger in Kap. 5.1 angepasst

11.07.2012

TEMP LSVA Entwicklungskit DE€¦ · FTP-Servers legt diesen Ort fest, per Default ist dies...

Documents

Transcript of TEMP LSVA Entwicklungskit DE€¦ · FTP-Servers legt diesen Ort fest, per Default ist dies...