natgillin/translations-raw huggingface dataset:
An example is the combination of an ETCS Level 1 using Eurobalise as a spot transmission means and an infill function not based on a unified solution, but on a national system.
Esimerkkinä tästä on tason 1 ETCS-järjestelmän rakentaminen käyttämällä pistekohtaiseen tietojen lähettämiseen eurobaliisia ja toteuttamalla täytetoiminto yhdenmukaistetun ratkaisun sijasta kansalliseen järjestelmään perustuvalla ratkaisulla.
This solution requires an on-board data link between the unified and the pre-unified system.
Tämä ratkaisu edellyttää junassa olevaa datayhteyttä yhdenmukaistetun ja osittain yhdenmukaistetun järjestelmän välillä.
Therefore, the solution is not in accordance with either Class A or Class B and is not interoperable.
Tämän vuoksi ratkaisu ei ole sen paremmin luokan A kuin luokan B:kään vaatimusten mukainen eikä yhteentoimiva.
There is, however, the possibility to use the combination as a national enhancement of an interoperable line.
Edellä mainittua yhdistelmää voidaan kuitenkin käyttää yhteentoimivan radan kansallisen tason lisänä.
This is only permitted if trains not equipped with the data link between both systems can operate either on the unified or on the pre-unified system without information from the other system.
Tämä sallitaan kuitenkin vain, jos junat, joissa ei ole kyseisten järjestelmien välistä datayhteyttä, voivat toimia käyttämällä joko yhdenmukaista tai osittain yhdenmukaista järjestelmää ilman, että käytettävissä olisi toisesta järjestelmästä saatuja tietoja.
If this is not possible, the line cannot be declared interoperable for the control-command subsystem.
Mikäli tämä ei ole mahdollista, rataa ei voi julistaa ohjaus- ja hallintaosajärjestelmän kannalta yhteentoimivaksi.
Specific solution for partial alternative use of ETCS Class A airgap
ETCS:n luokan A ilmavälin osittaista vaihtoehtoista käyttöä koskeva erityisratkaisu
An infrastructure may also be used for the movement of trains not compliant with the requirements of this TSI, according to Article 5(6) of Directive 2001/16/EC, provided this does not create prejudice to the fulfilment of essential requirements.
Direktiivin 2001/16/EY 5 artiklan 6 kohdan mukaan infrastruktuuria voidaan käyttää sellaisten junien liikennöintiin, jotka eivät vastaa tässä YTE:ssä esitettyjä vaatimuksia, edellyttäen, että tämä ei vaaranna olennaisten vaatimusten toteutumista.
Such trains receive information from a Class B signalling infrastructure via Class A track-to-train communication.
Tällaiset junat vastaanottavat tietoja luokan B mukaiselta signalointi-infrastruktuurilta luokan A mukaisen radalta junaan -viestintään tarkoitetun laitteen välityksellä.
Competition criteria
Kilpailukriteerit
Any action to allow the movement of interoperable trains on other infrastructures or the movement of not interoperable trains on interoperable infrastructures shall ensure that free competition between suppliers is not prejudiced.
Kaikissa toimissa, joilla pyritään mahdollistamaan yhteentoimivien junien liikennöinti muissa infrastruktuureissa tai ei-yhteentoimivien junien liikennöinti yhteentoimivissa infrastruktuureissa, on myös varmistettava, ettei niistä aiheudu haittaa tavarantoimittajien väliselle vapaalle kilpailulle.
Specially, knowledge about relevant interfaces between already installed equipment and new equipment to be purchased shall be put at the disposal of all the interested suppliers.
Erityisesti on varmistettava, että asiasta kiinnostuneilla tavarantoimittajilla on mahdollisuus saada tietoja jo käytössä olevien ja uusien, ostettavien laitteistojen välisistä liittymäkohdista.
According to the characteristics of the track-side control-command track-side assembly and its interfaces with other subsystems, some track-side functionality not classified as mandatory, may have necessarily to be implemented in certain applications to comply with the essential requirements.
Radanvarren ohjaus- ja hallintalaitteiden ominaisuuksien ja sen toisiin osajärjestelmiin olevien liitäntöjen ominaisuuksien mukaan joidenkin ei-pakollisiksi luokiteltujen ratalaitetoimintojen käyttöönotto saattaa olla välttämätöntä, jotta kaikki olennaiset vaatimukset täyttyvät.
The track-side implementation of national or optional-functions must not prevent the entry onto that infrastructure for a train that complies only with the mandatory requirements of Onboard Class A system except as required for the following on-board optional functions:
Kansallisten tai valinnaisten radanvarsitoimintojen toteuttaminen ei saa estää sellaisen junan pääsyä kyseiselle infrastruktuurille, joka täyttää ainoastaan veturissa olevien luokan A järjestelmien pakolliset vaatimukset. Tämä ei kuitenkaan koske seuraavia junan valinnaisia toimintoja:
an ETCS Level 3 Track-side application requires train integrity supervision onboard,
ETCS-järjestelmän tason 3 radanvarsisovellus edellyttää, että junassa on junakokonaisuutta valvova laitteisto.
an ETCS Level 1 Track-side application with infill requires corresponding in-fill functionality onboard if the release speed is set to zero for safety reasons (e.g. protection of danger points),
Lisäajotiedolla varustettu ETCS-järjestelmän tason 1 radanvarsisovellus edellyttää, että junassa on vastaavan toiminnon mahdollistava laitteisto, jos hätäjarru voidaan turvallisuussyistä vapauttaa vasta junan ollessa täysin pysähtynyt (esim. radan vaaralliset kohdat).
when ETCS requires data transmission by radio, the data transmission services of GSM-R must fulfil the ETCS data transmission requirements,
ETCS-järjestelmän edellyttäessä datan siirtoa radioitse, GSM-R:n datasiirtopalvelujen on täytettävä ETCS:n datasiirtoa koskevat vaatimukset.
an onboard assembly, which incorporates a KER STM, may require to implement the K-interface.
KER STM:n sisältävissä veturilaitteissa on mahdollisesti toteutettava K-liitäntä.
Management of change
Muutoshallinta
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 tietokoneperusteisiin järjestelmiin.
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.
Muutostarpeita aiheuttavat uudet vaatimukset tai entisten vaatimusten muuttuminen joko käytön aikana havaittujen virheiden tai suorituskyvyn parantamistarpeen tai muiden kuin toiminnallisten parantamistarpeiden seurauksena.
But change has to be managed as it is underpinned by safety-critical considerations and by backward compatibility objectives so as to provoke minimal time and cost overheads to the operation of already deployed ERTMS equipment (i.e. legacy ERTMS facilities).
Muutoksia on silti hallittava, koska niiden taustalla on turvallisuuden kannalta kriittisiä näkökohtia ja alaspäin yhteensopivuuteen liittyviä tavoitteita, joilla pyritään minimoimaan jo käytössä olevien ERTMS-laitteiden(eli aiempia sukupolvia edustavien ERTMS-laitteiden) käyttöön liittyvä ajankäytön ja kustannusten lisääntyminen.
It is therefore crucial to define a clear strategy of how to implement and manage change to legacy ERTMS equipment to avoid disruption to railway operations without undermining the underlying objectives of guaranteeing safety and interoperability.
Sen vuoksi on ratkaisevan tärkeää määritellä selkeä strategia, jonka mukaisesti muutos aiempien sukupolvien ERTMS-laitteista toteutetaan ja hallitaan vaarantamatta palvelun jatkuvuuden ja turvallisuuden ja yhteentoimivuuden takaamiseen liittyviä perustavoitteita.
Two main issues underpin the definition of such a strategy:
Tällaisen strategian määrittely perustuu kahteen tärkeään seikkaan:
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 tulisi sisältyä se, kuinka ehdotettuja järjestelmämuutoksia merkitään muistiin ja käsitellään, sekä se, kuinka nämä muutokset vaikuttavat järjestelmän komponentteihin, ja lisäksi se, kuinka järjestelmäversioita seurataan.
a policy for release of system baselines.
Järjestelmän perusversion julkaisemisen suuntaviivat.
System stability is essential so that actual implementation and deployment can be realistic.
Järjestelmän vakaus on sen toteuttamisen ja käyttöönoton kannalta oleellinen seikka.
This need for stability is akin to all parties:
Tämä vakauden vaatimus koskee yhtäläisesti kaikkia osapuolia:
the infrastructure managers and the railway operators that will have to handle various versions of ERTMS/ETCS or GSM-R,
infrastruktuurin hallintoja ja rautatieyrityksiä, joiden on käsiteltävä erilaisia ERTMS/ETCS- tai GSM-R-versioita,
the industry that needs time to specify, develop and prove continued interoperability.
alan teollisuutta, joka tarvitsee aikaa määritelläkseen, kehittääkseen ja todentaakseen jatkuvan yhteentoimivuuden.
A baseline in essence embodies the concept of a stable kernel in terms of system functionality, performance and other non-functional characteristics (e.g. RAMS).
Versioon kuuluu toiminnaltaan ja muilta ominaisuuksiltaan (esim. RAM) vakaa ydin.
However, past experience with this type of systems has shown that a number of version releases are needed to achieve a stable and implementation-suitable baseline.
Aiempi kokemus tällaisista järjestelmistä on kuitenkin osoittanut, että vakaan ja toteuttamiskelpoisen lähtöpisteen saavuttamiseen tarvitaan useita versiojulkaisuja.
This can be illustrated as a cascade process as follows:
Tätä prosessia voidaan havainnollistaa seuraavasti:
Working revisions
Toiminnallisia muutoksia
Flaw corrections
Puutteiden korjauksia
Interoperability proving
Yhteentoimivuuden toteaminen
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 and 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 for the specific case of ERTMS/ETCS:
Lähtöpisteitä on siten käsiteltävä peräkkäin eikä rinnan, kuten seuraavassa kuvassa on esitetty tietystä ERTMS/ETCS-tapauksesta:
Version Releases
Versiojulkaisut
End 2004/2005
Loppuvuosi 2004/2005
Current consolidation
Nykyiset versiot
4 years between baselines
Lähtöpisteiden välillä 4 vuotta
The first baseline of the ERTMS specifications (both ETCS and GSM-R) was appended to the TSI Command/Control and Signalling for high-speed (reference Decision 2002/731/EC).
ERTMS-eritelmien (sekä ECTS:ää että GSM-R:ää koskevien) ensimmäinen versio oli suurten nopeuksien rautatiejärjestelmän ohjaus- ja hallintaosajärjestelmää koskevan YTE:n liitteenä (viite: päätös 2002/731/EY).
A new version release of these specifications was issued recently (Decision 2004/447/EC).
Näiden eritelmien uusi versio julkaistiin hiljattain (päätös 2004/447/EY).
It included minor functional and system changes whereas laying down the foundation of a structured approach for conformity assessment of the on-board command/control equipment.
Se sisälsi vähäisiä toimintaan ja järjestelmään liittyviä muutoksia ja loi pohjan ohjaus- ja hallintalaitteiden vaatimustenmukaisuuden järjestelmälliselle arvioinnille.
The current on-going consolidation process for ERTMS (both ETCS and GSM-R) is clearly focused on two main issues:
Nyt käynnissä oleva ERTMS:n (koskee sekä ETCS:ää että GSM-R:ää) yhdenmukaistamisprosessi keskittyy selvästi kahteen pääasiaan:
the consolidation of the current baseline in order it becomes a more robust reference for interoperability, and
nykyisen version yhdenmukaistamiseen niin, että siitä tulee entistä parempi viitekehys yhteentoimivuudelle, ja
the closure of a number of still standing operational and technical open points.
useiden yhä avoinna olevien teknisten yksityiskohtien viimeistelyyn.
This work relies on the feedback from current pilots, early commercial applications as well as on structured program of cross-tests with products from different suppliers.
Tässä työssä käytetään hyödyksi nyt käynnissä olevista pilottihankkeista saatavaa palautetta, varhaisia kaupallisia sovelluksia sekä eri toimittajien tuotteiden järjestelmällistä vertailutestiohjelmaa. Sen on tarkoitus johtaa lopulta uuden version julkaisemiseen.
It should eventually lead to the release of a new baseline to be put under configuration management during the first half of 2005.
Versio on tarkoitus saada konfiguraationhallintajärjestelmään vuoden 2005 alkupuoliskolla.
During this phase it may be necessary to make special, mutual agreements between infrastructure managers and railway undertakings for using Class A systems.
Tämän vaiheen aikana saattaa olla tarpeen tehdä infrastruktuurin hallintojen ja rautatieyritysten välisiä erityissopimuksia luokan A järjestelmien käytöstä.
Based on current experience the timing between different baselines can be estimated to be approximately four to five years for ETCS and approximately two years for GSM-R.
Nykyisen kokemuksen mukaan eri versioiden ajallisen eron voidaan arvioida ETCS:n kohdalla olevan noin neljä viisi vuotta ja GSM-R:n kohdalla noin kaksi vuotta.
A new baseline should in principle be linked with significant modifications of the system functionality or system performance.
Uuden lähtöpisteen tulisi periaatteessa liittyä merkittäviin järjestelmän toimintaa tai suorituskykyä koskeviin muutoksiin.
This could include aspects such as:
Näihin voisi sisältyä seuraavia näkökohtia:
the incorporation of a set of today's national functions, where these can be generalised, within the interoperable kernel,
nykyisten kansallisten toimintojen sisällyttäminen, jos ne voidaan yleistää yhteentoimivan ytimen puitteissa,
the set-up of additional interoperability constituents on the ETCS on-board and trackside,
uusien yhteentoimivuuden osatekijöiden määrittely junaan ja radanvarren ETCS-järjestelmille,
GSM-R-based value-added services.
GSM-R:ään perustuvat lisäarvopalvelut.
Each baseline should also embrace the functionality of the previous baseline.
Jokaisen uuden version tulisi myös sisältää edellisen version toiminnallisuus.
Debugging versions to repair system faults or safety 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 lähtöpisteen versiojulkaisuina.
Unless prevented by safety implications such version releases within the same baseline are to be backward compatible.
Elleivät tietoturvanäkökohdat sitä estä, näiden saman lähtöpisteen 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 versioihin mahdollisesti sisällytettävät lisätoiminnot johtavat väkisin siihen, etteivät eri versiot 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 kuitenkin sisältää yhteinen toimintoydin, jota varten alaspäin yhteensopivuus tulisi varmistaa.
Such a common core should provide a minimum kernel to enable interoperable operation under acceptable performance.
Tällaisen yhteisen ytimen tulisi tarjota vähimmäisydin, joka mahdollistaa hyväksyttävän yhteentoimivan käytön.
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 versiosta toiseen yhdessä vuorokaudessa.
Henceforth, each baseline has to developed hand-in-hand with an appropriate migration strategy.
Tämän vuoksi jokainen versio on suunniteltava asianmukaisen siirtymästrategian kanssa yhdessä.
This is to address problems such as co-existence of ETCS and GSM-R facilities compliant with different versions of the ETCS or GSM-R specifications, preferred paths of migration (e.g. trackside priority, rolling-stock priority or simultaneous) as well as the indicative timeframes and the priorities for the migration.
Näin on tarkoitus hoitaa ongelmia, joita ovat erilaisten ETCS- tai GSM-R-eritelmien mukaisten ETCS- ja GSM-R-toimintojen esiintyminen rinnakkain, suositeltavat siirtymätavat (kuten radanvarsiprioriteetti tai liikkuvan kaluston prioriteetti tai molemmat) sekä siirtymisen alustavat aikataulut ja prioriteetit.
As discussed earlier change is a fact of life for large software based systems.
Kuten edellä on mainittu, muutosten esiintyminen suurissa ohjelmistoperusteisissa järjestelmissä on tosiasia.
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.
Tämän vuoksi on suunniteltava muutoksenhallintamenettelyjä sen varmistamiseksi, että muutosten kustannukset ja edut analysoidaan asianmukaisesti ja että muutokset toteutetaan hallitusti.
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.
Tämä edellyttää määriteltyä muutoksenhallintaprosessia ja siihen liittyviä välineitä, joilla varmistetaan, että muutokset kirjataan ja tehdään kustannustehokkaasti.
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:
Approval of CR
CR:n hyväksyntä
Changes to Specifications
Eritelmämuutokset
Traceability of Changes
Muutosten jäljitettävyys
Quality Approval
Laadun hyväksyntä
New Version of Specifications
Uusi eritelmäversio
Formalization of CR
Virallinen muutospyyntö
Analysis of CR
Muutospyynnö analyysi
CR valid
CR kelpaa
Implementation Strategy
Toteutusstrategia
Cost of Changes
Muutosten kustannukset
CR rejected
CR hyeätään
File CR in DB
CR tallennetaan tietokantaan
CR - Change Request
CR = muutospyyntö
CCB - Change Control Board
CCB = muutoksenhaleintalautakunta
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ä konfiguraationhallintasuunnitelma.
The generic requirements for such a plan are described in paragraph 7.3.7 below.
Tällaisen suunnitelman yleiset vaatimukset on esitetty jäljempänä 7.3.7 kohdassa.
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 käyttöönottostrategia tulisi virallistaa (asianmukaisten prosessien ja asianmukaisen dokumentaation perusteella) muutoksenhallintasuunnitelmaksi, johon sisältyvät 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
the policy for change management, release, migration and roll-out.
muutostenhallinnan, versiojulkaisujen, siirtymän ja laajennuksen suuntaviivat.
The configuration management plan should describe the set of standards and procedures for change management encompassing notably:
Konfiguraationhallintasuunnitelman tulisi kuvata muutoksenhallinnan standardit ja menettelyt, ja siihen pitäisi sisältyä erityisesti seuraavia asioita:
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ä, kenellä on vastuu konfiguraationhallintamenettelyistä ja hallittujen kokonaisuuksien sisällyttämisestä konfiguraationhallinnan päätöksentekojärjestelmään,
the configuration management policies that are to be used for change control and version management,
konfiguraationhallinnan suuntaviivat, 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ä konfiguraationhallintaprosessin tallenteista,
a description of the tools to be used for configuration management and the process to be applied when using these tools,
konfiguraationhallinnassa 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.
konfiguraatiotietojen tallentamiseen käytettävän konfiguraatiotietokannan määritelmä.
The specific details of the configuration management processes for ETCS and GSM-R are to be formalised through specifications to be incorporated in the list included under Annex A to this TSI, respectively, under Index 60 (for ETCS) and Index 61 (for GSM-R).
ETCS:ää ja GSM-R:ää koskevien konfiguraationhallintaprosessien tarkat tiedot on tarkoitus virallistaa tämän YTE:n liitteessä A oleviin luetteloihin sisällytettävissä eritelmissä, 60 kohdassa (ETCS:n osalta) ja 61 kohdassa (GSM-R:n osalta).
The management of change of the ERTMS/ETCS and GSM-R specifications is to be placed under the aegis of the European Railway Agency (ERA) established by Regulation (EC) No 881/2004.
ERTMS/ETCS- ja GSM-R-eritelmien muutoshallinta on tarkoitus antaa Euroopan rautatieviraston ERA:n (joka on perustettu asetuksella (EY) N:o 881/2004) hoidettavaksi.
The ERA will be responsible for mastering the change management process, including the delivery of the specifications, its quality assurance and configuration management.
Virasto vastaa muutoshallintaprosessin johtamisesta, ja siihen kuuluu myös eritelmien toimittaminen, laadunvarmistus ja konfiguraationhallinta.
This way the ERA will play the centre role of system authority centralising and ensuring the overall coherence of a process that is nowadays fragmented through a number of different parties as evidenced in the table below:
Näin Euroopan rautatievirastolla on keskeinen asema järjestelmäviranomaisena, joka varmistaa prosessin yleisen yhdenmukaisuuden ja keskittämisen. Nykyisin tämä prosessi on hajautettu eri osapuolten hoitoon, kuten seuraavasta taulukosta ilmenee:
Responsibility
Vastuualue
Delivery of specifications
Eritelmien toimittaminen
ERTMS users’ group, UIC and UNISIG
ERTMS-käyttäjien ryhmä, UIC ja UNISIG
EIRENE group, ERIG and GSM-R industry group
EIRENE-ryhmä, teollisuuden ERIG- ja GSM-R-ryhmä
ERTMS users’ group
ERTMS-käyttäjien ryhmä
EIRENE group, ERIG and ERTMS users’ group
EIRENE-ryhmä, ERIG- ja ERTMS-käyttäjien ryhmä
Configuration management
Konfiguraationhallinta