natgillin/translations-raw huggingface dataset:
Registration in other countries for the use on their national network,
referenčný súbor kódovania pre všetkých manažérov infraštruktúry, železničné podniky, podniky poskytujúce služby,
Safety certification for all Rolling Stock which does not comply with the Rolling Stock TSI.
referenčný súbor kódovania pre zákazníkov nákladnej dopravy,
The keeper is obliged to ensure that these data are available and the processes behind have been conducted.
referenčný súbor kódovania lokalít (primárnych a subsidiárnych),
Design data, which shall include all constitutive (physical) elements of the rolling stock, including characteristics related to the environment, and all information that is expected to remain valid throughout the life of the rolling stock — this part may contain a history of major modifications, major maintenance, overhaul, etc.
Európska železničná agentúra uloží kópiu referenčného súboru kódov lokalít a kódov podnikov.
The Rolling Stock Operational Data
Na individuálnu žiadosť a bez toho, aby boli dotknuté práva duševného vlastníctva, budú tieto údaje k dispozícii na nahliadnutie pre verejnosť.
Beside the reference data for rolling stock, the data representing the actual status of the rolling stock is the most important data for operational purposes.
Iné zoznamy kódov sú vymedzené v dokumente „TAF TSI – príloha D.2: dodatok F – Vzor údajov a správ TAF TSI“ uvedenom v dodatku I.
This data shall include temporary data, such as restrictions, current and projected maintenance actions, km and fault counters, etc.;
Iné databázy
and all data that could be considered as ‘status’ (temporary speed restrictions, brake isolated, needs for repair and fault description, etc.).
Na umožnenie sledovania polohy vlaku a vozňa musia byť nainštalované ďalej uvedené databázy, ktoré sa aktualizujú v reálnom čase pri každej relevantnej udalosti.
For use of the operational rolling stock data three different entities must be considered taking into account the different parties responsible for rolling stock during transport operation:
Schválené subjekty, ako sú držitelia a správcovia vozového parku, musia mať prístup k údajom potrebným na splnenie svojich funkcií podľa dvojstranných dohôd.
Railway Undertaking as Duty holder during its transport control,
Prevádzková databáza vozňov a intermodálnych jednotiek,
Keeper of rolling stock, and
plán dopravy pre vozeň a prepravy pre intermodálnu jednotku.
User (Hirer) of rolling stock.
Tieto databázy musia byť prístupné cez spoločné rozhranie (4.2.12.1: Všeobecná architektúra a 4.2.12.6: Spoločné rozhranie).
For all three different parties the operational rolling stock data must be accessible by the authorised user, down to his predefined authorised level, using the single key given by the wagon id (wagon number).
Prevádzková databáza vozňov a intermodálnych jednotiek
The operational rolling stock data is a part of the Wagon and Intermodal Unit Operational Database as described in Chapter 4.2.11.2 Other Databases.
Komunikácia medzi vedúcim železničným podnikom a železničnými podnikmi v režime spolupráce sa zakladá na číslach vozňov a/alebo intermodálnych jednotiek.
Reference Files
Železničný podnik, ktorý komunikuje s manažérmi infraštruktúry na úrovni vlaku, preto musí rozdeliť tieto informácie na informácie, ktoré sa týkajú vozňov, a informácie, ktoré sa týkajú intermodálnych jednotiek.
For the operation of freight trains on the European network the following reference files must be available and accessible to all service providers (IMs, RUs, logistic providers and fleet managers).
Informácie, ktoré sa týkajú vozňov, a informácie, ktoré sa týkajú intermodálnych jednotiek, musia byť uchovávané v prevádzkovej databáze vozňov a intermodálnych jednotiek.
The data must represent the actual status at all times.
Z informácií o pohybe vlaku vyplývajú nové záznamy/aktualizácie v prevádzkovej databáze vozňov a intermodálnych jednotiek pre informovanie zákazníka.
Where a reference file is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies.
Časť o pohybe vozňa alebo intermodálnej jednotky sa v databáze vytvorí najneskôr vtedy, keď je od zákazníka prijatý čas odovzdania vozňa alebo intermodálnej jednotky.
Locally stored and administrated:
Tento čas odovzdania je prvým záznamom o pohybe vozňa v prevádzkovej databáze vozňov a intermodálnych jednotiek, ktorý sa týka aktuálnej dopravnej cesty.
Reference File of the emergency services, correlated to type of hazardous goods.
Správy o pohybe vozňa sú vymedzené v kapitolách 4.2.8 (Pohyb vozňa) a 4.2.9 (Hlásenie výmeny).
Centrally stored and administrated:
Táto databáza musí byť prístupná cez spoločné rozhranie (4.2.12.1: Všeobecná architektúra a 4.2.12.6: Spoločné rozhranie).
Reference File of the Coding for all IMs, RUs, Service provider companies;
Prevádzková databáza vozňov a intermodálnych jednotiek je najdôležitejšou databázou na sledovanie polohy vozňov, a teda aj pre komunikáciu medzi príslušnými železničnými podnikmi a vedúcim železničným podnikom.
Reference File of the Coding for Freight Transport Customers;
Táto databáza ukazuje pohyb vozňa a intermodálnej jednotky od odchodu až do konečného dodania na vlečkových koľajach zákazníka s odhadovanými časmi výmeny (ETI) a skutočnými časmi v rozličných miestach až do času konečného dodania, teda odhadovaného času príchodu (ETA).
Reference File of the Coding of Locations (Primary and subsidiary),
Táto databáza ukazuje aj stav železničných koľajových vozidiel, napríklad:
The European Railway Agency will save a copy of the Reference File for the Locations Codes and Company Codes.
stav:
On individual request and without prejudice to intellectual property rights, this data shall be available for public consultation.
nakládka železničných koľajových vozidiel
Other code lists are defined in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I.
Tento stav sa vyžaduje pre výmenu informácií medzi železničným podnikom a manažérmi infraštruktúry a s ďalšími príslušnými železničnými podnikmi na dopravnej ceste.
Other Databases
naložený vozeň na ceste
To allow for the tracking of train and wagon movements, the following databases, updated at each relevant event in real time, must be installed.
Tento stav sa vyžaduje pre výmenu informácií medzi manažérom infraštruktúry a železničným podnikom, s ďalšími manažérmi infraštruktúry a ďalšími príslušnými železničnými podnikmi na dopravnej ceste.
Authorised entities such as keepers and fleet managers must have access to the data relevant to fulfil their functions, according to bilateral agreements.
prázdny vozeň na ceste
Wagon and Intermodal Unit Operational Database,
Tento stav sa vyžaduje pre výmenu informácií medzi manažérom infraštruktúry a železničným podnikom, s ďalšími manažérmi infraštruktúry a príslušnými železničnými podnikmi na dopravnej ceste.
Trip plan for wagon/Intermodal unit.
vykládka železničných koľajových vozidiel
These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Tento stav sa vyžaduje pre výmenu informácií medzi železničným podnikom v cieli a vedúcim železničným podnikom pre dopravu.
Wagon and Intermodal unit Operational Database
prázdny vozeň riadený správou vozového parku
The communication between the Lead RU and RUs in the cooperation mode is based on wagon and/or Intermodal unit numbers.
Tento stav sa vyžaduje na získanie informácií o použiteľnosti vozidla s vymedzenými charakteristikami.
Therefore an RU, which communicates with the IMs at train level, must break down this information into wagon and Intermodal unit related one.
Databázy plánov ciest vozňov
This wagon and Intermodal unit related information must be stored in the Wagon and Intermodal Unit Operational Database.
Vlaky sa môžu skladať z vozňov od rôznych zákazníkov.
The information on train movement leads to new entries/updates in the Wagon and Intermodal Unit Operational Database for customer information.
Pre každý vozeň musí vedúci železničný podnik (železničný podnik vo funkcii integrátora služieb) vytvoriť a aktualizovať plán cesty, ktorý zodpovedá vlakovej trase na úrovni vlaku.
The movement part for a wagon or Intermodal unit in the database is set up at the latest when receiving the release time for the wagons or Intermodal unit from the customer.
Nové vlakové trasy pre vlak, napríklad v prípade prerušenia služieb, vedú k revízii plánov ciest pre príslušné vozne.
This release time is the first movement entry for a wagon into the Wagon and Intermodal Unit Operational Database related to an actual transport journey.
Tieto databázy musia byť prístupné cez spoločné rozhranie (4.2.14.1: Všeobecná architektúra a 4.2.12.6: Spoločné rozhranie).
The messages for the wagon movement are defined in the Chapters 4.2.8 (Wagon Movement) and 4.2.9 (Interchange Reporting).
Okrem uvedených povinných databáz sa u každého manažéra infraštruktúry môže nainštalovať vlaková databáza.
This database must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Táto vlaková databáza manažéra infraštruktúry zodpovedá časti o pohybe prevádzkovej databázy vozňov a intermodálnych jednotiek.
The Wagon and Intermodal Unit Operational Database is the most important one for the tracking of wagons and therefore for the communication between the RUs involved and the Lead RU.
Hlavný záznam údajov predstavujú údaje správy „Zostava vlaku“ od železničného podniku, ktoré sa týkajú vlaku.
This database shows the movement of a wagon and of an Intermodal unit from departure through to final delivery at customer sidings with ETIs and actual times at different locations until the final delivery time ETA.
Všetky udalosti týkajúce sa vlaku majú za následok aktualizáciu tejto vlakovej databázy.
The database also shows the different status of the rolling stock such as:
Alternatívnou možnosťou uchovávania týchto údajov je databáza trás (kapitola 4.2.2: Žiadosť o trasu).
Status:
Tieto databázy musia byť prístupné cez spoločné rozhranie (4.2.12.1: Všeobecná architektúra a 4.2.12.6: Spoločné rozhranie).
loading of the rolling stock
Dodatočné požiadavky na databázy
This status is required for the information exchange between the RU and the IMs and to other railway undertakings involved in the transport journey.
V nasledujúcich bodoch sú uvedené dodatočné požiadavky, ktoré musia jednotlivé databázy spĺňať.
loaded wagon on journey
Sú to:
This status is required for the information exchange between the IM and the RU, with other infrastructure managers and with other railway undertakings involved in the transport journey.
Overovanie
empty wagon on journey
Databáza musí podporovať overovanie používateľov systémov predtým, než sa im umožní získať prístup k databáze.
unloading of rolling stock
Databáza musí podporovať hľadiská zabezpečenia v zmysle regulovania prístupu k databáze.
This status is required for the information exchange between the RU at destination and the Lead RU for the transport.
Prípadné šifrovanie samotného obsahu databázy sa nevyžaduje.
empty wagon under fleet management control
Konzistentnosť
This status is required to get the information about availability of a vehicle of defined characteristics.
Vybraná databáza musí podporovať zásadu ACID (atomicita, konzistentnosť, izolácia a trvalosť).
Wagon Trip Plan Databases
Kontrola prístupu
Trains may be composed of wagons from various Customers.
Databáza musí umožniť prístup k údajom používateľom alebo systémom, ktorým bolo udelené povolenie.
For each wagon the Lead RU (RU acting as Service Integrator) must establish and update a trip plan which corresponds to the train path at train level.
Kontrola prístupu musí byť podporovaná až na úroveň jednotlivých atribútov záznamov údajov.
New train paths for a train — e.g. in case of service interruptions — lead to revised trip plans for the wagons concerned.
Pre vkladanie, aktualizáciu alebo odstraňovanie záznamov údajov musí databáza podporovať konfigurovateľnú kontrolu prístupu založenú na rolách.
The creation time for the trip plan is the receipt of the consignment note from the customer.
Sledovanie
The Wagon Trip Plans must be stored by each LRU in a database.
Databáza musí podporovať zaznamenávanie všetkých úkonov v databáze, aby sa umožnilo podrobné sledovanie záznamu (kto, kedy a ako zmenil obsah).
These databases must be accessible via the Common Interface (4.2.14.1: General Architecture and 4.2.12.6: Common Interface).
Stratégia uzamykania
In addition to the mandatory databases mentioned above, at each IM side a train database may be installed.
Databáza musí používať stratégiu uzamykania, ktorá umožní prístup k údajom aj vtedy, keď iní používatelia práve upravujú záznamy.
This infrastructure manager train database corresponds to the movement part of the Wagon and Intermodal Unit Operational Database.
Prístup viacerých používateľov
The main data entry is the train related data of the train composition message from the RU.
Databáza musí podporovať možnosť súčasného prístupu niekoľkých používateľov a systémov k údajom.
All train events result in an update of this train related database.
Spoľahlivosť
An alternative storage possibility for these data is the path database (Chapter 4.2.2: Path Request).
Spoľahlivosť databázy musí podporovať požadovanú použiteľnosť.
These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Použiteľnosť
Additional Requirements on the Databases
Použiteľnosť databázy na požiadanie musí dosahovať aspoň 99,9 %.
Under the following points are listed additional requirements which must be supported by the various databases.
Udržovateľnosť
These are:
Udržovateľnosť databázy musí podporovať požadovanú použiteľnosť.
Authentication
Samotné databázy nesúvisia s bezpečnosťou.
A database must support the authentication of users of the systems before they can gain access to the database.
Hľadiská bezpečnosti preto nie sú relevantné.
Security
Toto sa však nesmie zamieňať so skutočnosťou, že údaje, napríklad chybné alebo neaktuálne údaje, môžu mať vplyv na bezpečnú prevádzku vlaku.
A database must support the security aspects in the meaning of controlling access to the database.
Zlučiteľnosť
The possible encryption of the database contents itself is not required.
Databáza musí podporovať všeobecne uznávaný jazyk na manipuláciu s údajmi, ako je napríklad SQL alebo XQL.
Consistency
Funkcia importu
A database selected shall support the ACID principle (Atomicity, Consistency, Isolation and Durability).
Databáza musí byť vybavená funkciou, ktorá umožní import formátovaných údajov, ktoré môžu byť použité na naplnenie databázy namiesto manuálneho vkladania.
Access Control
Funkcia exportu
A database must allow access to the data to users or systems that have been granted permission.
Databáza musí byť vybavená funkciou, ktoré umožní export obsahu celej databázy alebo jej časti ako formátovaných údajov.
The access control shall be supported down to a single attribute of a data record.
Povinné polia
The database shall support configurable, role based access control for insertion, update or deletion of data records.
Databáza musí podporovať povinné polia, ktoré majú byť vyplnené pred prijatím príslušného záznamu ako vstupného údaja do databázy.
Tracing
Kontroly hodnovernosti
A database must support logging all actions applied to the database to allow for tracing the detail of the data entry (Who, What, When did the contents change).
Databáza musí podporovať konfigurovateľné kontroly hodnovernosti pred prijatím vloženia, aktualizácie alebo odstránenia záznamov údajov.
Lock strategy
Časy odozvy
A database must implement a locking strategy which allows access to the data even when other users are currently editing records.
Databáza musí mať časy odozvy, ktoré umožnia používateľom včas vkladať, aktualizovať alebo odstraňovať záznamy údajov.
Multiple access
Hľadiská výkonnosti
A database must support that data can be accessed simultaneously by several users and systems.
Referenčné súbory a databázy musia nákladovo efektívnym spôsobom podporovať dopyty potrebné na efektívne fungovanie všetkých relevantných jázd vlakov a pohybov vozňov, na ktoré sa vzťahujú ustanovenia tejto TSI.
Reliability
Hľadiská kapacity
The reliability of a database must support the required availability.
Databáza musí podporovať uchovávanie príslušných údajov pre všetky nákladné vozne, prípadne pre sieť.
Availability
Jej kapacita sa musí dať jednoducho rozšíriť (t. j. pridaním väčšej pamäťovej kapacity a počítačov).
A database must have an availability on demand of at least 99,9 %.
Rozšírenie kapacity si nesmie vyžadovať výmenu subsystému.
Maintainability
Historické údaje
A maintainability of the database must support the required availability.
Databáza musí podporovať správu historických údajov v zmysle sprístupnenia údajov, ktoré už boli prenesené do archívu.
Databases themselves are not safety-related.
Stratégia zálohovania
Hence safety aspects are not relevant.
Musí sa uplatňovať stratégia zálohovania s cieľom zabezpečiť možnosť obnovy celého obsahu databázy za obdobie až 24 hodín.
This is not to be confused with the fact that the data — e.g. wrong or not actual data — may have impact on the safe operation of a train.
Komerčné hľadiská
Compatibility
Používaný databázový systém musí byť komerčne bežne dostupný (commercially-off-the-shelf, COTS) alebo voľne šíriteľný (Open Source).
A database must support a data manipulation language that is widely accepted, such as SQL or XQL.
Poznámky:
Import facility
Uvedené požiadavky musia byť riešené prostredníctvom štandardného systému riadenia databázy (Database Management System, DBMS).
A database shall provide a facility that allows the import of formatted data that can be used to fill the database instead of manual input.
Používanie rôznych databáz je začlenené do jednotlivých spomenutých pracovných postupov.
Export facility
Všeobecným pracovným postupom je mechanizmus požiadavka/odpoveď, kde zainteresovaná strana požaduje informácie z databázy cez spoločné rozhranie (4.2.12.1: Všeobecná architektúra a 4.2.12.6: Spoločné rozhranie).
A database shall provide a facility that allows to export the contents of the complete database or its part as formatted data.
DBMS odpovedá na túto požiadavku buď poskytnutím požadovaných údajov alebo odpoveďou, že nemôžu byť sprístupnené žiadne údaje (žiadne také údaje neexistujú alebo je prístup odmietnutý z dôvodu kontroly prístupu).
Mandatory Fields
Všeobecná architektúra
A database must support mandatory fields that are required to be filled before the relevant record is accepted as input to the database.
V tomto subsystéme postupne dôjde k nárastu a interakcii rozsiahleho a zložitého interoperabilného spoločenstva železničnej telematiky so stovkami zúčastnených aktérov (železničných podnikov, manažérov infraštruktúry, …), ktorí budú súťažiť a/alebo spolupracovať pri uspokojovaní potrieb trhu.
Plausibility Checks
Sieťová a komunikačná infraštruktúra, ktorá poskytne podporu takémuto spoločenstvu železničnej interoperability, bude založená na spoločnej architektúre výmeny informácií, ktorú všetci zúčastnení aktéri poznajú a prijmú.
A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Navrhovaná architektúra výmeny informácií:
Response times
je navrhnutá tak, aby zosúladila rôznorodé informačné modely prostredníctvom sémantickej transformácie údajov, ktoré sa vymieňajú medzi systémami, a zosúladením rozdielov v protokoloch na úrovni obchodných procesov a aplikácií,
A database must have response times that allow users to insert, update or delete data records in a timely manner.
má minimálny vplyv na existujúce architektúry informačných technológií implementované jednotlivými účastníkmi,
Performance aspects
chráni už vykonané investície v oblasti informačných technológií.
The reference files and databases shall support in a cost effective manner the queries necessary to allow the effective operation of all relevant train runs and wagon movements that are covered by the provisions of this TSI.
Architektúra výmeny informácií väčšinou podporuje typ interakcie „Peer-to-Peer“ (rovný s rovným) medzi všetkými aktérmi, pričom poskytovaním centralizovaných služieb zaručuje celkovú integritu a konzistentnosť spoločenstva železničnej interoperability.
Capacity aspects
Model interakcie „Peer-to-Peer“ umožní optimálne rozloženie nákladov medzi rôznych aktérov založené na skutočnom používaní a vo všeobecnosti bude predstavovať menšie problémy s rozšíriteľnosťou.
A database shall support the storage of the relevant data for all freight wagons respectively the network.
Grafické znázornenie všeobecnej architektúry sa nachádza v dokumente „TAF TSI – príloha A.5: Čísla a postupové diagramy správ TAF TSI“, kapitola 1.5, uvedenom v dodatku I.
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Sieť
The extension of the capacity shall not require replacement of the subsystem.
Budovanie siete v tomto prípade znamená metódu a filozofiu komunikácie a neznamená fyzickú sieť.
Historical data
Železničná interoperabilita je založená na spoločnej architektúre výmeny informácií, ktorú všetci účastníci poznajú a prijmú, čo podporuje vstup nových účastníkov, najmä zákazníkov, a znižuje jeho bariéry.
A database shall support the management of historical data in the meaning of making of data available that has been already transferred into an archive.
Otázka zabezpečenia sa preto nebude riešiť prostredníctvom siete (virtuálna privátna sieť, tunelovanie, …), ale výmenou a riadením správ, ktoré sú samy osebe zabezpečené.
Back-up strategy
Nevyžaduje sa preto virtuálna privátna sieť (virtual private network, VPN) (správa rozsiahlej virtuálnej privátnej siete by bola zložitá a jej riadenie nákladné), čo zabráni problémom so zodpovednosťou a určovaním vlastníctva.
A back-up strategy shall be in place to ensure that the complete database contents for up to a 24 hour period can be recovered.
Na dosiahnutie primeraného stupňa zabezpečenia nie je nevyhnutné spojenie prenosov cez IP protokol do jedného kanála (tunelovanie).
Commercial aspects
V každom prípade, ak už niektorí aktéri majú alebo chcú zaviesť rôzne stupne zabezpečenia na vybraných častiach siete, môžu tak urobiť.
A database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Hybridný model „Peer to Peer“ so spoločným rozhraním v uzlovom bode každého účastníka a centrálnym certifikačným orgánom je možné zaviesť cez verejnú internetovú sieť.
Remarks:
Komunikácia „Peer to Peer“ sa následne uskutočňuje medzi zúčastnenými aktérmi.
The above requirements must be handled by a standard Database Management System (DBMS).
Komunikácia „Peer to Peer“ je založená na technických normách pre spoločné rozhranie opísaných v dokumente „TAF TSI – príloha D.2: dodatok F – Vzor údajov a správ TAF TSI“ uvedenom v dodatku I.
The usage of the various databases is embedded into various work flows described here before.
Na účely dosiahnutia vysokého stupňa zabezpečenia musia byť všetky správy uzavreté, čo znamená, že informácia v správe je zabezpečená a príjemca môže overiť autentickosť správy.
The general workflow is a request/response mechanism, where an interested party requests information from the database through the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Toto je možné vyriešiť použitím systému šifrovania a podpisovania podobného šifrovaniu elektronickej pošty.
The DBMS responds to this request either by providing the requested data or by responding that no data can be made available (no such data exists or access is refused due to access control).
Šifrovanie
General Architecture
Musí sa používať buď asymetrické šifrovanie, alebo hybridné riešenie založené na symetrickom šifrovaní s verejným kľúčom, keďže zdieľanie spoločného tajného kľúča medzi mnohými aktérmi po určitom čase zlyhá.