natgillin/translations-raw huggingface dataset:
Hence safety aspects are not relevant.
Hľadiská zabezpečenia preto nie sú relevantné.
This is not to be confused with the fact that the data — e.g. wrong or not actual data — may have impact on the safety operation of a train.
Toto sa však nesmie zamieňať so skutočnosťou, že údaje – napríklad chybné alebo neaktuálne údaje – môžu mať dosah na bezpečnostnú prevádzku vlaku.
A database must support a data manipulation language that is widely accepted, such as SQL or XQL.
Databáza musí podporovať jazyk pre manipuláciu s údajmi, ktorý je všeobecne akceptovaný, ako napríklad SQL alebo XQL.
Import facility
Importné zariadenie
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.
Databáza musí poskytovať zariadenie, ktoré umožňuje import formátovaných údajov, ktoré môžu byť použité na uloženie do databázy namiesto manuálneho zadávania.
Export facility
Exportné zariadenie
A database shall provide a facility that allows to export the contents of the complete database or its part as formatted data.
Databáza musí poskytovať zariadenie, ktoré umožňuje export obsahu kompletnej databázy alebo jej časti ako formátovaných údajov.
Mandatory fields
Povinné kolónky
A database must support mandatory fields that are required to be filled before the relevant record is accepted as input to the database.
Databáza musí podporovať povinné kolónky, ktoré majú byť vyplnené pred prijatím príslušného záznamu ako vstupného údaja do databázy.
Plausibility checks
Kontrola hodnovernosti
A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Databáza musí podporovať konfigurovateľné kontroly hodnovernosti pred prijatím vloženia, aktualizácie alebo vymazania záznamov údajov.
Response times
Časy ohlasu
A database must have response times that allow users to insert, update or delete data records in a timely manner.
Databáza musí mať časy ohlasu, ktoré umožnia užívateľom včas vkladať, aktualizovať alebo vymazať záznamy údajov.
Performance aspects
Hľadiská prevádzky
A database shall support the queries necessary to allow the effective run of about 60000 train runs per 24 hours.
Databáza musí podporovať otázky potrebné na umožnenie efektívneho chodu približne 60000 vlakových jázd za 24 hodín.
About 50 % of these train runs are deemed to take place within two hours.
Predpokladá sa, že okolo 50 % z týchto vlakových jázd sa uskutoční do dvoch hodín.
The number and kind of queries or updates per train are dependent on the overall process for planning and running a train.
Počet a druh otázok alebo aktualizácií na vlak závisia od celkového procesu pre plánovanie a prevádzku vlaku.
Capacity aspects
Hľadiská kapacity
A database shall support the storage of the relevant data for all freight wagons respectively the network.
Databáza musí podporovať ukladanie príslušných údajov pre všetky nákladné vagóny v poradí v sieti.
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Musí byť možné jednoduchými prostriedkami rozšíriť kapacitu (t. j. pridaním väčšej pamäťovej kapacity a počítačov).
The extension of the capacity shall not require replacement of the subsystem.
Rozšírenie kapacity nesmie vyžadovať výmenu subsystému.
Historical data
Historické údaje
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.
Databáza musí podporovať správu historických údajov v zmysle sprístupnenia údajov, ktoré už boli prenesené do archívu.
Back-up strategy
Stratégia zálohovania
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.
Musí byť inštalovaná stratégia zálohovania s cieľom zabezpečiť možnosť obnovy kompletného obsahu databázy až do dĺžky trvania 24 hodín.
Commercial aspects
Komerčné hľadiská
A database system used shall be available commercially-off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Používaný databázový systém musí byť komerčne voľne dostupný (COS – produkt – commercially off the shelf) alebo byť k dispozícii vo verejnej sfére (otvorený zdroj).
The above requirements must be handled by a standard Database Management System (DBMS).
Uvedené požiadavky musia byť riadené štandardným systémom riadenia databázy (DBMS – Database Management System).
The usage of the various databases is embedded into various work flows described here before.
Používanie rôznych databáz je zabudované do rôznych pracovných tokov, ktoré tu boli opísané.
The general workflow is a request/response mechanism, where an interested party requests information from the database through the common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).
Všeobecným pracovným tokom je mechanizmus žiadosť/odpoveď, kde zainteresovaná strana požaduje informácie z databázy cez spoločné rozhranie (4.2.14.1: Všeobecná a 4.2.14.7: Spoločné rozhranie).
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).
Systém riadenia databázy (DBMS) odpovedá na túto žiadosť buď poskytnutím požadovaných údajov, alebo odpoveďou, že žiadne údaje nemôžu byť sprístupnené (žiadne také údaje neexistujú alebo je prístup odmietnutý z dôvodu kontroly prístupu).
The description in Chapter 4.2.14 (Networking and communication) presents the communication network to be used for data exchange.
Opis v kapitole 4.2.14 (Budovanie siete a komunikácia) predstavuje komunikačnú sieť, ktorá sa má používať na výmenu údajov.
This network and the described security handling allow any type of network transmission, such as e-mail, file transfer (ftp, http), etc. The type to choose can then be decided upon by the parties involved in the information exchange, which means, that the electronic transmission of documents, for example, via ftp is given.
Táto sieť a opísané bezpečnostné riešenie umožňuje akýkoľvek typ sieťového prenosu, ako je elektronická pošta, prenos súborov (ftp, http) atď. Strany zúčastnené na výmene informácií môžu potom rozhodnúť, ktorý typ si zvolia, čo znamená, že elektronický prenos dokumentov, napríklad cez ftp, je stanovený.
General architecture
Všeobecná štruktúra
This subsystem will see, over time, the growth and interaction of a large and complex telematic rail interoperability community with hundreds of participating actors (RUs, IMs, etc.), which will compete and/or cooperate in serving the market's needs.
S postupom času dôjde v tomto subsystéme k nárastu a interakcii rozsiahleho a zložitého spoločenstva interoperability železničnej telematiky so stovkami zúčastnených činiteľov (železničných podnikov, prevádzkovateľov infraštruktúry...), ktorí budú súťažiť a/alebo spolupracovať pri spĺňaní potrieb trhu.
The network and communication infrastructure supporting such rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all participating actors.
Infraštruktúra budovania siete a komunikácie, ktorá podporuje toto vzájomne prevádzkyschopné železničné spoločenstvo, bude založená na spoločnej štruktúre výmeny informácií, známej a prijatej všetkými zúčastnenými činiteľmi.
The proposed ‘Information Exchange Architecture’:
Navrhovaná štruktúra výmeny informácií:
is designed to reconcile heterogeneous information models by semantically transforming the data that is exchanged between the systems and by reconciling the business process and application-level protocol differences,
je navrhnutá na zosúladenie rôznorodých informačných modelov sémantickou transformáciou údajov, ktoré sa vymieňajú medzi systémami, a zosúladením rozdielov protokolov na aplikačnej úrovni a obchodného procesu,
has minimum impact on the existing IT architectures implemented by every actor,
má minimálny dosah na existujúce štruktúry informačných technológií implementované každým činiteľom,
safeguards IT investments made already.
zabezpečuje už vykonané investície v oblasti informačných technológií.
The Information Exchange Architecture favours a mostly peer-to-peer type of interaction between all actors, while it guarantees the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.
Štruktúra výmeny informácií podporuje väčšinou typ interakcie „Peer-to-Peer“ (rovný s rovným) medzi všetkými činiteľmi, pričom zaručuje celkovú integritu a konzistentnosť vzájomne prevádzkyschopného železničného spoločenstva poskytovaním súboru centralizovaných služieb.
A peer-to-peer interaction model allows the best cost distribution between the different actors, based on actual usage and it will present, in general, lesser scalability problems.
Model interakcie „Peer-to-Peer“ (rovný s rovným) umožňuje najlepšie rozloženie nákladov medzi rôznych činiteľov, ktoré je založené na aktuálnom využívaní, a vo všeobecnosti bude predstavovať menšie problémy prispôsobenia sa.
A pictorial representation on the general architecture is given in Annex A, Index 5, Chapter 1.5.
Grafické znázornenie všeobecnej štruktúry sa nachádza v prílohe A indexe 5 kapitole 1.5.
Network
Sieťová
Networking in this case means the method and philosophy of communication and does not mean the physical network.
Budovanie siete v tomto prípade znamená metódu a filozofiu komunikácie a neznamená fyzickú sieť.
Rail interoperability is based on a common ‘Information Exchange Architecture’, known and adopted by all participants, thus encouraging and lowering barriers for new entrants, especially customers.
Železničná interoperabilita sa zakladá na spoločnej štruktúre výmeny informácií, známej a prijatej všetkými účastníkmi, čím podporuje nových účastníkov a znižuje bariéry pre nových účastníkov, najmä zákazníkov.
The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and managing inherently secure messages.
Bezpečnostné hľadisko preto nebude riešiť sieť (virtuálna súkromná sieť – VPN, spojenie do jedného kanála (tunnelling)...), ale výmena a riadenie vnútorne bezpečných správ.
A VPN network is therefore not required (the administration of a large VPN network will be complex and costly to manage), thus avoiding problems with responsibilities and ownership allocation.
Nevyžaduje sa preto virtuálna súkromná sieť (VPN – virtual private network; správa veľkej virtuálnej súkromnej siete (VPN) by bola zložitá a nákladná na riadenie), čo zabráni problémom so zodpovednosťou a prideľovaním vlastníctva.
Tunnelling is not considered as a necessary means for achieving the appropriate security level.
Spojenie prenosov cez IP protokol do jedného kanála (tunelovanie) sa nepovažuje za nevyhnutný spôsob na dosiahnutie primeraného stupňa bezpečnosti.
In any case if some actors already have or want to implement various degrees of security on selected partitions of the network, they can do so.
V každom prípade, ak už niektorí činitelia majú alebo chcú zaviesť rôzne stupne bezpečnosti na vybraných častiach siete, môžu tak urobiť.
Over the public Internet network it is possible to implement a hybrid peer-to-peer model with a ‘central repository’ and a ‘common interface’ at each actors' node.
Cez verejnú internetovú sieť je možné zaviesť hybridný model „Peer to Peer“ (rovný s rovným) s centrálnou schránkou a spoločným rozhraním v uzlovom bode každého činiteľa.
The central repository is approached first to obtain meta-information, such as the identity of the peer (actor) on which some information is stored, or to verify security credentials.
Najprv sa pristupuje k centrálnej schránke s cieľom získať metainformácie, ako je totožnosť partnera (činiteľa), o ktorom sú uložené nejaké informácie, alebo overiť bezpečnostné doklady.
Afterwards, a peer-to-peer communication is performed between involved actors.
Komunikácia „Peer to Peer“ (rovný s rovným) sa následne uskutočňuje medzi zúčastnenými činiteľmi.
Protocols
Protokoly
Only protocols belonging to the full Internet Protocol suite must be used.
Musia sa používať len tie protokoly, ktoré patria k plnej sade internetových protokolov.
Internet Protocol Suite
Sada internetových protokolov
Application
Aplikačná
Presentation
Prezentačná
Session
Relačná
Transport
Transportná
Routing Protocols
Smerovacie protokoly
Link
Linková
Not specified
Nešpecifikovaná
Physical
Fyzická
To achieve a high level of security, all messages must be self-contained, which means that the information in the message is secured and the receiver can verify the authenticity of the message.
Na účely dosiahnutia vysokého stupňa bezpečnosti musia byť všetky správy uzatvorené, čo znamená, že informácia v správe je zabezpečená a príjemca môže overiť autentickosť správy.
This may be solved by using an encryption and signing scheme similar to email encryption.
Toto je možné vyriešiť použitím šifrovania a podpisovanej schémy podobnej šifrovaniu elektronickej pošty.
This makes it possible to use any type of network transmission, like e-mail, file transfer (ftp, http), etc. The actual type to choose can then be decided upon by the parties involved in the information exchange.
Umožňuje to používať ktorýkoľvek typ sieťového prenosu, ako je elektronická pošta, prenos súborov (ftp, http) atď. Strany zúčastnené na výmene informácií môžu potom rozhodnúť, ktorý konkrétny typ si zvolia.
Encryption
Šifrovanie
Either asymmetric encryption or a hybrid solution based on symmetric encryption with public key protection must be used, due to the fact that sharing a common secret key among many actors will fail at some point.
Musí sa používať buď asymetrické šifrovanie, alebo hybridné riešenie založené na symetrickom šifrovaní s ochranou verejného kľúča kvôli tomu, že zdieľanie spoločného tajného kľúča medzi mnohými činiteľmi v určitom bode zlyhá.
A higher level of security is easier to achieve if every actor takes responsibility for its own pair of keys, even though a high level of integrity of the central repository (the key server) is required.
Ľahšie sa dosiahne vyšší stupeň bezpečnosti, ak každý činiteľ preberie zodpovednosť za svoj vlastný pár kľúčov, aj keď sa vyžaduje vysoký stupeň integrity centrálnej schránky (kľúčového servera).
Central repository
Centrálna schránka
The central repository must be able to handle:
Centrálna schránka musí byť schopná zaobchádzať s:
metadata — structured data describing the content of messages,
metaúdajmi – štruktúrované údaje, ktoré opisujú obsah správ,
Public Key Infrastructure (PKI),
infraštruktúrou verejného kľúča (PKI – Public Key Infrastructure),
Certification Authority (CA),
certifikačným orgánom (CA – Certification Authority),
directory (phonebook) — it contains all needed information about the participating actors for exchanging messages.
adresárom („telefónnym zoznamom“) – obsahuje všetky potrebné informácie o zúčastnených činiteľoch pre výmenu správ.
The management of the central repository should be under the responsibility of a non-commercial co-European organisation.
Riadenie centrálnej schránky by malo byť v zodpovednosti nekomerčnej spoločnej európskej organizácie.
Common interface
Spoločné rozhranie
The common interface is mandatory for each actor in order to join the rail interoperability community.
Spoločné rozhranie je povinné pre každého činiteľa za účelom pripojenia k železničnému spoločenstvu interoperability.
The common interface has to be able to handle:
Spoločné rozhranie musí byť schopné zabezpečiť:
message formatting of outgoing messages according to the metadata,
formátovanie odosielaných správ podľa metaúdajov,
signing and encryption of outgoing messages,
podpisovanie a šifrovanie odosielaných správ,
addressing of the outgoing messages,
adresovanie odosielaných správ,
authenticity verification of the incoming messages,
overenie autenticity prichádzajúcich správ,
decryption of incoming messages,
dešifrovanie prichádzajúcich správ,
conformity checks of incoming messages according to metadata,
overenia zhody prichádzajúcich správ podľa metaúdajov,
handling the single common access to various databases.
zabezpečovanie jediného spoločného prístupu k rôznym databázam.
Each instance of the common interface will have access to all the data required according the TSI within each RU, IM, etc, whether the relevant databases are central or individual (see also Annex A, Index 5, Chapter 1.6).
Každý stupeň spoločného rozhrania bude mať prístup ku všetkým údajom požadovaným podľa technickej špecifikácie pre interoperabilitu v rámci každého železničného podniku, prevádzkovateľa infraštruktúry atď. bez ohľadu na to, či sú príslušné databázy centrálne, alebo individuálne (pozri tiež prílohu A index 5 kapitolu 1.6).
Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented:
Na základe výsledkov overenia autenticity prichádzajúcich správ sa môže implementovať minimálna úroveň potvrdenia správy:
positive send ACK;
kladné zaslanie ACK;
negative send NACK.
záporné zaslanie NACK.
The common interface uses the information in the central repository in order to manage the above tasks.
Spoločné rozhranie používa informácie v centrálnej schránke na účely riadenia uvedených úloh.
An actor may implement a local ‘mirror’ of the central repository to shorten response times.
Činiteľ môže implementovať miestne „zrkadlo“ centrálnej schránky na skrátenie časov odpovede.
In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces are as follows:
Vzhľadom na základné požiadavky v kapitole 3 sú funkčné a technické špecifikácie rozhraní tieto:
Interfaces with the TSI infrastructure
Rozhrania so štruktúrou technickej špecifikácie pre interoperabilitu
The infrastructure subsystem includes traffic management, tracking, and navigation systems: technical installations for data processing and telecommunications intended for long-distance passenger services and freight services on the network in order to guarantee the safe and harmonious operation of the network and efficient traffic management.
Subsystém infraštruktúry zahŕňa riadenie dopravy, vyhľadávanie a navigačné systémy: technické zariadenia na spracovanie údajov a telekomunikácie určené pre diaľkovú osobnú dopravu a nákladnú dopravu v sieti s cieľom zabezpečiť bezpečnú a harmonickú prevádzku siete a účinné riadenie dopravy.
The subsystem Telematic Applications for Freight uses the data required for operational purposes as given by the path contract, eventually updated in the restriction notice database, as provided by the IM. Thus no direct interface exists between this TSI and the TSI for infrastructure.
Subsystém „telematických aplikácií pre nákladnú dopravu“ používa údaje požadované na prevádzkové účely, ako sú stanovené v zmluve o trase, ktoré sú nakoniec aktualizované v databáze oznamov o obmedzeniach poskytovanej prevádzkovateľom infraštruktúry. Neexistuje teda žiadne priame rozhranie medzi touto technickou špecifikáciou pre interoperabilitu a technickou špecifikáciou pre interoperabilitu pre infraštruktúru.
The only connection to control command and signalling is via the
Jediné spojenie s riadením vlakov, zabezpečením a signalizáciou sa uskutočňuje prostredníctvom:
path contract, where within the line segment description the relevant information about usable command control and signalling equipment is given, and
zmluvy o trase, kde sú v rámci opisu časti trate uvedené relevantné informácie o použiteľných riadiacich a signalizačných zariadeniach, a
various Rolling Stock Reference Databases, where the command control and signalling equipment of the rolling stock must be stored.
rôznych referenčných databáz dráhových vozidiel, kde musia byť uložené riadiace a signalizačné zariadenia dráhových vozidiel.
The subsystem Telematic Applications for Freight identifies the technical and operational data, which must be available for the rolling stock.
Subsystém „telematických aplikácií pre nákladnú dopravu“ určuje technické a prevádzkové údaje, ktoré musia byť k dispozícii pre dráhové vozidlá.
The rolling stock TSI specifies the characteristics of a wagon.
Technická špecifikácia pre interoperabilitu „dráhové vozidlá“ špecifikuje charakteristiky vagóna.
If the characteristics changes for a wagon, this must be updated in the Rolling Stock Reference Databases within the normal maintenance process for the database.
Ak sa charakteristiky pre vagón zmenia, zmena musí byť aktualizovaná v referenčných databázach dráhových vozidiel v rámci bežného procesu údržby pre databázu.
Thus no direct interface exists between this TSI and the TSI for rolling stock.
Neexistuje teda žiadne priame rozhranie medzi touto technickou špecifikáciou pre interoperabilitu a technickou špecifikáciou pre interoperabilitu pre dráhové vozidlá.
The subsystem Operation and Traffic Management specifies the procedures and related equipment enabling a coherent operation of the different structural subsystems, both during normal and degraded operation, including in particular train driving, traffic planning and management.
Subsystém „Prevádzka a riadenie dopravy“ špecifikuje postupy a príslušné zariadenia, ktoré umožňujú súvislú prevádzku rôznych štrukturálnych subsystémov počas bežnej aj poruchovej prevádzky, najmä vrátane riadenia vlakov, plánovania a riadenia.
The subsystem Telematic Applications for Freight mainly specifies applications for freight services including real-time monitoring of freight and trains and the management of connections with other modes of transport.
Subsystém „Telematické aplikácie pre nákladnú dopravu“ špecifikuje hlavne aplikácie pre nákladnú dopravu, vrátane monitorovania nákladu a vlakov v reálnom čase a riadenia spojení s inými spôsobmi dopravy.
In order to ensure consistency between both TSIs, the following procedure applies.
Na zabezpečenie súladu medzi oboma technickými špecifikáciami pre interoperabilitu sa používa tento postup:
When the specifications of the TSI Operation and Traffic Management related to the requirements of this TSI will be written and/or will become subject to amendments, then the body in charge of this TSI must be consulted.
Keď sa budú zostavovať špecifikácie technickej špecifikácie pre interoperabilitu „prevádzka a riadenie dopravy“, ktoré sa týkajú požiadaviek tejto technickej špecifikácie pre interoperabilitu a/alebo sa stanú predmetom zmien, vtedy je potrebné konzultovať s orgánom zodpovedným za túto technickú špecifikáciu pre interoperabilitu.
In the case that the specifications of this TSI related to operational requirements specified in the TSI Operation and Traffic Management should be subject to any amendment, the body in charge of the TSI Operation and Traffic Management must be consulted.
V prípade, že technické špecifikácie tejto technickej špecifikácie pre interoperabilitu, ktoré sa týkajú prevádzkových požiadaviek stanovených v technickej špecifikácii pre interoperabilitu „prevádzka a riadenie dopravy“, by mali byť predmetom zmeny, je potrebné konzultovať s orgánom zodpovedným za technickú špecifikáciu pre interoperabilitu „prevádzka a riadenie dopravy“.
In light of the essential requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:
Vzhľadom na základné požiadavky v kapitole 3 sú pravidlá prevádzky špecifické pre subsystém, ktorý upravuje táto technická špecifikácia pre interoperabilitu, tieto:
For data quality assurance purposes, the originator of any TSI message will be responsible for the correctness of the data content of the message at the time when the message is sent.
Na účely zabezpečenia kvality údajov bude pôvodca každej správy technickej špecifikácie pre interoperabilitu zodpovedný za správnosť obsahu údajov správy v čase, keď je správa zaslaná.
Where the source data for data quality assurance purposes is available from the databases provided as part of the TSI, the data contained within those databases must be used for data quality assurance.
Ak sú zdrojové údaje na účely zabezpečenia kvality údajov dostupné z databáz poskytnuté ako súčasť technickej špecifikácie pre interoperabilitu, údaje obsiahnuté v týchto databázach musia byť použité na zabezpečenie kvality údajov.