natgillin/translations-raw huggingface dataset:
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 insertion, update or deletion of data records.
Vystopování
Tracing
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).
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).
Strategie uzamčení
Lock 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 currently editing records.
Přístup více uživatelů
Multiple access
Každá databáze musí umožňovat současný přístup více uživatelů a systémů k datům.
A database must support that data can be accessed simultaneously by several users and systems.
Spolehlivost
Reliability
Databáze musí být natolik spolehlivá, aby zaručovala požadovanou dostupnost.
The reliability of a database must support the required availability.
Databáze musí být dostupná na vyžádání v nejméně 99,9 % případů.
A database must have an availability on demand of at least 99,9 %.
Udržovatelnost
Maintainability
Udržovatelnost databáze musí umožňovat dosažení požadované dostupnosti.
A maintainability of the database must support the required availability.
Databáze se samy o sobě nedotýkají bezpečnosti.
Databases themselves are not safety related.
Proto je bezpečnostní stránka irelevantní.
Hence safety aspects are not relevant.
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.
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.
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 a data manipulation language that is widely accepted, such as SQL or XQL.
Funkce importu
Import facility
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 shall provide a facility that allows the import of formatted data that can be used to fill the database instead of manual input.
Funkce exportu
Export facility
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 to export the contents of the complete database or its part as formatted data.
Povinná pole
Mandatory fields
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 filled before the relevant record is accepted as input to the database.
Kontroly věrohodnosti
Plausibility checks
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 must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Reakční doby
Response times
Každá databáze musí mít reakční dobu, která umožňuje uživatelům vkládat, aktualizovat nebo mazat datové záznamy včasným způsobem.
A database must have response times that allow users to insert, update or delete data records in a timely manner.
Otázky výkonnosti
Performance aspects
Každá databáze musí podporovat dotazy nezbytné pro realizaci asi 60000 jízd vlaků za 24 hodin.
A database shall support the queries necessary to allow the effective run of about 60000 train runs per 24 hours.
Počítá se s tím, že cca 50 % těchto jízd se uskuteční v rozpětí 2 hodin.
About 50 % of these train runs are deemed to take place within two hours.
Počet a druh dotazů nebo aktualizací na jeden vlak závisí na celkovém způsobu plánování a provozování vlaků.
The number and kind of queries or updates per train are dependent on the overall process for planning and running a train.
Otázky kapacity
Capacity aspects
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 database shall support the storage of the relevant data for all freight wagons respectively the network.
Kapacitu musí být možno jednoduše rozšířit (např. přidáním dalších paměťových kapacit a počítačů).
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Rozšíření kapacity si nesmí vyžádat náhradu subsystému.
The extension of the capacity shall not require replacement of the subsystem.
Historická data
Historical data
Databáze musí podporovat správu historických dat ve smyslu zpřístupnění údajů, které již byly přesunuty do archívu.
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.
Strategie zálohování
Back-up strategy
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.
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.
Komerční otázky
Commercial aspects
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.
A database system used shall be available commercially-off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Uvedené požadavky musejí být řešeny prostřednictvím standardního systému řízení báze dat (DBMS).
The above requirements must be handled by a standard Database Management System (DBMS).
Používání databází je součástí jednotlivých pracovních toků popsaných v předchozím textu.
The usage of the various databases is embedded into various work flows described here before.
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.14.7: Společné rozhraní).
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).
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).
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).
V kapitole 4.2.14 (Sítě a komunikace) je popsána komunikační síť pro výměnu údajů.
The description in Chapter 4.2.14 (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. O typu elektronického přenosu dokumentů mohou rozhodovat strany účastnící se přenosu informací, které se mohou kupříkladu dohodnout, že použijí ftp.
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.
Obecná architektura
General architecture
Tento subsystém časem čeká rozmach a interakce velkého a složitého interoperabilního železničního telematického společenství čítající stovky partnerů (železniční podniky, provozovatelé infrastruktury, …), kteří spolu budou soutěžit, resp. spolupracovat na plnění potřeb trhu.
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íť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 rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all participating actors.
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 is exchanged between the systems and by reconciling the business process and application-level protocol differences,
má minimální dopad na existující IT architektury jednotlivých partnerů,
has minimum impact on the existing IT architectures implemented by every actor,
chrání dosavadní investice do IT.
safeguards IT investments made already.
Architektura výměny informací upřednostňuje hlavně rovnocennou (Peer-to-Peer) interakci mezi všemi partnery, 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 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.
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 cost distribution between the different actors, based on actual usage and it will present, in general, lesser scalability problems.
Schématické znázornění obecné architektury najdete v příloze A indexu 5 kapitole 1.5.
A pictorial representation on the general architecture is given in Annex A, Index 5, Chapter 1.5.
Síťová vrstva
Network
Sítí a prací v síti se v tomto případě rozumí způsob a filozofie komunikace a nikoli fyzická síť.
Networking in this case means the method and philosophy of communication and does not mean the physical network.
Interoperabilita železničního systému je založena na společné „Architektuře výměny informací“, kterou znají a akceptují 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.
Problematiku zabezpečení proto neřeší síť (VPN, tunelování, ...), ale výměna a správa zpráv, které jsou bezpečné samy ze své podstaty.
The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and managing inherently secure messages.
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í.
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.
Pro dosažení potřebné úrovně zabezpečení není nutné tunelování.
Tunnelling is not considered as a necessary means for achieving the appropriate security level.
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.
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.
Přes veřejnou internetovou síť je možné implementovat hybridní Peer-to-Peer model s „centrálním datovým skladem“ a „společným rozhraním“ na uzlu každého partnera.
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.
Nejprve se navazuje kontakt s centrálním datovým skladem, ze kterého lze získat metainformace, jako jsou údaje o totožnosti partnera, které jsou v něm uloženy, nebo kde lze ověřit bezpečnostní oprávnění.
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.
Poté probíhá rovnocenná (peer-to-peer) komunikace přímo mezi jednotlivými partnery.
Afterwards, a peer-to-peer communication is performed between involved actors.
Protokoly
Protocols
Smějí se používat pouze protokoly náležející do soustavy protokolů TCP/IP.
Only protocols belonging to the full Internet Protocol suite must be used.
Referenční model OSI
OSI Reference Model
Soustava protokolů TCP/IP
Internet Protocol Suite
Aplikační vrstva
Application
Prezentační vrstva
Presentation
Relační vrstva
Session
Přenosová vrstva
Transport
Směrovací protokoly
Routing Protocols
Linková vrstva
Link
Nestanoveny
Not specified
Fyzická vrstva
Physical
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.
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.
To lze vyřešit pomocí systému šifrování a podpisů podobného šifrování elektronické pošty.
This may be solved by using an encryption and signing scheme similar to email encryption.
Šifrování umožní využívat jakýkoli typ síťového přenosu, včetně e-mailu, přenosu souborů (ftp, http) apod. Strany, mezi nimiž probíhá výměna informací, se pak mohou samy rozhodnout pro konkrétní typ přenosu, který chtějí použít.
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.
Šifrování
Encryption
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 partnery musí po nějaké době nevyhnutelně selhat.
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.
Vyšší úrovně zabezpečení se snadno dosáhne, pokud každý partner 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íčů).
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.
Centrální datový sklad
Central repository
Centrální datový sklad musí být schopen pracovat s:
The central repository must be able to handle:
metadaty, což jsou strukturovaná data popisující obsah zpráv,
metadata — structured data describing the content of messages,
infrastrukturou veřejných klíčů (Public Key Infrastructure, PKI),
Public Key Infrastructure (PKI),
orgánem vydávajícím certifikáty (Certification Autority, CA),
Certification Authority (CA),
adresářem („telefonním seznamem“), který obsahuje všechny informace o zúčastněných partnerech potřebné pro výměnu zpráv.
directory (phonebook) — it contains all needed information about the participating actors for exchanging messages.
Za správu centrálního datového skladu by měla zodpovídat nezisková celoevropská organizace.
The management of the central repository should be under the responsibility of a non-commercial co-European organisation.
Společné rozhraní
Common interface
Společné rozhraní je povinné pro každého partnera, 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.
Společné rozhraní musí být schopno zvládat:
The common interface has to be able to handle:
formátování odchozích zpráv v souladu s metadaty,
message formatting of outgoing messages according to the metadata,
podepisování a šifrování odchozích zpráv,
signing and encryption of outgoing messages,
adresování odchozích zpráv,
addressing of the outgoing messages,
ověření pravosti příchozích zpráv,
authenticity verification of the incoming messages,
dešifrování příchozích zpráv,
decryption of incoming messages,
kontroly shody příchozích zpráv podle metadat,
conformity checks of incoming messages according to metadata,
jednotný společný přístup k jednotlivým databázím.
handling the single common access to various databases.
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ý ŽP, PI atd., bez ohledu na to, zda jsou příslušné databáze centrální, nebo individuální (viz též příloha A index 5 kapitola 1.6).
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).
Na základě ověření pravosti příchozích zpráv lze zavést kvitanci:
Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented:
kladná kvitance ACK, byla-li pravost uznána,
positive send ACK;
záporná kvitance 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.
Každý partner si může v zájmu zkrácení časů odezvy zavést místní „zrcadlo“ centrálního datového skladu.
An actor may implement a local ‘mirror’ of the central repository to shorten response times.
Ve světle základních požadavků stanovených v kapitole 3 jsou funkční a technické specifikace rozhraní stanoveny takto:
In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces are as follows:
Rozhraní s TSI pro subsystém „Infrastruktura“
Interfaces with the TSI infrastructure
Subsystém „Infrastruktura“ zahrnuje systémy pro řízení dopravy a sledovací a navigační systémy: 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.
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 „Využití telematiky v nákladní dopravě“ využívá údaje požadované pro provozní účely, které jsou uvedeny ve smlouvě o trase, případně aktualizovány PI v databázi informací o omezeních. Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Infrastruktura“.
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.
Jediná vazba na řízení a zabezpečení je přes
The only connection to control command and signalling is via the
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 přes
path contract, where within the line segment description the relevant information about usable command control and signalling equipment is given, and
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.
various Rolling Stock 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ě“ stanoví technické a provozní údaje, které musejí být k dispozici o kolejových vozidlech.
The subsystem Telematic Applications for Freight identifies the technical and operational data, which must be available for the rolling stock.
TSI pro subsystém „Kolejová vozidla“ stanoví vlastnosti vozů.
The rolling stock TSI specifies the characteristics of a wagon.
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.
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.
Neexistuje tedy žádné přímé rozhraní mezi touto TSI a TSI pro subsystém „Infrastruktura“.
Thus no direct interface exists between this TSI and the TSI for rolling stock.
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.
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ě“ 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.
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.
Aby byla zajištěna konzistentnost mezi oběma TSI, použije se tento postup:
In order to ensure consistency between both TSIs, the following procedure applies.
Při rozšíření nebo změně specifikací TSI pro 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.
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.
Při jakékoli změně specifikací této TSI, které se dotýkají požadavků TSI pro Provoz a řízení dopravy, musí být konzultován orgán odpovědný za TSI pro Provoz a řízení dopravy.
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.
Ve světle základních požadavků stanovených v kapitole 3 jsou provozní předpisy specifické pro subsystém upravený touto TSI stanoveny takto:
In 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 údajů, odpovídá autor jakékoli TSI zprávy za správnost údajů v ní obsažených v době odeslání zprávy.
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.