natgillin/translations-raw huggingface dataset:
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.
Vaihe 7: Viimeistään ennen vaihetta 8 on rautatieyrityksen tasolla toteutettava vaunujen liikkeitä koskevat toiminnot Ilmoitus vaunun lähtövalmiudesta ja Lähtöilmoitus, Vaunun saapuminen ratapihalle, Vaunun lähtö ratapihalta, Vaunun saapumisilmoitus ja Vaunun toimitusilmoitus/-vahvistus sekä matkan suunnittelutoiminto.
IT supported trip planning at wagon and intermodal unit level is possible.
Tietotekniikan tukema matkan suunnittelu vaunujen ja intermodaalisten lastausyksikköjen tasolla on mahdollista.
The system is prepared to calculate send and receive wagon and intermodal unit related movement messages.
Järjestelmä on valmis laatimaan, lähettämään ja vastaanottamaan vaunujen ja intermodaalisten lastausyksikköjen liikkeitä koskevia viestejä.
First step for the tracking and tracing of wagons and shipments at an international level.
Ensimmäinen vaihe vaunujen ja lähetysten kansainvälisessä seurannassa ja jäljittämisessä.
Step 8: For the next step the Train Running and Train Running Forecast messages should be realised.
Vaihe 8: Seuraavana vaiheena tulisi toteuttaa Juna kulussa- ja Junan kulkuennuste -viestit.
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.
Junan kulkuennuste -viestin yhteydessä voidaan lähettää tieto junan arvioidusta saapumisajasta (TETA- tai ETH-aika), jonka perusteella lasketaan vaunun/lähetyksen ETI-ajat ja ETA-aika.
This step also contains the realisation of the enquiry/response for train running and train forecast.
Tähän vaiheeseen sisältyy myös Juna kulussa- ja Junan kulkuennuste -kyselyjen ja niiden vastausten toteuttaminen.
Train running and train running forecast in real time sent to neighbour IMs and to the RUs.
Juna kulussa- ja Junan kulkuennuste -viestit lähetetään tosiaikaisena seuraaville infrastruktuurin hallinnoille ja rautatieyrityksille.
Enhanced and more reliable planning opportunities supporting efficient path usage.
Reittien käyttö tehostuu paremman ja luotettavamman suunnittelun ansiosta.
Reduces border stops, supports demand oriented path usage.
Vähentää rajoilla tapahtuvia pysähdyksiä ja tukee kysyntälähtöistä reitinkäyttöä.
Location and train estimated time as a basis for wagon/shipment related ETI/ETA calculation available.
Junan sijainti ja arvioitu aika ovat käytettävissä vaunun/lähetyksen ETI- ja ETA-ajan laskemista varten.
Tool to meet customer's wish to be informed if transport problems occur.
Väline, jonka ansiosta on mahdollista ilmoittaa asiakkaalle kuljetuksessa ilmenevistä ongelmista.
Together with the finalising of step 4 support for minimising expenses and costs by demand oriented path usage.
Auttaa yhdessä vaiheen 4 loppuun saattamisen kanssa minimoimaan kustannukset kysyntälähtöisen reitinkäytön ansiosta.
Enhanced and more reliable planning opportunities.
Paremmat ja luotettavammat reitinsuunnittelumahdollisuudet.
Support for speeding up shipment times by reducing border stops.
Auttaa lyhentämään lähetysaikoja vähentämällä rajoilla tapahtuvia pysähdyksiä.
Support for minimising risks during take over of trains.
Auttaa minimoimaan vaunujen luovutukseen liittyvät riskit.
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.
Vaihe 9: Vaihtoraportit (4.2.9 kohta: Vaihtoraportit) ja 4.2.7 kohdan (Lähetyksen ETI/ETA) toiminnallisuus olisi toteutettava samaan aikaan kuin vaihe 8 tai pian sen jälkeen. Tämä on erityisen tärkeää rautatieyritysten kannalta.
This is in particular relevant for RUs.
Osapuolten käytössä olevat toiminnot tämän vaiheen jälkeen
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.
Tieto vaunun sijainnista infrastruktuurin hallinnon alueella ja siitä, mikä rautatieyritys siitä vastaa, vaikka se ei olisikaan missään junassa.
Knowing wagon location and responsible entity in a yard.
Tieto vaunun sijainnista ja siitä ratapihalla vastaavasta osapuolesta.
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-ajan laskeminen TETA-aikojen perusteella, vaunun liikkeitä koskevien tietojen automaattinen päivitys vaunun ja intermodaalisen lastausyksikön käyttöä koskevaan tietokantaan.
International empty wagon management fully realised.
Tyhjien vaunujen kansainvälinen hallinta täysin toteutettu.
International trip planning completed.
Kansainvälinen matkansuunnittelu täysin käytössä.
Shipment tracking and tracing on an international level.
Lähetysten kansainvälinen seuranta ja jäljittäminen.
Speeding up wagon turn around times.
Nopeuttaa vaunujen kiertoaikoja.
Support for international empty wagon management.
Auttaa tyhjien vaunujen kansainvälistä hallintaa.
Support for consignments abroad and booking of services offered.
Auttaa ulkomaanlähetyksissä ja tarjottujen palvelujen varaamisessa.
Support for quality improvement of international transports.
Auttaa parantamaan kansainvälisten kuljetusten laatua.
Support for international trip planning.
Auttaa kansainvälisessä matkansuunnittelussa.
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.
Vaihe 10: Ilmoitukset toimintahäiriöistä -toiminnon toteuttaminen on osa vaihetta 10 samoin kuin junien viivästyksiä, junan tunnistetta ja junan ilmoittautumispisteeseen saapumista koskevien kyselyjen ja vastausten toteuttaminen.
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.
Toimintahäiriöitä koskevien tietojen perusteella voidaan käyttöön ottaa Vaunuun liittyvät poikkeamat -viesti rautatieyritystasolla (4.2.8.6 kohta: ja 4.2.8.7 kohta:). Osapuolten käytössä olevat toiminnot tämän vaiheen jälkeen
Disruption handling and delivery outstanding reports for RUs.
Toimintahäiriöiden käsittely ja vaadittavien raporttien toimittaminen rautatieyrityksille.
Quality improvement of the service.
Palvelun laadun parantuminen.
Exception handling and outstanding enquiries.
Poikkeamien käsittely ja vastaamatta olevat kyselyt.
International shipment tracking and tracing.
Lähetysten kansainvälinen seuranta ja jäljittäminen.
Step 11: After a consolidation phase, the evaluation of the transmitted and stored data for quality improvement could come into operation.
Vaihe 11: Yhtenäistämisvaiheen jälkeen voitaisiin käyttöönottaa lähetettyjen ja tallennettujen tietojen arviointi laadun parantamiseksi. Osapuolten käytössä olevat toiminnot tämän vaiheen jälkeen
Availability of exhaustive statistical database.
Kattavan tilastollisen tietokannan käyttömahdollisuus
Provision of input data for improvement of the transport service quality.
Tietoja kuljetuspalvelun laadun parantamiseksi on saatavana.
Change is a facet inherent to any kind of computer-based systems used in real-world environments.
Muutos kuuluu olennaisena osana kaikkiin tosielämässä käytettäviin tietokoneperustaisiin järjestelmiin.
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).
Mutta muutoksia on hallittava, koska niiden taustalla on palvelun jatkuvuuteen ja alaspäin yhteensopivuuteen liittyviä tavoitteita, joilla pyritään minimoimaan tavaraliikenteen telemaattisiin sovelluksiin liittyvien aiemmin käyttöön otettujen tietoteknisten laitteiden käytön vaatima aika ja kustannukset.
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.
Sen vuoksi on ratkaisevan tärkeää määritellä selkeä strategia, jonka mukaisesti aikaisempien tietoteknisten laitteiden muutosta toteutetaan ja hallitaan vaarantamatta palvelun jatkuvuuden ja yhteentoimivuuden takaamiseen liittyviä perustavoitteita.
the establishment of a configuration management framework defining the standards and procedures for managing system evolution.
Järjestelmän kehityksen hallinnassa tarvittavat standardit ja menettelyt määrittelevän ominaisuuksien hallintajärjestelmän laatiminen.
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,
Tähän voisi sisältyä se, kuinka ehdotettuja järjestelmämuutoksia merkitään muistiin ja käsitellään, se, kuinka nämä muutokset vaikuttavat järjestelmän komponentteihin, sekä se, kuinka järjestelmäversioita seurataan.
a policy for release of system baselines.
Järjestelmän perusversioiden julkaisemisen suuntaviivat.
the infrastructure managers and the railway operators that will have to handle various versions of systems providing TAF functionality,
infrastruktuurin hallintoja ja rautatieyrityksiä, joiden on käsiteltävä erilaisia tavaraliikenteen telemaattisiin sovelluksiin liittyviä toimintoja tarjoavia järjestelmiä,
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].
Perusversioon kuuluu toiminnaltaan ja muilta ominaisuuksiltaan (esim. RAM) [9] vakaa ydin.
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.
Aiempi kokemus tällaisista järjestelmistä on kuitenkin osoittanut, että vakaan ja toteuttamiskelpoisen perusversion saavuttamiseen tarvitaan useita versiojulkaisuja [10].
= a baseline
= perusversio
Through its feedback loops, such a process is highly intertwined.
Palautesilmukoidensa ansiosta tällainen prosessi on erittäin kiinteä.
This precludes putting several of those processes in parallel, an approach that would lead to unstable, confusing and operationally hampering situations.
Tämä estää useamman tällaisen prosessin samanaikaisen käytön, koska siitä olisi seurauksena epävakaita, ristiriitaisia ja toimintaa haittaavia tilanteita.
Baselines have then to be processed in a series rather than in a parallel manner as illustrated below:
Perusversioita on siten käsiteltävä peräkkäin eikä rinnan, kuten seuraavassa kuvassa esitetään:
Version Releases
Versiojulkaisuja
Baseline 1
Perusversio 1
Baseline 2
Perusversio 2
4 years between baselines
Perusversioiden välillä 4 vuotta
Based on current experience the timing between different baselines can be estimated to be circa four to five years.
Nykyisen kokemuksen mukaan eri perusversioiden ajallisen eron voidaan arvioida olevan noin neljä–viisi vuotta.
A new baseline should in principle be linked with significant modifications of the system functionality or system performance.
Uuden perusversion tulisi periaatteessa liittyä merkittäviin järjestelmän toimintaa tai suorituskykyä koskeviin muutoksiin.
the incorporation of set of today's national functions, where these can be generalized, within the interoperable kernel,
nykyisten kansallisten toimintojen sisällyttäminen, jos ne voidaan yleistää yhteentoimivan ytimen puitteissa,
other future value-added services.
muut tulevaisuuden lisäarvopalvelut.
Each baseline should also embrace the functionality of the previous baseline.
Jokaisen uuden perusversion tulisi myös sisältää edellisen perusversion toiminnallisuus.
Debugging versions to repair system faults or security shortcomings should be handled as a version release of a particular baseline.
Järjestelmän vikojen tai tietoturvapuutteiden korjaamiseksi tehtyjä version virheiden etsimisen ja poiston tuloksia tulisi käsitellä tietyn perusversion versiojulkaisuina.
Unless prevented by security implications such version releases within the same baseline are to be backward compatible.
Elleivät tietoturvanäkökohdat sitä estä, näiden saman perusversion versiojulkaisujen tulisi myös olla alaspäin yhteensopivia.
The added functionality that might be embodied in different baselines necessarily implies that different baselines are not backward compatible.
Eri perusversioihin mahdollisesti sisällytettävät lisätoiminnot johtavat väkisin siihen, etteivät eri perusversiot ole alaspäin yhteensopivia.
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.
Siirtymisen mahdollistamiseksi, ja siinä mitassa kuin se teknisesti on mahdollista, erilaisten versioiden pitäisi sisältää yhteinen toimintoydin, jota varten alaspäin yhteensopivuus tulisi varmistaa.
Such a common core should provide a minimum kernel to enable interoperable data services under acceptable performance.
Tällaisen yhteisen ytimen tulisi tarjota vähimmäisalusta, joka mahdollistaa hyväksyttävästi toimivat yhteentoimivat datapalvelut.
Infrastructure managers and railway operators will never be in a position to switch from one baseline to the next over night.
Infrastruktuurin hallinnot ja rautatieyritykset eivät koskaan kykene siirtymään perusversiosta toiseen yhdessä vuorokaudessa.
Henceforth, each baseline has to developed hand-in-hand with an appropriate migration strategy.
Tämän vuoksi jokainen perusversio on suunniteltava yhdessä asianmukaisen siirtymästrategian kanssa.
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.
Tällä on tarkoitus hoitaa erilaisia ongelmia, joita ovat tavaraliikenteen telemaattisten sovellusten eritelmien eri versioiden mukaisten toimintojen esiintyminen rinnakkain, suositeltavat siirtymätavat (kuten radanvarsiprioriteetti tai liikkuvan kaluston prioriteetti tai molemmat) sekä siirtymisen alustavat aikataulut ja prioriteetit.
As mentioned earlier, change is a fact of life for large software based systems.
Kuten edellä todetaan, muutosten esiintyminen suurissa ohjelmistoperustaisissa järjestelmissä on tosiasia.
Whatever the specific details of such a process might eventually be, the latter should be broadly mapped on a structured approach as follows:
Olipa tällainen prosessi yksityiskohdiltaan millainen tahansa, viimeksi mainittu vaatimus voidaan yleisesti esittää seuraavanlaisena kaaviona:
Formalisation of CR
Virallinen muutospyyntö
Analysis of CR
Muutospyynnön analvvsi
Changes to Specifications
Eritelmä-muutokset
File CR in DB
CR tellennetaan tietokantaan
New Version of Specifications
Uusi eritelmä-versio
CR – Change Request
CR = muutospyyntö
CCB – Change Control Board
CCB = muutoksenhallintalautakunta
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.
Koko yllä kuvatun muutoksenhallintaprosessin perustaksi tarvitaan muutoksenhallinnan standardit ja menettelyt sisältävä järjestelmän ominaisuuksien hallintasuunnitelma.
The generic requirements for such a plan are described in paragraph 7.3.6.
Tällaisen suunnitelman yleiset vaatimukset esitetään jäljempänä kohdassa 7.3.6.
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:
Hyväksyttyjen muutosten toteutusstrategia tulisi virallistaa (asianmukaisten prosessien ja asianmukaisen dokumentaation perusteella) muutoksenhallintasuunnitelmaksi, joka sisältää erityisesti seuraavat osat:
the identification of the technical constraints underpinning the change,
muutoksen perustana olevien teknisten rajoitusten tunnistaminen,
a statement of who takes responsibility for the change implementation procedures,
maininta siitä, kuka vastaa muutoksen toteuttamismenettelyistä,
the validation procedure for the changes to be implemented,
toteutettavien muutosten validointimenettely,
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.
Eritelmien toimittamisesta sekä laadunvarmistuksesta ja järjestelmän ominaisuuksien hallinnasta vastaavien tahojen määritteleminen on tärkeä osa muutoksenhallintaprosessia.
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.
Suunnitelmissa on, että useimmat näistä tehtävistä hoitaa tai niitä valvoo Euroopan rautatievirasto (joka on perustettu EY-asetuksella (EY) N:o 881/2004), kun se aloittaa toimintansa.
The change management process should be formalised within the set of documentation referred to in Annex A.
Muutoksenhallintaprosessi tulisi virallistaa liitteessä A mainittujen asiakirjojen osalta.
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.
Lopuksi on tärkeää, että muutoksenhallintalautakunnassa (CCB), joka lopulta toimii koko järjestelmästä vastaavana tahona, on riittävästi edustettuna kaikki sidosryhmät eli infrastruktuurin hallinnot, rautatieyritykset, toimittava teollisuus, ilmoitetut laitokset ja sääntelyviranomaiset.
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.
Tällaisella eri osapuolten välisellä kytköksellä tulisi voida varmistaa järjestelmällinen näkökulma tehtäviin muutoksiin ja kattava arvio niiden vaikutuksista.
The CCB ultimately will be put under the aegis of the European Railway Agency.
Muutoksenhallintalautakunta asetetaan aikanaan Euroopan rautatieviraston suojelukseen.
The configuration management plan should describe the set of standards and procedures for change management encompassing notably:
Järjestelmän ominaisuuksien hallintasuunnitelmassa olisi kuvailtava muutoksenhallinnan standardit ja menettelyt ja siihen olisi sisällyttävä erityisesti
the definition of what entities are to be managed and a formal scheme for identifying these entities,
sen määrittely, mitä kokonaisuuksia on tarkoitus hallita, ja muodollinen menettely näiden kokonaisuuksien tunnistamiseksi,
a statement of who takes responsibility for the configuration management procedures and for submitting controlled entities to the configuration management decision structure,
maininta siitä, kuka vastaa järjestelmän ominaisuuksien hallintamenettelyistä ja hallittujen kokonaisuuksien sisällyttämisestä ominaisuuksien hallinnan päätöksentekojärjestelmään,
the configuration management policies that are to be used for change control and version management,
järjestelmän ominaisuuksien hallinnan toimintaperiaatteet, joita on tarkoitus käyttää muutoksen hallinnassa ja versionhallinnassa,
a description of the records of the configuration management process which should be maintained,
kuvaus säilytettävistä ominaisuuksien hallintaprosessin tallenteista,
a description of the tools to be used for configuration management and the process to be applied when using these tools,
järjestelmän ominaisuuksien hallinnassa käytettävien välineiden ja niiden käytössä sovellettavan prosessin kuvaus,
a definition of the configuration database which will be used to record configuration information.
ominaisuuksien hallintaa koskevien tietojen tallentamiseen käytettävän konfiguraatiotietokannan määritelmä.
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.
Järjestelmän ominaisuuksien hallintaprosessien tarkat tiedot on virallistettava tämän YTE:n liitteessä A oleviin eritelmäluetteloihin sisältyvissä eritelmissä.
The following special provisions are permitted in the specific cases below.
Seuraavat erityissäännökset koskevat jäljempänä esitettyjä erityistapauksia.
These specific cases belong to two categories: the provisions apply either permanently (case P), or temporarily (case T).
Erityistapaukset jakaantuvat kahteen ryhmään: tapauksiin, joihin säännöksiä sovelletaan pysyvästi (tapaus ”P”) ja tapauksiin, joihin säännöksiä sovelletaan tilapäisesti (tapaus ”T”).
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).
Tilapäisesti voimassa olevien määräysten osalta on suositeltavaa, että asianomaiset jäsenvaltiot saattaisivat kyseisen osajärjestelmän vaatimusten mukaiseksi joko vuoteen 2010 mennessä (tapaus ”T1”) yhteisön suuntaviivoista Euroopan laajuisen liikenneverkon kehittämiseksi 23 päivänä heinäkuuta 1996 tehdyn Euroopan parlamentin ja neuvoston päätöksen N:o 1692/96/EY [11] mukaisesti tai vuoteen 2020 mennessä (tapaus ”T2”).
‘T open’ is defined as an undetermined period, which will be fixed in a future revision of this TSI.
”T open” on määritelty määräämättömäksi ajaksi, joka määritetään tätä YTE:ä tulevaisuudessa tarkistettaessa.
Specific case for EU member states with border to third countries
Erityistapaus, joka koskee niitä EU:n jäsenvaltioita, joilla on yhteinen raja kolmansien maiden kanssa
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).
Niiden EU:n jäsenvaltioiden alueella, joilla on yhteinen raja kolmansien maiden kanssa, eivät tämän YTE:n vaatimukset ole pakollisia niiden kuljetusten osalta, jotka saapuvat suoraan näistä kolmansista maista tai menevät niihin (tapaus ”T open”).
However if the transport journey will be extended to another EU Member State, then the requirements of this TSI must be applied in full, provided that there is not a bilateral or multilateral agreement between the States concerned or between RUs or IMs acting in the territory of those Member States
Jos kuljetusmatka kuitenkin jatkuu toiseen EU:n jäsenvaltioon, tämän YTE:n vaatimuksia on kokonaisuudessaan sovellettava edellyttäen, ettei kyseisten valtioiden tai näiden jäsenvaltioiden alueella toimivien rautatieyritysten tai infrastruktuurin hallintojen kesken ole kahden- tai monenkeskistä sopimusta.
For a transport journey operated on lines with 1000 mm track gauge, national rules shall apply.
Kansallisia sääntöjä sovelletaan kuljetuksiin, jotka tapahtuvat raideväliltään 1000 mm:n levyisillä radoilla.
Under departure point the start point of the path is understood, which can be the train departure point for the journey or an interchange point.
Lähtöpisteellä tarkoitetaan reitin lähtöpistettä, joka voi olla piste, josta junan matka alkaa, tai vaihtopiste.
The handover point is the end point of the path.
Luovutuspiste on reitin päätepiste.
This means, that the access to this information must be independent from which IM has stored the information or part of it.
Tämä tarkoittaa sitä, että tietojen on oltava käytettävissä riippumatta siitä, mikä infrastruktuurin hallinto on ne kokonaan tai osittain tallentanut.