natgillin/translations-raw huggingface dataset:
Følgende opbevares og administreres centralt:
The Infrastructure Data (the Network Statements and the infrastructure restriction notices ) and Rolling Stock Data (in the Rolling Stock Reference Databases and in the Wagon and Intermodal Unit Operational Database) are the most important data for the operation of freight trains on the European network.
Referencefil for kodning af alle infrastrukturforvaltere, jernbanevirksomheder og tjenesteydere
Both types of data together allow an assessment of the compatibility of the rolling stock with the infrastructure, help to avoid multiple data input, which increase especially the data quality, and they give a clear picture on all available installations and equipment at any time for fast decisions during the operation.
Referencefil for kodning af godstransportkunder
The Rolling Stock Reference Databases
Referencefil for kodning af lokaliteter (primær og sekundær)
The keeper of a rolling stock is responsible for the storage of the rolling stock data within a Rolling Stock Reference Database.
Det Europæiske Jernbaneagentur vil gemme en kopi af referencefilen med lokalitetskoder og virksomhedskoder.
The Information that must be included in the individual Rolling Stock Reference Databases is described in detail in Appendix I, Appendix C. They must contain all items for:
Disse data stilles til rådighed for offentligheden efter individuel anmodning med de indskrænkninger, hensynet til intellektuelle ejendomsrettigheder tilsiger.
Assessment of the compatibility with the infrastructure,
Der er fastsat andre kodelister i det dokument, som der henvises til i tillæg I:
The Rolling Stock Reference Databases must allow easy access (a single common access provided via the common interface) to the technical data to minimise the volume of data transmitted for each operation.
»TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model«.
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.
Andre databaser
The entries in the Rolling Stock Reference Database can be grouped as follows:
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.
Administrative data, related to certification and registration items such as reference to the EC registration file, id of the notified body, etc.;
Bemyndigede enheder, som f.eks. ihændehavere og vognparkforvaltere, skal på grundlag af bilaterale aftaler have adgang til de data, der er relevante for varetagelsen af deres opgaver.
this may include historical data related to ownership, rental, etc.
Driftsdatabasen for vogne og intermodale enheder
Additionally, according to Commission Regulation EU 445/2011, article 5, the Wagon Keepers may store the ECM certification identification number in the individual Rolling Stock Reference Databases.
Turplan for vogn/intermodal enhed.
The following steps have to be taken into account:
Disse databaser skal kunne tilgås via den fælles grænseflade (4.2.12.1: Overordnet arkitektur og 4.2.12.6: Fælles grænseflade).
EC certification,
Driftsdatabasen for vogne og intermodale enheder
Registration in the ‘home’ State,
Kommunikationen mellem den primære jernbanevirksomhed og jernbanevirksomhederne i et samarbejde bygger på vognenes og/eller de intermodale enheders numre.
Date put into service in the state of registration,
Derfor skal en jernbanevirksomhed, der sender infrastrukturforvalterne meddelelser om hele tog, angive oplysningerne for hver vogn og intermodal enhed.
Registration in other countries for the use on their national network,
Disse oplysninger om vogn og intermodal enhed skal lagres i driftsdatabasen for vogne og intermodale enheder.
Safety certification for all Rolling Stock which does not comply with the Rolling Stock TSI.
Oplysningerne om togbevægelser fører til nye poster/opdateringer i driftsdatabasen for vogne og intermodale enheder med kundeoplysninger.
The keeper is obliged to ensure that these data are available and the processes behind have been conducted.
Oplysningerne om vognes eller intermodale enheders bevægelser skal senest indføres i databasen, når frigivelsestidspunktet for vognene eller de intermodale enheder modtages fra kunden.
Design data, 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.
Dette frigivelsestidspunkt udgør den første post om en vogns bevægelse i driftsdatabasen for vogne og intermodale enheder i forbindelse med en transport.
The Rolling Stock Operational Data
Meddelelserne om vognbevægelser er defineret i punkt 4.2.8 (Vognbevægelse) og 4.2.9 (Overgangsrapportering).
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.
Denne database skal kunne tilgås via den fælles grænseflade (4.2.12.1: Overordnet arkitektur og 4.2.12.6: Fælles grænseflade).
This data shall include temporary data, such as restrictions, current and projected maintenance actions, km and fault counters, etc.;
Driftsdatabasen for vogne og intermodale enheder er den vigtigste database for sporing af vogne og dermed den vigtigste for kommunikationen mellem de deltagende jernbanevirksomheder og den primære jernbanevirksomhed.
and all data that could be considered as ‘status’ (temporary speed restrictions, brake isolated, needs for repair and fault description, etc.).
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.
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:
Databasen viser også forskellige statustilstande for det rullende materiel, f.eks.:
Railway Undertaking as Duty holder during its transport control,
lastning af det rullende materiel
Keeper of rolling stock, and
Denne status er nødvendig for udvekslingen af oplysninger mellem jernbanevirksomheden og infrastrukturforvalterne og andre jernbanevirksomheder, der deltager i transporten.
User (Hirer) of rolling stock.
lastet vogn undervejs
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).
Denne status er nødvendig for udvekslingen af oplysninger mellem infrastrukturforvalteren og jernbanevirksomheden, med andre infrastrukturforvaltere og med andre jernbanevirksomheder, der deltager i transporten.
The operational rolling stock data is a part of the Wagon and Intermodal Unit Operational Database as described in Chapter 4.2.11.2 Other Databases.
tom vogn undervejs
Reference Files
Denne status er nødvendig for udvekslingen af oplysninger mellem infrastrukturforvalteren og jernbanevirksomheden og med andre infrastrukturforvaltere og jernbanevirksomheder, der deltager i transporten.
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).
losning af det rullende materiel
The data must represent the actual status at all times.
Denne status er nødvendig for udvekslingen af oplysninger mellem jernbanevirksomheden ved destinationen og den primære jernbanevirksomhed for transporten.
Where a reference file is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies.
tom vogn under vognparkforvalterens kontrol
Locally stored and administrated:
Denne status er nødvendig for at få oplysninger om tilgængeligheden af et køretøj med bestemte egenskaber.
Reference File of the emergency services, correlated to type of hazardous goods.
Databaser over vognes turplaner
Centrally stored and administrated:
Tog kan være sammensat af vogne fra forskellige kunder.
Reference File of the Coding for all IMs, RUs, Service provider companies;
For hver vogn skal den primære jernbanevirksomhed (den jernbanevirksomhed, der fungerer som driftsintegrator) udarbejde og ajourføre en turplan, der svarer til kanalen på togniveau.
Reference File of the Coding for Freight Transport Customers;
Tildeles et tog en ny kanal — f.eks. ved driftsafbrydelser — revideres turplanerne for de berørte vogne.
Reference File of the Coding of Locations (Primary and subsidiary),
Disse databaser skal kunne tilgås via den fælles grænseflade (4.2.14.1: Overordnet arkitektur og 4.2.12.6: Fælles grænseflade).
The European Railway Agency will save a copy of the Reference File for the Locations Codes and Company Codes.
Udover ovennævnte obligatoriske databaser kan der oprettes togdatabaser hos de enkelte infrastrukturforvaltere.
On individual request and without prejudice to intellectual property rights, this data shall be available for public consultation.
Oplysningerne i infrastrukturforvalterens togdatabase svarer til oplysningerne om bevægelser i driftsdatabasen for vogne og intermodale enheder.
Other code lists are defined in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I.
Hovedposten er de togrelaterede data i meddelelsen om togets oprangering fra jernbanevirksomheden.
Other Databases
Alle toghændelser medfører ajourføring af denne togrelaterede database.
To allow for the tracking of train and wagon movements, the following databases, updated at each relevant event in real time, must be installed.
En alternativ lagringsmulighed for disse data er kanaldatabasen (punkt 4.2.2: Kanalansøgning).
Authorised entities such as keepers and fleet managers must have access to the data relevant to fulfil their functions, according to bilateral agreements.
Disse databaser skal kunne tilgås via den fælles grænseflade (4.2.12.1: Overordnet arkitektur og 4.2.12.6: Fælles grænseflade).
Wagon and Intermodal Unit Operational Database,
Yderligere krav til databaserne
Trip plan for wagon/Intermodal unit.
Nedenfor anføres de yderligere krav, som de forskellige databaser skal opfylde.
These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Kravene er:
Wagon and Intermodal unit Operational Database
Autentificering
The communication between the Lead RU and RUs in the cooperation mode is based on wagon and/or Intermodal unit numbers.
En database skal understøtte autentificering af brugerne af systemerne, før de kan få adgang til databasen.
Therefore an RU, which communicates with the IMs at train level, must break down this information into wagon and Intermodal unit related one.
En database skal understøtte relevante sikringsforholdsregler i form af kontrol med adgang til databasen.
The information on train movement leads to new entries/updates in the Wagon and Intermodal Unit Operational Database for customer information.
Der stilles ikke krav om, at selve databasens indhold skal kunne krypteres.
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.
Modsigelsesfrihed
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.
En database skal understøtte ACID-princippet (Atomicity, Consistency, Isolation, Durability — udelelighed, modsigelsesfrihed, isolation og stabilitet).
The messages for the wagon movement are defined in the Chapters 4.2.8 (Wagon Movement) and 4.2.9 (Interchange Reporting).
Adgangskontrol
This database must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
En database skal give brugere og systemer, som har fået tilladelse, adgang til dataene.
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.
Adgangskontrollen skal understøttes helt ned til dataposternes enkelte attributter.
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 skal understøtte konfigurerbar, rollebaseret adgangskontrol ved indlæsning, opdatering og sletning af dataposter.
The database also shows the different status of the rolling stock such as:
Sporing
Status:
En database skal understøtte logning af alle handlinger, der foretages i den, for at muliggøre sporing af hver enkelt detalje i dataindlæsningen (hvem har ændret hvad hvornår i indholdet).
loading of the rolling stock
Låsestrategi
This status is required for the information exchange between the RU and the IMs and to other railway undertakings involved in the transport journey.
I en database skal der implementeres en låsestrategi, som giver adgang til dataene, selv om andre brugere er i færd med at redigere poster.
loaded wagon on journey
Flerbrugeradgang
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.
En database skal sikre, at flere brugere og systemer kan få adgang til dataene samtidig.
empty wagon on journey
En database skal være driftssikker nok til, at den påkrævede rådighedsfaktor opnås.
unloading of rolling stock
Rådighedsfaktor
This status is required for the information exchange between the RU at destination and the Lead RU for the transport.
En database skal have en rådighedsfaktor på mindst 99,9 %.
empty wagon under fleet management control
Mulighed for vedligeholdelse
This status is required to get the information about availability of a vehicle of defined characteristics.
Databasen skal kunne vedligeholdes på en måde, så den krævede rådighedsfaktor sikres.
Wagon Trip Plan Databases
Databaser har i sig selv ikke direkte noget med sikker togdrift at gøre.
Trains may be composed of wagons from various Customers.
Sikkerhedsaspekterne er således ikke relevante.
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.
Dette må dog ikke forveksles med det forhold, at dataene — f.eks. forkerte eller uaktuelle data — kan påvirke togdriftens sikkerhed.
New train paths for a train — e.g. in case of service interruptions — lead to revised trip plans for the wagons concerned.
Forenelighed
The creation time for the trip plan is the receipt of the consignment note from the customer.
En database skal understøtte et udbredt datahåndteringssprog såsom SQL eller XQL.
The Wagon Trip Plans must be stored by each LRU in a database.
Importfunktion
These databases must be accessible via the Common Interface (4.2.14.1: General Architecture and 4.2.12.6: Common Interface).
En database 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.
In addition to the mandatory databases mentioned above, at each IM side a train database may be installed.
Eksportfunktion
This infrastructure manager train database corresponds to the movement part of the Wagon and Intermodal Unit Operational Database.
Databasen skal have en funktion, som gør det muligt at eksportere hele dens indhold eller dele af det som formaterede data.
The main data entry is the train related data of the train composition message from the RU.
Obligatoriske felter
All train events result in an update of this train related database.
En database skal have obligatoriske felter, som skal udfyldes, før den pågældende post accepteres som input til databasen.
An alternative storage possibility for these data is the path database (Chapter 4.2.2: Path Request).
Sandsynlighedskontrol
These databases must be accessible via the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
En database skal understøtte konfigurerbare sandsynlighedskontroller før accept af indlæsning, opdatering eller sletning af dataposter.
Additional Requirements on the Databases
Svartider
Under the following points are listed additional requirements which must be supported by the various databases.
En database skal have svartider, der gør det muligt for brugerne at indlæse, opdatere eller slette dataposter i rette tid.
These are:
Ydeevne
Authentication
Referencefilerne og databaserne skal på en omkostningseffektiv måde understøtte den mængde forespørgsler, der er nødvendig for effektiv drift af alle relevante togkørsler og vognbevægelser, der er omfattet af bestemmelserne i denne TSI.
A database must support the authentication of users of the systems before they can gain access to the database.
Kapacitet
Security
En database skal understøtte lagring af de relevante data for alle godsvogne hhv. for banenettet.
A database must support the security aspects in the meaning of controlling access to the database.
Det skal være muligt at udvide kapaciteten ved enkle midler (dvs. ved at tilføje mere lagerkapacitet og flere computere).
The possible encryption of the database contents itself is not required.
Kapacitetsudvidelser må ikke kræve udskiftning af delsystemet.
Consistency
Historiske data
A database selected shall support the ACID principle (Atomicity, Consistency, Isolation and Durability).
En database skal understøtte håndtering af historiske data ved at sikre adgang til data, som allerede er overført til et arkiv.
Access Control
Backup-strategi
A database must allow access to the data to users or systems that have been granted permission.
Der skal fastlægges en backup-strategi, som sikrer, at hele databasens indhold i en periode på op til 24 timer kan genetableres.
The access control shall be supported down to a single attribute of a data record.
Kommercielle aspekter
The database shall support configurable, role based access control for insertion, update or deletion of data records.
Det anvendte databasesystem skal være en hyldevare (standardprodukt i handelen) eller på anden måde være til fri rådighed for offentligheden (open source).
Tracing
Bemærkninger:
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).
Ovennævnte krav skal opfyldes ved anvendelse af et DBMS-system (databaseforvaltningssystem) i standardudgave.
Lock strategy
Brugen af de forskellige databaser ligger i de forskellige arbejdsgange, som beskrives ovenfor.
A database must implement a locking strategy which allows access to the data even when other users are currently editing records.
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.12.1: Overordnet arkitektur og 4.2.12.6: Fælles grænseflade).
Multiple access
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).
A database must support that data can be accessed simultaneously by several users and systems.
Overordnet arkitektur
Reliability
Dette delsystem vil danne rammen om et gradvis fremvoksende samvirke i et stort og komplekst IT-netværk om interoperabilitet i jernbanenettet, hvor hundreder af deltagere (jernbanevirksomheder, infrastrukturforvaltere osv.) konkurrerer og/eller samarbejder om at opfylde markedets behov.
The reliability of a database must support the required availability.
Den net- og kommunikationsinfrastruktur, der skal understøtte dette interoperabilitetsnetværk, vil være baseret på en fælles arkitektur for informationsudveksling, som alle deltagerne kender og bruger.
Availability
Den foreslåede arkitektur for informationsudveksling:
A database must have an availability on demand of at least 99,9 %.
udformes, så den forener forskelligartede informationsmodeller gennem semantisk omdannelse af de data, der udveksles mellem systemerne, og ved at udligne forskellene mht. forretningsgange og protokoller, der anvendes på applikationsniveau
Maintainability
får kun minimal indvirkning på den eksisterende IT-arkitektur, som de enkelte aktører anvender
A maintainability of the database must support the required availability.
beskytter de IT-investeringer, der allerede er foretaget.
Databases themselves are not safety-related.
Arkitekturerne for informationsudveksling favoriserer interaktion, der primært bliver af peer-to-peer-typen, mellem alle aktørerne og sikrer samtidig den overordnede integritet og sammenhæng i jernbanenettet ved at stille et sæt centrale tjenester til rådighed.
Hence safety aspects are not relevant.
En peer-to-peer-model for interaktionen giver mulighed for at fordele omkostningerne mellem de forskellige deltagere på den bedste måde med udgangspunkt i den faktiske brug, og generelt vil den medføre færre problemer med skalerbarhed.
This is not to be confused with the fact that the data — e.g. wrong or not actual data — may have impact on the safe operation of a train.
En grafisk fremstilling af den overordnede arkitektur findes i kapitel 1.5 i det dokument, som der henvises til i tillæg I: »TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages«.
Compatibility
Netværket
A database must support a data manipulation language that is widely accepted, such as SQL or XQL.
Med »netværk« henvises der her til kommunikationsmetoden og -princippet og ikke til det fysiske net.
Import facility
Interoperabiliteten i jernbanenettet bygger på en fælles arkitektur for informationsudveksling, som alle deltagere kender og bruger, og som dermed virker tiltrækkende og mindsker hindringerne for nye deltagere, ikke mindst kunder.
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.
Sikkerhedsspørgsmålet behandles derfor ikke af netværket (VPN, tunnelering, ...), men ved udveksling og håndtering af i sig selv sikre meddelelser.
Export facility
Et VPN-netværk er derfor ikke nødvendigt (det vil være komplekst og dyrt at forvalte et stort VPN-netværk), og derved undgås problemer med ansvarsfordeling og tildeling af ejerskab.
A database shall provide a facility that allows to export the contents of the complete database or its part as formatted data.
Tunnelering betragtes ikke som et nødvendigt middel til at opnå det relevante sikkerhedsniveau.
Mandatory Fields
Hvis nogle deltagere allerede har implementeret forskellige grader af sikkerhed i udvalgte dele af netværket eller ønsker at gøre det, står muligheden åben.
A database must support mandatory fields that are required to be filled before the relevant record is accepted as input to the database.
Via det offentlige internet er det muligt at implementere en blandet peer-to-peer-model med en fælles grænseflade ved hver aktørs knudepunkt og en central certifikatmyndighed.
Plausibility Checks
Derefter kommunikeres der peer-to-peer mellem de involverede deltagere.
A database must support configurable plausibility checks before accepting the insertion, update or deletion of data records.
Peer-to-peer-kommunikationen bygger på tekniske standarder for den fælles grænseflade, der er beskrevet i det dokument, som der henvises til i tillæg I:
Response times
»TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model«.
A database must have response times that allow users to insert, update or delete data records in a timely manner.
For at opnå et højt sikkerhedsniveau skal alle meddelelser være isolerede, hvilket betyder, at oplysningerne i meddelelserne er sikrede, og at modtageren kan kontrollere meddelelsens ægthed.
Performance aspects