natgillin/translations-raw huggingface dataset:
Tyto databáze musejí být přístupné přes společné rozhraní (4.2.14.1: Obecná architektura a 4.2.12.6: Společné rozhraní).
These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Kromě uvedených povinných databází si může vést každý PI databázi vlaků.
Additional Requirements on the Databases
Tato databáze vlaků provozovatele infrastruktury koresponduje s pohybovou částí provozní databáze vozů a intermodálních jednotek.
Under the following points are listed additional requirements which must be supported by the various databases.
Hlavní datovou položkou jsou údaje o vlaku ze zprávy o řazení vlaku od ŽP.
These are:
Databázi je zapotřebí aktualizovat při každé události související s vlaky.
Authentication
Alternativní možností uchovávání těchto údajů je databáze tras (kapitola 4.2.2: Žádost o trasu).
A database must support the authentication of users of the systems before they can gain access to the database.
Tyto databáze musejí být přístupné přes společné rozhraní (4.2.12.1: Obecná architektura a 4.2.12.6: Společné rozhraní).
Security
Další požadavky na databáze
A database must support the security aspects in the meaning of controlling access to the database.
Tato kapitola shrnuje další požadavky na databáze, které musí být podporovány různými databázemi.
The possible encryption of the database contents itself is not required.
Jsou to:
Consistency
Ověření pravosti.
A database selected shall support the ACID principle (Atomicity, Consistency, Isolation and Durability).
Každá databáze musí podporovat ověřování uživatelů systémů před umožněním přístupu k databázi.
Access Control
Zabezpečení
A database must allow access to the data to users or systems that have been granted permission.
Každá databáze musí mít zabezpečení ve smyslu kontroly přístupu k databázi.
The access control shall be supported down to a single attribute of a data record.
Šifrování samotného obsahu databáze není požadováno.
The database shall support configurable, role based access control for insertion, update or deletion of data records.
Konzistentnost
Tracing
Každá databáze musí zaručovat vlastnosti ACID (Atomicity, Consistency, Isolation, Durability, tj. atomicita, konzistentnost, oddělitelnost a trvalost).
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).
Kontrola přístupu
Lock strategy
Každá databáze musí umožňovat přístup k datům pouze uživatelům nebo systémům majícím příslušné oprávnění.
A database must implement a locking strategy which allows access to the data even when other users are currently editing records.
Kontrola přístupu musí být zajištěna až do úrovně jednotlivých atributů datových záznamů.
Multiple access
Databáze musí umožňovat nakonfigurování uživatelských přístupových práv pro vkládání, aktualizaci nebo mazání datových záznamů.
A database must support that data can be accessed simultaneously by several users and systems.
Vystopování
Reliability
Každá databáze musí podporovat evidenci všech činností prováděných s databází, aby se umožnilo podrobné vystopování vložených dat (kdo kdy provedl jakou změnu obsahu databáze).
The reliability of a database must support the required availability.
Strategie uzamčení
Availability
Každá databáze musí používat strategii uzamčení, která umožňuje přístup k datům, i když jiní uživatelé současně provádějí úpravu záznamů.
A database must have an availability on demand of at least 99,9 %.
Přístup více uživatelů
Maintainability
Každá databáze musí umožňovat současný přístup více uživatelů a systémů k datům.
A maintainability of the database must support the required availability.
Spolehlivost
Databases themselves are not safety-related.
Databáze musí být natolik spolehlivá, aby zaručovala požadovanou dostupnost.
Hence safety aspects are not relevant.
Dostupnost
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.
Databáze musí být dostupná na vyžádání v nejméně 99,9 % případů.
Compatibility
Udržovatelnost
A database must support a data manipulation language that is widely accepted, such as SQL or XQL.
Udržovatelnost databáze musí umožňovat dosažení požadované dostupnosti.
Import facility
Databáze se samy o sobě nedotýkají bezpečnosti.
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.
Proto je bezpečnostní stránka irelevantní.
Export facility
To ovšem nic nemění na skutečnosti, že data v databázi – např. nesprávná nebo neaktuální – mohou mít vliv na bezpečnost provozu vlaku.
A database shall provide a facility that allows to export the contents of the complete database or its part as formatted data.
Kompatibilita
Mandatory Fields
Každá databáze musí podporovat některý běžně rozšířený jazyk pro manipulaci s daty, např. SQL nebo XQL.
A database must support mandatory fields that are required to be filled before the relevant record is accepted as input to the database.
Funkce importu
Plausibility Checks
Každá databáze musí být vybavena funkcí, která umožňuje import formátovaných dat, která lze použít k naplnění databáze namísto ručního zadávání.
A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Funkce exportu
Response times
Každá databáze musí být vybavena funkcí, která umožňuje vyexportování celého obsahu databáze nebo jeho části v podobě formátovaných dat.
A database must have response times that allow users to insert, update or delete data records in a timely manner.
Povinná pole
Performance aspects
Každá databáze musí obsahovat povinná pole, která musejí být vyplněna, aby mohl být každý jednotlivý vkládaný záznam uznán jako platný záznam do databáze.
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.
Kontroly věrohodnosti
Capacity aspects
Každá databáze musí umožňovat nakonfigurování kontrol věrohodnosti před uznáním vložení, aktualizace nebo výmazu datových záznamů.
A database shall support the storage of the relevant data for all freight wagons respectively the network.
Reakční doby
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Každá databáze musí mít reakční dobu, která umožní uživatelům včas vkládat, aktualizovat nebo mazat datové záznamy.
The extension of the capacity shall not require replacement of the subsystem.
Otázky výkonnosti
Historical data
Referenční soubory a databáze musí nákladově efektivním způsobem podporovat dotazy nezbytné pro efektivní realizaci všech příslušných jízd vlaků a pohybů vozů, na které se vztahují ustanovení této TSI.
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ázky kapacity
Back-up strategy
Každá databáze musí podporovat uchovávání důležitých údajů o všech nákladních vozech resp. síti.
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.
Kapacitu musí být možno jednoduše rozšířit (např. přidáním dalších paměťových kapacit a počítačů).
Commercial aspects
Rozšíření kapacity si nesmí vyžádat náhradu subsystému.
A database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Historická data
Remarks:
Databáze musí podporovat správu historických dat ve smyslu zpřístupnění údajů, které již byly přesunuty do archívu.
The above requirements must be handled by a standard Database Management System (DBMS).
Strategie zálohování
The usage of the various databases is embedded into various work flows described here before.
K dispozici musí být strategie zálohování, která zajistí, aby bylo možno obnovit kompletní obsah databáze za posledních až 24 hodin.
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).
Komerční otázky
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).
U použitého databázového systému půjde o běžně komerčně dostupný (COTS) nebo volně šiřitelný (Open Source) produkt.
General Architecture
Poznámky:
This subsystem will see, over time, the growth and interaction of a large and complex Telematics rail interoperability community with hundreds of participating players (RUs, IMs, etc.), which will compete and/or cooperate in serving the market's needs.
Uvedené požadavky musejí být řešeny prostřednictvím standardního systému řízení databáze (DBMS).
The Network & Communication infrastructure supporting such rail interoperability community will be based on a common Information Exchange Architecture, known and adopted by all participating players.
Používání databází je součástí jednotlivých pracovních toků popsaných v předchozím textu.
The proposed Information Exchange Architecture:
Pracovní toky mají obecně formu mechanismu žádost – odpověď, kdy si příslušná strana vyžádá informace z databáze přes společné rozhraní (4.2.14.1: Obecná architektura a 4.2.12.6: Společné rozhraní).
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,
DBMS zareaguje na tuto žádost buď poskytnutím vyžádaných dat, nebo odpovědí, že nelze poskytnout žádná data (buď taková data neexistují, nebo k nim není povolen přístup).
has minimum impact on the existing IT architectures implemented by every actor,
Obecná architektura
safeguards IT investments made already.
Tento subsystém se časem rozvine a jeho typickým znakem bude interakce velkého a složitého interoperabilního železničního telematického společenství čítajícího stovky subjektů (železniční podniky, provozovatelé infrastruktury ...), kteří spolu budou soutěžit, resp. spolupracovat na plnění potřeb trhu.
The Information Exchange Architectures favours a mostly Peer-to-Peer type of interaction between all players, while it guarantees the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.
Síťová a komunikační infrastruktura, o níž se bude toto interoperabilní železniční telematické společenství opírat, bude založena na společné „Architektuře výměny informací“, která bude všem zúčastněným subjektům známa a bude jimi přijata.
A Peer-to-Peer interaction model allows the best cost distribution between the different players, based on actual usage and it will present, in general, lesser scalability problems.
Navrhovaná architektura výměny informací:
A pictorial representation on the general architecture is given in the document ‘TAF TSI — Annex A.5 Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.5, listed in Appendix I.
je zkonstruována tak, aby sladila nesourodé informační modely prostřednictvím sémantické transformace dat vyměňovaných mezi jednotlivými systémy a prostřednictvím sjednocení rozdílů v protokolech na úrovni podnikových procesů a aplikací;
Network
má minimální dopad na existující IT architektury jednotlivých subjektů;
Networking in this case means the method and philosophy of communication and does not mean the physical network.
chrání dosavadní investice do IT.
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.
Architektura výměny informací upřednostňuje většinou rovnocennou (Peer-to-Peer) interakci mezi všemi subjekty, a přitom zaručuje prostřednictvím souboru centralizovaných služeb celkovou integritu a konzistentnost interoperabilního železničního společenství.
The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and managing inherently secure messages.
Model interakce Peer-to-Peer umožňuje nejlepší rozdělení nákladů mezi jednotlivé subjekty na základě skutečného využívání a povede obecně k menším problémům při rozšiřování.
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.
Schématické znázornění obecné architektury je uvedeno v kapitole 1.5 dokumentu „TAF TSI – příloha A.5: Obrázky a schémata logického sledu zpráv TAF TSI“ uvedeného v dodatku I.
Tunnelling is not considered as a necessary means for achieving the appropriate security level.
Síť
In any case if some players already have or want to implement various degrees of security on selected partitions of the network, they can do so.
Sítí a prací v síti se v tomto případě rozumí způsob a filozofie komunikace a nikoli fyzická síť.
Over the public Internet network it is possible to implement a hybrid Peer to Peer model with a common interface at each actor's node and a central certificate authority.
Není proto zapotřebí VPN síť (správa velké VPN sítě by byla složitá a nákladná), čímž jsou odbourány problémy s odpovědností a určováním vlastnictví.
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.
Pro dosažení potřebné úrovně zabezpečení není nutné tunelování.
This may be solved by using an encryption and signing scheme similar to email encryption.
Pokud však některé zúčastněné subjekty mají zavedeny nebo chtějí zavést vyšší stupně zabezpečení na vybraných částech sítě, mohou tak učinit.
Encryption
Přes veřejnou internetovou síť je možné implementovat hybridní model Peer-to-Peer se společným rozhraním na uzlu každého subjektu a centrálního orgánu vydávajícího certifikáty.
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 players will fail at some point.
Poté probíhá komunikace Peer-to-Peer přímo mezi jednotlivými subjekty.
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.
Komunikace Peer-to-Peer vychází z technických norem pro společné rozhraní popsané v dokumentu „TAF TSI – příloha D.
Central Repository
2: dodatek F – TAF TSI Model údajů a zpráv“ uvedeném v dodatku I.
The Central Repository must be able to handle:
Aby se dosáhlo vysoké úrovně zabezpečení, musejí být všechny zprávy samostatné, což znamená, že informace ve zprávě jsou zabezpečeny a příjemce si může ověřit pravost zprávy.
metadata — structured data describing the content of messages,
To lze vyřešit pomocí systému šifrování a podpisů podobného šifrování elektronické pošty.
Public Key Infrastructure (PKI),
Šifrování
Certification Authority (CA),
Je třeba používat buď asymetrické šifrování, nebo hybridní řešení na bázi symetrického šifrování s veřejným klíčem, neboť sdílení společného tajného klíče mezi více subjekty po nějaké době nevyhnutelně selže.
The management of the central repository should be under the responsibility of a non-commercial co-European organisation.
Vyšší úrovně zabezpečení se snadněji dosáhne, pokud každý subjekt převezme odpovědnost za svůj vlastní pár klíčů, i když v takovém případě je zapotřebí vyšší úrovně integrity centrálního datového skladu (hlavního serveru pro správu klíčů).
Where the Central Repository is in use in conjunction with the TAP TSI (2), development and changes must be in line with TAP TSI (2) in order to achieve optimum synergies.
Centrální datový sklad
A Common Interface is mandatory for each actor in order to join the rail interoperability community.
Centrální datový sklad musí být schopen pracovat s:
A Common Interface has to be able to handle:
metadaty, což jsou strukturovaná data popisující obsah zpráv,
message formatting of outgoing messages according to the metadata,
orgánem vydávajícím certifikáty (Certification Authority, CA), Za správu centrálního datového skladu by měla zodpovídat nezisková celoevropská organizace.
signing and encryption of outgoing messages,
Pokud se centrální datový sklad již používá ve spojení s TAP TSI [2], musí být vývoj a změny tohoto souboru v souladu s TAF TSI [2], aby se dosáhlo optimální synergie.
addressing of the outgoing messages,
Společné rozhraní je povinné pro každý subjekt, který se chce zapojit do interoperabilního železničního společenství.
authenticity verification of the incoming messages,
Společné rozhraní musí být schopno zvládat:
decryption of incoming messages,
formátování odchozích zpráv v souladu s metadaty,
conformity checks of incoming messages according to metadata,
podepisování a šifrování odchozích zpráv,
handling the single common access to various databases.
adresování odchozích zpráv,
Each instance of a Common Interface will have access to all the data required according the TSI within each Wagon keeper, LRU, RU, IM, etc., whether the relevant Databases are central or individual (see also document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.6, listed in Appendix I).
ověření pravosti příchozích zpráv,
Where a Common Interface 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.
dešifrování příchozích zpráv,
Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented:
kontroly shody příchozích zpráv podle metadat,
positive send ACK;
jednotný společný přístup k jednotlivým databázím.
negative send NACK.
Každá instance společného rozhraní musí mít přístup ke všem údajům vyžadovaným podle TSI pro každého držitele vozů, HŽP, ŽP, PI atd., bez ohledu na to, zda jsou příslušné databáze centrální, nebo individuální (viz též kapitola 1.6 dokumentu „TAF TSI – příloha A.5: Obrázky a schémata logického sledu zpráv TAF TSI“ uvedeného v dodatku I).
A common interface uses the information in the central repository in order to manage the above tasks.
Pokud se společné rozhraní již používá v rámci TAP TSI [2], musí být vývoj a změny tohoto souboru v souladu s TAF TSI [2], aby se dosáhlo optimální synergie.
An actor may implement a local ‘mirror’ of the central repository to shorten response times.
Na základě ověření pravosti příchozích zpráv lze zavést minimální kvitanci:
In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces are as follows:
i. kladnou kvitanci ACK, byla-li pravost uznána,
The infrastructure subsystem includes traffic management, tracking, and navigation systems:
zápornou kvitanci NACK, nebyla-li pravost uznána.
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.
Společné rozhraní používá informace v centrálním datovém skladu k řízení výše uvedených úkolů.
The subsystem Telematics Applications for Freight uses the data required for operational purposes as given by the path contract, possibly completed by infrastructure restriction data, as provided by the IM.
Každý subjekt si může v zájmu zkrácení časů odezvy zavést místní „zrcadlo“ centrálního datového skladu.
Thus no direct interface exists between this TSI and the TSI for infrastructure.
S ohledem na základní požadavky v kapitole 3 jsou funkční a technické požadavky na rozhraní následující:
The only connection to control command and signalling is via the
Subsystém „Infrastruktura“ zahrnuje systémy pro řízení dopravy a sledovací a navigační systémy:
Path contract, where within the line segment description the relevant information about usable command control and signalling equipment is given, and
technické instalace pro zpracování dat a telekomunikace, které jsou určeny pro služby dálkové osobní a nákladní dopravy po železniční síti a které mají zaručit bezpečný a harmonický provoz sítě a efektivní řízení dopravy.
various Rolling Sock Reference Databases, where the command control and signalling equipment of the rolling stock must be stored.
Subsystém „Využití telematiky v nákladní dopravě“ využívá údaje požadované pro provozní účely, které jsou uvedeny ve smlouvě o trase, případně doplněny o údaje o omezeních na infrastruktuře, které poskytl PI.
The subsystem Telematics Applications for freight identifies the technical and operational data, which must be available for the rolling stock.
Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Infrastruktura“.
The rolling stock TSI specifies the characteristics of a wagon.
Jediná vazba na řízení a zabezpečení je přes
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.
smlouvu o trase, kde jsou v popisu úseku trati uvedeny příslušné informace o použitelných řídicích a zabezpečovacích zařízeních, a
Thus no direct interface exists between this TSI and the TSI for rolling stock.
různé referenční databáze kolejových vozidel, kde musejí být uloženy údaje o řídicích a zabezpečovacích zařízeních kolejových vozidel.
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 „Využití telematiky v nákladní dopravě“ stanoví technické a provozní údaje, které musejí být k dispozici o kolejových vozidlech.
The subsystem Telematics 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.
TSI pro subsystém „Kolejová vozidla“ stanoví vlastnosti vozů.
In order to ensure consistency between both TSIs, the following procedure applies.
Dojde-li ke změně vlastností vozu, musí být v rámci běžné údržby databáze provedena aktualizace příslušných údajů v referenčních databázích kolejových vozidel.
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.
Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Kolejová vozidla“.
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.
Subsystém „Provoz a řízení dopravy“ stanoví postupy a související vybavení umožňující hladkou spolupráci jednotlivých strukturálních subsystémů, a to jak při běžném, tak při zhoršeném provozu, včetně zejména řízení vlaků a plánování a řízení dopravy.
Interface
Subsystém „Využití telematiky v nákladní dopravě“ vymezuje hlavně využití pro nákladní dopravu včetně sledování nákladu a vlaků v reálném čase a řízení vazeb na jiné druhy dopravy.
Reference Telematics Applications for Freight TSI
Aby byla zajištěna konzistentnost mezi oběma TSI, použije se tento postup:
Reference Telematics Applications for passengers TSI
Při vypracování nebo změně specifikací TSI pro subsystém „Provoz a řízení dopravy“, které se dotýkají požadavků této TSI, musí být konzultován orgán odpovědný za tuto TSI.
Train ready
Při jakékoli změně specifikací této TSI, které se dotýkají požadavků TSI pro subsystém „Provoz a řízení dopravy“, musí být konzultován orgán odpovědný za TSI pro subsystém „Provoz a řízení dopravy“.
Train ready message