natgillin/translations-raw huggingface dataset:
A database must support mandatory fields that are required to be completed before the relevant record is accepted as input to the database.
En database må støtte obligatoriske felter som må være utfylt før den aktuelle posten godtas som inndata til databasen.
The reference files and databases shall support in a cost effective manner the queries necessary to allow the effective operation of all relevant train runs that are covered by the provisions of this TSI.
Referansefilene og databasene skal på en kostnadseffektiv måte støtte de forespørslene som er nødvendige for å muliggjøre effektiv drift av alle relevante togkjørsler som omfattes av bestemmelsene i denne TSI-en.
A database shall support the storage of the relevant data for all passenger wagons and/or the network.
I en database skal det kunne lagres relevante data for alle passasjervogner, og/eller hele jernbanenettet.
A database shall support the management of historical data by making data available that have been already transferred into an archive.
En database må støtte håndteringen av historiske data ved å gjøre allerede arkiverte data tilgjengelige.
A back-up strategy shall be in place to ensure that the complete database contents for a period of up to 24 hours can be recovered.
Det må være utarbeidet en sikkerhetskopistrategi som gjør at hele innholdet i databasen kan gjenopprettes for et tidsrom på inntil 24 timer.
The database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Databasesystemet som benyttes, skal være hyllevare (COTS-produkt) eller offentlig tilgjengelig (Open Source).
Privacy aspects
Personvern
A database has to fulfil the privacy policy requirements of the Member State in which the company performing the service is domiciled.
En database må oppfylle kravene til personvern i den medlemsstaten der selskapet som leverer tjenesten, er hjemmehørende.
The description in Section 4.2.21 — Networking and communication — presents the communication network to be used for data exchange.
I kapittel 4.2.21 (Nettverk og kommunikasjon) beskrives det kommunikasjonsnettet som skal brukes i forbindelse med datautvekslingen.
This network and the described security handling allow any type of network transmission, such as e-mail, file transfer (Ftp, Http), etc. The parties involved in the information exchange can then decide on the type to choose, thereby ensuring the electronic transmission of documents, for example, via FTP.
Dette nettet og sikkerhetshåndteringen som beskrives, muliggjør alle typer av nettoverføring, som for eksempel e-post, filoverføring (ftp, http), osv. Partene som deltar i informasjonsutvekslingen kan dermed avgjøre hvilken type de skal velge, og dermed sikre at dokumentene overføres elektronisk, f.eks. via ftp.
Over time this subsystem will see the growth and interaction of a large and complex telematics rail interoperability community with thousands of participating actors (railway undertakings, infrastructure managers, third parties such as retailers and public authorities, etc.), which will compete and/or cooperate in serving the market’s needs.
Dette delsystemet kommer med tiden til å vokse og danne et stort og sammensatt telematikksystem innenfor rammen av et jernbanefellesskap med samtrafikkevne, basert på samvirkende telematikksystemer, der tusenvis av deltakende organisasjoner (jernbaneforetak, infrastrukturforvaltninger, tredjeparter, som f.eks. detaljister og offentlige myndigheter) vil konkurrere og/eller samarbeide om å dekke markedets behov.
The network and communication infrastructure supporting such a rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all those participating in it.
Infrastrukturen for nettverk og kommunikasjon til støtte for jernbanefellesskapet med samtrafikkevne vil bygge på en felles arkitektur for informasjonsutveksling, som er kjent og anvendt av alle som deltar i det.
The proposed ‘Information Exchange Architecture’:
Den foreslåtte arkitekturen for informasjonsutveksling
is designed to reconcile heterogeneous information models by semantically transforming the data that are exchanged between the systems and by reconciling the differences in business processes and application-level protocols,
er beregnet på å gjøre forskjellige informasjonsmodeller forenlige ved semantisk å omdanne dataene som utveksles mellom systemene, og ved å utligne forskjellene mellom forretningsprosesser og programprotokoller,
has a minimal impact on the existing IT architectures implemented by each actor,
har minimal innvirkning på eksisterende IT-arkitektur som anvendes av alle aktører,
safeguards IT investments already made.
sikrer allerede foretatte IT-investeringer.
The Information Exchange Architecture favours a mostly Peer-to-Peer type of interaction between all actors, while guaranteeing the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.
Arkitekturen for informasjonsutveksling favoriserer hovedsakelig en likenettbasert («peer-to-peer») type av samhandling mellom aktørene, samtidig som den sikrer den samlede integriteten og ensartetheten til jernbanefellesskapet med samtrafikkevne ved å tilby et sett med sentraliserte tjenester.
A Peer-to-Peer interaction model allows the best distribution of costs between the different actors, based on actual usage and, in general, will pose fewer scalability problems.
En likenettbasert samhandlingsmodell gir mulighet for best mulig kostnadsfordeling mellom de forskjellige aktørene, basert på faktisk bruk, og vil generelt medføre færre skalerbarhetsproblemer.
The network shall ensure the necessary level for security, redundancy, traffic control, statistics tools, bandwidth growth, user accessibility and efficient management.
Jernbanenettet skal sikre det nødvendige nivået på sikkerhet, redundans, trafikkstyring, statistikkverktøy, vekst i båndbredde, brukertilgjengelighet og effektiv ledelse.
‘Network’ in this context means the method and philosophy of communication and does not refer to the physical network.
Med jernbanenett menes her kommunikasjonsmetode og –filosofi, og ikke det fysiske nettet.
Rail interoperability is based on a common ‘Information Exchange Architecture’, known and adopted by all participants, thus encouraging and lowering barriers for new entrants, especially customers.
Samtrafikkevne i jernbanenettet bygger på en felles arkitektur for informasjonsutveksling som er kjent og anvendt av alle deltakere, og som dermed oppmuntrer og minsker hindringene for nye aktører, særlig kunder.
First, the central Repository is approached to obtain meta-information, such as the identity of the peer (actor) on which information is stored, or to verify security credentials.
Først kontaktes det sentrale datalageret for å innhente metainformasjon, for eksempel identiteten til en aktør (peer) som det er lagret opplysninger om, eller for å verifisere sikkerhetsdata.
Afterwards, Peer-to-Peer communication takes place between the actors involved.
Deretter finner likenettskommunikasjon sted mellom de berørte aktørene.
Only protocols belonging to the Internet Protocol Suite (commonly known as TCP/IP, UDP/IP, etc.) may be used for developments.
Bare protokoller som tilhører samlingen av Internett-protokoller (vanligvis kjent som TCP/IP, UDP/IP, osv.), kan benyttes til utvikling.
On top of the security level guaranteed at the level of the network (see Section 4.2.21.2 Network), an additional level of security can be achieved for sensitive data by using a combination of encryption, certification scheme and VPN technologies.
På toppen av det garanterte sikkerhetsnivået på jernbanenettnivået (se avsnitt 4.2.21.2 Jernbanenett), kan et ytterligere sikkerhetsnivå oppnås for følsomme data ved å benytte en kombinasjon av kryptering, sertifiseringsordning og VPN-teknologier.
Either asymmetric or symmetric encryption can be used for data transmission and storage, depending on the business requirements.
Enten asymmetrisk eller symmetrisk kryptering kan benyttes for overføring og lagring av data, avhengig av forretningskravene.
For this purpose a public key infrastructure (PKI) is to be implemented.
For dette formål skal det innføres en offentlig nøkkelinfrastruktur (PKI).
list of electronic addresses where the actors addressed by this TSI allow other actors to obtain information or data according to the provisions of this TSI,
en liste over elektroniske adresser, der aktørene som denne TSI-en er rettet til, kan innhente opplysninger eller data i henhold til bestemmelsene i denne TSI-en,
encryption,
kryptering,
authentication,
autentisering,
directory (phonebook) — it contains all necessary information on those participating in exchanging messages and data.
katalog (telefonbok) — som inneholder alle nødvendige opplysninger om dem som deltar i utvekslingen av meldinger og data.
Where the Central Repository is in use in conjunction with the TAF TSI, development and changes shall be performed as closely as possible to the implemented TAF TSI in order to achieve optimum synergies.
Dersom det sentrale datalageret er i bruk i forbindelse med TSI-en «Telematikkprogrammer for godstrafikk», skal utvikling og endringer utføres så nært opptil den iverksatte TSI-en «Telematikkprogrammer for godstrafikk» som mulig, for å oppnå optimale synergivirkninger.
Common interface for RU/IM communication
Felles grensesnitt for kommunikasjon mellom jernbaneforetak/infrastrukturforvaltning
addressing of outgoing messages,
adressering av de utgående meldingene,
authenticity verification of incoming messages,
kontroll av innkommende meldingers gyldighet,
conformity checks of incoming messages according to the metadata,
samsvarkontroller av innkommende meldinger i henhold til metadata,
handling the single common access to the various databases.
håndtering av tilgangen til de ulike databasene via en felles inngang.
Each instance of the common interface will have access to all the data required according to the TSI within each railway undertaking, infrastructure manager, etc., whether the relevant databases are central or individual.
Hvert av de felles grensesnittene vil ha tilgang til alle dataene som er nødvendige i henhold til denne TSI-en innenfor hvert jernbaneforetak, hver infrastrukturforvaltning, osv., uavhengig av om de relevante databasene er sentrale eller individuelle.
Based on the results of verification of the authenticity of incoming messages, a minimum level of message acknowledgement can be implemented:
På grunnlag av resultatene av gyldighetskontrollen av innkommende meldinger kan et minstenivå for meldingskvittering iverksettes:
positive:
positivt:
send ACK;
send ACK,
negative:
negativt:
send NACK.
send NACK,
The common interface uses the information in the Central Repository in order to manage the above tasks.
De felles grensesnittene bruker opplysningene i det sentrale datalageret til å utføre oppgavene ovenfor.
If an actor implements a local ‘mirror’ of the Central Repository, that actor must then — by its own means — ensure that the local ‘mirror’ is an accurate and up to date copy of the Central Repository.
Dersom en aktør innfører et lokalt «speil» av det sentrale datalageret, så må den nevnte aktøren — ved hjelp av egne midler — sikre at det lokale «speilet» er en nøyaktig og oppdatert kopi av det sentrale datalageret.
Where the Common Interface is in common use with the TAF TSI, the development and changes shall take place as closely as possible to the implemented TAF TSI, in order to achieve optimum synergies.
Dersom det sentrale datalageret er i bruk i forbindelse med TSI-en «Telematikkprogrammer for godstrafikk», skal utvikling og endringer finne sted så nært opptil den iverksatte TSI-en «Telematikkprogrammer for godstrafikk» som mulig, for å oppnå optimale synergivirkninger.
Management of connection with other modes of transport
Styring av omstigning til andre transportsystemer
In order to manage the connection with other modes of transport, the following standard should be applied for the provision of information to and exchange of information with other modes of transport:
For å styre omstigningen til andre transportsystemer skal følgende standarder anvendes for å gi opplysninger til og utveksle informasjon med andre transportsystemer:
For the exchange of timetable information between railway undertakings and other modes of transport:
For utveksling av ruteplanopplysninger mellom jernbaneforetak og andre transportsystemer:
norms EN 12896 (‘Transmodel’) and EN TC 278 WI 00278207 (‘IFOPT — Identification of Fixed Objects in Public transport’),
standardene EN 12896 («Transmodel») og EN TC 278 WI 00278207 («IFOPT — Identification of Fixed Objects in Public transport»),
For the exchange of specific timetable data, the XML technical standards and protocols based on Transmodel, in particular norm EN 15531 (‘SIRI’) for the exchange of real-time timetables and norm EN TC 278 WI 00278207 (‘IFOPT’) for the exchange of ‘stop/station’ data.
For utveksling av spesifikke ruteplandata, de tekniske XML-standardene og -protokollene basert på Transmodel, særlig standarden EN 15531 («SIRI»), for utveksling av sanntidsruteplaner, og standarden EN TC 278 WI 00278207 («IFOPT»), for utveksling av «stoppesteds-/stasjonsdata».
For the exchange of tariff data:
For utveksling av billettprisdata:
this standard is still an open point (see Annex II — List of open points).
Denne standarden er fortsatt et åpent punkt (se vedlegg II — Liste over åpne punkter).
From the standpoint of technical compatibility, the interfaces of the subsystem ‘telematics applications for passenger services’ with the other subsystems are as described in the following paragraphs.
Med hensyn til teknisk forenlighet er grensesnittene mellom delsystemet «telematikkprogrammer for passasjertransport» og de andre delsystemene, slik som beskrevet i følgende avsnitt:
Interfaces with the Rolling Stock Subsystem
Grensesnitt mot delsystemet «rullende materiell»
Interfaces with the Rolling Stock subsystem
Grensesnitt mot delsystemet «rullende materiell»
Reference Telematics Applications for passengers TSI
Henvisning til TSI-en «Telematikkprogrammer for passasjertransport»
Reference Conventional Rail Rolling Stock TSI’s
Henvisning til TSI-en «Rullende materiell» i jernbanesystemet for konvensjonelle tog
Board device display
Visningsskjermer i toget
Handling of information provision in vehicle area
Håndtering av opplysninger som gis på kjøretøyområdet
Customer information (PRM)
Kundeopplysninger (bevegelseshemmede personer )
Automatic voice and announcement
Automatisk stemmeannonsering
Interfaces with the Telematics Applications for Freight Subsystem
Grensesnitt mot delsystemet «telematikkprogrammer for godstrafikk»
Interfaces with the Telematics Applications for Freight subsystem
Grensesnitt mot delsystemet «telematikkprogrammer for godstrafikk»
Reference Telematics Applications for passengers TSI
Henvisning til TSI-en «Telematikkprogrammer for passasjerer»
Reference Conventional Rail Telematics Applications for Freight TSI
Henvisning til TSI-en «Telematikkprogrammer for godstrafikk» i jernbanesystemet for konvensjonelle tog
Train ready message for all trains
«Tog klart»-melding for alle tog
Train ready message
Meldingen «Tog klart»
Train running forecast
Togtrafikkprognose
‘Train running forecast’ message for all trains
Meldingen «Togtrafikkprognose» for alle tog
Train running forecast message
Meldingen «Togtrafikkprognose»
Train running information
Opplysninger om togtrafikk
‘Train running information’ message for all trains
Meldingen «Opplysninger om togtrafikk» for alle tog
Train running interrupted to RU
Avbrutt togtrafikk til jernbaneforetaket
‘Train running interrupted’ message for all trains
Meldingen «Avbrutt togtrafikk» for alle tog
Train running interrupted
Avbrutt togtrafikk
Handling of short term timetable data
Håndtering av kortsiktige ruteplanopplysninger
Common Interface
Felles grensesnitt
Central Repository
Sentralt datalager
Reference Files
Referansefiler
In the light of the Essential Requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:
På bakgrunn av de grunnleggende kravene i kapittel 3 gjelder følgende driftsregler for det delsystemet som omfattes av denne TSI-en:
For the purposes of data quality assurance, the originator of any TSI message will be responsible for the correctness of the data content of the message at the time when the message is sent.
For å sikre datakvaliteten er avsenderen av enhver TSI-melding ansvarlig for at innholdet i meldingen er korrekt på det tidspunkt meldingen sendes.
Where the source data for data quality assurance purposes are available from the databases provided as part of the TSI, the data contained within those databases must be used for data quality assurance.
Dersom kildedataene stammer fra de databasene som utgjør en del av TSI-en, skal dataene i de nevnte databasene benyttes som grunnlag for å kvalitetssikre dataene.
Where the source data for data quality assurance purposes is not supplied by the databases provided as part of this TSI, the originator of the message must carry out the data quality assurance check from their own resources.
Dersom kildedataene ikke stammer fra de databasene som utgjør en del av denne TSI-en, skal avsenderen av meldingen kvalitetssikre dataene ved hjelp av egne ressurser.
Data quality assurance will include comparison with data from databases provided as part of this TSI as described above, plus — where applicable — logic checks to assure the timeliness and continuity of data and messages.
Kvalitetssikringen av dataene skal omfatte sammenligning av dataene med data fra databaser som utgjør en del av denne TSI-en som beskrevet ovenfor, pluss eventuelt logiske kontroller for å sikre rettidighet og kontinuitet i oversendelsen av data og meldinger.
Data are of high quality if they are fit for their intended uses, which means that they:
Dataene er av høy kvalitet dersom de egner seg for den bruken de er ment for, som betyr at de
accessible, accurate, timely, complete, consistent with other sources, etc.,
tilgjengelige, nøyaktige, rettidige, fullstendige, enhetlige i forhold til andre kilder, osv., og
possess the desired features:
har de ønskede egenskaper, dvs. er
The main characteristics of data quality are:
De viktigste kjennetegnene på datakvalitet er:
timeliness.
rettidighet.
Accuracy
Nøyaktighet
This is only feasible if the Primary Data only are recorded, if possible, on one single occasion.
Dette lar seg bare gjøre dersom primærdataene, om mulig, registreres ved én enkelt anledning.
Therefore, the Primary Data should be introduced into the system as close as possible to its source, so that they can be fully integrated into any subsequent processing operation.
Primærdataene bør derfor innføres i systemet så nært opptil kilden som mulig, slik at de kan integreres fullt ut i eventuelle etterfølgende prosesser.
Completeness
Fullstendighet.
Before sending out messages, the completeness and syntax must be checked using the Metadata.
Før meldingene sendes må meldingenes fullstendighet og syntaks kontrolleres mot metadataene.
All incoming messages must also be checked for completeness using the Metadata.
Alle inngående meldinger må også kontrolleres mot metadataene med tanke på fullstendighet.
The type of implementation of these business rules depends on their complexity.
Gjennomføringen av de nevnte forretningsreglene avhenger av hvor sammensatt de er.
In the case of more complex rules, which require data from various tables, validation procedures must be implemented which check the consistency of the data version before interface data are generated and the new data version becomes operational.
I forbindelse med mer kompliserte regler, som krever data fra flere tabeller, må det foretas en validering for å kontrollere at dataversjonen er enhetlig før grensesnittdata genereres og den nye dataversjonen tas i bruk.
It must be ensured that transferred data are validated against the defined business rules.
Det må sikres at de overførte dataene er validert mot de fastsatte forretningsreglene.
Timeliness
Rettidighet
Providing information right on time is important.
Å gi opplysninger til rett tid er viktig.
Insofar as the trigger for data storage or for message sending is event driven directly from the IT system, timeliness is not a problem if the system is designed properly and according the needs of the business processes.
Dersom data lagres eller en melding sendes som en direkte følge av en hendelse i IT-systemet, er rettidighet ikke noe problem, forutsatt at systemet er utformet i henhold til forretningsprosessene.
However, in most cases, the sending of a message is initiated by an operator or is at least based on additional input from an operator.
I de fleste tilfeller tar imidlertid en operatør initiativ til å sende en melding, eller sendingen baseres i det minste på at operatøren registrerer tilleggsopplysninger.
To fulfil the timeliness requirements, the data must be updated as soon as possible, also in order to guarantee that the actual data content of the messages is current when these messages are sent out automatically by the system.
For å oppfylle kravene til rettidighet må dataene oppdateres så snart som mulig, også for å garantere at det faktiske datainnholdet i meldingene fortsatt er aktuelt når disse meldningene sendes ut automatisk av systemet.
The response time for enquiries must be addressed for the various applications and user types within the detailed IT specifications.
Svartiden for forespørsler må fastsettes for de ulike programmene og brukertypene innenfor de detaljerte IT-spesifikasjonene.
All data updates and exchanges shall be carried out as soon as possible.
Alle data må oppdateres og utveksles så raskt som mulig.
The detailed IT specifications shall define appropriate percentages for:
De detaljerte IT-spesifikasjonene skal inneholde hensiktsmessige prosentverdier for:
the completeness of data (percent of data fields having values entered into them) and the consistency of data (percent of matching values across tables/files/records),
fullstendigheten av data (prosent av datafelter med registrerte verdier) og forenligheten av data (prosent av verdier som forekommer i flere tabeller /filer/registre),
the timeliness of data (percent of data available within a specified threshold time frame),
rettidighet av data (prosent av dataene som er tilgjengelige innenfor en nærmere angitt tidsramme),
the required accuracy (percent of stored values that are correct when compared to the actual value).
krav til nøyaktighet (prosent av korrekte lagrede verdier sammenlignet med faktisk verdi).
The functions of the Central Repository are defined in Section 4.2.21.6 Central repository.
Det sentrale datalagerets funksjoner er beskrevet i kapittel 4.2.14.6 (Sentralt datalager).
For the purpose of data quality assurance, the entity operating the Central Repository shall be responsible for the updating and quality of the Metadata and the directory, and also for the administration of the access control.
Den enheten som er ansvarlig for driften av det sentrale datalageret, skal også ha ansvaret for å oppdatere og kvalitetssikre metadataene og katalogen samt for å administrere tilgangskontrollen.
The quality of the Metadata in terms of completeness, consistency, timeliness and accuracy shall enable appropriate functioning for the purposes of this TSI.
Kvaliteten på metadataene med hensyn til fullstendighet, forenlighet, rettidighet og nøyaktighet skal sikre en problemfri gjennomføring innenfor rammen av denne TSI-en.
In the light of the Essential Requirements in Chapter 3, the maintenance rules specific to the subsystem concerned by this TSI are as follows:
På bakgrunn av de grunnleggende kravene i kapittel 3 gjelder følgende vedlikeholdsregler for det delsystemet som omfattes av denne TSI-en:
The quality of the transport service must be guaranteed, even if the data were corrupted or if the data processing equipment were to suffer a complete or partial breakdown.
Kvaliteten på transporttjenesten må garanteres, selv om dataene ble ødelagt, eller dersom databehandlingsutstyret helt eller delvis skulle bryte sammen.