natgillin/translations-raw huggingface dataset:
The example shows only the logical inter-system communication dependencies structured in stepwise manner without accounting for any individual migration needs that might be required by the individual systems.
Näites esitatakse üksnes süsteemidevahelised loogilised andmeseosed etappide kaupa struktureerituna, võtmata arvesse konkreetsete süsteemide konkreetseid üleminekuvajadusi.
These latter needs should be duly considered when drawing up the SEDP.
Viimati nimetatud vajadusi tuleb silmas pidada SEDP koostamisel. 1. etapp.
Step 1: The general architecture, as described in Chapter 4.2.14.1 (General architecture), embodies the concept of a ‘central repository’ operated by a neutral and independent entity.
Punktis 4.2.14.1 (Võrgud ja side) kirjeldatud üldine arhitektuur sisaldab erapooletu ja sõltumatu üksuse hallatava “keskhoidla” ideed.
At the site of each participant in the communication network, an interface layer, which may include a message broker, is specified for interoperability, which can be built centrally or individually.
Iga sidevõrgus osaleja juures on koostalitluseks ette nähtud üks liidesekiht, mis võib sisaldada teatevahetussüsteemi ning mille võib välja töötada tsentraliseeritult või iseseisvalt.
These parts are in respect of ‘networking and communication’, the only operational aspects required for interoperability.
Need osad on seotud “võrkude ja sidega”, mis on ainsad koostalitlusvõime seisukohalt vajalikud toimimisaspektid.
They are also the basic preconditions for the European-wide data exchange.
Need on ka üleeuroopalise andmevahetuse peamisteks eeltingimusteks.
Therefore they must be realised and installed before any other function can come into operation.
Seepärast tuleb need realiseerida ja paigaldada, enne kui saab kasutusele võtta muid funktsioone.
After this step already the electronic transmission of documents (Chapter 4.2.13:) may be realised independent from the logical sequence of the other steps.
Pärast seda etappi saab juba rakendada dokumentide elektroonilist edastamist (punkt 4.2.13: Dokumentide elektrooniline edastamine), olenemata teiste etappide loogilisest järjestusest.
Available features after this step for
Käesoleva etapi käigus loodud võimalused
The basis for the information exchange is given.
Loodud on teabevahetuse alused.
Advantage:
Kasu:
Electronic transmission of documents in the final environment is possible.
Võimalik edastada elektrooniliselt dokumente lõplikus keskkonnas.
Tests of the various further steps can be made in real environment.
Võimalik katsetada mitmesuguseid edasisi etappe reaalses keskkonnas. 2. etapp.
Step 2: At the same time or shortly after step 1, the Rolling Stock Reference Databases and the Wagon and Intermodal Unit Operational Database (Chapter 4.2.11.3: The Rolling Stock Reference Databases and Chapter 4.2.12.2: Other databases) must be available.
Samaaegselt 1. etapiga või vahetult pärast seda peavad olema kättesaadavad veeremi viiteandmebaasid ning vagunite ja ühendveoüksuste kasutamise andmebaas (punkt 4.2.11.3: Veeremi viiteandmebaasid ja punkt 4.2.12.2: Muud andmebaasid).
If not all data are already in the databases, it must be at least possible to put manually into the Wagon and Intermodal Unit Operational Database — for each wagon in a running train — the data needed for rail transport as listed in Annex A, Index 2).
Kui andmebaasid ei sisalda veel kõiki andmeid, peab vähemalt olema võimalik vagunite ja ühendveoüksuste kasutamise andmebaasi käsitsi sisestada A lisa jaotises 2 loetletud raudteeveoks vajalikud andmed sõitva rongi iga vaguni kohta.
The basic information in the Wagon and Intermodal Unit Operational Database and the Rolling Stock Reference Databases are accessible.
Kättesaadavad on vagunite ja ühendveoüksuste kasutamise andmebaasi ja veeremi viiteandmebaasides sisalduvad põhiandmed.
A manual update of the relevant data is possible.
Asjaomaseid andmeid on võimalik käsitsi ajakohastada.
The IT support for a path request and for the train composition is given.
Loodud infotehnoloogiline tugi liinitaotlusteks ja rongide koosseisu teatamiseks.
An easy access to the rolling stock data for third parties e.g. fleet managers can be realised.
Kolmandatele isikutele, nt veeremiettevõtjatele saab anda hõlpsa juurdepääsu veeremi andmetele. 3. etapp.
A database for the storage of path/train information is prepared.
Käesoleva etapi käigus loodud võimalused
The data input can start manually.
IE RE
Data of incoming messages can be stored as for the final version.
Võib alustada käsitsi andmesisestust.
The database(s) for the movement data of wagons/intermodal units and for the load (weight, dangerous goods) is prepared, together with the reference files needed.
Olemas sidusühendus IE olemasolevate süsteemidega, võimalik automaatselt andmeid sisestada ja ajakohastada.
For the next steps it is important to mention, that the proposed architecture allows for a smooth coming into operation of the various functions to fulfil the requirement of the subsystem Telematic Applications for Freight.
Loodud andmebaasid vagunite/ühendveoüksuste liikumise andmete ja veose andmete (kaal, ohtlikud kaubad) jaoks ning vajalikud viitefailid.
Based on the central repository (message metadata, directory and certification authority), it is possible to enable the data exchange between two partners individually depending on message type.
Nüüdsest võib üleantud saatekirjade (veojuhised) andmeid ja/või olemasolevaid rongikoosseise käsitsi sisse kanda, või juba ka automaatselt läbi RE-sisese ühenduse olemasolevate süsteemidega, et salvestada saatekirjade ja rongikoosseisude andmed.
Automatic data input into the database for the storage of path/train information.
Abi rongide koostamisel.
Faster reaction by IM on path requests. A higher reliability of the path characteristic data.
Keskhoidla abil (teadete metaandmed, register ja sertifitseerimissüsteem) saab võimaldada andmevahetust kahe konkreetse partneri vahel, olenevalt teate liigist.
Speeds up wagon turn around times.
etapp.
Step 5: The wagon orders data deliver basic information for the composition of a train, therefore these messages should go into operation before step 6.
Liinitaotluse teateid on võimalik rakendada järgmistest etappidest sõltumatult, kuid 6. etapiks on vajalik, et liin oleks juba määratletud liini numbri alusel.
No additional features.
Lisavõimalusi ei ole.
Automatic take over of the consignment note data into the data storage of step 3.
Telemaatikatoega liinide määratlemine koos infrastruktuuri piiranguteadete andmebaasidega. Kasu:
Automatic generation and sending of wagon orders to cooperating RUs.
Kiirem reageerimine liinitaotlustele, nõudlusele orienteeritud parem liinikasutus, liini andmete suurem usaldusväärsus (infrastruktuuri piiranguteatiste andmebaasid), infrastruktuurikasutuse paranemine.
Faster distribution of the wagon orders, shortened handling time at interchange points.
Võimalik parem nõudlusele orienteeritud liinikasutus. IE kiirem reageerimine liinitaotlustele.
Support for applying international purchase/sales contracts.
Liini andmete suurem usaldusväärsus. Kiirem vaguniringlus. 5. etapp.
Step 6: The coming into operation of train preparation messages is the next step, whereby the sending of the train composition message is the most important one and should be realised first.
Veojuhiste andmetest saadakse põhiline teave rongi koosseisu kohta, seepärast tuleb need teated kasutusele võtta enne 6. etappi. Käesoleva etapi käigus loodud võimalused IE RE
Higher reliability of the data.
Veojuhiste kiirem edastamine, lühem käitlusaeg vahetuspunktides.
Clear time stamp of the start time for the use of the path.
Toetus rahvusvaheliste ostu-müügilepingute rakendamiseks. 6. etapp.
Automatic update of the database for the storage of path/train information.
Järgmiseks etapiks on rongi ettevalmistamise teadete kasutuselevõtt, mistõttu olulisim on rongi koosseisu teade ning see tuleks kasutusele võtta esimesena.
Sending train composition mostly automatically generated, high reliability of the data, automatic update into the data storage of step 3.
Liini kasutamise alguse selge ajatempel. Andmete automaatne ajakohastamine andmebaasis, et salvestada liini/rongi andmed.
Clear responsibility at start time for the IM service, reliable start time for the wagons/shipments.
Liinide kasutamise optimeerimine, selge vastutus alates teeleasumise ajast. Saadetavad rongi koosseisu andmed peamiselt automaatselt koostatud, andmed väga usaldusväärsed, 3. etapi andmesalvestuse automaatne ajakohastamine.
Support for minimising expenses and costs by reduced data capture at borders.
Kasu: Selge vastutus alates IE teenuse algusajast, vagunite/saadetiste usaldusväärne väljasõiduaeg.
Support for speeding up shipment times by guaranteed take-over of trains by RU and IM.
Aitab kaasa kulutuste vähenemisele tänu vähemale andmekogumisele piiridel. Veoaegade kiirendamine tänu rongide garanteeritud ülevõtmisele RE ja IE poolt.
Support for minimising risks during takeover of wagons.
Vähenevad riskid vagunite ülevõtmisel.
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.
Step 7: Hiljemalt enne 8. etappi tuleb RE tasandil kasutusele võtta vaguni liikumisega seotud funktsioonid “vaguni vabastamise ja väljasõidu teatis, vaguni saabumine sorteerjaama, vaguni väljumine sorteerjaamast, vaguni saabumisteatis ja vaguni üleandmisteatis/kinnitus” ning veo koosteplaani koostamine.
IT supported trip planning at wagon and intermodal unit level is possible.
Võimalik IT-toega veo koosteplaanimine vagunite ja ühendveoüksuste tasandil.
The system is prepared to calculate send and receive wagon and intermodal unit related movement messages.
Süsteem on valmis arvutama, saatma ja vastu võtma vagunite ja ühendveoüksuste liikumisega seotud teateid.
First step for the tracking and tracing of wagons and shipments at an international level.
Esimene samm vagunite ja saadetiste rahvusvaheliseks jälgimiseks ja jälitamiseks.
Step 8: For the next step the Train Running and Train Running Forecast messages should be realised.
etapp. Järgmises etapis tuleb kasutusele võtta rongi sõidu ja sõiduprognoosi teated.
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.
Rongi sõiduprognoosi teatega saab saata rongi eeldatava saabumise aja (TETA, vajadusel ETH), mis on vaguni/saadetise ETIde ja ETA arvutamise aluseks.
This step also contains the realisation of the enquiry/response for train running and train forecast.
Selles etapis tuleb rakendada ka rongi sõidu ja sõiduprognoosi päringud ja vastused.
Train running and train running forecast in real time sent to neighbour IMs and to the RUs.
Rongi sõiduandmete ja sõiduprognoosi saatmine reaalajas järgmistele IEdele ja REdele.
Enhanced and more reliable planning opportunities supporting efficient path usage.
Paremad ja usaldusväärsemad plaanimisvõimalused, mis toetavad tõhusamat liinikasutust.
Reduces border stops, supports demand oriented path usage.
Vähendab piiripeatusi, edendab nõudlusele orienteeritud liinikasutust.
Location and train estimated time as a basis for wagon/shipment related ETI/ETA calculation available.
Olemas andmed rongi asukoha ja eeldatava saabumise aja kohta, mis on vaguni/saadetise ETI/ETA arvutamise aluseks.
Tool to meet customer's wish to be informed if transport problems occur.
Võimalus teavitada klienti veoprobleemide tekkest.
Together with the finalising of step 4 support for minimising expenses and costs by demand oriented path usage.
Koos 4. etapi lõpuleviimisega abi kulude minimeerimiseks tänu nõudlusele orienteeritud liinikasutusele.
Enhanced and more reliable planning opportunities.
Paremad ja usaldusväärsemad plaanimisvõimalused.
Support for speeding up shipment times by reducing border stops.
Saadetiste liikumine kiireneb tänu piiriületuste vähendamisele.
Support for minimising risks during take over of trains.
Vähenevad riskid vagunite ülevõtmisel. 9. etapp.
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.
Vahetamisteated (punkt 4.2.9: Vahetamisteated) ja punktis 4.2.7 (Saadetise ETI/ETA) funktsioonid tuleks kasutusele võtta samaaegselt 8. etapiga või vahetult pärast seda.
This is in particular relevant for RUs.
See kehtib eelkõige REde kohta.
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.
Andmed RE vastutuse alla kuuluva vaguni asukohast IE infrastruktuuril, isegi kui vagun ei ole rongi koosseisus.
Knowing wagon location and responsible entity in a yard.
Andmed vaguni asukoha ja sorteerjaama vastutava isiku kohta.
ETI and ETA calculation based on TETA values, automatic update of the movement data in the Wagon and Intermodal Unit Operational Database.
ETI ja ETA arvutamine TETA andmete alusel, liikumisandmete automaatne ajakohastamine vagunite ja ühendveoüksuste andmebaasis.
International empty wagon management fully realised.
Rahvusvaheline tühjade vagunite ringluse täielik süsteem.
International trip planning completed.
Rahvusvaheline veo koosteplaanide koostamine.
Shipment tracking and tracing on an international level.
Saadetiste jälgimine ja jälitamine rahvusvahelisel tasandil.
Speeding up wagon turn around times.
Kiirem vaguniringlus. 11. etapp.
Support for international empty wagon management.
Abi rahvusvaheliseks tühjade vagunite ringluseks.
Support for consignments abroad and booking of services offered.
Toetus kaupade saatmisel välismaale ja broneerimisteenuste pakkumisel.
Support for quality improvement of international transports.
Toetus rahvusvaheliste vedude kvaliteedi tõstmiseks.
Support for international trip planning.
Toetus rahvusvaheliseks veo koosteplaanimiseks.
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.
etapp. 10. etapi alla kuulub “teenusehäirete andmete” süsteemi kasutuselevõtmine ning rongi viivitustega seotud päringute/vastuste, rongi identifitseerimistunnuse ja rongi aruandluskoha teadete kasutuselevõtmine.
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.
Andmed häirete kohta on REde tasandil saadetava vaguni erandjuhtumi teate (punkt 4.2.8.6: Teade “Vaguni erandjuhtum”) ja punkt 4.2.8.7: (Teade “Vaguni erandjuhtum”, uue ETI/ETA taotlus) kasutuselevõtmise aluseks.
Disruption handling and delivery outstanding reports for RUs.
Häirete menetlemise ja saadetiste viibimise aruandlus REde tasandil.
Quality improvement of the service.
Teenuse kvaliteedi paranemine.
Exception handling and outstanding enquiries.
Erandjuhtude ja päringute haldamine.
International shipment tracking and tracing.
Rahvusvaheline saadetiste jälgimine ja jälitamine.
Step 11: After a consolidation phase, the evaluation of the transmitted and stored data for quality improvement could come into operation.
Pärast konsolideerimisetappi võib hakata teostama saadetud ja salvestatud andmete hindamist, et parandada kvaliteeti.
Availability of exhaustive statistical database.
Olemas täielik statistiline andmebaas.
Provision of input data for improvement of the transport service quality.
Olemas veoteenuse kvaliteedi parandamiseks vajalikud sisendandmed.
Change is a facet inherent to any kind of computer-based systems used in real-world environments.
Muudatused on iga reaalsetes keskkondades kasutatavate arvutipõhiste süsteemide üks iseloomulikke aspekte.
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.
Muudatuste põhjuseks on uute nõudmiste teke või olemasolevate nõudmiste muutumine seoses töös tekkinud tõrgete või talitlusvõime või muude mittefunktsionaalsete omaduste parandamise vajadusega.
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).
Muudatusi tuleb aga juhtida, kuna seda nõuavad teenuse järjepidevusega seotud kaalutlused ning tagasiulatuva ühilduvuse eesmärgid, pidades silmas minimaalset ajakulu ja üldkulusid seoses TAF-funktsioone juba täitvate olemasolevate infotehnoloogiaseadmete (st olemasolevate IT-vahendite) toimimisega.
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.
Seepärast on oluline määratleda olemasolevate IT-seadmete muudatuste rakendamiseks ja haldamiseks selge strateegia, et vältida häireid raudteevedudes, kahjustamata seejuures põhieesmärke, milleks on teenuse järjepidevuse ja koostalitlusvõime tagamine.
the establishment of a configuration management framework defining the standards and procedures for managing system evolution.
konfiguratsiooni juhtimise raamistiku loomine, millega määratakse kindlaks süsteemi arengu juhtimise standardid ja protseduurid.
a policy for release of system baselines.
süsteemi arendusaluste rakendamise poliitika.
This need for stability is akin to all parties:
Stabiilsus on vajalik kõikidele osalistele:
the infrastructure managers and the railway operators that will have to handle various versions of systems providing TAF functionality,
raudteeinfrastruktuuri-ettevõtjatele ja raudtee-ettevõtjatele, kes peavad kasutama TAF-funktsioone võimaldavate süsteemide eri versioone,
the industry that needs time to specify, develop and prove continued interoperability.
tööstusele, kes vajab aega jätkuva koostalitlusvõime määratlemiseks, arendamiseks ja katsetamiseks.
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].
Arendusalus on sisuliselt stabiilne süsteemituum, millel on vajalik funktsionaalsus, jõudlus ja muud mittefunktsionaalsed omadused (nt RAM).
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.
Varasemad kogemused seda liiki süsteemidega on siiski näidanud, et stabiilse ja rakendamiskõlbliku arendusaluse saamiseks on vaja välja lasta mitu versiooni.
This can be illustrated as a cascade process as follows:
Seda võib kujutada alljärgneva astmelise protsessina:
Interoperability proving
Koostalitlusvõime katsetamine
Set of consolidated Spec
Konsolideeritud =spetsifikaadid
= a baseline
= arendusalus
Through its feedback loops, such a process is highly intertwined.
Tagasisideahelate tõttu on kõnealune protsess ülimalt läbipõimunud.
This precludes putting several of those processes in parallel, an approach that would lead to unstable, confusing and operationally hampering situations.
See välistab mitme protsessi paralleelse teostamise, kuna selline lähenemisviis viiks ebastabiilsete, segadusttekitavate ja tööd takistavate olukordadeni.
Baselines have then to be processed in a series rather than in a parallel manner as illustrated below:
Arendusaluseid ei tohi seega välja töötada paralleelselt, vaid jadana, nagu on kujutatud allpool:
Baseline 1
Arendusalus 1
Baseline 2
Arendusalus 2
4 years between baselines
Arendusaluste vaheline aeg 4 aastat
Based on current experience the timing between different baselines can be estimated to be circa four to five years.
Olemasolevatest kogemustest lähtudes võib erinevate arendusaluste vahele jäävaks ajavahemikuks hinnata ligikaudu neli kuni viis aastat.
A new baseline should in principle be linked with significant modifications of the system functionality or system performance.
Uus arendusalus peaks üldjuhul seonduma oluliste muudatustega süsteemi funktsionaalsuses või jõudluses.
the incorporation of set of today's national functions, where these can be generalized, within the interoperable kernel,
olemasolevate siseriiklike funktsioonide kogumi lisamine koostalitlusvõimelisele tuumale, kui neid funktsioone on võimalik üldistada,
other future value-added services.
muud tulevased lisandväärtust pakkuvad teenused.
Debugging versions to repair system faults or security shortcomings should be handled as a version release of a particular baseline.
Silumisversioone, mille eesmärk on kõrvaldada süsteemi vigu või turvalisuse puudujääke, tuleks käsitada konkreetse arendusaluse versioonidena.
Unless prevented by security implications such version releases within the same baseline are to be backward compatible.
Kui turvanõuetest ei tulene teisiti, peavad sama arendusaluse versioonid ühilduma eelmiste versioonidega.
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.
Kiireima tehniliselt võimaliku ülemineku soodustamiseks peaksid erinevad arendusalused aga sisaldama ühiseid põhifunktsioone, mille osas tuleks tagada tagasiulatuv ühilduvus.
Such a common core should provide a minimum kernel to enable interoperable data services under acceptable performance.
Kõnealune ühine tuum peaks tagama minimaalsed vajalikud koostalitlusvõimelised andmeteenused nõuetekohasel tasemel.
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.
See aitab lahendada probleeme, nagu näiteks mitmetele TAFi spetsifikaatide versioonidele vastavate TAFi vahendite kooskehtivus, ülemineku eelisvaldkonnad (eelistades infrastruktuuri või veeremit või mõlemat) ning ülemineku ajakavad ja prioriteedid.
As mentioned earlier, change is a fact of life for large software based systems.
Nagu varem öeldud, on muudatused suurte tarkvarapõhiste süsteemide puhul möödapääsmatud.
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.
Seepärast peavad muudatuste juhtimise menetlused tagama muudatustega seotud kulude ja tulude nõuetekohase analüüsi ning muudatuste kontrollitud rakendamise.
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.
Selleks on vaja kindlaksmääratud muudatuste juhtimise protsessi ja seonduvaid vahendeid, et tagada muudatuste registreerimine ja säästev kohaldamine spetsifikaatide suhtes.
Whatever the specific details of such a process might eventually be, the latter should be broadly mapped on a structured approach as follows:
Protsessi konkreetsetest üksikasjadest olenemata tuleks see üldiselt kavandada alljärgneva struktuurse süsteemina:
Formalisation of CR
MT vormistamine
Changes to Specifications
Spetsifikaati de muudatused
New Version of Specifications
Spetsifikaati de uus versioon
CR – Change Request
MT – Muudatustaotlus
CCB – Change Control Board
MJN – Muudatuste kontrollinõukogu
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.
Kogu eespool kirjeldatud muudatuste juhtimise protsessi aluseks peaks olema muudatuste juhtimise standardite ja protseduuride kogumit sisaldav konfiguratsiooni juhtimise kava.