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
• Je v provozu (zapnutá jakákoliv výstraha)
o Po čase - nastavení max. 60 vteřin,
o Po ujeté vzdálenosti - nastavení 200 m,
o Po změně azimutu - doporučené nastavení 10°.
• Není v provozu (klidový režim)
o Po ujeté vzdálenosti - nastavení 200 m,
o Po změně azimutu doporučené nastavení 10°.
Pro sběr dat musí být splněn alespoň jeden z uvedených parametrů.
3.3 Předávání dat do systému ŘSD ČR
3.3.1 Frekvence
Předávání dat do systému ŘSD ČR musí být realizováno okamžitě s maximálním zpožděním 60 sekund
od vzniku dat (platí při dostupnosti signálu GSM, jinak v co nejkratším čase po získání signálu).
3.3.2 Mechanismus
Data budou předávána na rozhraní ŘSD ČR, které se bude nacházet na rozhraních popsaných v kapitole
3.4 v níže popsaném datovém formátu a to vždy v pořadí od nejstarších záznamů po nejnovější.
3.3.3 Obsah předávaných dat
Data budou odpovídat datům, která vznikají na GPS.
3.4 Technická rozhraní pro příjem dat v prostředí ŘSD
ŘSD nabízí možnost předávat data na jedno nebo více ze tří nabízených technických rozhraní, lišících
se podporovaným protokolem komunikace. Rozhraní jsou označena jako:
3.4.1 E - rozhraní pro SOAP komunikaci
Adresa produkční služby: https://e-wso2-prod.rsd.cz/transform-qps
Adresa testovací služby: https://e-wso2-testrsd.cz/transform-qps
Za účelem volání této služby není nutná autentizace.
Předpokládáme, že:
• maximální počet požadavků (request) zaslaných na tuto službu za 1 sekunduje 10. Jedná se o
součet za všechny uživatele této služby. V případě vyššího využití může docházet k chybě při
zpracování. V tomto případě, by klientská aplikace obdržela chybový HTTP status kód (např.
500 nebo 503).
• velikost jedné XML zprávy (request body) bude max. 10 kB (cca 18 záznamů činnosti GPS
jednotek, tj. elementů CARINFO)
Poznámka: V případě odeslání většího objemu GPS dat (např. zaslání sady sdružených dat za
uplynulé fakturační období) na službu Tra nsform GPS je vhodné data rozložit jednotlivé
požadavky (request) v čase tak, aby zatížení sběrnicové služby bylo pokud možno rovnoměrné.
Je třeba mít na paměti, že takový způsob použití rozhraní je mimořádný a musí být vždy předem
projednán s provozovatelem viz. body 3.3.1 a 8.2 tohoto dokumentu.
3.4.1.1 Vstupní data E- rozhraní
Sběrnice umožňuje zpracovat GPS data ve 2 formátech:
3.4.1.1.1 GPS data bez SOAP obálky
• formát: XML, kódování UTF-8
• obsah zprávy: kořenový element DOC, tento může obsahovat sadu GPS dat (tj. několik
elementů CARINFO)
• Příklad zprávy (za účelem přehlednosti byly ze zprávy vynechány některé elementy)
2022-08-12T15:25:00+01:00
2 022-0 8-12T14:00:00 +01:00
3.4.1.1.2 GPS data v SOAP obálce
• podobné jako předchozí bod, s tím rozdílem, že element DOC je uvedený v SOAP obálce.
• Příklad zprávy
< ! [CDATA[
] ]>
3.4.1.2 Zpracování zprávy na E-rozhraní
1. Příchozí XML zpráva je auditována
2. GPS data jsou extrahována z XML zprávy (v případě že GPS data jsou v SOAP obálce).
3. GPS data jsou transformována pomocí XSLT šablony.
a. Tímto se provádí převod ze starého formátu GPS dat do nového XML formátu.
b. Hodnoty některých atributů jsou mapovány z číselníku pro starý formát do
atributu v novém formátu.
c. Když příchozí zpráva obsahovala několik elementů CARINFO, výstupní zpráva
zaslaná na GPS server obsahuje několik elementů GPSDATA.
4. V případě, že data byla přijata v očekávaném formátu a byla korektně transformována, je
XML zpráva v novém formátu zaslána na GPS server přes REST službu k dalšímu zpracování.
5. Sběrnice vrací odpověď klientské aplikaci.
3.4.1.3 Odpověď sběrnice na E-rozhraní
1. V případě, že GPS data byla úspěšně přijata a transformována do nového formátu, vrací se
odpověď s HTTP statusem 200 (OK). Sběrnice vrací HTTP status 200 i v případě, že GPS data
sice byla úspěšně transformována, ale došlo k chybě při jejich předání přes REST službu na
GPS server, v takovém případě se jedná o interní chybu zpracování, která je ošetřena,
auditována a zpráva je zapsána do diskové mezipaměti, kde čeká na nové předání službě
REST. Pro klientskou aplikaci je považována za úspěšně doručenou.
2. V případě že došlo k chybě (např. když GPS data nejsou ve správném formátu), sběrnice vrací
status 5XX (Internal Server Error). Klientské aplikace tedy mohou rozpoznat, že došlo k chybě
při transformaci tak, že HTTP status kód má hodnotu 5XX. Kde X představuje libovolnou číslici
0-9.
Odpověď se liší dle typu příchozí zprávy.
3.4.1.3.1 Odpověď sběrnice na E-rozhraní v případě, že se nezpracovává SOAP request
V případě že převod do nového formátu proběhl úspěšně
. HTTP status kód: 200 (OK)
• formát odpovědi: zpráva je prázdná
V případě, že došlo k nějaké chybě (např. když v příchozí zprávě chybí ukončující značka)
• HTTP status kód: 5XX (Internal Server Error)
• formát odpovědi: JSON
• obsah zprávy:
{
"Error": true
}
3.4.1.3.2 Odpověď sběrnice na E-rozhraní na SOAP request
formát zprávy: XML
content-type: text/xml
HTTP status kód:
proběhla-li transformace úspěšně: 200 (OK)
v případě chyby: 5XX (Internal Server Error)
Obsah zprávy je stejný v případě úspěšné transformace zprávy i v případě chybného formátu
příchozí zprávy:
< s o a p :Body>
3.4.2 S - rozhraní pasivního TCP Socketu
Adresa produkční služby: gps.rsd.cz
Adresa testovací služby: gps-testrsd.cz
Za účelem volání této služby není nutná autentizace.
Předpokládáme, že:
• Klientská aplikace bude přijímat odpověď a data považovat za odeslaná až v případě
potvrzení zprávou „OK" jako data(reply) a dodržovat komunikační schéma uvedené v bodu
3.4.2.I. tohoto dokumentu - část TCP Client
• Klientská aplikace bude kromě chyb komunikačního protokolu TCP/IP reagovat na
odpovědi specifikující chyby dat které jsou zasílány jako odpověď na komunikaci a popsány,
včetně požadované reakce klienta v bodu 3.42.3 tohoto dokumentu
• Klientská aplikace nebude zbytečně resetovat nebo uzavírat spojení v průběhu odesílání
zpráv - v rámci jednoho navázaného spojení je možné odesílat další zprávy téměř bez
omezení - jak vyplývá z komunikačního diagramu v bodu 3.42.1. tohoto dokumentu, a to
opakováním činností data(request) a čekáním na data(reply), vyhodnocení data(reply) a
další aktivitou data(request) dle v bodu 3.42.3 tohoto dokumentu
• Klientská aplikace omezí velikost jedné odesílané zprávy data(request) na maximálně 512
KB, nebo na velikost, nevyžadující při nízké kvalitě linky a pomalé konektivitě a přenos delší
než 3 sekundy
• Klientská aplikace nebude z jednoho klienta (nikoliv IP adresy) navazovat více než 3 spojení
za sekundu (nejedná se o bloky zpráv, ale opravdu o spojení)
• Klientská aplikace bude respektovat limit max. 10 konkurentních spojení a umět reagovat
na odmítnutí spojení - v případě potřeby dojde k navýšení kapacity škálováním do šířky a
load balancerem na straně poskytovatele na vyžádání od provozovatele, při doložení
mimořádných okolností.
Poznámka: Ř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í. V případě odeslání většího objemu GPS
dat (např. zaslání sady sdružených dat za uplynulé fakturační období) je vhodné data rozložit
jednotlivé požadavky data(request) v čase tak, aby zatížení TCP Socket kanálu bylo pokud možno
rovnoměrné. Je třeba mít na paměti, že takový způsob použití rozhraní je mimořádný a musí být
vždy předem projednán s provozovatelem viz. body 3.3.1 a 8.2 tohoto dokumentu.
3.4.2.1 Blokové komunikační schéma pro S-rozhraní
TCP Server
socketfl
listenu
TCP Ghent accept!)
sodtetO
blocks until
connects connection
řrom dient
write ()
TCP connection estaohshmertt
closet)
data (request) react)
-data (reply) do something
■.vrte i)
EOF notification react)
ciose()
3A.2.2 Data request
• formát XML, kódování UTF-8
• obsah zprávy: kořenový element DOC, tento může obsahovat sadu GPS dat (tj. několik
elementů GPSDATA)
• Příklad zprávy (za účelem přehlednosti byly ze zprávy vynechány některé elementy)
CGPSDATA ...>
< / GPSDATA>
< / GPSDATA>
3.4.23 Data reply Požadovaná reakce klienta
Data(reply) Význam
Odeslání další zprávy
OK Doručeno korektně Odstranění zprávy z odesílání,
Socket - neplatný obsah zprávy, neúplná zpráva odeslání další zprávy v pořadí
433 neobsahující konec
Opakování odesílané zprávy s
J a k ý k o li Selhání podřízeného TCP severu prodlevou >300ms
v jiný
text
lib o v o ln é
d é lk y
3.4.3 R - rozhraní pro REST komunikaci protokolem http 2.0
Probíhá implementace rozhraní pro použití - jeho specifikace, jakož i podmínky
provozu budou upřesněny dodatkem při jeho zprovoznění.
4 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á 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.
Název Atribut Popis Formát Rozsah hodnot Jednotky Povinný
xml
Příklad: Záhlavní XML dokumentu ANO
G PSDATA
Příklad:
CREATED
Příklad: ANO
GPSRECORD
Přiklad: Čas vygenerování YYYY-MM- ANO
DDTHH:MM:SS
+HH:MM
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, 0=bez signálu, Číslo 0-5 ANO
5=silný signál)
satellitecount Počet satelitů Číslo Kladné celé číslo ANO
gpsunitid Jednoznačný identifikátor GPS jednotky Číslo Kladné celé číslo ANO