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
1 ÚČEL DOKUMENTU
Tento předpis stanovuje závazné požadavky na 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 dokumentuje
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í verzí
Změny verze 1.2 oproti verzi datové sady definované ve verzi 1.1
• V datové 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
• přidány atributy RoadState, RoadSlip, WaterLevel a CriticalWarning do elementu
TEMPERATURE
• 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
• upřesněn datový typ a formát atributu gram elementu SPREADINGINFO
• 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
• V datové větě LIGHTTRAILER, byla zrušena pro dodavatele povinnost předávat atributy
lighton, modearrow, akuvoltage a rampup
2 OBSAH DAT
U pojmenování atributů a elementů v XML nezáleží na velikosti písmen. Hvězdička * vedle názvu elementu vyznačujejeho povinnost v každé datové sadě
a není součástí názvu elementu.
Název Atribut Popis Formát Rozsah hodnot Jednotky Povinný
Xml* Záhlavní XML dokumentu
Příklad:
GPSDATA* ANO
Příklad: 1
CREATED* version Čas vygenerování YYYY-MM- „1.1" ANO
Příklad: Identifikátor verze datové sady DDTHH:MM:SS _________ ANO
+HH:MM
Konstantní text
2014-05-27T14:18:31+01:00
GPSRECORD* gpstime Reálný čas, kdy byl záznam pořízen v YYYY-MM- ANO
Příklad:
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)
sateliitecount Počet satelitů Číslo Kladné celé číslo ANO
gpsunitid Jednoznačný identifikátor GPS jednotky Číslo Kladné celé číslo ANO
(max. 20 číslic)
j
Název Atribut Popis Formát Rozsah hodnot Jednotky Povinný
VEHICLEINFO*
Rz Registrační značka vozidla Text 1-15 znaků ANO
1 Číslo dle
Příklad: Type Druh vozidla rozsahu 1 = Osobní vozidlo ANO
Číslo 2 = Dodávkové vozidlo
Text 3 = Nákladní vozidlo ■— -----------
Text
Číslo 4 = Traktor/stroj
Číslo dle
rozsahu 5 = Přívěsný vozík
6 = Osoba
Driverid ID řidiče Kladné celé číslo dle ANO,
Driver Jméno a příjmení řidiče databáze zadavatele NE dodavatelé údržby
Company Název dodavatele 1-30 znaků NE,
idvehideorig Identifikátor vozidla ANO dodavatelé údržby
technology Nesená nástavba 1-20 znaků NE,
ANO dodavatelé údržby
Kladné celé číslo ANO
1 = sypač ANO, pouze u VEHICLEINFO/type = 2,3,4 |
2 = sekačka 1
3 = samosběr 1
4 = kropice
5 = valník
6 = nosič kontejnerů
7 = ostatní
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 Ředitelství silnic a dálnic s. p. (dále jen ŘSD) 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< /CREATED >
cVEHICLEINFO rz= "2AH 5487" type="2" driverid= "215487" driver="Jan
N ovak" com pany= "Firm axyz" idvehicleorig= "5658478" technology="5" />
V
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 GPSRECORDjsou 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 httos://podporaeps.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řijeti 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é částí stránky, spolu s opisem převzatých dat na rozhraní a seznamem
chyb a vad. V částí 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 Funkcí 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)
*Pike> O
n4fc5íti>89njn1O2n3lD2mMt9n332lfc7h1f32890d5ns0(tfrr3g7hscvs D c pože AP^E^vkjžts klíč. který Vám
Obsan zprávy by« přidělen pracovníkem USD Qbsui
zprávy GPS vk«dejte fcez kořenovebo
-GFSDAIA elementu DOC v kódování U7F-P
pote stiskněte bacttko Test. přijet*
*CREATEP»20í®-0S-27T’ 4 18 31*01 IXHCREATED* zprávy na rozhraní je indikováno
zeleným zaškrtévátkerr*, v případě, že
•GPSRECORO5psíí:!e= 20I8-05-27TU 180M H OC <£m6ign*= 5 i se objeví červený křížek, zkontrolujte
obsah zprávy a v a í afbley a akci
gS5tf!«í* 55598545375441 > opakujte Pote vyčkejte zpracován«,
dokud je zobrazen prvek přesýpacích
»VEJ-íftE.NFO rr- 2AM5437 ř>pé=2 drtren4= 2t54á7 onv«!='Jan Nova* c « w iy = ‘ 'r hodin Následné se objeví přehledný
obsah záznamu, kterývzniki v
KTIGNiNFO ;a*e* = 14 5J3964 attum nne
-SPR-NKi-ERSAI*"» r^nt6usř»r>g= Irtié centiaíur-^r.^ Vue m s t i l i
•'i.iGHTTRAJLERIg^íín^tn» nwtesvrow='l »;uvo*age= 255* ra~iMp- '1nM cr9ír--'fl
■TEMPERATURE tempán 22 T tefrproac= 20 2 r
<£XTEVOfD»MFOrevs= 22*revse>t"nstor.= ftie!=*0223" fwemxiagp:
jFSRECORQ:
'.ůPSDATř>
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í Tím er, který vyčká
10 Sekund
APiKíí ©
n4K$|tn89ri^*02n3í02m30?9í>g32* 7nif32890G5n$0<žíir.3g 7h$cv$
Ob**h /pravý
-GPSOaU*
•Cft£ATED»20T*4W7T14 TI
■Gf'SW£COWP Q t l f l U i# 0i-4erar can«anťi '
-¥EWlC|Í:Tři#0n* r typ*e‘r
i t t í r r W « l o g , '”5*^
9*10*-* - 115731*M'&&&***>*iMÉfif lOMfcaycit21>
v
J tsKt<«0P»r Í4M US* !> JW ilín T !ÍÍ 1H ' i^ o č m ť 7 6 é i fJ5 nňO & 9fm *’T •*»
^VPEADIWdlMfOi ipw tlnpi>m » 1TfMwrOftiť ©fám*W w & M t f l * ' ! / **artn0fi*’-. 12$ S w s u 1*= TI t í f
Ufj/
*CUÍW^0 cuCíí-ttfM ‘a
• M I P M f O Ktygor»«Trm‘ lni* ftgfBiiřeesiřTTUi* w w i« : vw* w nw vpuft* ~rmr «>
£ftQírj^d^B^± Vím mM*©*'«* a^JfuTnir ^
*LíGtfTTRArfl£R fcg***->V** ř «* CTOf^ta»»« *
•TLUPE R A tu R t 22 J > «PW >» 1Q T *•
•exTf >«0€OW*7Qr*ťS5 2 / f*wW.S**iO^- Kí^»T122J « * * M * * 'U 3T i » NgňtNsjw ^ /•
‘ GT^ECORD-
•XJPSOATA»
S vypršením tímeru dojde protokolem HTTPS REST API k volání funkce TestResult a
předání APIKEY a Clientld, Funkce vrátí prázdný JSON nebo JSON s obsahem dat a seznamem
chyb.
Výsledek uloženého zaznamu Auditni zaznam
Vypiš z databáze
id: Cf96ff6c-7bdd-4a06-b27d-7d45eb78be2f
ip: 192.16.16.16 deirveryTsme: 2023-09-
created: 2018-05-27T14:13:31 0 7 T 13:00:53.6833843+02:00
clientld: e62d00ad667be46 ip: 192.16.16 16
last 2018-05-27T14:18:31 message-
gp5time: 2018-05-27T14:18:01 2018-05-27T14:18:31
latitude: 51 100894 01:G0*/CREATED>
longitude: 14.578964 ''GPSRECORD gpstime= '2013-05-27T14:18:01
gsMsignal: 5 01:00‘ gsmsignal=~5‘ satel(itecount= *9"
sacelliteCount: 9 gpsunitid= ’56598545875441"*'
gpsUmtlD: 56598545875441
speedcan: 22.3
tachoGps: 2568.125 '5PREADINGINcO spreadingm ode=’3''
tachoTach: 2568 125 p io w -'tru e g r a m ^ 'W widthleft='145.2''
tachoCan: 2568.125 widthnght=‘ 125 5 sumsalt= '0.123s
modeDnve: 2 sumjnert="0.132" sumbrlne= 1*t>
spreadingMode: 3 ^CUTSINFO cu ts l ^ tru e cuts2="fafse
plow: true cuts3**false' t>
gram: 60
sumSaťt: 0 123 ^SPRINKLERSINFO leftflushing=' true ‘
sum Inert: 0.132 rightfkjshmg=*true' cemralfiushing="true"
sumBrlne: 1 misting=riru e ” pump=‘ true* f>
cutsl: true
Pokud funkce TestResult vrátí prázdný JSON, interní Tímer se nastaví na další 5 Sekund prodelvy,
poté opakuje předchozí odrážku.
Pokud funkce TestResult vrátí neprázdný JSON, dojde ke skrytí indikátoru nic/ přesýpací hodiny
(indikátor čekání na zápis do DB) a obsah vráceného JSON se buď přímo a nebo po parsování
zobrazí v prvku Obsah záznamu v DB GPS a zpřístupní se tlačítko Reset
Stiskem tlačítka Reset dojde k vymazání prvku Obsah zprávy, uvededení obou indikátorů do
výchozího prázdného stavu, vymazání obsahu prvku Obsah záznamu v DB GPS a zpřístupnění
tlačítka Test, pozor - obsah prvku APIKEY musí zůstat k dispozici
4.3 Výsledky testování
V levém sloupci výstupního okna si může poskytovatel telemetrických dat ověřit v testovacím
prostředí, jak bude vypadat záznam jím zasílaných dat přímo v databázi. Pravý sloupec mu ukáže,
v jaké podobě byla data originálně přijata a zobrazí případné chyby s datovou sadou spojené-
nesprávné formáty, chybějící údaje, popřípadě nekorektní datové typy.
Poskytovatel pak může přizpůsobit v rámci ladění svoji službu, tak aby poskytovala datové sady, které
se budou korektně přenášet, parsovat a ukládat do systémů ŘSD.
Technický předpis funkce sběru
telemetrických dat a jejich předávání
pomocí rozhraní TCP/IP Socket a REST -
prostřednictvím Veřejného rozhraní ŘSD
pro příjem GPS dat
Verze 1.1.1 Ze dne 25.10. 2023
Obsah
1 Ú vod...................................................................................................................................... 3
1.1 Názvosloví....................................................................................................................... 3
1.2 Účel dokumentu..............................................................................................................4
2 Architektura systému..............................................................................................................5
2.1 Konceptuální diagram..................................................................................................... 5
2.2 Komponenty systému...................................................................................................... 5
2.2.1 GPS jednotka..............................................................................................................5
2.2.2 Sběr dat na vozidle.....................................................................................................6
2.2.2.1 Sledované parametry............................................................................................6
2.2.2.2 Data specificky podle vozidel.............................................................................. 7
2.2.2.3 Průběh sběru d a t................................................................................................. 9
2.2.3 Předávání dat do systému ŘSD.................................................................................... 9
2.2.3.1 Frekvence............................................................................................................ 9
2.2.3.2 Mechanismus..................................................................................................... 10
2.2.3.3 Obsah předávaných dat...................................................................................... 10
2.3 Přehled součástí serveru ŘSD obsluhujícího rozhraní pro příjem telemetrických dat........ 10
2.4 Protokoly a rozhraní...................................................................................................... 11
2.4.1 TCP/IP - Rozhraní S...................................................................................................11
2.4.1.1 Komunikační diagram......................................................................................... 12
2.4.1.2 Komunikace na socketu - zásady......................................................................... 13
2.4.1.3 Technická omezení a doporučení...................................................................... 13
2.4.1.4 Zabezpečení.....................................................................................................13
2.4.1.5 Chybové stavy a očekávaná reakce na straně klientské služby............................. 13
2.4.1.6 Ukázkový kód (.NET Core - C#).........................................................................14
2.4.1.7 Testová metoda pro Unit testy..........................................................................16
2.4.2 REST API - Rozhraní R............................................................................................... 17
2.4.2.1 Definice REST API.............................................................................................. 17
2.4.2.2 Metody rozhraní.............................................................................................. 18
2.4.2.3 Zabezpečení.....................................................................................................19
2.4.2.4 Chybové stavy a reakce na chyby....................................................................... 19
2.5 Popis dat a form át........................................................................................................ 19
2.6 Evidence užití konkrétních vozidel a nástaveb v rámci činností........................................20
1 ÚVOD
Tento předpis stanovuje požadavky na provedení a kvalitu GPS jednotek a telemetrických dat vozidel
provádějící údržbu komunikací ve správě Ředitelství silnic a dálnic s. p. (dále jen ŘSD) a to jak vozidel
ŘSD, tak vozidel dodavatelů provádějících údržbu na základě uzavřených rámcových dohod.
Dodavatel bude prováděné činnosti údržby komunikací, evidovat v software webové aplikace
„Provozní deník", kterou Objednatel Dodavateli zpřístupní a umožní vyškolení uživatelů vítězného
Dodavatele k jejímu užívání.
Zadavatel si vyhrazuje právo na změnu protokolu pro předávání dat i datového formátu a obsahu.
Součástí komunikačního protokolu jsou přílohy - aktuálně platná dokumentace ke GPS ke stažení
níže v aktuálně platném znění https://podporaeps.rsd.cz/ke-stazeni/Protokol/(Verze) a
https://podporaeps.rsd.cz/ke-stazeni/Datow format/ÍVerze)
Kde (Verze) označuje číslo verze Protokolu () resp. Datového formátu ()
Pro nejnovější platnou verzi se číslo nahrazuje slovem „Aktuální"
Tedy aktuálně nejnovější verze Protokolu je k dispozici pod odkazem
https://podporaeps.rsd.cz/ke-stazeni/Protokol/Aktualni
a nejnovější platná verze datového formátu je k dispozici pod odkazem
https://podporaeps.rsd.cz/ke-stazeni/Datovv format/Aktualni
1.1 Názvosloví
Jednotka GPS - je zjednodušený název pro technické zařízení umístěné ve vozidlech, které zajišťuje
sběr a předávání dat o poloze, automaticky generovaných dat o prováděných činnostech, data z CAN
sběrnice vozidel, vozidlových nástaveb a dat ze čteček RFID, které jsou k ní připojeny.
GPS - pro potřeby tohoto dokumentu obecně jakýkoliv globální družicový polohový systém
Vozidla - tímto pojmem jsou myšlena všechna vozidla a stroje sloužící pro údržbu komunikací
popsaná v tomto dokumentu.
Vozíky - přívěsné vozidlo nesoucí dopravní zařízení nebo zařízení předběžné výstrahy podle typu
používaný jako výstražný vozík nebo předzvěstný vozík.
Komunikační server-se rv e r na straně provozovatele GPS jednotek, který sbírá data poskytovaná
GPS jednotkami vozidel, podle níže uvedeného funkčního popisu a datového formátu a následně je
předává do ISUD.
Informační systém údržby dálnice / a silnic (ISUD/ISUDaS) - informační systém sledování a kontroly
údržby komunikací ve správě ŘSD.
Dodavatelé údržby - dodavatelé ŘSD provádějící činnosti údržby.
Rozhraní S - rozhraní pro předávání telemetrických dat prostřednictvím TCP/IP Socketu
Rozhraní R- rozhraní pro předávání telemetrických dat prostřednictvím HTTP / REST API
1.2 Účel dokumentu
Předpis upravuje technické provedení mechanismu předávání telemetrických dat na veřejná rozhraní
ŘSD - rozhraní S a R. Definuje komunikační postupy a omezení obou rozhraní, která musí být
dodržena při implementaci klientských služeb na straně poskytovatele telemetrických dat při jejich
návrhu a provozu. Předpis stanoví závazné postupy, jejichž dodržení je podmínkou pro převzetí
plnění.
Změny oproti předchozí verzi
Změny verze 1.1.1. oproti verzi datové sady definované v dokumentu KOMUNIKAČNÍ PROTOKOL 1.0
• oddělena dokumentace formátu datové sady od komunikačního protokolu
• doplněna kompletní definice REST rozhraní R (Swagger) a popis jeho použití
• doplněn přehled součástí serveru ŘSD obsluhujícího rozhraní pro příjem telemetrických dat
• přidán blok Chybové stavy a očekávaná reakce na straně klientské služby pro rozhraní S
• přidán Ukázkový kód (.NET Core - Ctt) a Testová metoda pro unit test pro rozhraní S
• zavedeno elektronické umístění dokumentů https://podporagps.rsd.cz/ke-stazeni/
• odebrána specifikace povinnosti pro C-ITS
2 ARCHITEKTURA SYSTÉMU
2.1 Konceptuální diagram
Sít
z vozidla *»
**
«
komunikační server inform ainí.yztém
údržby dálnioe
5bér d at na vozidle
Diagram schematicky popisuje proces sběru, přenosu a předávání dat, který je určen tímto
předpisem. Data jsou sbírána na úrovni vozidla pomocí jednotky GPS, která sleduje polohu pomocí
satelitního systému GPS, snímá telemetrická data z vozidla, popř. vozidlové nástavby a zpracovává
tyto informace dále doplněné o data ze čtečky karet. Data jsou následně pomocí mobilní sítě
přenášena na komunikační server, kde jsou převedena do jednotného formátu (viz dokument
Technický předpis datového formátu telemetrických údajů) a konečně předána ke zpracování a
uložení do ISUD/ISUDaS.
2.2 Komponenty systému
Přehled požadovaných součástí řešení na straně poskytovatele údržby a poskytovatele
telemetrických dat.
Tato část definuje požadavky jednotky určené do vozidel ŘSD. Pro dodavatele údržby jsou klíčové
funkční požadavky popsané v dalších kapitolách (sběr, přenos a formát), povinné údaje a závazný
datový formát je pak přesně stanoven v dokumentu Technický předpis datového formátu
telemetrických údajů, nicméně parametry HW mohou využít jako doporučení pro správné funkce HW
2.2.1 GPS jednotka
GPS jednotky musí splňovat tyto parametry:
• napájení universální v rozsahu 12/24 V, tj. vhodné do všech typů vozidel bez nutnosti použití
převodníků napětí,
• teplotní rozsah od -25‘>C +60°C,
• podpora připojení CAN sběrnice (FMS standard),
• GPS přijímač s vysokou citlivostí (doporučena podpora 2 sítí globálního družicového
polohového systému),
• modem pro on-line přenos dat (GPRS nebo novější technologie),
• integrované akcelerační/decelerační čidlo,
• vnitřní paměť pro záznamy o kapacitě minimálně 40.000 záznamů,
• záložní napětí v případě výpadku napájení (minimálně 15 minut),
• možnost ukládat do záznamů servisní informace:
o palubní napájení,
o počet satelitů,
o kvalita GSM signálu.
• jednotka musí být vybavena dostatečným počtem příslušných vstupů, aby bylo možné
sledovat níže uvedené parametry z vozidla,
• nedostupnost GSM sítě - v případě výpadku nebo nedostupnosti mobilní sítě musí být data
ukládána v jednotce GPS a po připojení do domovské sítě okamžitě odeslána,
• GPS jednotka musí odesílat uložená data od nejstarších záznamů po nejnovější.
2.2.2 Sběr dat na vozidle
2.2.2.1 Sledované p a ra m e try
Hodnoty sledované jednotkou GPS nebo získávané z jiných systémů ve vozidle a sbírané jednotkou
GPS pro zajištění přenosu. Všechna vozidla budou poskytovat povinně sledované hodnoty. Další
parametry jsou závislé zejména na technické vyspělosti vozidla a jeho schopnosti předávat tyto data
jednotce GPS. Ostatní parametry se liší v závislosti na typu vozidla, resp. jeho nástavby. Níže je pro
přehlednost uveden základní výpis sledovaných dat, které jsou následně přesně specifikovány
v samostatném dokumentu Technický předpis datového formátu telemetrických údajů v aktuální
verzi.
Po vin ně sled o van é u všech vozid el a strojů
• Datum, čas-vzniku záznamu,
• Kvalita signálu GSM,
• Počet satelitů,
• Jednoznačný identifikátor jednotky,
• Registrační značka vozidla
• Druh vozidla (osobní, dodávkové, nákladní, traktor/stroj, vozík, osoba),
• ID řidiče/jméno řidiče (NE pro dodavatele),
• Číslo smlouvy (NE pro ŘSD, ANO pro dodavatele)
• Identifikátor vozidla,
• Nesená nástavba (sypač, sekačka, samosběr, kropice, valník, nosič kontejnerů, ostatní)
• Zapnuté zapalování (klíček),
• Zeměpisná poloha,
• Aktuální rychlost z GPS,
• Aktuální rychlost z tachometru z GPS,
• Aktuální rychlost z CAN sběrnice,
• Aktuální stav tachometru z GPS,
• Aktuální stav tachometru z tachometru,
• Aktuální stav tachometru z CAN sběrnice,
• Režim jízdy (zimní údržba, letní údržba, kontrolní jízda, inspekční jízda, jízda BESIP, služební
jízda, DIO),
• Otáčky motoru, pouze u nákladních vozidel, strojů, popř. pokud dodávkové vozidlo
umožňuje,
• Spotřeba PHM od předcházejícího záznamu (pro dodávkové, nákladní vozidla, traktor/stroj)
(NE pro dodavatele),
• Palubní napětí (NE pro dodavatele),
• Sledování zapnutí majáku (pokud je jím vozidlo vybaveno).
2.2.2.2 D a ta s p e c ific k y p o d le v o z id e l
Jedná se o úplný výčet vozidel, na kterých může být v rámci poskytování služeb pro ŘSD požadováno
umístění GPS a předávání dat GPS. Konkrétní povinnost vyplývá ze specifikace činnosti v konkrétní
smlouvě a proto výčet povinných vozidel a mechanizací je uveden v podrobné specifikaci služeb.
• Sypač
o režim posypu (nesype, chemický posyp, chemický posyp se zkrápěním, inertní posyp,
inertní posyp se zkrápěním, zkrápění)
o stav plužení,
o gramáž posypu,
o aktuální nastavená šíře posypu,
o spotřeba materiálu (chemického, inertního, solanky),
• Sekačka
o činností cepáku hlavní kosy,
o činností cepáku druhé kosy,
o činností cepáku třetí kosy,
• Samosběr - s rozdělením
o válcové koště,
o levé boční koště,
o pravé boční koště,
o turbína/sání,
o spuštěná šachta,
• Kropicí vůz
o levý splach,
o pravý splach,
o střední splach,
o mlžení (ozónu),
o čerpadla, (popř. čištění propustků, čištění vpustí)
• Vozík (ŘSD)*
* pro dodavatele povinná pouze poloha GPS, ostatní údaje nepovinné
o výstražná světla/šipka zapnuto,
o režim zapnuté šipky (doleva, doprava, dolů)
o rampa nahoře,
o napětí akumulátoru
• Další typy vozidel/nástaveb
Vždy se sleduje činnost nástavby popř. stroje provádějící činnost, pro kterou je určena v rozsahu
pracuje/nepracuje. Typy nástaveb popř. strojů:
o univerzální nosič, nástavba (pokud není specifikován v jiných činnostech) (bude
popsání v deníku):
■ mytí značek
■ mytí směrových sloupků
■ mytí nástavců na svodidla
■ mytí baliset
■ mytí svodidel
■ čištění propustků
■ čištění vpustí
■ tlaková voda
■ čištění
■ seřezávání krajnic
■ hloubení příkopů
■ oprava silničních svahů
o vozidlo provádějící inspekční jízdu
■ práce vozidla
o jeřáb
■ činnost nástavby
o plošina
■ činnost nástavby
o nakladač
■ práce vozidla (otáčky motoru větší než 0)
o samopojízdný značkovací stroj
■ práce vozidla
o samojízdný stroj pro nedestruktivní odstraňování VDZ
■ práce vozidla
o samojízdný stroj pro nedestruktivní obnovu PVV
práce vozidla
o válec
■ práce vozidla
o finišer
■ práce vozidla
o distributor
■ práce vozidla
o fréza
■ práce vozidla
o pracovní vozidlo (např. nákladní vozidlo odvážející odpad nebo vytěžený materiál na
skládku nebo deponii) - dle definice v konkrétní smlouvě (neplatí pro vozidlo
přivážející pracovníky)
■ práce vozidla
o speciální sací čistící vozidlo
■ práce vozidla, vč. odvozu odpadu na skládku
2 .2 .2 3 Průběh sběru dat
Jednotka musí být schopna zaznamenávat data na základě těchto parametrů:
• Po čase - nastavení max. 10 vteřin při jízdě,
• Po ujeté vzdálenosti - (minimální nastavitelný interval 10 m),
• Po změně azimutu - doporučené nastavení 10°.
Specifická je situace vozíků, a proto je třeba specifické nastavení:
• 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ů.
2.2.3 Předávání dat do systému ŘSD
2.2.3.1 Frekvence
Předávání dat do systému ŘSD 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).
2.23.2 Mechanism us
Data budou předávána na rozhraní ŘSD, které se nachází na veřejné URL adrese specifikované
v dokumentaci na stránkách https://podporagps.rsd.cz/ v datovém formátu určeném v samostatném
dokumentu Technický předpis datového formátu telemetrických údajů, a to vždy v pořadí od
nejstarších záznamů po nejnovější.
2.2.33 Obsah předávaných dat
Data budou odpovídat datům, která vznikají na GPS jednotkách.
2.3 Přehled součástí serveru ŘSD obsluhujícího rozhraní pro příjem telemetrických dat
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í R i 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
• O kaž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/IP- 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 Kom unikační diagram
TCP Server
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 K o m u n ikace n a socketu - zásad y
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 4 6X -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 T echnická o m e z e n í a d o p o ru če n í Rozmezí Doporučená
hodnota
Parametr 20ms
ls
Prodleva mezi relacemi >=10ms ~ 64 kB
Prodleva po neúspěšném pokusu o navázání relace >=100ms <1000ms
Velikost přenášené zprávy lkB - 786 kB
Doba trvání relace 50ms - 1200ms
Paralelní relace <=10
2.4.1.4 Zab ezp ečení
Metody pro autentizaci a šifrování komunikace nebyly na vyžádání poskytovatelů dat
implementovány.
2.4.1.5 Chybové sta v y a očekávan á reakce n a stra n ě klientské slu žb y
Chyby a odezvy Očekávaná reakce klienta
OK Odeslání datové sady proběhlo bez problémů
4IX - 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
4 5 X - 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 dle ustanovení tohoto dokumentu. V případě
49X - Jiná chyba modulu Socket opakovaného výskytu kontaktovat podporu v ŘSD
2.4.1.6 U kázkový kó d (.NET Core - O f )
using Microsoft.Extensions.Logging;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;
namespace SSL_TCP_Protocol_Client
{
I I I
I I I Non secure Tcp client - for non-server actions
I I I
public class NsTcpCIient
{
#iegion Private NsTcpCIient properties
private readonly TcpCIient _client;
private readonly ILogger Jogger;
private readonly NetworkStream _networkStream;
ttendregion
fcregion NsTcpCIient constructor
public N i (string machineName, ILogger logger)
{
Jogger = logger;
// Create a TCP/IP client socket.
// machineName is the host running the server app 'cation.
try
{
TcpCIient _client = new TcpCIientf);
IPEndPoint endPoint = new IPEndPoint(IPAddress.Loopback, 3050);
_client.Connect(endPoint);
Jogger.LogDebug( Client corn ed );
// Create a NetworkStream to access the client's stream.
_networkStream = _client.GetStream();
}
catch (SocketException err)
{
Jogger.LogError(err.Message);
}
}
public NsTcpClient(string adress,int port, ILogger logger)
{
Jogger = logger;
// Create a TCP/IP client socket.
// machineName is the host running the server application.
try port);
{
TcpClient_client = new TcpClient();
IPEndPoint endPoint = new IPEndPoint(IPAddress.Parse(adress),
_client.Connect(endPoint);
Jogger.LogDebug("Client connected.");
// Create a NetworkStream to access the client's stream.
_networkStream = _dient.GetStream();
}
catch (SocketException err)
{
Jogger.LogError(err.Message);
}
}
ffendregion
tfregion Public methods ReadMessage, SendMessage and CloseClient
public Task ReadMessage()
{
// Read the message sent by the server.
// The end of the message is signaled using the
// "" marker
byte[] buffer = new byte[2048];
StringBuilder messageData = new();
int bytes;
do
{
bytes = _networkStream.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, 0, bytes, chars, 0);
messageData .Append(chars);
// Check for /DOC.
if (messageData.ToString().lndexOf( ') != -1)
{
break;
}
} while (bytes != 0);
return Task.Run(() => messageData.ToStringO);
}
public Task SendMessage(string messageData)
{
int charscn = messageData.Length;
int loopctr = 0;
do
{
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 = Encodlng.UTF8.GetEncoder();
byte[] bytes = new byte[encoder.GetByteCount(messagePart, 0, chunkLength, true)];
encoder.GetBytes(messagePart, 0, chunkLength, bytes, 0, true);
_networkStream.Wrlte(bytes);
charscn -= chunkLength;
loopctr++;
} while (charscn != 0);
return Task.CompletedTask;
}
public void CloseClient()
{
if (_networkStream!=null && _networkStream.CanWrite) _networkStream.Close();
if (_client!=null) _client.Close();
_logger.LogDebug("Client closed );
}
fiendregion
2.4.1.7 Testová m etoda pro U n it testy
[TestMethod]
public async void Test_RSD_NS_Client()
{
using var loggerFactory = LoggerFactory.Create(builder => builder.AddFilter("Microsoft", LogLevel.Warning)
,AddFllter("System", LogLevel.Warning)
.AddFilter("UnitTest1”, LogLevel.Debug));
logger = loggerFactory.CreateLogger();
NsTcpCIient nsClient = null;
// Directory, where are the tes data sets stored as XML files
string[] files =
Directory.GetFlles(@"X:\RSD\GPS_vstup , "*.xml", SearchOptlon.AIIDIrectories);
nsClient = new NsTcpClient( 'grv-gpst.rsd.cz", logger, false);
Assert.IsNotNull(nsCllent);
foreach (string flleName in files)
{
// Send message to the server.
await nsClient.SendMessage(File.ReadAIIText(fileName));
// Read message from the server.
string serverMessage = await nsClient.ReadMessage();
Assert.AreEqualfserverMessage, "OK");
}
nsCIient.CloseClientO;
}
2.4.2 R E S T A P I - R o z h r a n í R
Rozhraní umožňuje zasílat data zpráv GPS na REST rozhraní definované následujícím Swagger
popisem:
2.4.2.1 D efinice REST A PI
{
"openapi": "3.0.1",
"info": {
"title": "GPS_Records_REST_Server",
"version": "vl"
},
"paths": {
"/GPSRecords/HeartBeat": {
"get": {
"tags": [
"GPSRecords"
],
"responses": {
"200": {
"description": "Success"
}
}
}
},
"/GPSRecords/State": {
"get": {
"tags”: [
"GPSRecords"
] ,
"responses": {
" 200": {
"description": "Success"
}
>,
"/GPSRecords/PostMessage": {
"post": {
"tags": [
GPSRecords
],
"parameters": [
{
"name": "messageld",
"in": "query",
"schema": {
"type": "string",
"format": "uuid"
} "remotelPAddress",
},
{
"name":
"in": "query",
"schema": {
"type": "string",
"nullable": true
}
}
] ,
"requestBody": {
"content": {
"text/plain": {
"schema": {
"type": "string",
"nullable": true
}
}
)
},
"responses": {
"200": {
"description": "Success"
}
}
},
"components": { }
}
2A .2.2 M etody 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.23 Zabezpečení
Volání je prováděno se šifrováním protokolem HTTPS
2.4.2A 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 S 00.33X jso u ře šite ln é opako van ým voláním m e to d y se stejným obsahem s prodlením . U
o sta tn ích chyb vede takové ře še n í pou ze k o b d rže n í stejného chybového h lá še n í a dů razn ě se na
klien tu 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ě, zeje nějaká
odlišnost mezi vozidly ŘSD 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 ISUDaS 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.)
POLOŽKOVÝ ROZPOČET PLNĚNÍ Příloha č. 2
RÁMCOVÁ DOHODA - spáry a trhliny AB 1 2 1 0 2 0 0 ,0 0 Kč
7 5 0 0 0 ,0 0 Kč
Sil. I. tř. Pardubického kraje, spáry a trhliny, okr. Pardubice
2 4 7 0 0 0 ,0 0 Kč
Číslo Rám cové dohody: 11PU-005320 ev.č. 240/25 1 5 3 2 2 0 0 ,0 0 Kč
SO 101 Spáry a trhliny v e vo zo v c e s AHV 3 2 1 7 6 2 ,0 0 Kč
SO 102 Přetěsnění příčných spár m onolitického žlabu 1 8 5 3 9 6 2 ,0 0 Kč
SO 180 DIO
3 0 6 4 4 0 0 ,0 0 Kč
N abídková c e n a za 12 m ěsíc ů v Kč CELKEM b ez DPH 6 4 3 5 2 4 ,0 0 Kč
21% DPH v Kč
N abídková c e n a za 12 m ěsíc ů v Kč CELKEM v č e tn ě DPH 3 7 0 7 9 2 4 ,0 0 Kč
N abídková c e n a za 2 4 m ěsíc ů v Kč CELKEM b ez DPH
21% DPH v Kč
N abídková c e n a za 2 4 m ěsíc ů v Kč CELKEM v č e tn ě DPH
Nabídku podává:
Příloha č. 3
SEZNAM PODDODAVATELŮ
a) Dodavatel nevyužije při plnění předmětu Rámcové dohody a dílčích smluv žádných
poddodavatelů.
b) Dodavatel využije při plnění předmětu Rámcové dohody a dílčích smluv následujících
poddodavatelů:
1. jméno/název: DROMOS Construction s.r.o.
se sídlem: Mikulášská 2184/46a, Pod Bezručovým vrchem, 794 01 Krnov
IČO: 09258591
rozsah plnění: 10%
2. jméno/název: RPS s.r.o.
se sídlem: Průmyslová 199/2, 250 64 Měšice
IČO: 23729112
rozsah plnění: 10%
3. jméno/název: Silverton s.r.o.
se sídlem: Za zastávkou 373, 109 00 Praha 10 - Dolní Měcholupy
IČO: 24283410
rozsah plnění: 10%
Příloha č. 4
PŘEDÁVACÍ PROTOKOL - VZOR
Ředitelství silnic a dálnic s. p.
se sídlem Čerčanská 2023/12, Krč, 140 00 Praha 4
IČO: 65993390
(dále jen „ŘSD“)
jméno/název: EDS Trade s.r.o.
se sídlem: Červený dvůr 1180/18, Pod Cvilínem, 794 01 Krnov
IČO: 03832210
(dále jen „Dodavatel“)
tímto potvrzují, že níže uvedeného dne, měsíce a roku:
1. Dodavatel odevzdal a ŘSD od něj převzalo následující Plnění:
druh Plnění:
množství / rozsah:
specifikace Plnění (např. výrobce, model, typ, značka): ffcoidftdoplnenoj
2. Společně s Plněním Dodavatel odevzdal a ŘSD od něj převzalo následující Dokumentaci vztahující
se k Plnění:
3. ŘSD uvádí, že:
a) výše uvedené Plnění bylo převzato ŘSD bez zjevných vad.
b) výše uvedené Plnění bylo převzato ŘSD s následujícími zjevnými vadami: fBdďfetfelrfiďSftí)
4. Tento předávací protokol se podepisuje ve dvou (2) stejnopisech s tím, že jeden (1) stejnopis je
určen pro ŘSD a jeden (1) stejnopis je určen pro Dodavatele.
V Praze dne V Praze dne
Ředitelství silnic a dálnic s. P- F D S T i-q íI a « r n
jednatel a obchodní ředitel
Příloha č. 5
D ÍL Č Í O BJED N Á V KA - V ZO R
Číslo související Rámcové dohody: 11PU-005320 ev.č. 240/25
Číslo dílčí objednávky
Ze dne:
Objednatel: Dodavatel:
Ředitelství silnic a dálnic s. P-
IČO: 65993390
DIČ: CZ65993390
zapsaný v obchodním rejstříku pod sp. zn.:
A 80478 vedenou u Městského soudu v Praze
Tato dílčí objednávka je návrhem na uzavření dílčí smlouvy ve smyslu čl. III uzavřené Rámcové
dohody. Způsob akceptace dílčí objednávky dodavatelem (uzavření dílčí smlouvy), obchodní, smluvní
a platební podmínky a další práva a povinnosti smluvních stran touto dílčí dohodou výslovně
neupravená stanovuje Rámcová dohoda.
Na základě uzavřené Rámcové dohody u Vás objednáváme:
Místo dodání:
Celková hodnota objednávky v Kč bez DPH / vč, DPH:
Objednatel použije přijaté plnění pro účely, které nejsou předmětem DPH a ve vztahu k danému plnění
nevystupuje jako osoba povinná k této dani.
Objednatel použije přijaté plnění pro účely určené k ekonomické činnosti a ve vztahu k danému plnění
vystupuje jako osoba povinná k DPH.
Následující tabulka odkazuje na Smluvní podmínky pro stavby menšího rozsahu - Obecné podmínky
ve znění Smluvních podmínek pro stavby menšího rozsahu - Zvláštní podmínky (dále jen „Smluvní
podmínky“).
Název Pod-článku Číslo Pod- Údaje
Smluvních podmínek článku
Smluvních Ředitelství silnic a dálnic s. p.
Název a adresa Objednatele podmínek Čerčanská 2023/12, Krč, 140 00 Praha 4
Název a adresa Zhotovitele
Datum zahájení prací 1.1.4 |bude doplněno |
Doba pro dokončení
1.1.5 ■i
1.1.7
1.1.9 Nepoužije se.
Nepoužije se.
Doba pro uvedení do 1.1.22 Další náležitosti faktury:
provozu
Sekce 1.1.26
Faktura 1.1.28
Další náležitosti nejsou určeny.
Hierarchie smluvních 1.3 ták i uraci d\čm a Objcdm udm n alp |
dokumentů (a) Dílčí objednávka/Příloha
(b) Rámcová dohoda
Právo 1.4 (c) Zvláštní podmínky
(d) Obecné podmínky
Komunikace 1.5 (e) Výkaz výměr
Poskytnutí staveniště 2.1 Právo České republiky
v
Čeština
Od Data zahájení prací oznámeného dle
Pod-článku 1.1.7
Pověřená osoba 3.1
Zástupce objednatele 3.2
Zajištění splnění smlouvy 4.4
Záruka za odstranění vad 4.6. Nepoužije se.
Nepoužije se.
Projektová dokumentace 5.1
Do 7 dnů po Datu zahájení prací
Zhotovitele Forma harmonogramu:
Harmonogram 7.2