[Seite 1]
D atenaustauschformat der
automatisierten
Einsatzdatenerfassung
& NSEXT07
Autor: Haymo Jupè Druckdatum: 09.05.2023 14:31 Dateiname: MBDE Protokoll NSEXT07 Dokumentenstatus: abgeschlossen Freigegeben am: Freigegeben durch: Dokumentennummer: 20
NOVASIB GmbH – 99097 Erfurt-Waltersleben – Alte Chaussee 77 – Internet: www.novasib.de Seite 1 von 17 Email: novasib@novasib.de – Telefon: +49 (0) 361 654 99 11 – Fax: +49 (0) 361 654 99 44
[Seite 3]
Inhaltsverzeichnis
1.1 Kopf (Header) der Datei (Meldung) 4 1.2 Allgemeines 5 1.3 Mehrfachbody für Sendegründe T, S 5 1.3.1 Bemerkungen zu den Kennungen 6 1.4 Body des Protokolls für die Kennungen K, A, Q, W, E, S, B, H, F 8 1.4.1 Tätigkeitscodes und Streuerwerte 9 1.4.2 Fehlercodes im Code F 9 1.5 Versandt der Daten zu NOVASIB 10 1.6 Empfang der Daten von der NOVASIB 10 1.6.1 Erweiterte Referenzierung von Originaldaten 10 1.6.2 Format der empfangenen Daten 11 1.7 Beispiel Wartezeit und Datumsüberschlag 13 1.8 Beispiel Datumsüberschlag ohne Wartezeit 14 1.9 Erläuterungen 15 1.10 Änderungsliste 16
© NOVASIB GmbH Seite 3 von 17
[Seite 4]
1 Kopf (Header) der Datei (Meldung)
Das Trennzeichen (durch + 1 angegeben) ist das Komma („,“).
- ABSENDERTELEFONNUMMER char 13+1 14 Fahrzeugnummern werden mit einem Identifizierungscode (z.B. 4 mal ‚9‘ für TSI Fahrzeuge) eingeleitet : +99990000XXXX Für die Fahrzeugnummern der Dienstleister stehen die Bereiche 0000 und XXXX zur Verfügung, so dass 8 Stellen vorhanden sind. Es sind nur die Ziffern von ‚0’ bis ‚9’ als Zeichen erlaubt. Die Identifizierungscodes für die Dienstleister werden von der NOVASIB GmbH nach Prüfung der Winterdiensttechnik und der Erteilung des Zertifikates vergeben.
- PROTKOLLNAME char 8 + 1 23 Der Protokollname ist immer NSEXT07 (Änderung 19).
- GERÄTESTATUS char 2 + 1 26 der Gerätestatus kann leer bleiben, das Feld ist aber zu erzeugen
- SMSNR char 10 + 1 37 Die SMS-Nr. gilt immer nur für ein Fahrzeug, und wird mit den gesendeten Dateien für das Fahrzeug inkrementiert (jede gesendete Datei für das Fahrzeug hat somit eine andere, fortlaufende SMS-Nr.). Sie dient der Identifizierung der Datei und der späteren Referenzierung von Auswertungsdaten zu Ausgangsdateien. Die kleinste mögliche SMS-Nr. ist 1, nach oben wird keine Begrenzung vergeben, es sei denn, die SMS-Nr überschreitet einen Wert von 2.000.000.000. In diesem Fall ist erneut mit der 1 zu beginnen.
- IDA (KOSTENSTELLE) char 2 + 1 40 Dies ist eine zusätzliche Angabe zu den Ausgangsdaten. Zusammen mit der SMSNR Und der (folgenden) IDB kann hier die Rückwärtsreferenz zu den Originaldaten erzeugt werden. Die drei Felder SMSNR, IDA und IDB helfen, Originalberichte und Auswertungen zuzuordnen. Insbesondere gilt dies für Berichte, die über die Mitternachtsgrenze hinweg gehen. (siehe Änderung 10 ). Die Felder IDA und IDB werden mit der SMS Nummer, dem Namen der Ausgangsdatei in der *.NFO Datei bereitgestellt. Diese *.NFO Datei liegt dem Archiv der Auswertungen bei. (Änderung 06)
- IDB (BERICHTSNUMMER) char 6 + 1 47 Zweite zusätzliche Angabe für die Dereferenzierung der NOVASIB Berichte. (siehe Beschreibung zu IDB) (Änderung 06)
- DATUM Erzeugung der SMS ddmmjj char 6 + 1 54 Datum ist das Einsatzdatum auf das sich die folgenden Koordinaten beziehen. In einer Datei dürfen nur Daten eines Tages geliefert werden !
- UHRZEIT Erzeugung der SMS hhmmss char 6 + 1 61 Uhrzeit ist die letzte Uhrzeit des Einsatzes, d.h. die Uhrzeit vom Einsatzende. Es sollten Datum und Uhrzeit des Einsatzendes sein. (Änderung 03)
- SENDEGRUND char 1 + 1 63 Sendegründe E Fehlermeldung (dieser Meldungstyp ist optional !) T Timerintervall /Puffer leeren S Senden wegen Pufferleerung
Der Sendgrund (Feld 7 im Kopf der SMS) kann für Externe (TSI etc.) ‚S’ sein. E und T können gestrichen werden, da Daten Intervalle nicht relevant sind, und Fehlermeldungen für die Bearbeitung der Daten ebenfalls nicht relevant sind. 10. SNRID Seriennummer oder anderweitige ID zur Identifizierung der char 20 + 1 84 KFZ – Anbaugerät – Kombination, oder zur Identifizierung des (der) Anbaugeräts (e). (Änderung 13) 11. FID ID zur Identifizierung des Fahrers char 20 + 1 105 Die ID kann maximal 20 Stellen lang sein. (Änderung 14) 12. BFID ID zur Identifizierung des Beifahrers (wie Fahrer). char 20 + 1 126 Die ID kann maximal 20 Stellen lang sein. (Änderung 15)
© NOVASIB GmbH Seite 4 von 17
[Seite 5]
| Body der Meldungen bei Sendegrund E Wird nur gesendet, wenn ein Fehler bereits vor Tätigkeitsbeginn eintritt | |
|---|---|
| Fehlerzähler | z.B. 21 |
| Warnungszähler | z.B. 0 |
| GPS – Fehler - No | z.B. 0 |
| GSM-Feldstärke | z.B. 31 |
Der Fehlerzähler und/ oder die Fehlercodes im Body Kein GPS Kontakt A, Kein GSM Kontakt B, Kein Sensorkontakt C, Schittstellenfehler D, dürfen nicht zur Aus- oder Überblendung von Datensätzen verwendet werden. Diese Felder tragen informativen Charakter und werden vom Parser nicht als Steuerfelder interpretiert. Datensätze, die zwischen solchen Fehlermeldungen liegen, werden weiterhin bearbeitet.
(Änderung 08)
2 Allgemeines
Bis auf die Tätigkeit gibt es keine Kleinbuchstaben, bzw. keine Unterscheidung zwischen Groß- und Kleinschreibung.
Grundsätzlich werden alle ASCII Daten in Großbuchstaben konvertiert.
Für jedes Ereignis muß ein entsprechender Großbuchstabe erzeugt werden.
Die einzelnen Datensätze dürfen mit CR+LF abgeschlossen werden, um die Meldungen lesbar zu halten. Für die Interpretation der Daten ist die Trennung mit CR+LF nicht nötig.
Die angegebenen Feldbreiten verstehen sich als Maximalwerte. Liegen für Felder keine Werte vor, bleiben diese Stellen leer, d.h., die Kommas folgen direkt aufeinander. Führende Nullen oder Leerzeichen sind nicht nötig.
3 Mehrfachbody für Sendegründe T, S
- KENNUNG char 1 + 1 2 K Fahrzeug an Knoten A Tätigkeitsanfang Q Wechsel der Streuereinstellungen W Tätigkeitswechsel E Tätigkeitsende S Streckenintervall mindestens 1 Knoten im GPS-Toleranzbereich (150 m) 30 mindestens 1 Knoten im GPS-Nahbreich ( 300 m ) 150 weniger als 1 Knoten in GPS-Nahbereich ( 300 m) 500
B Ende der Standzeit H Beginn der Standzeit M Wende
F Fehler
© NOVASIB GmbH Seite 5 von 17
[Seite 6]
3.1 Bemerkungen zu den Kennungen
Prinzipiell sind alle Gewerkemeldungen, also Meldungen, die eine Änderung an den Sensoren melden ‚Pflicht’. D.h., wenn das Schild gehoben / gesenkt wird, der Streuer ein- / ausgeschaltet wird, oder die Streueinstellungen sich ändern muß dies exakt zu diesem Zeitpunkt gemeldet werden. Tritt eine solche Meldung zeitlich gleich mit einer ‚S’ Meldung auf, wird die ‚S’ - Meldung nicht gesendet. In allen anderen Fällen bleibt das Intervall der ‚S’ -Meldung von diesen Meldungen unbeeinflusst !
‚B’ und ‚H’ Meldungen bilden immer eine Klammer. Das heißt, das jedes ‚H’ mit einem ‚B’ beendet werden muß auch, wenn ein Tag mit einer Standzeit, die am Vortag anfing, beginnt, muß die erste Meldung nach dem ‚A’ ein ‚H’ sein.
Anmerkung : Daten müssen nicht mehr an der Datumsgrenze getrennt werden. Es steht dem Absender der Daten jedoch frei, weiterhin die Trennung selbst vorzunehmen. In diesem Fall gilt die vorher beschriebene Regelung. Werden die Daten nicht getrennt, sorgt der Parser selbst für die korrekte Interpretation der Standzeiten. (Änderung 11)
Sowohl ‚B’ als auch ‚H’ Meldungen tragen die (identische) Gesamtdauer der Standzeit in Sekunden im Feld 17.
Zusammenfassend gilt somit folgendes : ‚A’ und ‚E’ Meldungen übersteuern alle anderen Meldungen ! ‚S’ Meldungen werden im angegebenen Algorithmus immer erzeugt, die einzige Ausnahme sind Meldungen, die exakt mit einer ‚S’-Meldung zusammenfallen. ‚B’ und ‚H’ Meldungen Das gleichzeitige Auftreten (d.h. selbe Uhrzeit) ist ausgeschlossen (implizit). ‚M’ – Meldungen dürfen zwischen ‚S’ – Meldungen liegen, dürfen diese aber nur ersetzen, wenn sie zeitlich exakt zusammenfallen. ‚F’ - Meldungen sind reine Zusatzmeldungen (i.d.R. ohne Koordinaten) und werden zwischen allen anderen gesendet, wenn sie anfallen. Sie ersetzen keine der anderen Meldungen ! ‚Q’ und ‚W’ Meldungen werden immer dann gesendet, wenn sie anfallen. Wechselnde Angaben zu Schild und / oder Streuer dürfen nicht bis zur nächsten ‚S’ - Meldung ‚gesammelt’ werden. Angaben zu den Gewerken gelten immer ab der Koordinate an der sie gemeldet wurden, bis zu einer Angabe, die neue Werte setzt, oder das Gewerk beendet.
A Der Tätigkeitsanfang. Es ist für die Abrechnung gegenüber dem Landesamt nicht relevant, von wo das Fahrzeug zum Einsatzort fährt, oder wo es danach hinfährt. Es interessieren nur die Strecken, die im Rahmen des Winterdienstes zu betreuen sind. Beginnt die Winterdienststrecke direkt am Hof (was in den seltensten Fällen vorkommen dürfte) ist A identisch mit dem Einschalten des Geräts. In allen anderen Fällen ist das A an der Stelle zu senden, wo die Winterdienststrecke beginnt, d.h. Anfahrten werden nicht protokolliert. Strecken, die nicht zur Winterdienststrecke gehören, aber dem Bilden einer Winterdienst - Tour dienen, oder in Ortslagen liegen, werden wie vergebene Winterdienststrecken erfasst. Ortsdurchfahrten werden ohnehin herausgerechnet, nicht vergebene Strecken müssen mit dem Landesamt bzw. dem SBA geklärt werden. Jeder Einsatz beginnt mit einem ‚A‘ und endet mit einem ‚E‘. Auf diese Weise können mehrere Einsätze eines Tages in einer Datei verpackt werden, bzw. Daten zur Anfahrt / Abfahrt ausgeklammert werden. E Das Tätigkeitsende. Diese Meldung wird in Analogie zur A – Meldung gesendet, wenn das Fahrzeug die Winterdiensttour beendet (und zum Hof zurückkehrt, ein Salzlager anfährt). Das Fahrzeug bleibt also in Ortslagen, auf Austauschstrecken und ‚Verbindungsstrecken’, die dazu dienen, die im Rahmen der Ausschreibung gewonnenen Strecken sinnvoll zu verbinden auf ‚A’. Erst, wenn der Fahrer die im Rahmen des Winterdienstes zu betreuende Strecke, bzw. die dafür gebildete Route verlässt, ist das ‚E’ fällig. Das ‚E’ bedeutet nur in den Fällen den Hof, wo die Route diesen direkt tangiert. Abfahrtswege von der Winterdienstroute sind also nicht mit zu erfassen. Ein ‚E‘ sollte einen Einsatz beenden. Wenn die Datei nach dem Datensatz der das ‚E‘ beinhaltet endet, ist es kein Problem. Endet der Einsatz ohne ein ‚E‘ und es folgen weitere Daten zur Abfahrt bzw. einer Tour, kann es zu Komplikationen bei der späteren Abrechnung gegen das Landesamt, bzw. beim Vergleich mit den firmeninternen Daten kommen, da die Daten zu der vorherigen Tour hinzugezählt werden. D.h. es entsteht eine ‚längere’ Tour. Endet eine Tour korrekt mit einem ‚E’ und es folgen weitere Tourdaten, werden diese vom Parser ignoriert. D.h., dass eine folgende Tour ‚verschwindet’.
© NOVASIB GmbH Seite 6 von 17
[Seite 7]
A und E Egal wie, da der Tagesumschlag den Einsatz beendet (und auch in der Datenbank später nach Tagen ausgewertet wird) trägt der letzte Datensatz ein ‚E‘ als Kennung. Folgerichtig beginnt die Datei des nächsten Tages nach dem Tagesumschlag mit einem ‚A‘. (Der Parser ergänzt Daten, die nicht an der Datumsgrenze getrennt wurden automatisch um die entsprechenden ‚A’ und ‚E’ Meldungen) (Änderung 10) Außerhalb einer A-E Klammer gibt es keine Daten, die das Programm auswertet ! Sind dort Gewerkeangaben zu finden, werden sie nicht in der Auswertung berücksichtigt, da sich das Fahrzeug noch nicht im Dienst oder nicht mehr im Dienst befand. Wird eine Datei mit Tagesumschlag ausgewertet, trennt der Parser die Daten an der Datumsgrenze, und setzt den ersten Datensatz des folgenden Tages auf ‚A’. Der Teil der Tour, die im folgenden Tag liegt, wird als eigenständige Tour ausgewertet. Die Rückwärtsreferenzierung der Auswertungen zu den Ausgangsdaten erfolgt über die Felder IDA und IDB. Außerdem wird in den Auswertungen vermerkt, dass ein automatischer Tagesumbruch vorgenommen wurde (Angabe 1/2 bzw. 2/2 im Kopf der Auswertung).
(Änderung 10) Q Die Gewerke ändern sich nicht, aber der Fahrer muß die Einstellungen am Streuer korrigieren / ändern. Genau in diesem Fall wird das Q gesendet. Die Tätigkeit muß trotzdem f, g oder h sein ! ‚Q’ schaltet i.d.R. den Streuer nicht ein, sondern erlaubt die Angabe von Streuereinstellungen außerhalb der Streckenintervalle. Das Einschalten des Streuers wird durch ein ‚W’ (Tätigkeitswechsel) eingeleitet. I.d.R. ist die Situation die, dass der Fahrer den Streuer einschaltet, und dann die Streueinstellungen ändert. Der Streuer kann logisch ‚abgeschaltet werden, wenn ein ‚Q’ mit Streuwerten = 0 gesendet wird. Endgültig abgeschaltet wird er durch ein ‚W’ mit der Tätigkeitskennung ‚e’ oder ‚f’. Explizit werden alle Sensoren durch ein ‚E’ (Tätigkeitsende) abgeschaltet, da danach keine Daten mehr ausgewertet werden. Wird nach dem ‚E’ eine neue Tour begonnen (‚A’ – Meldung) müssen die Streuerwerte in dieser neu gesetzt werden. W Diese Meldung kündigt den Wechsel der Gewerke an. Das Schild wird gehoben / gesenkt bzw. der Streuer ein- / ausgestellt oder beide Sensoren sprechen gemeinsam an. Das ‚W‘ ist für die Fälle, wo vom Streuer ein explizites Signal über das Ein- / Ausschalten erzeugt wird, bzw. die erste Meldung vom Streuer überhaupt. Während einer Tour bezeichnet ‚W‘ die erste Streuer - Meldung mit Werten ungleich (0,0) nach einer vorherigen impliziten Abschaltung durch (0, 0). In jedem Fall ist die Reihenfolge wichtig, d.h., daß ‚W‘ vor ‚Q‘ kommt. Während einer Tour kann ein Neubeginn des Streuens durch ein ‚W‘ mit den entsprechenden Werten für den Streuer begonnen werden. Beim Abschalten des Streuers ist es letztlich egal, welche der beiden Meldungstypen die Werte auf 0 zieht. Egal wie, die Tätigkeit muß dann auch auf ‚e‘ oder ‚f‘ gezogen werden. Analog muß die Tätigkeit beim Einschalten des Streuers auf ‚g‘ bzw. ‚h‘ gehen. H Das Fahrzeug ist im Stand, wenn keine Gewerke aktiv sind, und die Koordinaten einen Fangradius von 50 Metern länger als 15 Minuten nicht verlassen. Die Angabe der Standzeit erfolgt inclusive der 15 Minuten Wartezeit zu Beginn. M Die Wende ist als optional anzusehen. In der Tat kann es an Ampeln, Bahnübergängen etc. zum beschriebenen Wandern der GPS – Koordinaten kommen. Als maximale Abweichung zur Identifizierung einer Wende schlagen wir eine Gradänderung von minimal 90° vor. Die Triggerbedingung ist, dass das Fahrzeug in Bewegung sein muß. K In einem Fangradius von 150 Metern ist das Fahrzeug am Netzknoten. Dieser Meldungstyp ist optional und kann verwendet werden, wenn kein Streckenintervall (S) greift und es notwendig erscheint, eine zusätzliche Meldung einzusetzen. Die Notwendigkeit kann z.B. bei hoher Geschwindigkeit oder ungenauem GPS Signal (weniger als 4 Satelliten) in der vorhergehenden Q, W oder S Meldung bestehen. Die K – Meldungen können ausgelassen werden, wenn die ‚S‘- und Gewerkemeldungen Meldungen. Im Netzknotenbereich ausreichen.
Anmerkung : Prinzipiell ist der Empfang bei < 4 Satelliten schlecht, da 3 Satelliten minimal für die Triangulation nötig sind. Der 4. Satellit liefert nicht nur die nötigen Informationen für die Ermittlung der Höhe über dem Geoiden, sondern erhöht außerdem die Sicherheit bei der Positionsbestimmung. Jeder weitere verwendbare Satellit (bis 12) verbessert prinzipiell die Positionsbestimmung, wobei einschränkend erwähnt sein soll, daß die meisten Empfänger lediglich eine Auswahl der am stärksten empfangenen Satelliten vornehmen.
Das Format für die Koordinaten ist das Format des NMEA Protokolls, also zum Beispiel : 5120.3348,01228.2522. Die erste Angabe ist immer der Breitengrad, die zweite immer der Längengrad.
© NOVASIB GmbH Seite 7 von 17
[Seite 8]
4 Body des Protokolls für die Kennungen
K, A, Q, W, E, S, B, H, F
- TÄTIGKEIT bzw. FEHLERCODE char 2 + 1 5
- UHRZEIT Position oder Fehlerzeitpunkt hhmmss char 6 + 1 12
- DATUM (DDMMYY) Datum zur Uhrzeit in Feld 10. char 6 + 1 19 Das Datum ermöglicht die eindeutige Zuordnung der Daten zum Einsatztag. Durch diese Angabe entfällt die Pflicht, Daten vor dem Versandt an die NOVASIB GmbH an der Datumsgrenze zu trennen. Damit entfallen auch alle Anweisungen zur Behandlung der Umbruchdaten. (Änderung 09)
- GENAUIGKEIT char 1 +1 21 (Anzahl der Satelliten: 0 kein Empfang, 1 schlechter Empfang, 4-9 Satellitenzahl) (Das Feld kann leer bleiben, muß aber angelegt werden ! Es darf nicht als Kriterium für ungültige Koordinaten benutzt werden ! siehe Erläuterung am Ende des Dokuments.) (Änderung 05)
- BREITENGRAD char 9 +1 31
- LÄNGENGRAD char 10+1 42
- STREUBREITE in cm char 2 + 1 45
- STREUMENGE in g/m2 char 2 + 1 48
- LAUGEMENGE in Prozent (%) char 2 + 1 51 Die angegebenen Laugenprozente werden von der Salzmenge abgezogen : z.B. : 30g/m2 und 30% Lauge werden als 21g/m2 Salz und 9g/m2 Lauge berechnet.
- Bei H und B die Länge der Standzeit in Sekunden. Die Standzeit wird immer char 5 + 1 57 komplett angegeben ! D.h., dass die Triggerzeit, bis die Standzeit erkannt wird mit dazu gerechnet werden muß ! 0 wenn keine, leer sonst. In allen anderen Meldungen leer.
- STRASSENTEMPERATUR char 4 +1 62 Temperatur der Straßenoberfläche in °C x 10 (-121 = - 12,1 °C) oder wenn keine, Standardwert: ‚1234’ (z.B.: Sensorwerte von ThermoMAT oder Thermologic)
- STREUSTUFE char 1 +1 64 Eingestellte Streustufe für die temperaturabhängige automatische Streudichteeinstellung Werte: 0 .. 4, Standardwert: 0 (z.B.: Thermologic-Step oder Streustufe von ThermoMAT)
- STREUMATERIAL char 2 +1 67 Kodierung des Streuerherstellers oder wenn keine, Standardwert: 0
- STREUBILD char 4 +1 72 2 Stellen Streubreite in dm links + 2 Stellen Streubreite in dm rechts z.B.: 3020 -> 35dm links + 15dm rechts bei einer Gesamtstreubreite von 5m oder wenn keine, Standardwert: 0 (Änderung 17
- WORKCODE für Leistungen char 1 +1 74 Siehe Tabelle 4.3 (Änderung 19)
- STATUSCODE für Fehlerzustände char 2 +1 77 Siehe Tabelle 4.4 (Änderung 19)
- Endezeichen Datensatz CR+LF char 2 79 (Änderung 02)
© NOVASIB GmbH Seite 8 von 17
[Seite 9]
4.1 Tätigkeitscodes und Streuerwerte
| Tätigkeit | ||
|---|---|---|
| e | Kein Sensor | |
| f | Sensor 1 (im Winter das Schild) | |
| g | Sensor 2 (im Winter der Streuer) | |
| h | Sensor 1 + 2 |
4.2 Fehlercodes im Code F
Kein GPS Kontakt A Kein GSM Kontakt B Kein Sensorkontakt C Schnittstellenfehler D
4.3 Workcode
| Workcode | Art der Tätigkeit: | |
|---|---|---|
| 0 | Fahren ohne zu Streuen | |
| 1 | Schneepflug | |
| 2 | Streuen | |
| 3 | Streuen und Schneepflug | |
| 4 | Sprühen | |
| 5 | Sprühen und Schneepflug | |
| 6 | Streuen und Sprühen (Kombi) | |
| 7 | Streuen, Sprühen und Schneepflug (Kombi) |
Die Information ist notwendig um abwechselndes Sprühen, Streuen oder Kombibetrieb zu erfassen.
4.4 Statuscodes für Fehlerzustände
| binär | Bedeutung | ||
|---|---|---|---|
| Statuscode | |||
| 0001 | Warnung Streukontrolle -> kein Salz | ||
| 1 | |||
| 0010 | WLA bzw. VLT aufgeklappt und aktiv | ||
| 2 | |||
| 0100 | |||
| 4 | |||
| 1000 | |||
| 8 |
Es können 4 Fehlerzustände binär codiert übertragen werden.
© NOVASIB GmbH Seite 9 von 17
[Seite 10]
5 Versandt der Daten zu NOVASIB
Die Daten werden tagfertig, spätestens jedoch 3 Tage nach dem Einsatz per Webservice an die NOVASIB übertragen. Später einlaufende Daten werden zu einem gesonderten Tarif berechnet, den der Sub / die Meisterei selbst zu tragen hat. Sollen Daten komplett nachberechnet werden, geschieht dies zu den Konditionen der Firma NOVASIB. Alle fristgerecht übermittelten Daten werden im Rahmen des Vertrages mit der NOVASIB ohne weitere Kosten berechnet.
Der Dateiname der übertragenen Datei folgt der Konvention :
| Einsatzdatum | Start - Zeit des Einsatzes | Endung |
|---|---|---|
| YYYYMMDD | HHMMSS |
Mehrere Dateien dürfen in einem ZIP – Archiv enthalten sein, es dürfen jedoch keine ZIP – Archive in neuen ZIP – Archiven zusammengefasst werden. (Änderung 01) Wird die Datei gepackt, folgt der Dateiname des Archivs der Konvention
| Erstellungsdatum | Start - Zeit der Erstellung | Endung |
|---|---|---|
| YYYYMMDD | HHMMSS | .ZIP |
Die Zugangsdaten des Web-Dienstes zum Upload der Daten werden rechtzeitig vergeben und gelten jeweils für eine Winterdienstsaison.
6 Empfang der Daten von der NOVASIB
Die Berichte werden über das Internet bereitgestellt. Die Referenz zwischen Originaldaten und Auswertungen ist schwer herzustellen. Normalerweise erfolgt die spätere Analyse auf der Basis Tag / Zeit / Fahrzeugnummer bzw. KFZ-KZ. Für exportierte Dateien kann folgendes Format vorgeschlagen werden : KFZNO_DDMMYY_SMSNO. Dazu muß die SMS Nummer natürlich den Forderungen nach Eindeutigkeit für ein Fahrzeug genügen (siehe oben).
6.1 Erweiterte Referenzierung von Originaldaten
Die SMS – Nummer und die im Header angegebenen ID’s (IDA und IDB) werden zusammen mit dem Namen der Originaldatei, der KFZID und der vom NOVASIB System erzeugten Bezeichnung der Auswertungen in der NFO – Datei angegeben. Die NFO – Datei liegt jedem Auswertearchiv bei, dass Auswertungen zu Daten Dritter beinhaltet. Beispiel : 0042; IDA, IDB, 999900200003; 20021225093004.ZIP; T501YLC00101 SMNR, IDA, IDB, KFZID, Originaldatei, Systemname der Auswertungen (Änderung 12)
© NOVASIB GmbH Seite 10 von 17
[Seite 11]
6.2 Format der empfangenen Daten
Die von der NOVASIB erzeugten Archive haben folgendes Format : AXXXYYYIII, also z.B. T237HKB001
AXXXYYYIII A ... Kennung, N für NOVASIB, bzw. T für externe Files XXX ... KFZID aus der Datenbank YYY ... Code für das Datum wobei 1. Stelle Tag A ... Z und 1 ... 5 2. Stelle Monat A ... L 3. Stelle Jahr A ... Z und 1 ... 0 Startjahr ist 2000 III ... Dateinummer. Für NOVASIB Daten ist die Dateinummer immer 1, für externe Daten läuft die Dateinummer mit den Dateien für das Fahrzeug für den Tag nach oben.
Beispiel : N1003LB001 für NOVASIB Daten für das KFZ 100, am 29.12.2001 Datei 1 T237HKB001 für externe Daten für das KFZ 237 am 08.11.2001 Datei 1.
Die Zuordnung der KFZID zu einem KFZ Kennzeichen, oder zu einem anderen Ordnungssystem, ist nur über eine, von der NOVASIB zu beziehenden Liste möglich, aus der diese Zuordnung hervorgeht. (Änderung 04)
© NOVASIB GmbH Seite 11 von 17
[Seite 13]
Die folgenden Beispiele sind nur für den Fall, dass der Datumsüberschlag beim Dienstleister berechnet wird.
7 Beispiel Wartezeit und Datumsüberschlag
Vortag
+999900004630,$NSEXT06,,4,,,241201,235012,S,,,, // Anfang, Datum Einsatztag, letzter Satz ist von 23:50:12 … W,e,234841,241201,8,5049.0054,01043.7552,0,0,0,0,1234,0,0,0, S,e,234934,241201,8,5048.9467,01043.7976,0,0,0,0,1234,0,0,0, W,f,234948,241201,8,5048.9341,01043.8070,0,0,0,0,1234,0,0,0, W,e,235012,241201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, H,e,235012,241201,8,5048.9630,01043.8113,0,0,0,588,1234,0,0,0, // Beginn Wartezeit B,e,000000,251201,8,5048.9630,01043.8113,0,0,0,588,1234,0,0,0, // Ende des Tages, Ende der Wartezeit an diesem Tag; E,e,000000,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Berichtsende Tagesüberschlag: Nächste "SMS" Folgetag
+999900004630,$NSEXT06,,5,,,251201,060106,S,,,, // Kopf vorhergehende SMSNr=4 für ...4630
A,e,000000,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Einsatzbeginn H,e,000000,251201,8,5048.9630,01043.8113,0,0,0,884,1234,0,0,0, // Wiederholung der Halt-Meldung mit Uhrzeit 00:00:00 B,e,001444,251201,8,5048.9630,01043.8113,0,0,0,884,1234,0,0,0, // Neues Ende der Standzeit. Standzeit ist nur die Zeit am Folgetag ! W,f,001444,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Gewerkewechsel, Pflug ist ein (jetzt käme bei Bedarf auch eine 'Q' Meldung) W,e,001531,251201,8,5048.9870,01043.8330,0,0,0,0,1234,0,0,0, // weiter mit der Tour W,f,001602,251201,7,5049.0002,01043.7940,0,0,0,0,1234,0,0,0, S,f,001708,251201,8,5049.2703,01043.6575,0,0,0,0,1234,0,0,0, S,f,001741,251201,8,5049.4542,01043.5262,0,0,0,0,1234,0,0,0, S,f,001756,251201,8,5049.5411,01043.4921,0,0,0,0,1234,0,0,0, …
© NOVASIB GmbH Seite 13 von 17
[Seite 14]
8 Beispiel Datumsüberschlag ohne Wartezeit
Vortag
+999900004630,$NSEXT06,,4,,,241201,235012,S,,,, // Anfang, Datum Einsatztag, letzter Satz ist von 23:50:12 … W,e,235841,241201,8,5049.0054,01043.7552,0,0,0,0,1234,0,0,0, // Tätigkeitswechsel S,e,235934,241201,8,5048.9467,01043.7976,0,0,0,0,1234,0,0,0, // Streckenintervall W,f,235948,241201,8,5048.9341,01043.8070,0,0,0,0,1234,0,0,0, // Tätigkeitswechsel,letzte Meldungdieses Tages W,e,000023,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Tätigkeitswechsel am Folgetag, // erste Meldung des Folgetages E,e,000023,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Ende der Datei, Ende des Einsatzes an diesem Tag Folgetag
+999900004630,$NSEXT06,,5,,,251201,060106,S,,,, // Kopf vorhergehende SMSNr=4 für ...4630
A,e,000023,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Einsatzbeginn W,f,235948,241201,8,5048.9341,01043.8070,0,0,0,0,1234,0,0,0, // Wiederholung der letzten Meldung vom Vortag W,e,000023,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Tätigkeitswechsel am aktuellen Tag, erste Meldung dieses Tages W,f,000124,251201,8,5048.9630,01043.8113,0,0,0,0,1234,0,0,0, // Gewerkewechsel, Pflug ist ein W,e,000231,251201,8,5048.9870,01043.8330,0,0,0,0,1234,0,0,0, // weiter mit der Tour W,f,000302,251201,7,5049.0002,01043.7940,0,0,0,0,1234,0,0,0, W,f,000302,251201,7,5049.0002,01043.7940,0,0,0,0,1234,0,0,0, S,f,000408,251201,8,5049.2703,01043.6575,0,0,0,0,1234,0,0,0, …
© NOVASIB GmbH Seite 14 von 17
[Seite 15]
9 Erläuterungen
(Änderung 05) Das Feld 12 (GENAUIGKEIT) im Body des Protokolls dient der Angabe der GPS Güte. Dieses Feld darf nicht dazu verwandt werden, Koordinaten als ungültig zu deklarieren! Die Auswertesoftware geht in jedem Fall von gültigen Koordinaten aus, und kann eventuelle Fehlmeldungen nicht im Nachhinein korrigieren! Werden Koordinaten außerhalb eines gültigen Rasters gemeldet (z.B. Deutschland) korrigiert der NOVASIB Parser diese auf die erste gültige Koordinate in der übertragenen Datei. Dabei gehen die Strecken verloren, die das Fahrzeug bis zu dieser ersten gültigen Koordinate zurückgelegt hat. Da die Koordinate, die korrigiert werden musste ohnehin falsch war, ist dies die einzige Möglichkeit, zumindest die gemachten Zeitangaben zu ‚retten’.
Soll die NOVASIB solche Koordinaten nicht korrigieren, geht die gesamte Tour verloren oder enthält falsche Strecken- bzw. Zeitangaben für NKN. Solche Datensätze werden von der NOVASIB entsprechend markiert und für Dritte als „fehlerhaft abgeliefert“ ausgewiesen.
Prinzipiell sollten alle an die NOVASIB übertragenen Daten vom Bereitsteller (Versender) auf ihre Sinnfälligkeit hin überprüft werden. Fährt ein Fahrzeug zum Beispiel im Winterdienst in Thüringen, sollten die Koordinaten auch im Koordinatenfenster für Thüringen liegen. Hat das Fahrzeug Austauschstrecken nach Bayern, Hessen, Sachsen-Anhalt oder Sachsen, muss dies vom Versender bei der Korrektur berücksichtigt werden.
Bsp. Für ein Fahrzeug eines Dienstleisters am 07.11.2002. A,e,030153,071102,0,0000.0000,00000.0000,0,0,0,0,1234,0,0,0, falsche Koordinate M,e,031209,071102,1,5123.2979,01019.7413,0,0,0,0,1234,0,0,0, S,e,031224,071102,1,5123.3355,01019.6226,0,0,0,0,1234,0,0,0, M,e,031236,071102,1,5123.3402,01019.5361,0,0,0,0,1234,0,0,0, S,e,031251,071102,1,5123.2942,01019.4176,0,0,0,0,1234,0,0,0, S,e,031257,071102,1,5123.2793,01019.3742,0,0,0,0,1234,0,0,0, S,e,031301,071102,1,5123.2739,01019.3475,0,0,0,0,1234,0,0,0, S,e,031328,071102,4,5123.2640,01019.3046,0,0,0,0,1234,0,0,0, ...
Die Tour beginnt an der Koordinate (0, 0). Wird nicht korrigiert, wird der Datensatz mit dem Einsatzbeginn ‚A’ verworfen. Das heißt, das die Tour keinen Anfang hat. Da nach Definition jede Tour mit einem ‚A’ beginnen und mit einem ‚E’ enden muss, wird keine Tour erzeugt. Für dieses Fahrzeug entsteht aus der übermittelten Datei damit keine abrechnungsfähige Auswertung.
Wird korrigiert, erhält der erste Datensatz dieselbe Koordinate wie der erste Datensatz mit gültigen Koordinaten, in diesem Fall also die Koordinaten des zweiten Datensatzes. Damit sieht der Datenblock so aus: A,e,030153,071102,0,5123.2979,01019.7413,0,0,0,0,1234,0,0,0, korrigierte Koordinate M,e,031209,071102,1,5123.2979,01019.7413,0,0,0,0,1234,0,0,0, S,e,031224,071102,1,5123.3355,01019.6226,0,0,0,0,1234,0,0,0, M,e,031236,071102,1,5123.3402,01019.5361,0,0,0,0,1234,0,0,0, S,e,031251,071102,1,5123.2942,01019.4176,0,0,0,0,1234,0,0,0, S,e,031257,071102,1,5123.2793,01019.3742,0,0,0,0,1234,0,0,0, S,e,031301,071102,1,5123.2739,01019.3475,0,0,0,0,1234,0,0,0, S,e,031328,071102,4,5123.2640,01019.3046,0,0,0,0,1234,0,0,0,
Im Beispiel entsteht eine Standzeit von 10 Minuten und 16 Sekunden. Die Streckenlänge beträgt 0 Meter. Da die wirkliche Position des Fahrzeugs um 03:01:53 von niemandem mehr rekonstruiert werden kann, Ist diese Methode die einzige, um wenigstens die Zeitangabe und die Gesamttour zu retten.
© NOVASIB GmbH Seite 15 von 17
[Seite 16]
10 Änderungsliste
| Dok Nr. | Datum | Änderungsinhalt, Seite | Änderung erfolgt aufgrund: (ext. Dokument, Telefonat etc.) | Verant- wortlich: | ||
|---|---|---|---|---|---|---|
| 01 | 18.09.2002 | mehrere Dateien in einem Archiv | Es wird nur eine Datei pro Archiv verpackt | Haymo Jupè | ||
| 02 | 18.09.2002 | Zeilenende | Das Zeilenende mit CR + LF (0x0D 0x0A) ist ab sofort nicht mehr optional, sondern Pflicht für externe Daten | Haymo Jupè | ||
| 03 | 18.09.2002 | Uhrzeiten | Uhrzeiten sind immer MEZ bzw. MESZ. D.h. es werden keine UTC-Zeiten übertragen ! | Haymo Jupè | ||
| 04 | 30.10.2002 | Format der versendeten Dateien | Erläuterung des | Haymo Jupè | ||
| Namensformats der | ||||||
| exportierten Archive. | ||||||
| 05 | 26.11.2002 | Angabe der GPS Güte | Das Feld zur Angabe der | Haymo Jupè | ||
| GPS Güte dient nicht dem | ||||||
| Ausschluß ungültiger | ||||||
| Koordinaten. | ||||||
| 06 | 10.07.2003 | Header | Der Header wurde von 7 auf | Haymo Jupè | ||
| 9 Felder erweitert. Die | ||||||
| beiden neuen Felder sind | ||||||
| die Felder 05 (IDA) und 06 | ||||||
| (IDB). Die folgenden Felder | ||||||
| rutschen in ihrer | ||||||
| Nummerierung | ||||||
| entsprechend nach hinten. | ||||||
| 07 | 10.07.2003 | Protokollname | Der Protokollname wurde | Haymo Jupè | ||
| von NSTSI02 auf NSEXT03 | ||||||
| geändert. | ||||||
| 08 | 10.07.2003 | Fehlermeldungen | GPS und GSM Fehler | Haymo Jupè | ||
| dürfen nicht zur | ||||||
| Übersteuerung von | ||||||
| Datensätzen genutzt | ||||||
| werden. Ergänzt Änderung | ||||||
| 05. | ||||||
| 09 | 10.07.2003 | Body | Erweiterung des Bodys von | Haymo Jupè | ||
| 9 auf 10 Felder. Es wurde | ||||||
| das DATUM als Feld 11 | ||||||
| eingefügt. Nachfolgende | ||||||
| Felder rutschen in ihrer | ||||||
| Nummerierung nach hinten. | ||||||
| 10 | 10.07.2003 | Tagesumbruch | Parser wertet den | Haymo Jupè | ||
| Tagesumbruch in den | ||||||
| Originaldaten selbst aus, | ||||||
| und macht entsprechende | ||||||
| Vermerke in den | ||||||
| Auswertungen. |
© NOVASIB GmbH Seite 16 von 17
[Seite 17]
| 11 | 10.07.2003 | Standzeiten und | Anmerkung zur Behandlung | Haymo Jupè | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Tagesumbruch | von Standzeiten | |||||||||||||
| 12 | 10.07.2003 | NFO Datei | NFO Datei | Erweiterte Referenzierung | Haymo Jupè | |||||||||
| von Originaldaten | ||||||||||||||
| 13 | 31.08.2005 | Header - SNRID | ID zur Identifizierung von | Haymo Jupè | Haymo Jupè | |||||||||
| KFZ / Gerätekombinationen, | ||||||||||||||
| oder zur Angabe einer | ||||||||||||||
| weiteren Fahrzeug-ID | ||||||||||||||
| (20 Stellen) | ||||||||||||||
| 14 | 31.08.2005 | Header - FID | ID zur Identifizierung des | Haymo Jupè | ||||||||||
| Fahrers (20 Stellen) | ||||||||||||||
| 15 | 31.08.2005 | Header - BFID | ID zur Identifizierung des | Haymo Jupè | ||||||||||
| Beifahrers (20 Stellen) | ||||||||||||||
| 16 | 10.07.2003 | Protokollname | Der Protokollname wurde | Haymo Jupè | Haymo Jupè | |||||||||
| von NSEXT03 auf NSEXT05 | ||||||||||||||
| geändert. | ||||||||||||||
| 17 | 08.01.2010 | Erweiterung zu Version 06 | Protokoll um zusätzliche Felder erweitert. | Haymo Jupè | ||||||||||
| 18 | 10.12.2013 | Layout, alle Seiten | Steffen Günther | |||||||||||
| 19 | 05.12.2018 | Erweiterung zu Version 07 | Protokoll um zusätzliches Feld erweitert. | Steffen Günther | ||||||||||
| 20 | 09.05.2023 | Adresse geändert, FTP entfernt | Steffen Günther |
© NOVASIB GmbH Seite 17 von 17