natgillin/translations-raw huggingface dataset:
På grundlag af veldefinerede adgangsrettigheder baseret på fortrinsret skal databasernes indhold være tilgængeligt for alle serviceleverandører (infrastrukturforvaltere, jernbanevirksomheder, logistikleverandører og flådeforvaltere) navnlig med henblik på flådeforvaltning og vedligeholdelse af rullende materiel.
Contents of the databases must be accessible, based on structured access rights depending on privilege to all service providers (IMs, RUs, logistic providers and fleet managers) in particular for purposes of fleet management and rolling stock maintenance.
Posterne i referencedatabasen over rullende materiel kan grupperes som følger:
The entries in the Rolling Stock Reference Database can be grouped as follows:
Administrative data
Administrative data,
Disse vedrører certificering og registrering og kan f.eks. være referencer til relevante registreringsfiler, id for bemyndigede organer osv. De kan omfatte historiske data vedrørende ejerskab, lejemål osv.
related to certification and registration items such as reference to the EC registration file, ID of the notified body, etc.; this may include historical data related to ownership, rental, etc. The following steps have to be taken into account:
Der skal tages hensyn til følgende:
EC certification,
EF-certificering registrering i »hjemstaten«
registration in the ‘home’ State,
dato for idriftsættelse i registreringsstaten
date put into service in the State of registration,
registrering i andre lande med henblik på anvendelse på disses netværk
registration in other countries for the use on their national network,
sikkerhedscertificering af alt rullende materiel, som ikke overholder TSI'en for rullende materiel.
safety certification for all rolling stock which does not comply with the Rolling Stock TSI.
Det er leverandørens ansvar at sikre, at disse data er tilgængelige, og at de bagvedliggende processer er gennemført.
The keeper is obliged to ensure that these data are available and the processes behind have been conducted.
Konstruktionsmæssige data
Design data,
Disse omfatter alle det rullende materiels (fysiske) bestanddele, herunder miljømæssige egenskaber, og alle oplysninger, som ventes at være gyldige i hele materiellets levetid. Denne del kan omfatte en historik over større ændringer, vedligeholdelse, hovedreparation osv.
which shall include all constitutive (physical) elements of the rolling stock, including characteristics related to the environment, and all information that is expected to remain valid throughout the life of the rolling stock — this part may contain a history of major modifications, major maintenance, overhaul, etc.
Operationelle data om rullende materiel
The Rolling Stock Operational Data
Bortset fra referencedataene om det rullende materiel er de data, der viser materiellets aktuelle status, de vigtigste i forhold til driften.
Beside the reference data for rolling stock, the data representing the actual status of the rolling stock is the most important data for operational purposes.
Disse data skal omfatte midlertidige data om bl.a. begrænsninger, igangværende og planlagt vedligeholdelse, kilometer- og fejltællere osv. samt alle data, der kan anses for at være »statusdata« (midlertidige hastighedsbegrænsninger, behov for reparationer og fejlbeskrivelser osv.).
This data shall include temporary data, such as restrictions, current and projected maintenance actions, kilometers and fault counters, etc.; and all data that could be considered as ‘status’ (temporary speed restrictions, brake isolated, needs for repair and fault description, etc.,).
Ved anvendelse af de operationelle data om rullende materiel skal tre forskellige enheder tages i betragtning under hensyntagen til de forskellige parter med ansvar for rullende materiel under transport:
For use of the operational rolling stock data, three different entities must be considered taking into account the different parties responsible for rolling stock during transport operation:
jernbanevirksomheden, der fungerer som opgaveansvarlig under dens transportkontrol
Railway Undertaking as Duty holder during its transport control,
leverandøren af det rullende materiel og
Keeper of rolling stock, and
brugeren (lejeren) af materiellet.
User (Hirer) of rolling stock.
Hos alle tre parter skal de operationelle data om rullende materiel være tilgængelige for bemyndigede brugere, som skal anvende den nøgle, som ligger i vogn-id'et (vognnummeret).
For all three different parties the operational rolling stock data must be accessible by the authorised user, down to his predefined authorised level, using the single key given by the wagon ID (wagon number).
De operationelle data om rullende materiel indgår i den fælleseuropæiske operationelle database over vogne og intermodale enheder, som beskrives i kapitel 4.2.12.2 Andre databaser.
The operational rolling stock data is a part of the European-wide Wagon and Intermodal Unit Operational Database as described in Chapter 4.2.12.2 Other databases .
I forbindelse med driften af godstog i det europæiske netværk skal følgende referencefiler være tilgængelige for alle serviceleverandører (infrastrukturforvaltere, jernbanevirksomheder, logistikleverandører og flådeforvaltere).
For the operation of freight trains on the European network the following reference files must be available and accessible to all service providers (IMs, RUs, logistic providers and fleet managers).
Dataene skal til enhver tid afspejle den aktuelle status.
The data must represent the actual status at all times.
Følgende opbevares og administreres lokalt:
Locally stored and administrated:
Referencefil for nødtjenester med henvisning til typen af farligt gods.
reference file of the emergency services, correlated to type of hazardous goods.
Følgende opbevares og administreres centralt:
Centrally stored and administrated:
Referencefil for kodning af alle infrastrukturforvaltere, jernbanevirksomheder og serviceleverandører
reference file of the coding for all IMs, RUs, service provider companies,
Referencefil for kodning af transportkunder
reference file of the coding for transport customers,
Referencefil for kodning af lokaliteter (primær, sekundær og zone-spor-sted)
reference file of the coding of locations (primary, subsidiary and zone-track-spot),
Referencefil for kodning af kundelokaliteter
reference file of the coding for customer locations,
Referencefil for alle eksisterende togkontrolsystemer
reference file of all existing train control systems,
Referencefil for farligt gods, UN- og RID-numre
reference file of hazardous goods, UN and RID numbers,
Referencefil for alle lokomotivtyper
reference file of all different locomotive types,
Referencefil for alle CN- og HS-koder for gods
reference file of all CN and HS codes for goods,
Referencefil for alle europæiske vedligeholdelsesværksteder
reference file of all European maintenance workshops,
Referencefil for alle europæiske revisionsmyndigheder
reference file of all European audit bodies,
Referencefil for alle godkendte europæiske operatører, herunder liste med de nationale sikkerhedscertifikater, der er udstedt.
reference file of all European licensed operators including respective list of national safety certificates granted.
Kodningen af infrastrukturforvaltere, jernbanevirksomheder, transportorganisationer og -selskaber samt transportkunder og af lokaliteter (primære, sekundære osv.), herunder kundelokaliteter, ligger endnu ikke fast.
The coding of IMs, RUs, transport organisations and companies and transport customers as well as of locations (primary, subsidiary, etc.) including customer locations are pending.
For at gøre det muligt at spore togs og vognes bevægelser skal der installeres følgende databaser, som skal ajourføres i realtid ved relevante hændelser.
To allow for the tracking of train and wagon movements, the following databases, updated at each relevant event in real time, must be installed.
De bemyndigede enheder såsom leverandører og flådeforvaltere skal have adgang til de data, der har betydning for, at de kan udføre deres funktioner i overensstemmelse med de kontraktlige forpligtelser.
Authorised entities such as keepers and fleet managers must have access to the data relevant to fulfil their functions, according to contractual conditions.
databasen om bevægelsen af vogne og intermodale enheder
Wagon and Intermodal Unit Operational Database,
ruteplan for vogn/intermodal enhed.
Trip plan for wagon/intermodal unit.
Databasen om bevægelsen af vogne og intermodale enheder
Wagon and Intermodal Unit Operational Database
Kommunikationen mellem den primære jernbanevirksomhed og jernbanevirksomhederne i et samarbejde er baseret på numrene på vognene og/eller de intermodale enheder.
The communication between the Lead RU and RUs in the cooperation mode is based on wagon and/or intermodal unit numbers.
Derfor skal en jernbanevirksomhed, der kommunikerer med infrastrukturforvalterne på togniveau, angive disse oplysninger ved hjælp af oplysninger om vogn og intermodal enhed.
Therefore an RU, which communicates with the IMs at train level, must break down this information into wagon and intermodal unit related one.
Disse oplysninger om vogn og intermodal enhed kan lagres i databasen om bevægelsen af vogne og intermodale enheder.
This wagon and intermodal unit related information must be stored in the Wagon and Intermodal Unit Operational Database.
Oplysningerne om togbevægelser fører til nye poster/opdateringer i databasen om bevægelsen af vogne og intermodale enheder til kundeoplysninger.
The information on train movement leads to new entries/updates in the Wagon and Intermodal Unit Operational Database for customer information.
Oplysningerne om vognes eller intermodale enheders bevægelser skal senest indføres i databasen ved modtagelse af frigivelsestidspunktet for vognene eller enhederne fra kunden.
The movement part for a wagon or intermodal unit in the database is set up at the latest when receiving the release time for the wagons or intermodal unit from the customer.
Dette frigivelsestidspunkt udgør den første vognbevægelsespost i databasen om bevægelsen af vogne og intermodale enheder i forbindelse med en transport.
This release time is the first movement entry for a wagon into the Wagon and Intermodal Unit Operational Database related to an actual transport journey.
Meddelelserne ved vognbevægelser beskrives i kapitel 4.2.8 (Vognbevægelse) og 4.2.9 (Overdragelsesrapportering).
The messages for the wagon movement are defined in the Chapters 4.2.8 (Wagon movement) and 4.2.9 (Interchange reporting).
Denne database skal være tilgængelig via den fælles grænseflade (4.2.14.1: Generel arkitektur og 4.2.14.7: Fælles grænseflade).
This database must be accessible via the common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).
Databasen om bevægelsen af vogne og intermodale enheder er den vigtigste i forbindelse med sporing af vogne og således den vigtigste for kommunikationen mellem de deltagende jernbanevirksomheder og den primære jernbanevirksomhed.
The Wagon and Intermodal Unit Operational Database is the most important one for the tracking of wagons and therefore for the communication between the RUs involved and the Lead RU.
Databasen viser en vogns/intermodal enheds bevægelser fra afgang til endelig levering ved kundens sidespor med ETI-værdier og faktiske tidspunkter ved forskellige lokaliteter frem til ETA for endelig levering.
This database shows the movement of a wagon and of an intermodal unit from departure through to final delivery at customer sidings with ETIs and actual times at different locations until the final delivery time ETA.
Databasen viser også det rullende materiels status, f.eks.:
The database also shows the different status of the rolling stock such as:
Status: læsning af det rullende materiel
Status: loading of the rolling stock
Denne status er nødvendig for udvekslingen af oplysninger mellem jernbanevirksomheden og infrastrukturforvalterne og andre jernbanevirksomheder, der deltager i transporten.
This status is required for the information exchange between the RU and the IMs and to other railway undertakings involved in the transport journey.
Status: læsset vogn undervejs
Status: loaded wagon on journey
Denne status er nødvendig for udvekslingen af oplysninger mellem infrastrukturforvalteren og jernbanevirksomheden, med andre infrastrukturforvaltere og med andre jernbanevirksomheder, der deltager i transporten.
This status is required for the information exchange between the IM and the RU, with other infrastructure managers and with other railway undertakings involved in the transport journey.
Status: tom vogn undervejs
Status: empty wagon on journey
Denne status er nødvendig for udvekslingen af oplysninger mellem infrastrukturforvalteren og jernbanevirksomheden og med andre infrastrukturforvaltere og jernbanevirksomheder, der deltager i transporten.
This status is required for the information exchange between the IM and the RU, with other infrastructure managers and railway undertakings involved in the transport journey.
Status: losning af det rullende materiel
Status: unloading of rolling stock
Denne status er nødvendig for udvekslingen af oplysninger mellem jernbanevirksomheden ved destinationen og den primære jernbanevirksomhed ved transporten.
This status is required for the information exchange between the RU at destination and the Lead RU for the transport.
Status: tom vogn under flådeforvalterens kontrol
Status: empty wagon under fleet management control
Denne status er nødvendig for at få oplysninger om tilgængeligheden af et køretøj med bestemte egenskaber.
This status is required to get the information about availability of a vehicle of defined characteristics.
Databaser over vognes ruteplaner
Wagon Trip Plan Databases
For hver enkelt vogn opretter og opdaterer den primære jernbanevirksomhed (den jernbanevirksomhed, der fungerer som driftsintegrator) en ruteplan, der svarer til togkanalen på togniveau.
For each wagon the Lead RU (RU acting as service integrator) must establish and update a trip plan which corresponds to the train path at train level.
Nye togkanaler for et tog, f.eks. i forbindelse med driftsafbrydelser, resulterer i reviderede ruteplaner for de berørte vogne.
New train paths for a train — e.g. in case of service interruptions — lead to revised trip plans for the wagons concerned.
De enkelte primære jernbanevirksomheder skal lagre vognenes ruteplaner i en database.
The Wagon Trip Plans must be stored by each LRU in a database.
Bemærk:
Remark:
Udover ovennævnte obligatoriske databaser kan der oprettes togdatabaser hos de enkelte infrastrukturforvaltere.
In addition to the mandatory databases mentioned above, at each IM side a train database may be installed.
Oplysningerne i disse databaser svarer til oplysningerne om bevægelser i databasen om bevægelsen af vogne og intermodale enheder.
This infrastructure manager train database corresponds to the movement part of the Wagon and Intermodal Unit Operational Database.
De vigtigste dataposter er de togrelaterede data i meddelelsen om togsammensætning fra jernbanevirksomheden.
The main data entries are the train related data of the train composition message from the RU.
En alternativ lagringsmulighed for disse data er kanaldatabasen (kapitel 4.2.2: Kanalansøgning).
An alternative storage possibility for these data is the path database (Chapter 4.2.2: Path request).
Yderligere krav til databaserne
Additional requirements on the databases
Databasen skal understøtte autentificering af brugerne af systemerne, før de kan opnå adgang til databasen.
A database must support the authentication of users of the systems before they can gain access to the database.
Databasen skal understøtte relevante sikringsaspekter i form af kontrol med adgang til databasen.
A database must support the security aspects in the meaning of controlling access to the database.
Mulighed for kryptering af selve databasens indhold er ikke påkrævet.
The possible encryption of the database contents itself is not required.
Konsekvens
Consistency
Databasen skal understøtte ACID-princippet (Atomicity, Consistency, Isolation, Durability — atomicitet, konsekvens, isolation og holdbarhed).
A database selected shall support the ACID principle (Atomicity, Consistency, Isolation, Durability).
Adgangskontrol
Access control
Databasen skal give brugere og systemer, som har fået tilladelse, adgang til dataene.
A database must allow access to the data to users or systems that have been granted permission.
Adgangskontrollen skal understøttes helt ned til dataposternes enkelte attributter.
The access control shall be supported down to a single attribute of a data record.
Databasen skal understøtte konfigurerbar, rollebaseret adgangskontrol ved indlæsning, opdatering og sletning af dataposter.
The database shall support configurable, role based access control for insertion, update or deletion of data records.
Sporing
Tracing
Databasen skal understøtte logning af alle hændelser, der lægges i den, for at muliggøre sporing af dataposternes detaljer (hvem, hvad, hvornår blev indholdet ændret).
A database must support logging all actions applied to the database to allow for tracing the detail of the data entry (Who, What, When did the contents change).
Låsestrategi
Lock strategy
I databasen skal der implementeres en låsestrategi, som giver adgang til dataene, mens andre brugere er i færd med at redigere poster.
A database must implement a locking strategy which allows access to the data even when other users are currently editing records.
Flerbrugeradgang
Multiple access
Databasen skal sikre, at flere brugere og systemer kan få adgang til dataene samtidig.
A database must support that data can be accessed simultaneously by several users and systems.
Pålidelighed
Reliability
Databasen skal være pålidelig nok til at sikre den fornødne tilgængelighed.
The reliability of a database must support the required availability.
Databasen skal have en tilgængelighedsgrad på mindst 99,9 %.
A database must have an availability on demand of at least 99,9 %.
Mulighed for vedligeholdelse
Maintainability
Databasen skal kunne vedligeholdes, så den fornødne tilgængelighed kan sikres.
A maintainability of the database must support the required availability.
Databaser har i sig selv ikke direkte noget med sikker togdrift at gøre.
Databases themselves are not safety related.
Sikkerhedsaspekter er således ikke relevante.
Hence safety aspects are not relevant.
Dette udelukker dog ikke, at dataene — f.eks. forkerte eller ikke faktuelle data — kan have indflydelse på sikker togdrift.
This is not to be confused with the fact that the data — e.g. wrong or not actual data — may have impact on the safety operation of a train.
Kompatibilitet
Compatibility
Databasen skal understøtte et udbredt datahåndteringssprog såsom SQL eller XQL.
A database must support a data manipulation language that is widely accepted, such as SQL or XQL.
Importfunktion
Import facility
Databasen skal have en funktion, som gør det muligt at importere formaterede data direkte til databasen i stedet for at skulle indlæse dem manuelt.
A database shall provide a facility that allows the import of formatted data that can be used to fill the database instead of manual input.
Eksportfunktion
Export facility
Databasen skal have en funktion, som gør det muligt at eksportere hele eller dele af dens indhold som formaterede data.
A database shall provide a facility that allows to export the contents of the complete database or its part as formatted data.
Obligatoriske felter
Mandatory fields
Databasen skal have obligatoriske felter, som skal udfyldes, før den pågældende post accepteres som input til databasen.
A database must support mandatory fields that are required to be filled before the relevant record is accepted as input to the database.
Sandsynlighedskontroller
Plausibility checks
Databasen skal understøtte konfigurerbare sandsynlighedskontroller før accept af indlæsning, opdatering eller sletning af dataposter.
A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Svartider
Response times
Databasen skal have svartider, der gør det muligt for brugerne at indlæse, opdatere eller slette dataposter i rette tid.
A database must have response times that allow users to insert, update or delete data records in a timely manner.
Ydeevne
Performance aspects
Databasen skal understøtte den mængde forespørgsler, der er nødvendig for at sikre effektiv drift af omkring 60000 togkørsler inden for 24 timer.
A database shall support the queries necessary to allow the effective run of about 60000 train runs per 24 hours.
Omkring 50 % af disse togkørsler forventes at finde sted inden for to timer.
About 50 % of these train runs are deemed to take place within two hours.
Antallet og arten af forespørgsler og opdateringer pr. tog afhænger af den overordnede process i forbindelse med planlægning og togkørsel.
The number and kind of queries or updates per train are dependent on the overall process for planning and running a train.
Kapacitet
Capacity aspects
Databasen skal understøtte lagring af de relevante data i forhold til alle godsvogne og netværket.
A database shall support the storage of the relevant data for all freight wagons respectively the network.
Det skal være muligt at udvide kapaciteten vha. enkle midler (dvs. ved at tilføje mere lagerkapacitet og flere computere).
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Kapacitetsudvidelser må ikke kræve udskiftning af delsystemet.
The extension of the capacity shall not require replacement of the subsystem.
Historiske data
Historical data
Databasen skal understøtte håndtering af historiske data i den forstand, at den skal sikre adgang til data, som allerede er overført til et arkiv.
A database shall support the management of historical data in the meaning of making of data available that has been already transferred into an archive.
Backup-strategi
Back-up strategy
Der skal fastlægges en backup-strategi, som sikrer, at hele databasens indhold i en periode på op til 24 timer kan genetableres.
A back-up strategy shall be in place to ensure that the complete database contents for up to a 24-hour period can be recovered.
Kommercielle aspekter
Commercial aspects
Det anvendte databasesystem skal være et kommercielt standardprodukt eller på anden måde offentligt tilgængeligt (åben kilde).
A database system used shall be available commercially-off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Bemærk:
Remarks:
Ovennævnte krav skal opfyldes ved anvendelse af et DBMS-system (databaseforvaltningssystem) i standardudgave.
The above requirements must be handled by a standard Database Management System (DBMS).
Brugen af de forskellige databaser ligger i de forskellige arbejdsgange, som beskrives ovenfor.
The usage of the various databases is embedded into various work flows described here before.
Den normale arbejdsgang består af en forespørgsel og et svar, hvor en interesseret part anmoder om oplysninger fra databasen via den fælles grænseflade (4.2.14.1: Generel arkitektur og 4.2.14.7: Fælles grænseflade).
The general workflow is a request/response mechanism, where an interested party requests information from the database through the common interface (4.2.14.1: General architecture and 4.2.14.7: Common interface).
DBMS-systemet svarer på denne anmodning ved enten at levere de efterspurgte data eller ved at svare, at de ikke kan gøres tilgængelige (de pågældende data findes ikke, eller adgangskontrollen vil ikke give adgang til dem).
The DBMS responds to this request either by providing the requested data or by responding that no data can be made available (no such data exists or access is refused due to access control).
Af beskrivelsen i kapitel 4.2.14 (Netværkssamarbejde og kommunikation) fremgår det kommunikationsnetværk, som skal anvendes til dataudveksling.
The description in Chapter 4.2.14 (Networking and communication) presents the communication network to be used for data exchange.