natgillin/translations-raw huggingface dataset:
Podpora snížení výdajů a nákladů prostřednictvím omezení evidence na hranicích.
Support for minimising expenses and costs by reduced data capture at borders.
Podpora urychlení zásilek prostřednictvím garantovaného přejímání vlaků na straně ŽP a PI
Support for speeding up shipment times by guaranteed take-over of trains by RU and IM.
Podpora minimalizace rizik během předávky vozů.
Support for minimising risks during takeover of wagons.
Krok 7: Nejpozději před krokem 8 by měly být na úrovni ŽP realizovány funkce pro pohyb vozů Oznámení o připravenosti vozu k odsunu a o odjezdu vozu, Zpráva o příjezdu vozu do seřaďovacího nádraží, Zpráva o odjezdu vozu ze seřaďovacího nádraží, Oznámení o příjezdu vozu a Oznámení o příjezdu vozu do stanice určení/Potvrzení příjezdu vozu do stanice určení, společně s funkcí plánování přepravy.
Step 7: At latest before step 8, the wagon movement functions ‘Wagon Release and Departure Notice, Wagon Yard Arrival, Wagon Yard Departure, Wagon Arrival Notice and Wagon Delivery Notice/Confirmation’ together with the trip planning functionality should be realised at the RU level.
Umožněna IT podpora pro plánování přepravy vozů a intermodálních jednotek.
IT supported trip planning at wagon and intermodal unit level is possible.
Systém je připraven počítat, zasílat a přijímat zprávy o pohybu vozů a přepravních jednotek.
The system is prepared to calculate send and receive wagon and intermodal unit related movement messages.
První krok k umožnění sledování a vystopování vozů a zásilek v mezinárodním měřítku.
First step for the tracking and tracing of wagons and shipments at an international level.
Krok 8: Pro další krok by měly být realizovány zprávy Jízda vlaku a Prognóza jízdy vlaku.
Step 8: For the next step the Train Running and Train Running Forecast messages should be realised.
S pomocí zprávy Prognóza jízdy vlaku lze zaslat předpokládanou dobu příjezdu (TETA resp. ETH), která je základem pro výpočet ETI a ETA pro vozy/zásilky.
With the Train Running Forecast message, the Train Estimated Time of Arrival (TETA respectively ETH) can be sent, which is the basis for the calculation of the wagon/shipment related ETIs and the ETA.
Tento krok také zahrnuje realizaci dotazů/odpovědí ohledně jízdy vlaku a prognózy.
This step also contains the realisation of the enquiry/response for train running and train forecast.
Zprávy Jízda vlaku a Prognóza jízdy vlaku mohou být zasílány v reálném čase sousedním PI a ŽP.
Train running and train running forecast in real time sent to neighbour IMs and to the RUs.
Možnost lepšího a spolehlivějšího plánování, které umožňuje efektivnější využívání tras.
Enhanced and more reliable planning opportunities supporting efficient path usage.
Zkrácení zastávek na hranicích, podpora využívání tras na základě poptávky.
Reduces border stops, supports demand oriented path usage.
K dispozici jsou údaje o poloze vlaku a předpokládaném čase vlaku, které tvoří základ pro výpočet ETI/ETA pro vůz/zásilku.
Location and train estimated time as a basis for wagon/shipment related ETI/ETA calculation available.
Nástroj, který je schopen vyhovět přání zákazníka být informován, nastanou-li během přepravy problémy.
Tool to meet customer's wish to be informed if transport problems occur.
Společně se završením kroku 4 napomáhá minimalizaci výdajů a nákladů prostřednictvím využívání tras podle poptávky.
Together with the finalising of step 4 support for minimising expenses and costs by demand oriented path usage.
Možnost lepšího a spolehlivějšího plánování.
Enhanced and more reliable planning opportunities.
Urychlení zásilek prostřednictvím zkrácení zastávek na hranicích.
Support for speeding up shipment times by reducing border stops.
Přispění k minimalizaci rizik během předávek vlaků.
Support for minimising risks during take over of trains.
Krok 9: Současně s krokem 8 nebo krátce po něm by mělo být zprovozněno vykazování výměn (kapitola 4.2.9:) a funkce popisované v kapitole 4.2.7 .
Step 9: The interchange reporting (Chapter 4.2.9:Interchange reporting) and the functionality of Chapter 4.2.7 (Shipment ETI/ETA) should be implemented at the same time or shortly after step 8.
To je důležité zejména pro železniční podniky.
This is in particular relevant for RUs.
Znalost, kde přesně se nachází vůz na infrastruktuře PI a který ŽP je za něj odpovědný, dokonce i když vůz není zapojen ve vlaku.
Knowing the location of a wagon within the IM's infrastructure, and which RU is responsible, even if the wagon is not in a train.
Znalost polohy vozu a subjektu odpovědného na seřaďovacím nádraží.
Knowing wagon location and responsible entity in a yard.
Výpočet ETI a ETA na základě hodnot TETA, automatická aktualizace pohybových údajů v provozní databázi vozů a intermodálních jednotek.
ETI and ETA calculation based on TETA values, automatic update of the movement data in the Wagon and Intermodal Unit Operational Database.
Plně realizován mezinárodní management prázdných vozů.
International empty wagon management fully realised.
Dokončeno mezinárodní plánování přepravy.
International trip planning completed.
Možnost sledování a vystopování zásilek v mezinárodním měřítku.
Shipment tracking and tracing on an international level.
Urychlení obrátek vozů.
Speeding up wagon turn around times.
Podpora pro mezinárodní management prázdných vozů.
Support for international empty wagon management.
Podpora pro zásilky do zahraničí a rezervace nabízených služeb.
Support for consignments abroad and booking of services offered.
Umožnění zlepšení kvality mezinárodní dopravy.
Support for quality improvement of international transports.
Podpora pro mezinárodní plánování přepravy.
Support for international trip planning.
Krok 10: Krok 10 zahrnuje zprovoznění funkce „informací v případě narušení provozu“ a realizaci dotazů/odpovědí ohledně zpoždění vlaku, identifikátoru vlaku a vlaku v místě hlášení.
Step 10: The realisation of the ‘service disruption information’ functionality is part of step 10, together with the realisation of the enquiry/response about train delay, train identifier and train at reporting location.
Na základě informací o narušení provozu by mohla být zprovozněna zpráva o vozové mimořádnosti na úrovni ŽP (kapitola 4.2.8.6: vozové mimořádnosti a kapitola 4.2.8.7:).
Based on the disruption information, the Wagon Exception message at RU level (Chapter 4.2.8.6: Wagon Exception message and Chapter 4.2.8.7: Wagon Exception message New ETI/ETA Request) could come into operation.
Zvládání narušení a podávání zbývajících zpráv pro železniční podniky.
Disruption handling and delivery outstanding reports for RUs.
Zlepšení kvality služby.
Quality improvement of the service.
Zvládání výjimek a zbývajících dotazů.
Exception handling and outstanding enquiries.
Možnost sledování a vystopování dodávek v mezinárodním měřítku.
International shipment tracking and tracing.
Krok 11: Po fázi konsolidace by mohlo být zavedeno vyhodnocování předávaných a uchovávaných dat pro účely zlepšování kvality.
Step 11: After a consolidation phase, the evaluation of the transmitted and stored data for quality improvement could come into operation.
Dostupnost vyčerpávající statistické databáze.
Availability of exhaustive statistical database.
Poskytování vstupních dat pro zlepšení kvality dopravní služby.
Provision of input data for improvement of the transport service quality.
Změna je běžnou stránkou všech počítačových systémů používaných v reálném světě.
Change is a facet inherent to any kind of computer-based systems used in real-world environments.
Dávají k ní podnět nové požadavky nebo změny existujících požadavků v důsledku chyb zaznamenaných v provozu nebo potřeba zlepšit výkon či funkční vady.
It is prompted by the emergence of new requirements or by changes to existing requirements either due to errors reported in operation or the need of improvements in performance or other non-functional characteristics.
Změna však musí být řízená, neboť při ní musí být zaručena kontinuita služeb a zpětná kompatibilita, aby si vyžádala minimální čas a zatížila provoz stávajícího IT vybavení zajišťujícího funkce TAF co nejmenšími režijními náklady.
But change has to be managed as it is underpinned by continuity of service considerations and by backward compatibility objectives so as to provoke minimal time and cost overheads to the operation of already deployed IT equipment providing TAF functionality (i.e. legacy IT facilities).
Je proto nezbytné stanovit jasnou strategii, jak zavést a řídit změnu stávajícího IT vybavení, aby se zabránilo narušení železničního provozu a ohrožení kontinuity služeb a interoperability.
It is therefore crucial to define a clear strategy of how to implement and manage change to legacy IT equipment to avoid disruption to railway operations without undermining the underlying objectives of guaranteeing continuity of service and interoperability.
Stanovení takové strategie se opírá o dva stěžejní aspekty:
Two main issues underpin the definition of such a strategy:
vytvoření obecného rámce pro řízení konfigurace, který stanoví standardy a postupy pro řízení vývoje systému.
the establishment of a configuration management framework defining the standards and procedures for managing system evolution.
Tento rámec by měl zahrnovat to, jak evidovat a provést navrhované změny systému, jak vztáhnout tyto změny ke komponentům systému a jak sledovat verze systému,
This should include how to record and process proposed system changes, how to relate these changes to system components and how to track system releases,
politika pro určování základních vývojových úrovní.
a policy for release of system baselines.
Základním předpokladem pro to, aby uplatňování a zavedení systému mohlo být realistické, je stabilita systému.
System stability is essential so that actual implementation and deployment can be realistic.
Tato potřeba stability se týká všech stran:
This need for stability is akin to all parties:
provozovatelů infrastruktury a železničních podniků, které se budou muset umět vypořádat s různými verzemi systémů poskytujících funkce TAF,
the infrastructure managers and the railway operators that will have to handle various versions of systems providing TAF functionality,
odvětví, které potřebuje čas, aby mohlo stanovit, vyvinout a projevit trvalou interoperabilitu.
the industry that needs time to specify, develop and prove continued interoperability.
Základní vývojová úroveň v podstatě představuje stabilní jádro, pokud jde o funkčnost, výkon a jiné nefunkční charakteristiky (např. RAM) [9].
A baseline in essence embodies the concept of a stable kernel in terms of system functionality, performance and other non-functional characteristics (e.g. RAM) [9].
Zkušenosti se systémy tohoto typu z minulosti však ukazují, že pro dosažení stabilní základní vývojové úrovně vhodné pro implementaci je zapotřebí vydání několika verzí [10].
However, past experience with this type of systems has shown that a number of version releases [10] are needed to achieve a stable and implementation-suitable baseline.
Tento poznatek lze znázornit jako takovýto stupňovitý proces:
This can be illustrated as a cascade process as follows:
Potvrzení interoperability
Interoperability proving
Soubor konsolidovaných specifikací
Set of consolidated Spec
= základní vývojová úroveň
= a baseline
Tento proces je díky zpětným smyčkám hodně propletený.
Through its feedback loops, such a process is highly intertwined.
Dílčí procesy proto nemohou probíhat souběžně, to by vedlo k nestabilním a zmatečným situacím, které by narušovaly provoz.
This precludes putting several of those processes in parallel, an approach that would lead to unstable, confusing and operationally hampering situations.
Základní vývojové úrovně se proto musí vypracovávat postupně, nikoli souběžně, jak je ukázáno v následujícím schématu:
Baselines have then to be processed in a series rather than in a parallel manner as illustrated below:
Vydané verze
Version Releases
Základní vývojová úroveň 1
Baseline 1
Základní vývojová úroveň 2
Baseline 2
4letý odstup mezi základními vývojovými úrovněmi
4 years between baselines
Podle současných zkušeností lze odhadnout časový odstup mezi dvěma základními vývojovými úrovněmi na cca čtyři až pět let.
Based on current experience the timing between different baselines can be estimated to be circa four to five years.
Každá nová základní vývojová úroveň by měla být v zásadě vázána na významné změny funkčnosti nebo výkonu systému.
A new baseline should in principle be linked with significant modifications of the system functionality or system performance.
Může jít kupříkladu o:
This could include aspects such as:
zapracování souboru dnešních vnitrostátních funkcí nějaké země, které lze zevšeobecnit, do interoperabilního jádra,
the incorporation of set of today's national functions, where these can be generalized, within the interoperable kernel,
jiné budoucí služby poskytující přidanou hodnotu.
other future value-added services.
Každá základní vývojová úroveň by měla zahrnovat i funkce předchozí úrovně.
Each baseline should also embrace the functionality of the previous baseline.
Dolaďovací verze, které napravují vady systému nebo bezpečnostní nedostatky, by měly být řešeny jako nové verze téže základní vývojové úrovně.
Debugging versions to repair system faults or security shortcomings should be handled as a version release of a particular baseline.
Nebrání-li tomu bezpečnostní důsledky, musí být takové nové verze téže základní vývojové úrovně zpětně kompatibilní.
Unless prevented by security implications such version releases within the same baseline are to be backward compatible.
Rozšíření funkcí v dalších základních vývojových úrovních má nutně za následek, že jednotlivé základní vývojové úrovně nejsou zpětně kompatibilní.
The added functionality that might be embodied in different baselines necessarily implies that different baselines are not backward compatible.
Aby se však co možná nejvíce usnadnil přechod mezi jednotlivými základními vývojovými úrovněmi a jeho technické řešení, měly by jednotlivé základní vývojové úrovně obsahovat společné jádro funkcí, u nichž by měla být zpětná kompatibilita zaručena.
However, in order to facilitate migration and in the extent possible from a technical view point, different baselines should encompass a common core of functionality for which backward compatibility should be ensured.
Toto společné jádro by mělo představovat minimální základ umožňující interoperabilní datové služby s přijatelným výkonem.
Such a common core should provide a minimum kernel to enable interoperable data services under acceptable performance.
Provozovatelé infrastruktury a železniční podniky nikdy nebudou schopni přejít z jedné základní vývojové úrovně na jinou přes noc.
Infrastructure managers and railway operators will never be in a position to switch from one baseline to the next over night.
Každá základní vývojová úroveň proto musí být vyvíjena ruku v ruce s vhodnou strategií přechodu na ni.
Henceforth, each baseline has to developed hand-in-hand with an appropriate migration strategy.
Tato strategie musí řešit takové problémy, jako je současná existence TAF zařízení kompatibilních s různými verzemi specifikací TAF, upřednostňované pořadí přechodu (např. napřed traťová zařízení, napřed kolejová vozidla nebo současně) a též přibližné časové horizonty a priority pro přechod.
This is to address problems such as co-existence of TAF facilities compliant with different versions of the TAF specifications, preferred paths of migration (namely trackside priority, rolling-stock priority or simultaneous) as well as the indicative timeframes and the priorities for the migration.
Jak již bylo řečeno, změna je pro velké softwarové systémy osudem.
As mentioned earlier, change is a fact of life for large software based systems.
Proto by měly být postupy řízení změn navrženy tak, aby zajistily, že budou náležitě zanalyzovány náklady a přínosy změny a že změny budou zavedeny kontrolovaným způsobem.
Henceforth, change management procedures should be designed to ensure that the costs and benefits of change are properly analysed and that changes are implemented in a controlled way.
To vyžaduje přesně vymezený proces řízení změn a související nástroje, které zajistí, aby změny byly efektivně evidovány a náležitě zohledňovaly specifikace.
This requires the defined change management process and associated tools to ensure that changes are recorded and applied to the specifications in a cost-effective manner.
Bez ohledu na konečné konkrétní detaily by měl být proces řízení změn zhruba založen na tomto přístupu:
Whatever the specific details of such a process might eventually be, the latter should be broadly mapped on a structured approach as follows:
Formalizace ŽZ
Formalisation of CR
Analýza ŽZ
Analysis of CR
Schválení ŽZ
Approval of CR
ŽZ platná
CR valid
ŽZ zamítnuta
CR rejected y
Strategie zavedení
Implementation Strategy
Sledovatelnost změn
Traceability of Changes
Náklady změn
Cost of Changes
Zanesení ŽZ do DB
File CR in DB
Kvalitativní schválení
Quality Approval
ŽZ – Žádost o změnu
CR – Change Request
CCB – Výbor pro kontrolu změny
CCB – Change Control Board
Celý proces řízení změn popsaný výše by se měl opírat o plán řízení konfigurace obsahující soubor standardů a postupů pro řízení změn.
A configuration management plan embodying the set of standards and procedures for change management should underpin the whole of the change management process as described above.
Obecné požadavky na takový plán jsou popsány v odstavci 7.3.6 níže.
The generic requirements for such a plan are described in paragraph 7.3.6.
Strategie zavedení schválených změn by měla být formálně rozpracována (na základě náležitého postupu a dokumentace) do podoby plánu řízení změn, který zahrnuje zejména:
The implementation strategy for the approved changes should be formalised (on the basis of due process and due documentation) into a change management plan that includes notably:
identifikaci technických překážek, o něž se změna opírá,
the identification of the technical constraints underpinning the change,
určení odpovědnosti za postupy související se zavedením změny,
a statement of who takes responsibility for the change implementation procedures,
postup pro potvrzení změn, které mají být zavedeny,
the validation procedure for the changes to be implemented,
politiku řízení, zveřejnění, přechodu a zavádění změn.
the policy for change management, release, migration and roll-out.
Jednou z důležitých součástí procesu řízení změn je určení odpovědnosti za stanovení specifikací a za zabezpečení jakosti změn a řízení konfigurace.
An important part of the change management process is the definition of the responsibilities for the delivery of the specifications and for both its quality assurance and configuration management.
Počítá se s tím, že většina těchto úkolů bude svěřena Evropské železniční agentuře (zřízené nařízením ES č. 881/2004), až agentura zahájí provoz, nebo pod dohled této agentury.
It is planned that most of these tasks will revert to or will be supervised by the European Railway Agency (established by Regulation (EC) No 881/2004) when this will begin operation.
Proces řízení změn by měl být formálně popsán v dokumentech stanovených v příloze A.
The change management process should be formalised within the set of documentation referred to in Annex A.
Nakonec je nezbytné zajistit, aby výbor pro kontrolu změny (Change Control Board, CCB), který by měl působit jako komplexní systémový orgán, byl složen z reprezentativního průřezu všemi zainteresovanými stranami – tj. provozovateli infrastruktury, železničními podniky, stranou nabídky, oznámenými subjekty i regulačními orgány.
Finally, it is essential that the Change Control Board (CCB), which eventually will act as overall system authority, is composed of a representative cross-section of the all interested parties — namely infrastructure managers, railway undertakings, supply industry, notified bodies and regulatory authorities alike.
Toto spojení různých stran by mělo zajistit dostatečně široký pohled na připravované změny a komplexní posuzování jejich dopadů.
Such affiliation of the parties should ensure a system perspective on the changes that are to be made and a global assessment of their implications.
Funkce CCB bude posléze svěřena pod záštitu Evropské železniční agentury.
The CCB ultimately will be put under the aegis of the European Railway Agency.
Plán řízení konfigurace by měl popisovat soubor standardů a postupů pro řízení změn a měl by obsahovat zejména:
The configuration management plan should describe the set of standards and procedures for change management encompassing notably:
definici subjektů, které je třeba řídit, a formální plán pro identifikaci těchto subjektů,
the definition of what entities are to be managed and a formal scheme for identifying these entities,
určení odpovědnosti za postupy spojené s řízením konfigurace a za podřízení kontrolovaných subjektů rozhodovací struktuře pro oblast řízení konfigurace,
a statement of who takes responsibility for the configuration management procedures and for submitting controlled entities to the configuration management decision structure,
politiku řízení konfigurace, kterou je třeba použít pro udržení kontroly nad změnou a pro správu verzí,
the configuration management policies that are to be used for change control and version management,
popis záznamů, které by měly být vedeny o procesu řízení konfigurace,
a description of the records of the configuration management process which should be maintained,
popis nástrojů, které by měly být použity k řízení konfigurace, a postupu, který by měl být při použití těchto nástrojů uplatněn,
a description of the tools to be used for configuration management and the process to be applied when using these tools,
definici databáze konfigurací, ve které se budou evidovat informace o konfiguraci.
a definition of the configuration database which will be used to record configuration information.
Konkrétní podrobnosti o postupech řízení konfigurace musejí být stanoveny prostřednictvím specifikací zahrnutých v seznamu specifikací uvedených v příloze A této TSI.
The specific details of the configuration management processes are to be formalised through specifications to be incorporated in the list of specifications included under Annex A to this TSI.
Následující zvláštní ustanovení jsou povolena v níže uvedených zvláštních případech.
The following special provisions are permitted in the specific cases below.
Tyto zvláštní případy spadají do dvou kategorií: ustanovení se použijí buď trvale (případ „P“), nebo dočasně (případ „T“).
These specific cases belong to two categories: the provisions apply either permanently (case P), or temporarily (case T).
V dočasných případech je doporučeno, že by dotyčné členské státy měly dosáhnout shody s příslušným subsystémem buď do roku 2010 (případ „T1“), což je cíl stanovený v rozhodnutí Evropského parlamentu a Rady č. 1692/96/ES ze dne 23. července 1996 o hlavních směrech Společenství pro rozvoj transevropské dopravní sítě [11], nebo do roku 2020 (případ „T2“).
In temporary cases it is recommended that the Member States concerned should conform with the relevant subsystem either by 2010 (case T1), an objective set out in Decision No 1692/96/EC of the European Parliament and of the Council of 23 July 1996 on Community guidelines for the development of the trans-European transport network [11], or by 2020 (case T2).
Případ „T open“ je definován jako nespecifikované období, které bude stanoveno v některé z dalších verzí této TSI.
‘T open’ is defined as an undetermined period, which will be fixed in a future revision of this TSI.
Zvláštní případ pro členské státy EU, které hraničí s třetími zeměmi
Specific case for EU member states with border to third countries
Na územích členských států EU, které hraničí s třetími zeměmi, nejsou požadavky této TSI závazné pro přepravu, která přijíždí přímo z těchto třetích zemí nebo jede přímo do těchto třetích zemí (případ „T open“).
On the territories of EU Member States having a border with third countries, the requirements of this TSI are not obligatory to transports directly arriving from or going to these third countries (case T open).