Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
PŘÍLOHA Č. 8
KOMUNIKAČNÍ PROTOKOL SLEDOVÁNÍ VOZIDEL
1 VŠEOBECNĚ
Příloha sestává ze dvou dílčích dokumentů určujících rozsah, obsah, formát a způsob předávání dat.
Jsou to:
1/ Technický předpis datového formátu telemetrických údajů, definující formát, obsah a rozsah
požadovaných dat a vysvětlující souvislosti a povinnost, či nepovinnost předávat určité údaje
v souvislosti s vykonávanou činností, použitou technologií a druhem vozidla, či stroje.
2/ Technický předpis funkce sběru telemetrických dat a jejich předávání definující pojmy,
předepsané technické vybavení vozidel a strojů. Způsob a rozhraní pro komunikaci při předávání
dat. Závazné postupy a omezení při předávání dat.
Oba tyto dokumenty jsou nedílnou součástí PŘÍLOHY Č. 8 této zadávací dokumentace.
Jsou pro podání nabídky závazné a jsou v nich obsaženy všechny potřebné konkrétní specifikace a
informace technického charakteru.
2 POŽADAVEK NA DRUHY VOZIDEL, MAJÍCÍ POVINNOST PŘEDÁVAT DATA
KOMUNIKAČNÍM PROTOKOLEM
požadavek na GPS
Rámcová dohoda DIO Mechanizace Odvoz odpadu
Spáry a trhliny CBK ano X ano
Spáry a trhliny AHV ano X X
Technický předpis datového formátu
telemetrických údajů
Verze 1.2 Ze dne: 25. 10. 2023
Obsah
1. Účel DOkUMENtU ............... ooo eee eee eee none K en RAK KAP ARR AA KRKA KRAS nA Aaa a Aaa n tat 2
1.1 ODE P 2
1.2 Zřňěný oproti predehází We P Z z s 30430850 8330 VRH OH KA 2
2 Dbšák OÁT z: zs 05 666800088 RAKA SR NON R RGB SOA ERA HRA BABA 3
KOJ LAT V n Cz DC- oN 12
3.1 Příklad XML záznaMU .................0.........e200 0000000000000 0 0000000 e Ke KK Ke Ke Ke Pe K PA KAP K Ke Pe P anon nete 12
4 | Testování a ověření korektnosti datové sady ............................4.*44+++++*<<<<<%<<<(((KÚeeeesa000000000e 14
4.1 Použití testovací aplikace datových Sad.........................%%%444<.4<4444444+4+44440s400010100eeeeerr6es 14
4.2 Sčěnář Testo VÁNÍ 3-30- FR 058 FR FA R00 08 FRA RR EK HE WF KR EKK RKO EKK A 14
43 Výsledky TěSLOVÁNÍ sz 088808 KARA ABAK ARM CRAR ARA AAA AE ARA ARR VRR S SR AL DAR ARA R S 16
1. ÚČEL DOKUMENTU
Tento předpis stanovuje závazné požadavky n předávaná data telemetrických údajů z GPS jednotek.
Stanoví formát, strukturu, obsah a povinnost jednotlivých datových položek. Stanoví rovněž
podmínky, za kterých jsou příslušná data vyžadována. Dodržení ustanovení tohoto dokumentu je
předpokladem ke korektnímu zpracování zaslaných datových sad.
1.1. Obecný přehled
Datové sady jsou předávány na veřejná technická rozhraní R a S poskytovaná na URL adresách
zveřejněných na webu https://podporagps.rsd.cz. Způsob technické realizace komunikace s těmito
rozhraními je definován v dokumentu Technický předpis funkce sběru telemetrických dat a jejich
předávání v jeho aktuální verzi.
1.2 | Změny oproti předchozí verzi
Změny verze 1.2 oproti verzi datové sady definované ve verzi 1.1
« | Vdatové větě LIGHTTRAILER, byla zrušena pro dodavatele povinnost předávat atributy
lighton, modearrow, akuvoltage a rampup
Změny verze 1.2 oproti verzi datové sady definované v dokumentu KOMUNIKAČNÍ PROTOKOL 1.0
« | oddělena dokumentace formátu datové sady od komunikačního protokolu
« | přidán povinný konstantní atribut version do elementu CREATED
e | přidány atributy RoadState, RoadSlip, WaterLevel a CriticalWarning do elementu
TEMPERATURE
e | doplněno omezení počtu číslic u atributu gpsunitid elementu GPSRECORD
* | doplněna omezení délky textu u atributu RZ, driver a company elementu VEHICLEINFO
e | upřesněn datový typ a formát atributu gram elementu SPREADINGINFO
e | doplněn znak * vedle názvu elementu, označující elementy, které jsou povinné v libovolné
datové sadě
* © upraven příklad XML záznamu datové sady, aby odpovídal verzi 1.1 protokolu
« © doplněn popis webové aplikace pro testování přenosu datové sady a jejího parsování a
podoby dat ukládané do systémů ŘSD
« | Vdatové větě LIGHTTRAILER, byla zrušena pro dodavatele povinnost předávat atributy
lighton, modearrow, akuvoltage a rampup
2 OBSAHDAT
U pojmenování atributů a elementů v XML nezáleží na velikosti písmen. Hvězdička * vedle názvu elementu vyznačuje jeho povinnost v každé datové sadě
a není součástí názvu elementu.
Název Atribut Popis Formát Rozsah hodnot Jednotky Povinný
| Záhlavní XML dokumentu | | | | ANO
Příklad:
| | | | (ANO
Příklad:
Čas vygenerování YYYY-MM- ANO
DDTHH:MM:SS
+HH:MM
version Identifikátor verze datové sady Konstantní text | „1.1“ ANO
2014-05-27T14:18:31+01:00
gpstime Reálný čas, kdy byl záznam pořízen v YYYY-MM- ANO
GPS jednotce v SEČ (SELČ) DDTHH:MM:SS
+HH:MM
gsmsignal Kvalita signálu GSM (0-5, O=bez signálu, | Číslo 0-5 ANO
B=silný signál)
satellitecount | Počet satelitů Číslo Kladné celé číslo ANO
gpsunitid Jednoznačný identifikátor GPS jednotky | Číslo Kladné celé číslo ANO
(max. 20 číslic)
Příklad:
Název Atribut Popis Formát Rozsah hodnot Jednotky Povinný
VEHICLEINFO* © Registrační značka vozidla Text 1-15 znaků ANO
Type Druh vozidla Číslo dle 1 = Osobní vozidlo ANO
rozsahu
2 = Dodávkové vozidlo
3 = Nákladní vozidlo
4 = Traktor / stroj
5 = Přívěsný vozík
6 = Osoba
Driverid ID řidiče Číslo Kladné celé číslo dle ANO,
databáze zadavatele NE dodavatelé údržby
Driver Jméno a příjmení řidiče Text 1-30 znaků NE,
ANO dodavatelé údržby
Company Název dodavatele Text 1-20 znaků NE,
ANO dodavatelé údržby
idvehicleorig Identifikátor vozidla Číslo Kladné celé číslo ANO
technology Nesená nástavba Číslo dle 1 = sypač ANO, pouze u VEHICLEINFO/type = 2,3,4
rozsahu 2 = sekačka
3 = samosběr
4 = kropice
5=valník
6 = nosič kontejnerů
7 =ostatní
Příklad:
a kódováním UTF-8
Kompletní popis dat pro všechna vozidla vyplývá z níže uvedené tabulky, kde jsou také uvedeny
popisy, hodnoty, kterých nabývají, jednotky a informace v jakých případech jsou dané parametry
povinné. V případě, že je nějaká odlišnost mezi vozidly ŘSD ČR a dodavatelů údržby, je toto uvedeno
v posledním sloupci. Použití je pak dáno uvedenými příklady.
3.1. Příklad XML záznamu
Pro ilustraci přikládáme příklad kompletního XML záznamu. Tento příklad je pouze ilustrační a má
ukázat využití všech atributů a v praxi nemůže nastat.
2018-05-27T14:18:31+01:00
V případě, že typ vozidla nebo typ jízdy nevyžaduje předání informací, vynecháváme při zasílání
celou datovou větu. Například, není-li vozidlo sekačkou, element CUTSINFO bude vynechán.
Elementy, které musí obsahovat povinně každá datová sada GPSRECORD jsou v tabulce OBSAH DAT
označeny hvězdičkou vedle názvu elementu.
4 TESTOVÁNÍ A OVĚŘENÍ KOREKTNOSTI DATOVÉ SADY
Za účelem možnosti ověření správnosti formátu a dat obsažených v datových sadách byla
vytvořena testovací a aplikace a zveřejněna na portálu https://podporagps.rsd.cz/DataTest
Pro možnost aplikaci používat je nutné, aby si poskytovatel datových sad GPS vyžádal svůj unikátní
klíč APIKEY u pověřeného pracovníka ŘSD.
4.1 Použití testovací aplikace datových sad
Do pole APIKEY vložte klíč, který Vám byl přidělen pracovníkem ŘSD. Obsah zprávy GPS vkládejte
bez kořenového elementu DOC v kódování UTF-8, poté stiskněte tlačítko Test, přijetí zprávy na
rozhraní je indikováno zeleným zaškrtávátkem, v případě, že se objeví červený křížek, zkontrolujte
obsah zprávy a váš APIKEY a akci opakujte. Poté vyčkejte zpracování, dokud je zobrazen prvek
probíhající činnosti na místě tlačítka Test. Následně se objeví přehledný obsah záznamu, který
vznikl v testovací DB v levé části stránky, spolu s opisem převzatých dat na rozhraní a seznamem
chyb a vad. V části pravé Pro opakovaný test použijte tlačítko Reset, které připraví formulář pro
další test s novými daty. Váš APIKEY zůstane zadán.
4.2 | Scénář testování
Uživatel zadá APIKEY a Obsah zprávy
Stiskne tlačítko Test
Aplikace zavolá protokolem HTTPS REST API Funkci TestLoad a předá jí APIKEY a Obsah zprávy
obohacený o vygenerovaný rootový element DOC , kde Clientld bude vygenerovaný jedinečný
BIGINT , volání je synchronní a počká na návratovou hodnotu (OK - 2XX / Error )
APlKey a
n4k5jin8Snjnf02n3f02m30r9ng32IK7h1f32690d5ns0dfm3g7hsevs si i ré
| Do pole APIKEY vložte klíč, který Vám
Obsah zprávy byl přidělen pracovníkem ŘSD. Obsah
=GPSDATA> zprávy GPS vkládejte bez kořenového
2018-05-27T14:18:31+01:00 elementu DOC v kódování UTF-B,
zůstane zadán.
(ee
Aplikace si zapamatuje Clientld
Aplikace zobrazí indikátor nic / zelené zaškrtávátko / červený křížek (indkátor úspěchu odeslání)
na zíkladě vrácené hodnoty volání
V případě, že volání skončilo OK, dojde k zobrazení indikátoru nic/ přesýpací hodiny (indikátor
čekání na zápis do DB), znepřístupní se tlačítka Test a Reset a spustí se interní Timer, který vyčká
10 Sekund
APiKey o
n4k5jtn89njnf02n3f02m30f9ng32Ik7h1f32890d5nsOdfm3g7hscvs
Obsah zprávy
2018-05-27T14:18:31+01:00
SGPSDATA>
2018-05-27T14:18:31
01:00
, :
: « ax/ ů A
|
Odeslání dat do
Příjem dat REST fronty - řízené
| / časovačem | |
< je“ “ « w Ď
502 -
ze WSO2 Resender Y
SOAP2REST Data s
i transformace / Prose
Krátkodobá diskové v ————
4 ké
M vw > - jd >
ýstupní Cache O : BA ; X
ho A (| Odesílání dat do
: i fronty řízené
Příjem dat Socket Zaan
sovač
x Ž X >
, L =
upní tabulka A ll A
B
Validace Aktiviit a cache
l augmentace dato
oblasti a obvody
na základě geo
- Ba >.
X
ZOE 3 Parsování a
Dávkové vkládání í
t ožišt dat řízené Krátk diskov J | tokenizace dat do (3
Finální tabulka úožiště only cache ýchdat datových objektů
sa: časovačem . o
sa. / třídy záznam
— —-—-HU“< -U NS „£ h „
: S -0
Výše uvedené schéma DTD (data transfer diagram) je přiloženo pro informaci a může být vodítkem
pro pracovníky IT poskytovatelů telemetrických dat při úvahách o návrhu a realizaci klientských
služeb pro předávání telemetrických dat.
Vstupní body R a S reprezentují veřejná rozhraní. R reprezentuje HTTP/REST API rozhraní,
S reprezentuje Socket TCP/IP rozhraní.
Vstupní bod E reprezentuje rozhraní HTTP/SOAP , které již není ve verzi 1.1 podporováno pro nově
uzavírané smlouvy a je zachováno pouze z důvodu zpětné kompatibility s rozhraním verze 1.0
platným pro dobíhající smlouvy.
Vstupní bod O je interní a veřejně nepřístupný.
Z uvedeného schématu vyplývá, že příjem telemetrických dat a jejich zpracování v systému ŘSD
probíhá asynchronně a pro účely kompenzace vysokých zatížení v určitých momentech, například ve
chvíli nepříznivých meteorologických podmínek je odděleno přijetí dávky telemetrických dat od jejího
parsování, validace obsahu a zavedení do relační databáze střednědobou frontou.
Z tohoto uspořádání vyplývají i některé zásadní charakteristiky systému pro příjem telemetrických
dat v interakci s klientskými službami zasílání telemetrických dat na straně poskytovatelů.
« | Převzetí telemetrických dat na rozhraní je synchronní, ale další zpracování je asynchronní,
z toho vyplývá, že rozhraní Ri S vracejí návratové hodnoty chybových stavů související pouze
s komunikací, předáním a převzetím datové sady a s formátem datové sady. Případné chyby
a vady obsahu datové sady (nevalidní rozsah hodnot, chybějící povinné elementy a datové
věty pro daný typ provozovaného vozidla a další) zde vyhodnocovány nejsou a nejsou tedy
ani součástí synchronní odezvy.
« | Veškeré pokyny uvedené v tomto předpisu, týkající se frekvence předávání dat a případných
časových limitů se vztahují na předání datové sady prostřednictvím jednoho ze synchronních
rozhraní R nebo S a poskytovatel dat nemusí počítat s žádnou rezervou na zpracování dat
vnitřními mechanismy systémů ŘSD
« | Okaždé ať již úspěšně nebo neúspěšně předané datové sadě se v rámci celého mechanismu
jejího zpracování v systémech ŘSD vede auditní záznam — stopa. Do této auditní stopy jsou
zaznamenávány i případné problémy s obsahem dat, rozsahem hodnot atd. Přístup
k auditním stopám je k dispozici pověřeným pracovníkům ŘSD.
* V případě rozhraní R je k dispozici API nazvané R-ERR, zprostředkující feed chybových
záznamů z auditní stopy, včetně identifikátoru původní předávané datové sady. Záznamy ve
feedu jsou odstraňovány s předáním klientské službě voláním R-ERR API nebo, nejsou-li
vyzvednuty, tak po 24 hodinách od vzniku.
2.4 | Protokoly a rozhraní
2.4.1. TCP/iIP— Rozhraní S
Klient se připojí k serveru na předem definovanou adresu URL a port.
Např. GPST.RSD.CZ:45123
Po navázání spojení se přenese celý obsah zprávy, která je tvořena daty ve formátu XML obsahujícími
standardní XML hlavičku a vlastní data v rootovém elementu .... .
Server při příjmu dat kontroluje, zda datový blok XML obsahuje počátek a zakončení rootového
elementu. Přijetím rootového elementu , očekává zároveň převzetí odezvy klientem.
Po ukončení přenosu dat se klient přepne do režimu příjmu a příjme zprávu o chybách přenosu, která
obsahuje, v případě korektně přijatých dat pouze dva znaky „OK“, v případě, že v přenosu dat došlo
k chybě, obsahuje její kód, a detailní popis, jehož délka se může lišit. Tato kontrola slouží k
zabezpečení přenosu a vyloučení chyb během přenosu.
2.4.1.1. Komunikační diagram
TCP Server
socketí)
i
bind)
i
listení)
i
TCP Client acceptí)
socket) blocks until
connection
from client
connect() =————— TCP connection establishment ——-
i
= Wwrite() F data (reguest)
do something
i
= write()
m data (reply)
read()
i
closef() EOF notification ————Vg readí)
o T
closef()
náš
Komunikace je synchronní, očekává se, že klient po odeslání každé relace počká s další relací na
potvrzení předcházející přijetím „OK“. V případě, že server vrátí cokoliv jiného než „OK“, má se za to,
že data nebyla úspěšně přenesena. Výjimkou je chybový kód „44X“, zde došlo k přenosu zprávy, ale
klient odmítl převzít výsledek přenosu. V případě, že tento výsledek byl OK, zpráva je přijata.
U veškerých přenosů je předpokládáno kódování textu UTF-8.
2.4.1.2 — Komunikace na socketu - zásady
1/ Přijímat odpověď — data považovat za odeslaná až v případě potvrzení zprávou „OK“
2/ Přijímat a reagovat na chyby - jsou zasílány jako odpověď na komunikaci
3/ Neresetovat zbytečně spojení v průběhu
4/ Nezasílat zprávy delší než 512 KB (přibližně), nebo vyžadující konektivitu a přenos delší než 3
sekundy
5/ Nezasílat z jednoho klienta více než 3 spojení za sekundu (nejedná se o bloky zpráv, ale opravdu o
spojení)
6/ Respektovat limit max. 10 konkurenčních klientů a umět reagovat na odmítnutí spojení a případné
chyby 46X- v případě prokazatelné potřeby lze individuálně dojednat navýšení škálováním do šířky a
load balancerem
7/ Řešení bylo navrženo na rovnoměrnou komunikaci s jednotlivými GPS jednotkami, koncentrace a
dávkové zasílání může znamenat přetížení, nesnažte se tedy data ukládat v bufferech na straně
klientských služeb a odesílat je hromadně.
2.4.1.3. Technická omezení a doporučení
Parametr Rozmezí Doporučená
hodnota
Prodleva mezi relacemi >=10ms 20ms
Prodleva po neúspěšném pokusu o navázání relace >=100ms 1s
Velikost přenášené zprávy 1kB - 786 kB = 64 kB
Doba trvání relace 50ms— 1200ms <1000ms
Paralelní relace <=10
2.4.1.4 Zabezpečení
Metody pro autentizaci a šifrování komunikace nebyly na vyžádání poskytovatelů dat
implementovány.
2.4.1.5 — Chybové stavy a očekávaná reakce na straně klientské služby
Chyby a odezvy Očekávaná reakce klienta
OK Odeslání datové sady proběhlo bez problémů
41X — Problémy navázání konexe Kontrola kvality konektivity do internetu
42x — Neplatná komunikace a uzavření kanálu © [Ověření správné funkce klientské aplikace
klientem
43X — neplatný obsah zprávy, neúplná zpráva Nové odeslání úplné zprávy nebo zprávy ve
neobsahující konec správném formátu XML
44x — klient odmítl přijmout potvrzení OK nebo [Provést kontrolu přijímání potvrzení a chyb, ale
oznámení chyby konkrétní datovou sadu již vícečetně nezasílat
45X — neočekávaná přerušení komunikace RST a [Kontrola kvality konektivity do internetu
timeout
46X — Session Flood — příliš velký počet spojení, |Omezit počet navazovaných spojení, jejich frekvenci
příliš dlouhá zpráva, příliš mnoho klientů a dobu odesílání datových sad, tak jak je uvedeno
v bodu „Komunikace na socketu — zásady“
47x - Problémy přístupu k rozhraní fronty Zvážit snížení frekvence odesílání datových sad,
, : “ „. pokud je výrazně vyšší, než požadované minimum
48x - Zámek nebo timeout při odeslání do fronty , Wm
dle ustanovení tohoto dokumentu. V případě
49x - Jiná chyba modulu Socket opakovaného výskytu kontaktovat podporu v ŘSD
2.4.1.6 | Ukázkový kód (.NET Core— Cf)
using Microsoft.Extensions.Logging;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;
namespace SSL TCP Protocol Client
i
//[1
//[/ Non secure Tcp client - for non-server actions
/[1
public class NsTcepClient
i
Hregion Private NsTcpClient properties
private readonly TcepClient client;
private readonly ILogger logger;
private readonly NetworkStream networkStream;
Kendregion
Hregion NsTepClient constructor
public NsTcpClient(string machineName, ILogger logger)
i
„logger = logger;
// Create a TCP/IP client socket.
// machineName is the host running the server application.
try
í
TepClient client = new TepClient();
IPEndPoint endPoint = new IPEndPoint(IPAddress.Loopback, 3050);
„client.Connect(endPoint);
„logger.LogDebug("Client connected.");
/! Create a NetworkStream to access the client's stream.
„networkStream = client.GetStream();
3
catch (SocketException err)
i
port);
3
„logger.LogError(err.Message);
public NsTcpClient(string adress,int port, ILogger logger)
i
3
„logger = logger;
// Create a TCP/IP client socket.
// machineName is the host running the server application.
try
f
TepClient client = new TepClient();
IPEndPoint endPoint = new IPEndPoint(IPAddress.Parse(adress),
„client.Connect(CendPoint);
„logger.LogDebug("Client connected.");
// Create a NetworkStream to access the client's stream.
„networkStream = client.GetStream();
3
catch (SocketException err)
í
„logger.LogError(err.Message);
Kendregion
Hregion Public methods ReadMessage, SendMessage and CloseClient
public Task ReadMessage()
i
3
// Read the message sent by the server.
// The end of the message is signaled using the
// "" marker.
byte[] buffer = new byte[20u8];
StringBuilder messageData = new();
int bytes;
do
i
bytes = onetworkStream.Read(buffer, 0, buffer.Length);
// Use Decoder class to convert from bytes to UTF8
// in case a character spans two buffers.
Decoder decoder = Encoding.GetEncoding("utf-8").GetDecoder();
char[] chars = new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder .GetChars(buffer, ©, bytes, chars, 0);
messageData.Append(chars);
/f Check for /DOC.
if (messageData.ToString().Indexof("") != -1)
i
break;
3
3 while (bytes != 0);
return Task.Run(() => messageData.ToString());
public Task SendMessage(string messageData)
i
int charscn
int Loopctr
do
1
messageData.Length;
0;
int chunkLength = (messageData.Length — 1024 * loopctr) >= 1024 ?
1024: (messageData.Length - 1024 * loopctr);
char[] messagePart = messageData.Substring(1024 * Loopctr,
chunkLength).ToCharArray();
// Use Encoder class to convert from bytes from UTF8
// in case a character spans two buffers.
Encoder encoder = Encoding.UTF8.GetEncoder();
byte[] bytes = new byte[encoder.GetByteCount(messagePart, 0,
chunkLength, true)];
encoder .GetBytes(messagePart, ©, chunkLength, bytes, 0, true);
„networkStream.Write(bytes);
charscn -= chunkLength;
Loopctr++;
3 while (charscen != 9);
return Task.CompletedTask;
3
public void CloseClient()
í
if ( networkStream!=nulL 86 | networkStream.CanWrite)
„networkStream.Close();
if ( client!=null) client.Close();
„logger.LogDebug("Client closed.");
Kendregion
2.4.1.7 — Testová metoda pro Unit testy
[TestMethod]
public async void Test RSD NS Client()
i
using var LoggerFactory = LoggerFactory.Create(builder =>
builder.AddFilter("Microsoft", LogLevel.Warning)
„AddFilUter("System", LogLevel.Warning)
„AddFiUter("UnitTestl", LogLevel.Debug));
logger = loggerFactory.CreateLogger();
NsTcpClient nsClient = null;
// Directory, where are the tes data sets stored as XML files
string[] files =
Directory.GetFiles(©"X:XRSDNGPS vstup", "*.xml",
SearchOption.AUlDirectories);
nsClient = new NsTepClient("grv-gpst.rsd.cz", logger, false);
Assert.IsNotNull(nsClient);
foreach (string fileName in files)
i
// Send message to the server.
await nsClient.SendMessage(File.ReadAllText(fileName));
// Read message from the server.
string serverMessage = await nsClient.ReadMessage();
Assert.AreEgual(serverMessage, "0R");
nsCLient.CloseClient();
2.4.2 RESTAPI— Rozhraní R
Rozhraní umožňuje zasílat data zpráv GPS na REST rozhraní definované následujícím Swagger
popisem:
2.4.2.1 Definice REST API
í
"openapi": "3.0.1",
"info"z (£
"fitle": "GPS Records REST Berver",
"version": "vl"
I,
"paths": 1
"/GPSRecords/HeartBeat": (
"get"
"tags“"í [
"GPSRecords"
1,
"responses": (
"200": 4
"description": "Success"
I,
"/GPSRecords/State": |
"get":
"tags": [
"GPSRecords"
1,
"responses": (|
"200": +
"description": "Success"
I,
"/GPSRecords/PostMessage": (
"post": (
"tags": [
"GPSRecords"
1,
"parameters": [
Í
"name": "messagelId",
"3
1n
T č "guery",
"schema":
"type": "string",
"format": "uuid"
"name": "remoteIPAddress",
"5
LL
TY ž "guery",
"schema": 1
"type": "string",
"nullable": true
],
"reguestBody": (
"content": (
"text/plain": (£
"schema": 1
"rype“"“ "střing",
"nullable": true
i
]
i
I,
"responses": (£
"200":
"description": "Success"
]
]
]
]
I,
"components": ( )
2.4.2.2 Metody rozhraní
* © Metoda /GPSRecords/ HeartBeat se použije jako ověření, že je rozhraní připraveno a
nedochází k timeoutu.
* © Metoda /GPSRecords/ PostMessage přijímá jako parametry
hodnoty "messageld" a "remotelPAddress“, kde messageld je jednoznačným identifikátorem
zprávy ve formátu GUID, sloužícím později k párování datové sady s feedem chyb auditního
záznamu a remotelPAddress je řetezec uvádějící zdrojovou IP adresu. V těle zprávy pak
metoda očekává data předávaná jako MIME "text/plain"
Datovou sadou je obsah zprávy, která je tvořena daty formátu XML dle dokumentu Technický
předpis datového formátu telemetrických
2.4.2.3. Zabezpečení
Volání je prováděno se šifrováním protokolem HTTPS
2.4.2.4 | Chybové stavy a reakce na chyby
Obě metody vracejí chybové kódy dle standardu protokolu http/2.0. Úspěšné volání metody je
identifikováno návratovým kódem 200.
V případě chyby jsou vraceny kódy 500.YYY, kde YYY představuje vlastní detail kategorie kódu chyby:
31X REST — chyba volání metody
32X REST — chyby obsahu a kódování znaků
33X REST — nedostupnost nebo timeout interní cache
37X Problémy přístupu k rozhraní fronty
38X Zámek nebo timeout při odeslání do fronty
39X Jiná chyba modulu REST
Chyby 500.31X— 500.33X jsou vraceny na klienta, ostatní chyby jsou zapsány pouze do auditního
logu.
Pouze chyby 500.33X jsou řešitelné opakovaným voláním metody se stejným obsahem s prodlením. U
ostatních chyb vede takové řešení pouze k obdržení stejného chybového hlášení a důrazně se na
klientu nedoporučuje.
2.5 | Popis dat a formát
Data budou předávána v obecném a standardizovaném formátu XML (Extensible Markup Language).
Kompletní popis dat pro všechna vozidla vyplývá ze samostatného dokumentu Technický předpis
datového formátu telemetrických údajů, kde jsou také uvedeny popisy, hodnoty, kterých nabývají,
jednotky a informace v jakých případech jsou dané parametry povinné. V případě, že je nějaká
odlišnost mezi vozidly ŘSD ČR a dodavatelů údržby, je toto uvedeno v dokumentu jako poznámka ke
konkrétní položce.
Podrobné informace o formátech, číselníky, příklady a návody jsou umístěny jako aktuální a
předchozí podporované verze tohoto dokumentu a dokumentu Technický předpis datového formátu
telemetrických údajů na stránkách https://podporaGPS.rsd.cz. Ke všem informacím uvedených na
těchto stránkách je vedeno datum platnosti informace.
Objednatel si vyhrazuje právo změnit formální náležitosti komunikačního protokolu. K takové úpravě
dat či datové komunikace Objednatel Dodavatele písemně vyzve s určením lhůty, dokdy musí
Dodavatel přejít na nově určený protokol, přičemž tato lhůta nebude kratší než 6 měsíců od doručení
výzvy Dodavateli.
2.6 | Evidence užití konkrétních vozidel a nástaveb v rámci činností
Dodavatel je povinen evidovat jednotlivé činnosti a užití jednotlivých konkrétních nástaveb dle
odstavce 3.2.1.2 v provozním deníku v systému ISUDa$ a tento provozní deník musí být v souladu se
zasílanými daty GPS.
Provozní deník slouží k zaznamenávání provozních údajů. Za každý den je veden jeden deník.
V provozním deníku je možné evidovat výjezdy a návraty vozidel, počasí a jiné události
(mimořádné události, poruchy, ad.)