natgillin/translations-raw huggingface dataset:
Pokud se referenční soubor již používá v rámci TAF TSI (subsystém „Využití telematiky v nákladní dopravě“), musí se vývoj a použití tohoto souboru co nejvíce přibližovat provádění TAF TSI s cílem dosáhnout optimální synergie.
Where a reference file is in common use with the TAF TSI, its development and use shall be as close as possible to the implemented TAF TSI in order to achieve optimum synergies.
Další požadavky na databáze
Additional requirements concerning databases
Tato kapitola shrnuje další požadavky na databáze.
The additional requirements which must be supported by the various databases are listed below.
Tyto požadavky jsou následující:
They are:
Každá databáze musí mít zabezpečení ve smyslu kontroly přístupu k databázi.
A database must support security aspects in terms of controlling access to the database.
Každá databáze musí zaručovat vlastnosti ACID (Atomicity, Consistency, Isolation, Durability, tj. atomicita, shoda, oddělitelnost, stálost).
A database selected shall support the ACID principle (Atomicity, Consistency, Isolation, Durability).
Každá databáze musí umožňovat přístup k datům uživatelům nebo systémům majícím příslušné oprávnění.
A database must allow access to the data by users or systems that have been granted permission.
Kontrola přístupu musí být zajištěna až do úrovně jednotlivých atributů datových záznamů.
The access control shall be supported down to a single attribute of a data record.
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ů.
The database shall support configurable, role based access control for the insertion, update or deletion of data records.
Dohledávání
Tracing
Každá databáze musí podporovat evidenci všech činností prováděných s databází, aby se umožnilo podrobné dohledání vložených dat (kdo kdy jakou změnu obsahu databáze provedl).
A database must support the logging of all actions applied to the database to allow the detail of the data entry to be traced (Who, What, When did the contents change?).
Strategie uzamčení
Locking strategy
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 implement a locking strategy which allows access to the data even when other users are engaged in editing records.
Každá databáze musí zajistit současný přístup více uživatelů a systémů k datům.
A database must ensure that data can be accessed simultaneously by several users and systems.
Databáze musí mít nezbytnou úroveň dostupnosti, která odpovídá povaze dat a na nich založených obchodních případů.
A database must have the necessary availability level for the nature of the data and the business cases based on it.
Udržovatelnost databáze musí umožňovat dosažení požadované dostupnosti.
The maintainability of the database must support the required availability.
Proto je bezpečnostní stránka irelevantní.
Hence, safety aspects are not relevant.
To ovšem nic nemění na skutečnosti, že data – např. nesprávná nebo neaktuální – mohou mít vliv na bezpečnost provozu vlaku.
This is not to be confused with the fact that the data — e.g. incorrect or not up-to-date data — may have an impact on the safe operation of a train.
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 shall provide a facility that allows the contents of the complete database or part thereof to be exported as formatted data.
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.
A database must support mandatory fields that are required to be completed before the relevant record is accepted as input to the database.
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ů, na které se vztahují ustanovení této TSI.
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 that are covered by the provisions of this TSI.
Každá databáze musí podporovat uchovávání důležitých dat o všech osobních vozech a/nebo síti.
A database shall support the storage of the relevant data for all passenger wagons and/or the network.
Databáze musí podporovat správu historických dat zpřístupněním dat, která již byla přesunuta do archivu.
A database shall support the management of historical data by making data available that have been already transferred into an archive.
K dispozici musí být strategie zálohování, která zajistí, aby bylo možno obnovit kompletní obsah databáze za období až do výše posledních 24 hodin.
A back-up strategy shall be in place to ensure that the complete database contents for a period of up to 24 hours can be recovered.
Pokud jde o použitý databázový systém, půjde o běžně komerčně dostupný (COTS) nebo volně šiřitelný (Open Source) produkt.
The database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Ochrana osobních údajů
Privacy aspects
Databáze musí splňovat požadavky ochrany osobních údajů členského státu, v němž má sídlo společnost poskytující službu.
A database has to fulfil the privacy policy requirements of the Member State in which the company performing the service is domiciled.
V kapitole 4.2.21 – Sítě a komunikace – je popsána komunikační síť pro výměnu dat.
The description in Section 4.2.21 — Networking and communication — presents the communication network to be used for data exchange.
Tato síť a popsané zabezpečení umožňují jakýkoli typ síťového přenosu, jako e-mail, přenos souboru (FTP, HTTP) apod. Strany účastnící se přenosu informací pak mohou rozhodnout o tom, jaký typ elektronického přenosu vybrat, a tím zajistit předávání dokumentů v elektronické podobě například přes FTP.
This network and the described security handling allow any type of network transmission, such as e-mail, file transfer (Ftp, Http), etc. The parties involved in the information exchange can then decide on the type to choose, thereby ensuring the electronic transmission of documents, for example, via FTP.
Tento subsystém postupem času čeká rozmach a interakce velkého a komplexního interoperabilního železničního telematického společenství čítajícího tisíce subjektů (železniční podniky, provozovatelé infrastruktury, třetí strany, jako jsou prodejci a orgány veřejné správy atd.), kteří spolu budou soutěžit a/nebo spolupracovat na plnění potřeb trhu.
Over time this subsystem will see the growth and interaction of a large and complex telematics rail interoperability community with thousands of participating actors (railway undertakings, infrastructure managers, third parties such as retailers and public authorities, etc.), which will compete and/or cooperate in serving the market’s needs.
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í“, kterou budou znát a kterou přijmou všechny zúčastněné strany.
The network and communication infrastructure supporting such a rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all those participating in it.
Navrhovaná „architektura výměny informací“:
The proposed ‘Information Exchange Architecture’:
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í,
is designed to reconcile heterogeneous information models by semantically transforming the data that are exchanged between the systems and by reconciling the differences in business processes and application-level protocols,
má minimální dopad na existující IT architektury jednotlivých subjektů,
has a minimal impact on the existing IT architectures implemented by each actor,
chrání dosavadní investice do IT.
safeguards IT investments already made.
Architektura výměny informací upřednostňuje hlavně rovnocennou (peer-to-peer) interakci mezi všemi subjekty a přitom prostřednictvím souboru centralizovaných služeb zaručuje celkovou integritu a konzistentnost interoperabilního železničního společenství.
The Information Exchange Architecture favours a mostly Peer-to-Peer type of interaction between all actors, while guaranteeing the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.
Model „peer-to-peer“ interakce umožňuje nejlepší rozdělení nákladů mezi jednotlivé partnery 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 Peer-to-Peer interaction model allows the best distribution of costs between the different actors, based on actual usage and, in general, will pose fewer scalability problems.
Síť musí zajišťovat nezbytnou úroveň zabezpečení, zálohování, řízení provozu, statistických nástrojů, růstu šířky pásma, uživatelské přístupnosti a efektivního řízení.
The network shall ensure the necessary level for security, redundancy, traffic control, statistics tools, bandwidth growth, user accessibility and efficient management.
Sítí se v tomto případě rozumí způsob a filozofie komunikace, a nikoli fyzická síť.
‘Network’ in this context means the method and philosophy of communication and does not refer to the physical network.
Interoperabilita železničního systému je založena na společné „architektuře výměny informací“, kterou znají a přijímají všechny zúčastněné strany, což snižuje překážky a napomáhá vstupu nových subjektů, zejména zákazníků.
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.
Nejprve se navazuje kontakt s centrálním datovým skladem, ze kterého lze získat metainformace, jako jsou data o totožnosti subjektu, která jsou v něm uložena, nebo kde lze ověřit bezpečnostní oprávnění.
First, the central Repository is approached to obtain meta-information, such as the identity of the peer (actor) on which information is stored, or to verify security credentials.
Poté probíhá rovnocenná (peer-to-peer) komunikace přímo mezi jednotlivými subjekty.
Afterwards, Peer-to-Peer communication takes place between the actors involved.
Pro vývoj je možné používat pouze protokoly náležející do soustavy internetových protokolů (běžně známé jako TCP/IP, UDP/IP apod.).
Only protocols belonging to the Internet Protocol Suite (commonly known as TCP/IP, UDP/IP, etc.) may be used for developments.
Vedle úrovně zabezpečení zaručené na úrovni sítě (viz kapitola 4.2.21.2. Síť) lze dosáhnout dodatečné úrovně zabezpečení citlivých dat použitím kombinace šifrování, certifikace a technologií VPN.
On top of the security level guaranteed at the level of the network (see Section 4.2.21.2 Network), an additional level of security can be achieved for sensitive data by using a combination of encryption, certification scheme and VPN technologies.
V závislosti na obchodních požadavcích lze pro přenos a uchovávání dat používat buď asymetrické, nebo symetrické šifrování.
Either asymmetric or symmetric encryption can be used for data transmission and storage, depending on the business requirements.
Pro tento účel je třeba zavést infrastrukturu veřejných klíčů (Public Key Infrastructure, PKI).
For this purpose a public key infrastructure (PKI) is to be implemented.
seznamem elektronických adres, kde mohou subjekty, jimž je tato TSI určena, umožnit dalším subjektům získat informace nebo data podle ustanovení této TSI,
list of electronic addresses where the actors addressed by this TSI allow other actors to obtain information or data according to the provisions of this TSI,
šifrováním,
encryption,
ověřováním,
authentication,
adresářem („telefonním seznamem“), který obsahuje všechny nezbytné informace o subjektech, které se podílejí na výměně zpráv a dat.
directory (phonebook) — it contains all necessary information on those participating in exchanging messages and data.
Pokud se centrální datový sklad používá ve spojení s TAF TSI, musí se vývoj a změny provádět tak, aby se co nejvíce přibližovaly provádění TAF TSI s cílem dosáhnout optimální synergie.
Where the Central Repository is in use in conjunction with the TAF TSI, development and changes shall be performed as closely as possible to the implemented TAF TSI in order to achieve optimum synergies.
Společné rozhraní pro komunikaci ŽP/PI
Common interface for RU/IM communication
Společné rozhraní je povinné pro každý subjekt, který se chce zapojit do interoperabilního železničního společenství.
The common interface is mandatory for each actor in order to join the rail interoperability community.
adresování odchozích zpráv,
addressing of outgoing messages,
ověření pravosti příchozích zpráv,
authenticity verification of incoming messages,
kontroly shody příchozích zpráv podle metadat,
conformity checks of incoming messages according to the metadata,
jednotný společný přístup k jednotlivým databázím.
handling the single common access to the various databases.
Každá instance společného rozhraní musí mít přístup ke všem datům vyžadovaným podle TSI pro každý železniční podnik, provozovatele infrastruktury atd., bez ohledu na to, zda jsou příslušné databáze centrální, nebo individuální.
Each instance of the common interface will have access to all the data required according to the TSI within each railway undertaking, infrastructure manager, etc., whether the relevant databases are central or individual.
Na základě ověření pravosti příchozích zpráv lze zavést minimální potvrzení (acknowledgement – ACK):
Based on the results of verification of the authenticity of incoming messages, a minimum level of message acknowledgement can be implemented:
kladné ACK, byla-li pravost uznána,
positive: send ACK;
záporné NACK, nebyla-li pravost uznána.
negative: send NACK.
Společné rozhraní používá informace v centrálním datovém skladu k řízení výše uvedených úkolů.
The common interface uses the information in the Central Repository in order to manage the above tasks.
Pokud si subjekt zřídí místní repliku (místní „zrcadlo“) centrálního datového skladu, musí tento subjekt svými vlastními prostředky zajistit, aby místní replika byla přesná a aktuální kopie centrálního datového úložiště.
If an actor implements a local ‘mirror’ of the Central Repository, that actor must then — by its own means — ensure that the local ‘mirror’ is an accurate and up to date copy of the Central Repository.
Pokud se společné rozhraní používá také v rámci TAF TSI, musí se vývoj a změny provádět tak, aby se co nejvíce přibližovaly provádění TAF TSI s cílem dosáhnout optimální synergie.
Where the Common Interface is in common use with the TAF TSI, the development and changes shall take place as closely as possible to the implemented TAF TSI, in order to achieve optimum synergies.
Zabezpečování spojení s jinými druhy dopravy
Management of connection with other modes of transport
Za účelem zabezpečení spojení mezi železniční dopravou a jinými druhy dopravy se na poskytování informací jiným druhům dopravy a výměnu informací s jinými druhy dopravy použijí následující normy:
In order to manage the connection with other modes of transport, the following standard should be applied for the provision of information to and exchange of information with other modes of transport:
Pro výměnu informací o jízdních řádech mezi železničními podniky a ostatními druhy dopravy: normy EN 12896 („Transmodel“) a EN TC 278 WI 00278207 („IFOPT – Identification of Fixed Objects in Public transport“ (Identifikace pevných objektů ve veřejné dopravě)).
For the exchange of timetable information between railway undertakings and other modes of transport: norms EN 12896 (‘Transmodel’) and EN TC 278 WI 00278207 (‘IFOPT — Identification of Fixed Objects in Public transport’),
Pro výměnu konkrétních údajů o jízdním řádu se použijí technické normy a protokoly XML založené na „Transmodelu“, a to zejména norma EN 15531 („SIRI“) pro výměnu údajů o jízdních řádech v reálném čase a norma EN TC 278 WI 00278207 („IFOPT“) pro výměnu údajů o „zastávkách/stanicích“.
For the exchange of specific timetable data, the XML technical standards and protocols based on Transmodel, in particular norm EN 15531 (‘SIRI’) for the exchange of real-time timetables and norm EN TC 278 WI 00278207 (‘IFOPT’) for the exchange of ‘stop/station’ data.
Pro výměnu údajů o tarifech: tato norma je stále otevřeným bodem (viz příloha II – seznam otevřených bodů).
For the exchange of tariff data: this standard is still an open point (see Annex II — List of open points).
Rozhraní subsystému „využití telematiky v osobní dopravě“ a rozhraní ostatních subsystémů jsou z hlediska technické kompatibility popsána v následujících odstavcích.
From the standpoint of technical compatibility, the interfaces of the subsystem ‘telematics applications for passenger services’ with the other subsystems are as described in the following paragraphs.
Rozhraní se subsystémem „kolejová vozidla“
Interfaces with the Rolling Stock Subsystem
Rozhraní se subsystémem „kolejová vozidla“
Interfaces with the Rolling Stock subsystem
Odkaz v TSI týkající se „využití telematiky v osobní dopravě“
Reference Telematics Applications for passengers TSI
Odkaz v TSI subsystému „Kolejová vozidla“ konvenčního železničního systému
Reference Conventional Rail Rolling Stock TSI’s
Displej zobrazovacího zařízení
Board device display
Poskytování informací v prostoru pro automobily
Handling of information provision in vehicle area
Informace pro zákazníky (OOSPO)
Customer information (PRM)
Automatické hlasové oznámení
Automatic voice and announcement
Rozhraní se subsystémem „využití telematiky v nákladní dopravě“
Interfaces with the Telematics Applications for Freight Subsystem
Rozhraní se subsystémem „využití telematiky v nákladní dopravě“
Interfaces with the Telematics Applications for Freight subsystem
Odkaz v TSI pro subsystém „využití telematiky v nákladní dopravě“ konvenčního železničního systému
Reference Conventional Rail Telematics Applications for Freight TSI
Vlak připraven
Train ready
Zpráva Vlak připraven pro všechny vlaky
Train ready message for all trains
Zpráva Vlak připraven
Train ready message
Zpráva „prognóza jízdy vlaku“ pro všechny vlaky
‘Train running forecast’ message for all trains
Zpráva Prognóza jízdy vlaku
Train running forecast message
Informace o jízdě vlaku
Train running information
Zpráva „informace o jízdě vlaku“ pro všechny vlaky
‘Train running information’ message for all trains
Jízda vlaku přerušena ŽP
Train running interrupted to RU
Zpráva „jízda vlaku přerušena“ pro všechny vlaky
‘Train running interrupted’ message for all trains
Jízda vlaku přerušena
Train running interrupted
Poskytování krátkodobých údajů o jízdním řádu
Handling of short term timetable data
Společné rozhraní
Common Interface
Centrální datový sklad
Central Repository
Referenční soubory
Reference Files
S ohledem na základní požadavky stanovené v kapitole 3 jsou provozní předpisy specifické pro subsystém upravený touto TSI stanoveny takto:
In the light of the Essential Requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:
Aby byla zabezpečena kvalita dat, odpovídá autor jakékoli TSI zprávy za správnost dat v ní obsažených v době odeslání zprávy.
For the purposes of data quality assurance, 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.
Jsou-li pro účely zajištění kvality k dispozici výchozí data z databází podle této TSI, musejí být tato data použita pro zajištění kvality dat.
Where the source data for data quality assurance purposes are available from the databases provided as part of the TSI, the data contained within those databases must be used for data quality assurance.
Nejsou-li k dispozici výchozí data z databází stanovených podle této TSI, musí autor zprávy provést kontrolu kvality dat z vlastních zdrojů.
Where the source data for data quality assurance purposes is not supplied by the databases provided as part of this TSI, the originator of the message must carry out the data quality assurance check from their own resources.
Součástí zabezpečení kvality dat jsou srovnání s daty z databází stanovených podle této TSI, jak je popsáno výše, plus případné logické kontroly, které mají zaručit včasnost a kontinuitu dat a zpráv.
Data quality assurance will include comparison with data from databases provided as part of this TSI as described above, plus — where applicable — logic checks to assure the timeliness and continuity of data and messages.
Vysoká kvalita dat závisí na jejich vhodnosti pro zamýšlené použití, čímž se rozumí, že:
Data are of high quality if they are fit for their intended uses, which means that they:
jsou bezchybné dostupné, přesné, včasné, kompletní, konzistentní s jinými zdroji apod.,
are error-free accessible, accurate, timely, complete, consistent with other sources, etc.,
mají požadované vlastnosti jsou relevantní, komplexní, náležitě podrobné, snadno čitelné, snadno interpretovatelné apod.
possess the desired features relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc.
Hlavní vlastnosti kvality údajů jsou:
The main characteristics of data quality are:
úplnost,
completeness,
konzistentnost,
consistency,
včasnost.
timeliness.
Požadované informace (data) musejí být zachyceny co možná nejekonomičtěji.
The information (data) required needs to be captured as economically as possible.
To je možné jedině tehdy, jsou-li primární data zaznamenávána, pokud je to možné, v jediném okamžiku.
This is only feasible if the Primary Data only are recorded, if possible, on one single occasion.
Proto by měla být primární data zadávána do systému co možná nejblíže jejich zdroji, aby mohla být kompletně použita při jakémkoli dalším zpracování.
Therefore, the Primary Data should be introduced into the system as close as possible to its source, so that they can be fully integrated into any subsequent processing operation.
Před zasláním zprávy je třeba zkontrolovat její úplnost a syntax oproti metadatům.
Before sending out messages, the completeness and syntax must be checked using the Metadata.
Také u všech příchozích zpráv je zapotřebí zkontrolovat jejich úplnost oproti metadatům.
All incoming messages must also be checked for completeness using the Metadata.
Konzistentnost
Consistency
Obchodní pravidla musejí zaručovat konzistentnost.
Business rules must be implemented in order to guarantee consistency.
Měla by bránit dvojímu zadávání a jasně stanovit osobu odpovědnou za údaje.
Double entry should be avoided and the owner of the data should be clearly identified.
To, jakým způsobem budou tato pravidla realizována v praxi, závisí na jejich složitosti.
The type of implementation of these business rules depends on their complexity.
V případě složitějších pravidel, která vyžadují údaje z různých tabulek, musí být zavedeny validační postupy, které kontrolují konzistentnost verze dat, než dojde k vygenerování dat pro rozhraní a uvedení nové verze dat do provozu.
In the case of more complex rules, which require data from various tables, validation procedures must be implemented which check the consistency of the data version before interface data are generated and the new data version becomes operational.
Musí být zaručeno, aby byl ověřen soulad přenesených dat se stanovenými obchodními pravidly.
It must be ensured that transferred data are validated against the defined business rules.
Je důležité, aby informace byly poskytovány v pravý čas.
Providing information right on time is important.
Pokud dává podnět k uložení dat nebo odeslání zprávy přímo systém IT, není včasnost problémem, je-li systém navržen správně a vyhovuje-li potřebám obchodních procesů.
Insofar as the trigger for data storage or for message sending is event driven directly from the IT system, timeliness is not a problem if the system is designed properly and according the needs of the business processes.