BILAGA

INNEHÅLLSFÖRTECKNING

INLEDNING

443

1.1

Förkortningar

443

1.2

Referensdokument

444

1.3

Tekniskt tillämpningsområde

445

1.4

Geografiskt tillämpningsområde

445

1.5

Innehållet i denna TSD-TAF.

445

DEFINITION AV DELSYSTEMET OCH TILLÄMPNINGSOMRÅDET

446

2.1

Funktion som omfattas av denna TSD

446

2.2

Funktion som inte omfattas av denna TSD

446

2.3

Översiktlig beskrivning av delsystemet

446

2.3.1

Berörda enheter

446

2.3.2

Berörda processer

448

2.3.3

Allmänt

449

VÄSENTLIGA KRAV

450

3.1

Överensstämmelse med de väsentliga kraven

450

3.2

De väsentliga kravens olika aspekter

450

3.3

Aspekter som rör allmänna krav

451

3.3.1

Säkerhet

451

3.3.2

Tillförlitlighet och tillgänglighet

451

3.3.3

Hälsa

451

3.3.4

Miljöskydd

451

3.3.5

Teknisk kompatibilitet

451

3.4

Aspekter som hänför sig till de krav som är specifika för delsystemet Telematikapplikationer för godstrafik

451

3.4.1

Teknisk kompatibilitet

451

3.4.2

Tillförlitlighet och tillgänglighet

451

3.4.3

Hälsa

452

3.4.4

Säkerhet

452

BESKRIVNING AV DELSYSTEMET

452

4.1

Inledning

452

4.2

Delsystemets funktionella och tekniska specifikationer

452

4.2.1

Uppgifter på fraktsedeln

453

4.2.2

Ansökan om tågläge

454

4.2.3

Iordningsställa tåg

455

4.2.4

Tågföringsprognos

456

4.2.5

Information om trafikstörning

457

4.2.6

ETI/ETA för en försändelse

458

4.2.7

Vagnrörelse

459

4.2.8

Rapportering om utväxling

460

4.2.9

Datautväxling för kvalitetsförbättring

461

4.2.10

Viktigaste referensdata

462

4.2.11

Olika referensfiler och databaser

463

4.2.12

Nätverk och kommunikation

466

4.3

Funktionella och tekniska specifikationer för gränssnitten

468

4.3.1

Gränssnitt till TSD Infrastruktur

468

4.3.2

Gränssnitt till delsystemet TSD Trafikstyrning och signalering

468

4.3.3

Gränssnitt till delsystemet Rullande materiel

468

4.3.4

Gränssnitt till delsystemet TSD Drift och Trafikledning

468

4.3.5

Gränssnitt till delsystemet Telematikapplikationer för persontrafik

469

4.4

Driftsregler

469

4.4.1

Uppgifternas kvalitet

469

4.4.2

Driften av den centrala datakatalogen

471

4.5

Underhållsregler

471

4.6

Yrkeskvalifikationer

471

4.7

Hälso- och säkerhetskrav

471

DRIFTSKOMPATIBILITETSKOMPONENTER

471

5.1

Definition

471

5.2

Förteckning över komponenter

471

5.3

Prestanda och specifikationer för komponenterna

472

BEDÖMNING AV KOMPONENTERNAS ÖVERENSSTÄMMELSE OCH/ELLER LÄMPLIGHET OCH KONTROLL AV DELSYSTEMET

472

6.1

Driftskompatibilitetskomponenter

472

6.1.1

Bedömningsförfaranden

472

6.1.2

Modul

472

6.1.3

Delsystemet Telematikapplikationer för godstrafik

472

GENOMFÖRANDE

473

7.1

Metoder för tillämpning av denna TSD

473

7.1.1

Inledning

473

7.1.2

Fas 1 – Detaljerade IT-specifikationer och översiktsplan

473

7.1.3

Fas 2 och 3 – Utveckling och införande

473

7.1.4

Ledning, roller och ansvarsfördelning

473

7.2

Förändringshantering

475

7.2.1

Förändringshanteringsprocess

475

7.2.2

Särskild förändringshanteringsprocess för dokument som förtecknas i tillägg I till denna förordning

475

Tillägg I

Förteckning över tekniska dokument

476

Tillägg II

Ordlista

477

Tillägg III

Uppgifter som ska utföras av den nationella kontaktpunkten för telematikapplikationer för godstrafik/persontrafik

488

1. INLEDNING

1.1 Förkortningar

Tabell 1

Förkortningar

Förkortning	Definition
ANSI	American National Standards Institute
CI	Gemensamt gränssnitt
CR	Begäran om ändring
EC	Europeiska kommissionen
ERA	Europeiska järnvägsbyrån, även kallad byrån
ERTMS	Europeiskt trafikstyrningssystem för tåg
ETCS	European Train Control System
IM	Infrastrukturförvaltare
ISO	International Organization for Standardization (Internationella standardiseringsorganisationen)
LAN	Local Area Network (lokalt nät)
LCL	Less than Container Loads
LRU	Huvudansvarigt järnvägsföretag
ONC	Open Network Computing
OTIF	Mellanstatliga organisationen för internationell järnvägstrafik
PVC	Permanent virtuell förbindelse
RISC	Kommittén för driftskompatibilitet och säkerhet
RU	Järnvägsföretag
TAF	Telematikapplikationer för godstrafik
TAP	Telematikapplikationer för persontrafik
TCP/IP	Transmission Control Protocol/Internet Protocol
TEN	Transeuropeiska nätet
TSD	Tekniska specifikationer för driftskompatibilitet
WK (Wagon Keepers)	Vagninnehavare
WP	Arbetsgrupp som organiseras av Europeiska järnvägsbyrån

1.2 Referensdokument

Tabell 2

Referensdokument

Referensnummer	Dokumenthänvisning	Titel	Senaste versionen utfärdad:
1.	Direktiv 2008/57/EG	Europaparlamentets och rådets direktiv 2008/57/EG av den 17 juni 2008 om driftskompatibiliteten hos järnvägssystemet inom gemenskapen (EUT L 191, 18.7.2008, s. 1).	17.6.2008
2.	Förordning (EU) nr 454/2011 om TAP och TSD	Kommissionens förordning (EU) nr 454/2011 av den 5 maj 2011 om teknisk specifikation för driftskompatibilitet avseende delsystemet ”Telematikapplikationer för persontrafik” i det transeuropeiska järnvägssystemet (EUT L 123, 12.5.2011, s. 11).	5.5.2011
3.	Direktiv 2012/34/EU	Europaparlamentets och rådets direktiv 2012/34/EU av den 21 november 2012 om inrättande av ett gemensamt europeiskt järnvägsområde (EUT L 343, 14.12.2012, s. 32).	21.11.2012
4.	Era-td- 105	TAF TSI – ANNEX D.2: APPENDIX F – TAF TSI DATA AND MESSAGE MODEL	22.3.2013
5.	Förordning (EU) nr 62/2006 om TSD TAF	Kommissionens förordning (EG) nr 62/2006 av den 23 december 2005 om teknisk specifikation för driftskompatibilitet (TSD) avseende delsystemet ”Telematikapplikationer för godstrafik” i det transeuropeiska järnvägssystemet för konventionella tåg (EUT L 13, 18.1.2006, s. 1).	18.1.2006
6.	Kommissionens förordning (EU) nr 280/2013	Kommissionens förordning (EU) nr 280/2013 av den 22 mars 2013 om ändring av förordning (EG) nr 62/2006 om teknisk specifikation för driftskompatibilitet (TSD) avseende delsystemet ”Telematikapplikationer för godstrafik” i det transeuropeiska järnvägssystemet för konventionella tåg (EUT L 84, 23.3.2013, s. 17).	22.3.2013
7.	Kommissionens förordning (EU) nr 328/2012	Kommissionens förordning (EU) nr 328/2012 av den 17 april 2012 om ändring av förordning (EG) nr 62/2006 om teknisk specifikation för driftskompatibilitet (TSD) avseende delsystemet ”Telematikapplikationer för godstrafik” i det transeuropeiska järnvägssystemet för konventionella tåg (EUT L 106, 18.4.2012, s. 14).	17.4.2012
8.	K(2010) 2576 slutlig.	Kommissionens beslut av den 29 april 2010 avseende ett mandat till Europeiska järnvägsbyrån att vidareutveckla och se över de tekniska specifikationerna för driftskompatibilitet för att utöka deras tillämpningsområde till hela järnvägssystemet i unionen	29.4.2010
9.	Direktiv 2004/49/EG	Europaparlamentets och rådets direktiv 2004/49/EG av den 29 april 2004 om säkerhet på gemenskapens järnvägar och om ändring av rådets direktiv 95/18/EG om tillstånd för järnvägsföretag och direktiv 2001/14/EG om tilldelning av infrastrukturkapacitet, uttag av avgifter för utnyttjande av järnvägsinfrastruktur och utfärdande av säkerhetsintyg (järnvägssäkerhetsdirektivet) (EUT L 164, 30.4.2004, s. 44).	28.11.2009
10.	Direktiv 2001/13/EG	Europaparlamentets och rådets direktiv 2001/13/EG av den 26 februari 2001 om ändring av rådets direktiv 95/18/EG om tillstånd för järnvägsföretag (EGT L 75, 15.3.2001, s. 26).	26.2.2001

1.3 Tekniskt tillämpningsområde

Denna tekniska specifikation för driftskompatibilitet (nedan kallad TSD TAF) rör delen ”applikationer för godstrafik” i delsystemet Telematikapplikationer som inbegrips i det funktionellt definierade området i förteckningen i bilaga II till direktiv 2008/57/EG[1].

Denna TSD TAF syftar till att säkerställa en effektiv informationsutväxling genom att de tekniska ramarna fastställs för att uppnå en transportprocess som är så ekonomiskt bärkraftig som möjligt. Den omfattar applikationer för godstrafik och anslutningssamordning med andra transportsätt, vilket innebär att den är inriktad på de transporttjänster ett järnvägsföretag utför, utöver den rena tågdriften. Säkerhetsaspekterna beaktas bara i den mån som det finns vissa uppgifter. Värdena kommer inte att påverka den säkra driften av ett tåg och överensstämmelse med kraven enligt TSD TAF kan inte betraktas som överensstämmelse med säkerhetskrav.

TSD TAF påverkar också villkoren för alla användare av järnvägstransporter. I detta sammanhang avses med begreppet användare inte bara infrastrukturförvaltare och järnvägsföretag, utan även alla andra tjänsteleverantörer såsom vagnägare, operatörer för intermodala transporter och även kunder.

Det tekniska tillämpningsområdet för denna TSD definieras närmare i artikel 2.1 och 2.3 i denna förordning.

1.4 Geografiskt tillämpningsområde

Det geografiska tillämpningsområdet för denna TSD är järnvägsnätet i hela järnvägssystemet, som består av följande delar:

—	Järnvägsnätet för det transeuropeiska järnvägssystemet för konventionell trafik (TEN), så som det beskrivs i punkt 1.1 ”Järnvägsnät” i bilaga I till direktiv 2008/57/EG[1].

—	Järnvägsnätet för det transeuropeiska järnvägssystemet för höghastighetstrafik (TEN), så som det beskrivs i punkt 2.1 ”Järnvägsnät” i bilaga I till direktiv 2008/57/EG[1].

—	Andra delar av järnvägsnätet för hela järnvägssystemet, efter utvidgningen av tillämpningsområdet i enlighet med punkt 4 i bilaga I till direktiv 2008/57/EG[1].

De fall som avses i artikel 1.3 i direktiv 2008/57/EG[1] är undantagna från tillämpningsområdet.

1.5 Innehållet i denna TSD TAF

Innehållet i denna TSD TAF är utformat i enlighet med artikel 5 i direktiv 2008/57/EG[1].

Denna TSD innehåller också, i kapitel 4 (Beskrivning av delsystemet), de särskilda drifts- och underhållskrav som gäller för det tillämpningsområde som anges i punkterna 1.1 (Tekniskt tillämpningsområde) och 1.2 (Geografiskt tillämpningsområde).

2. DEFINITION AV DELSYSTEMET OCH TILLÄMPNINGSOMRÅDET

2.1 Funktion som omfattas av denna TSD

Delsystemet Telematikapplikationer för godstrafik definieras i avsnitt 2.5 b i bilaga II till direktiv 2008/57/EEG[1].

Det inbegriper bland annat

—	applikationer för godstrafik, bl.a. informationssystem (övervakning i realtid av gods och tåg),

—	ranger- och tilldelningssystem, där man med tilldelningssystem avser system för tågsammansättning,

—	reserveringssystem, vilket här avser system för reservering av tåglägen,

—	anslutningssamordning med andra transportsätt samt utfärdande av elektroniska följedokument.

2.2 Funktioner som inte omfattas av denna TSD

Denna TSD omfattar inte betalnings- och faktureringssystem för kunder, och inte heller betalnings- och faktureringssystem mellan olika tjänsteleverantörer såsom järnvägsföretag eller infrastrukturförvaltare. Genom den systemkonstruktion som ligger till grund för datautväxlingen i enlighet med kapitel 4.2 (Funktionella och tekniska specifikationer för delsystemet), kan man dock alltid få fram den information som krävs som underlag för betalning av transporttjänsterna.

Långsiktig tidtabellsplanering omfattas inte heller av denna TSD för telematikapplikationer. I vissa sammanhang kommer hänvisningar ändå att göras till den långsiktiga planeringen, i den mån det finns ett samband mellan långsiktig planering och en effektiv utväxling av sådan information som krävs för tågdriften.

2.3 Översiktlig beskrivning av delsystemet

2.3.1 Berörda enheter

Denna TSD omfattar befintliga tjänsteleverantörer och olika potentiella framtida tjänsteleverantörer som är involverade i godstransport genom att de tillhandahåller något av följande (listan är inte uttömmande):

—	Godsvagnar

—

Lok

—

Lokförare

—	Växling och vallväxling

—	Tilldelning av tåglägen

—	Godshantering

—	Tågsammansättning

—

Tågdrift

—	Tågövervakning

—	Tågledning.

—	Godsövervakning

—	Kontroll och underhåll av vagnar och/eller lok

—	Tullklarering

—	Drift av intermodala terminaler

—	Åkerinäring

Vissa tjänsteleverantörer definieras uttryckligen i direktiven 2012/34/EU[3], 2008/57/EG[1] och 2004/49/EC[9]. Eftersom hänsyn måste tas till båda dessa direktiv, beaktas i denna TSD särskilt följande definitioner:

infrastrukturförvaltare (IM) (Direktiv 2012/34/EU[3]) : varje organ eller företag som särskilt ansvarar för att anlägga, förvalta och underhålla järnvägsinfrastruktur, inklusive trafikledning, trafikstyrning och signalering. Infrastrukturförvaltarens uppgifter med avseende på järnvägsnät eller del av ett järnvägsnät får tilldelas olika organ eller företag. Om infrastrukturförvaltaren inte är oberoende i förhållande till samtliga järnvägsföretag, till sin juridiska form och med avseende på organisation eller beslutsfattande, ska de uppgifter som avses i avsnitten 2 och 3 i kapitel IV utföras av ett avgiftsorgan respektive av ett tilldelningsorgan som är oberoende i förhållande till samtliga järnvägsföretag till sin juridiska form och med avseende på organisation och beslutsfattande.

Med utgångspunkt från denna definition, berör denna TSD en IM i egenskap av tjänsteleverantör i fråga om tilldelning av tåglägen, tågledning och tågövervakning samt tåg- och tåglägesrelaterad rapportering.

sökande (direktiv 2012/34/EU[3]) : ett järnvägsföretag eller en internationell sammanslutning av järnvägsföretag eller andra fysiska eller juridiska personer, såsom till exempel behöriga myndigheter enligt förordning (EG) nr 1370/2007 och befraktare, speditörer samt operatörer för kombinerade transporter, som har ett allmännyttigt eller kommersiellt intresse av att ansöka om infrastrukturkapacitet.

järnvägsföretag (direktiv 2004/49/EG[3]) : järnvägsföretag enligt definitionen i direktiv 2001/14/EG, samt andra offentliga eller privata företag vars verksamhet består i att tillhandahålla gods- och/eller persontrafik på järnväg med krav på att företaget ska sörja för traktion (dragkraft); här innefattas även företag som endast tillhandahåller traktion.

Med utgångspunkt från denna definition berör denna TSD RU i egenskap av tjänsteleverantör i fråga om tågdrift.

När det gäller tilldelning av ett tågläge för framförande av ett tåg måste även artikel 38 i direktiv 2012/34/EU[3] beaktas:

Infrastrukturkapacitet ska tilldelas av en infrastrukturförvaltare. Infrastrukturkapacitet som tilldelats en sökande får av mottagaren inte överlåtas till ett annat företag eller för en annan verksamhet.

Varje transaktion som rör infrastrukturkapaciteten ska vara förbjuden och ska medföra uteslutning från ytterligare tilldelning av kapacitet.

När ett järnvägsföretag utnyttjar kapacitet för att utföra tjänster för en sökande som inte är ett järnvägsföretag ska detta inte anses som en överlåtelse.

När det gäller scenarierna för kommunikation mellan infrastrukturförvaltare och sökande i det operativa skedet av en transport, är det endast IM och RU som behöver beaktas och inte alla typer av sökande, vilka däremot kan vara relevanta i planeringsfasen. I det operativa skedet finns alltid ett givet IM–RU-förhållande, för vilket reglerna för utväxling av meddelanden och lagring av information specificeras i denna TSD. Definitionen av en sökande och de därav följande möjligheterna vad gäller tilldelning av infrastrukturkapacitet påverkas inte av detta.

En rad olika typer av tjänster måste tillhandahållas i samband med en godstransport. Ett exempel är tillhandahållandet av vagnar. Denna tjänst kan hänföras till en vagnparksförvaltare. Om denna tjänst är en av de tjänster som RU tillhandahåller för en transport, fungerar RU också som vagnparksförvaltare. En vagnparksförvaltare kan i sin tur förvalta sina egna vagnar och/eller vagnar från andra innehavare (en annan tjänsteleverantör för godsvagnar). Behovet av denna tjänsteleverantör beaktas oavsett om det rättssubjekt som agerar vagnparksförvaltare är en RU eller inte.

Denna TSD innebär inte att några nya rättssubjekt skapas och den tvingar inte RU att anlita externa tjänsteleverantörer för sådana tjänster som de själva kan erbjuda. Däremot benämns, i de fall det anses nödvändigt, en viss tjänst med hjälp av benämningen på motsvarande tjänsteleverantör. Om tjänsten tillhandahålls av en RU, fungerar RU som tjänsteleverantör för den tjänsten.

Med kundens behov i åtanke, är en av tjänsterna att organisera och hantera transportkedjan i enlighet med det åtagande som gjorts gentemot kunden. Denna tjänst tillhandahålls av det huvudansvariga järnvägsföretaget (Lead RU eller LRU). LRU är kundens enda kontaktpunkt. Om mer än ett järnvägsföretag ingår i transportkedjan, ansvarar LRU också för samordningen med övriga järnvägsföretag.

Denna tjänst kan också tillhandahållas av en speditör eller av någon annan fysisk eller juridisk person.

En RU: s roll som LRU kan se olika ut från ett transportflöde till ett annat. I samband med intermodala transporter sköts styrningen av kapaciteten i heltåg och utfärdandet av speditörsfraktsedlar av en samordnare för intermodala transporter, som kan vara kund till LRU.

Det viktiga är, hur som helst, att RU och IM liksom alla andra tjänsteleverantörer (i den mening som avses i denna bilaga) måste samverka, genom samarbete och/eller öppen tillgång, men också genom en effektiv utväxling av information, för att tillhandahålla sömlösa tjänster till kunden.

2.3.2 Berörda processer

Denna TSD för industrin för godstransport med järnväg, begränsas i enlighet med direktiv 2008/57/EG[1] till IM och RU/LRU med hänvisning till deras direkta kunder. Enligt avtal ska LRU lämna information till kunden, särskilt följande:

—	Tåglägesinformation.

—	Tågföringsinformation vid avtalade rapporteringspunkter, inbegripet åtminstone den avtalade transportens utgångs-, utväxlings-/överlämnings- och ankomstpunkter.

—	Beräknad ankomsttid (ETA) till slutdestinationen inbegripet bangårdar och intermodala terminaler.

—	Trafikstörningar. Då LRU får kännedom om en trafikstörning, ska den informera kunden om detta i god tid.

För tillhandahållandet av denna information fastställs särskilda TAF-meddelanden i kapitel 4.

Vid utförandet av en godstransport börjar LRU: s verksamhet, när det gäller en försändelse, med mottagandet av en fraktsedel från kunden och, när det gäller till exempel vagnslaster, vid tiden för frisläppande av vagnarna. LRU upprättar en preliminär färdplan (med utgångspunkt från erfarenhet och/eller avtal) för transporten. Om LRU avser att placera vagnslasten i ett tåg i en situation med öppen tillgång (LRU ansvarar för driften av tåget under hela färden), är den preliminära färdplanen också den slutliga. Om LRU avser att placera vagnslasten i ett tåg som omfattas av samarbete med andra RU, måste LRU först ta reda på vilka RU som ska kontaktas och vid vilken tidpunkt utväxlingen från en RU till en annan kan ske. LRU upprättar sedan preliminära fraktorder, för var och en av de berörda RU, vilka utgör delar av den fullständiga fraktsedeln. Fraktorderna beskrivs närmare i kapitel 4.2.1 (Uppgifter på fraktsedeln).

De RU som kontaktats kontrollerar tillgången till resurser för drift av vagnarna och tillgängliga tåglägen. Med utgångspunkt från svaren från de olika RU kan LRU sedan justera färdplanen eller gå ut med nya förfrågningar – eventuellt även till andra RU – till dess att en färdplan som svarar mot kundens krav slutligen kan fastställas.

Alla RU/LRU måste i allmänhet, åtminstone, ha kapacitet att

—	DEFINIERA tjänster i fråga om pris och transiteringstider, tillgång till vagnar (om tillämpligt), information om vagnar/intermodala enheter (position, status och beräknad ankomsttid ”ETA” för vagnar/intermodala enheter), var försändelser kan lastas på tomma vagnar, containrar etc.,

—	TILLHANDAHÅLLA den tjänst som definierats, på ett tillförlitligt och sömlöst sätt med hjälp av gemensamma affärsprocesser och sammanlänkade system; RU, IM och andra tjänsteleverantörer och intressenter såsom tullen måste ha möjlighet att utbyta information elektroniskt,

—	MÄTA kvaliteten på den tillhandahållna tjänsten i förhållande till vad som definierats, dvs. överensstämmelsen mellan fakturerat belopp och offererat pris, mellan faktiska transiteringstider och åtaganden, mellan beställda vagnar och tillhandahållna vagnar samt mellan ETA och faktiska ankomsttider,

—	VERKA på ett produktivt sätt för att på bästa sätt utnyttja tåg-, infrastruktur- och vagnkapacitet, genom användning av de affärsprocesser, de system och den datautväxling som krävs för att stödja tidtabellsplaneringen för vagnar/intermodala enheter och tåg.

RU/LRU måste också i egenskap av sökande (genom avtal med IM) tillhandahålla det tågläge som krävs, och inom sin delsträcka ansvara för tåguppdragets utförande. När det gäller tågläget kan de använda redan bokade tåglägen (i planeringsfasen) eller också ansöka om ett ad hoc-tågläge från den eller de infrastrukturförvaltare (IM) som ansvarar för den eller de delsträckor på vilka RU skall framföra tåget. I tillägg I ges exempel på ett scenario för ansökan om tågläge.

Innehavet av tågläge har också betydelse för kommunikationen mellan IM och RU under tågets framförande. Kommunikationen måste alltid baseras på tågupdrags- och tåglägesidentiteter, med vars hjälp IM kommunicerar med den RU som tilldelats tågläget på IM: s infrastruktur (se även tillägg I).

Om en RU står för hela färden A – F (RU har öppen tillgång, inga andra RU är involverade) kommunicerar varje berörd IM direkt med denna enda RU. Sådan ”öppen tillgång” för RU kan åstadkommas genom att tågläget bokas i sin helhet via ”One stop shop” (OSS) eller i sektioner genom direktkommunikation med varje IM. TSD tar hänsyn till båda dessa fall, vilket framgår av kapitel 4.2.2.1: Ansökan om tågläge, Inledande anmärkningar.

Dialogprocessen mellan RU och IM för att fastställa ett tågläge för ett godståg beskrivs i kapitel 4.2.2 (Ansökan om tågläge). Denna funktion hänför sig till artikel 48.1 i direktiv 2012/34/EU[3]. Denna dialogprocess omfattar inte utfärdandet av tillstånd för RU som tillhandahåller tjänster i enlighet med direktiv 2001/13/EG[10], utfärdandet av säkerhetsintyg enligt direktiv 2012/34/EU[3] eller rätt till tillgång till infrastruktur enligt rådets direktiv 2012/34/EU[3].

I kapitel 4.2.3 (Iordningställande av tåg) beskrivs informationsutväxlingen med avseende på tågsammansättning och avgångsprocedur. Datautväxlingen under framförandet av ett tåg vid normal drift beskrivs i kapitel 4.2.4 (Tågföringsprognos) och meddelanden för undantagsfall beskrivs i kapitel 4.2.5 (Information om trafikstörning). Alla dessa meddelanden utbyts mellan RU och IM och refererar till tåg.

För en kund är den viktigaste informationen den beräknade ankomsttiden (ETA) för försändelsen. Utifrån informationsutväxlingen mellan LRU och IM (vid öppen tillgång) kan en ETA beräknas. Vid samarbete mellan flera RU, kan ETA och även de beräknade tiderna för utväxling (ETI) bestämmas utifrån utväxlingen av meddelanden mellan RU och IM och meddelas till LRU av de olika RU (kapitel 4.2.6 ETI/ETA för en försändelse).

Det är också på grundval av informationsutväxlingen mellan IM och RU som LRU får kännedom om till exempel

—	när vagnarna avgick ifrån eller ankom till en bangård eller en viss bestämd position (kapitel 4.2.7 Vagnrörelse) eller

—	när ansvaret för vagnarna överfördes från en RU till nästa RU i transportkedjan (kapitel 4.2.8 Rapportering om utväxling).

På grundval av datautväxlingen inte bara mellan IM och RU utan också mellan de olika RU och LRU, kan olika typer av statistik beräknas

—	för att man – på medellång sikt – ska kunna planera produktionsprocessen mer i detalj och

—	för att man – på lång sikt – ska kunna genomföra strategiska planeringsövningar och kapacitetsstudier (t.ex. analyser av nätet, beskrivningar av uppställnings- och rangerbangårdar och planering med avseende på rullande materiel), men framför allt

—	för att man skall kunna förbättra kvaliteten på transporttjänsterna och öka produktiviteten (kapitel 4.2.9 Datautväxling för kvalitetsförbättring).

Hanteringen av tomma vagnar är av särskild betydelse när det gäller driftskompatibla vagnar. I princip är det ingen skillnad mellan hanteringen av lastade och tomma vagnar. Transporten av tomma vagnar baseras också på fraktorder, varvid de tomma vagnarnas vagnparksförvaltare ses som en kund.

2.3.3 Allmänt

Ett informationssystem är aldrig bättre än tillförlitligheten hos de data som systemet innehåller. Därför måste de data som har avgörande betydelse för en försändelses, en vagns eller en containers befordran vara korrekta och samlas in på ett ekonomiskt sätt – vilket innebär att de ska föras in i systemet bara en gång.

Mot denna bakgrund, undviks i applikationerna och meddelandena i denna TSD att data måste föras in flera gånger manuellt, genom att tillgång ges till redan lagrade data såsom referensdata om rullande materiel. Kraven på referensdata för rullande materiel anges i kapitel 4.2.10 (Viktigaste referensdata). De angivna referensdatabaserna för rullande materiel måste ge enkel tillgång till tekniska data. Innehållet i databaserna måste vara tillgängligt, enligt en struktur för tillträdesrätt som bygger på fastställda rättigheter, för alla IM, RU och vagnparksförvaltare, särskilt för sådana syften som vagnparksförvaltning och underhåll av rullande materiel. De måste innehålla alla tekniska data som är kritiska för transporten, såsom

—	identifiering av den rullande materielen,

—	tekniska data/konstruktionsdata,

—	bedömning av kompatibiliteten med infrastrukturen,

—	bedömning av relevanta lastningsegenskaper,

—	bromsegenskaper,

—	underhållsdata, och

—	miljöegenskaper.

När det gäller intermodala transporter finns det olika punkter (omlastningsplatser) där inte bara vagnar kan kopplas till ett annat tåg, utan intermodala enheter kan också föras över från en vagn till en annan. Därför räcker det inte att arbeta med en färdplan för vagnar, utan det krävs också att en färdplan upprättas för de intermodala enheterna.

I kapitel 4.2.11 (Olika referensfiler) finns en förteckning över vissa referensfiler och olika databaser, bland annat driftdatabasen för godsvagnar och intermodala enheter. Denna databas innehåller data angående driftstatus för den rullande materielen, viktangivelser och information om farligt gods, information om intermodala enheter och positionsangivelser.

I TSD för delsystemet Telematikapplikationer för godstrafik definieras den information som måste utbytas mellan de olika parter som ingår i en transportkedja, vilket gör att ett standardiserat förfarande för obligatorisk datautväxling kan inrättas. I TSD beskrivs också arkitekturstrategin för en sådan kommunikationsplattform. Detta skisseras i kapitel 4.2.12 (Nätverk och kommunikation), med hänsyn tagen till

—	gränssnittet till delsystemet Drift och trafikledning som avses i artikel 5.3 i direktiv 2008/57/EG[1],

—	kraven angående innehållet i järnvägsnätsbeskrivningen, vilka anges i direktiv 2012/34/EG[3], artikel 27 och bilaga IV,

—	tillgänglig information om rullande materiel för godstransport och underhållskraven i TSD Rullande materiel.

Det finns ingen direkt överföring av data från delsystemet Telematikapplikationer för godstrafik till tåget, till föraren eller till några delar av delsystemet Trafikstyrning och signalering, och det fysiska överföringsnätet är helt skilt från det nät som används av delsystemet Trafikstyrning och signalering. ERTMS/ETCS-systemet använder GSM-R. I specifikationerna för ETCS klargörs att säkerhet i detta öppna nät uppnås genom korrekt hantering av riskerna med öppna nät enligt EURORADIO-protokollet.

Gränssnitt till de strukturella delsystemen Rullande materiel och Trafikstyrning finns endast inom ramen för de referensdatabaser för rullande materiel (kapitel 4.2.10.2: Referensdatabaserna för rullande materiel) som kontrolleras av innehavarna. Gränssnitten till delsystemen Infrastruktur, Trafikstyrning och Energi berörs i sammanhanget fastställande av tågläge (kapitel 4.2.2.3: Meddelandet Specifikation av tågläge) från IM: s sida, där infrastrukturrelaterade värden för tåget anges, och i samband med IM: s tillhandahållande av information angående begränsningar i infrastrukturen (kapitel 4.2.2: Ansökan om tågläge och kapitel 4.2.3 Iordningställande av tåg).

3. VÄSENTLIGA KRAV

3.1 Överensstämmelse med de väsentliga kraven

Enligt artikel 4.1 i direktiv 2008/57/EG[1] ska det transeuropeiska järnvägssystemet, dess delsystem och driftskompatibilitetskomponenter uppfylla de väsentliga krav som i allmänna ordalag definieras i bilaga III till det direktivet.

Enligt denna TSD uppfylls de relevanta väsentliga kraven för detta delsystem, vilka anges i kapitel 3, genom överensstämmelse med de specifikationer som beskrivs i kapitel 4: Beskrivning av delsystemet.

3.2 De väsentliga kravens olika aspekter

De väsentliga kraven avser

—

säkerhet,

—	tillförlitlighet och tillgänglighet,

—

hälsa,

—	miljöskydd, och

—	Teknisk kompatibilitet

De väsentliga kraven kan enligt direktiv 2008/57/EG[1] vara generellt tillämpliga på hela det europeiska järnvägssystemet, eller specifika för varje delsystem och dess komponenter.

3.3 Aspekter som rör allmänna krav

De allmänna kravens relevans för delsystemet Telematikapplikationer för godstrafik kan beskrivas som följer:

3.3.1 Säkerhet

De väsentliga kraven 1.1.1, 1.1.2, 1.1.3, 1.1.4 och 1.1.5 i bilaga III till direktiv 2008/57/EG[1] är inte relevanta för delsystemet Telematikapplikationer.

3.3.2 Tillförlitlighet och tillgänglighet

”Övervakning och underhåll av fasta eller rörliga delar som ingår i tågtrafiken ska organiseras och utföras på ett sådant sätt och i sådan omfattning att komponenternas funktionsduglighet bibehålls under angivna förhållanden.”

Hur detta väsentliga krav uppfylls beskrivs i följande kapitel:

—	Kapitel 4.2.10: Viktigaste referensdata.

—	Kapitel 4.2.11: Olika referensfiler och databaser.

—	Kapitel 4.2.12: Nätverk och kommunikation.

3.3.3 Hälsa

De väsentliga kraven 1.3.1 och 1.3.2 i bilaga III till direktiv 2008/57/EG[1] är inte relevanta för delsystemet Telematikapplikationer.

3.3.4 Miljöskydd

De väsentliga kraven 1.4.1, 1.4.2, 1.4.3, 1.4.4 och 1.4.5 i bilaga III till direktiv 2008/57/EG[1] är inte relevanta för delsystemet Telematikapplikationer.

3.3.5 Teknisk kompatibilitet

Det väsentliga kravet 1.5 i bilaga III till direktiv 2008/57/EG[1] är inte relevant för delsystemet Telematikapplikationer.

3.4 Aspekter som hänför sig till de krav som är specifika för delsystemet Telematikapplikationer för godstrafik

3.4.1 Teknisk kompatibilitet

Väsentligt krav 2.7.1 i bilaga III till direktiv 2008/57/EG[1]:

”De väsentliga kraven för telematikapplikationer ska garantera resande och godskunder en lägsta servicenivå, särskilt avseende den tekniska kompatibiliteten.

När det gäller dessa applikationer måste följande uppnås:

—	Databaser, programvara och dataöverföringsprotokoll ska utarbetas för största möjliga datautbyte mellan de olika applikationerna och mellan operatörerna, men utbytet ska inte omfatta konfidentiella handelsdata.

—	Användarna måste enkelt kunna få tillgång till information.”

Hur detta väsentliga krav uppfylls beskrivs i följande kapitel:

—	Kapitel 4.2.10: Viktigaste referensdata.

—	Kapitel 4.2.11: Olika referensfiler och databaser.

—	Kapitel 4.2.12: Nätverk och kommunikation.

3.4.2 Tillförlitlighet och tillgänglighet

Väsentligt krav 2.7.2 i bilaga III till direktiv 2008/57/EG[1]:

”Användning, handhavande, uppdatering och underhåll av databaserna, programvaran och dataöverföringsprotokollen måste garantera högsta möjliga effektivitet och kvalitet.”

Hur detta väsentliga krav uppfylls beskrivs i följande kapitel:

—	Kapitel 4.2.10: Viktigaste referensdata.

—	Kapitel 4.2.11: Olika referensfiler och databaser.

—	Kapitel 4.2.12: Nätverk och kommunikation.

Detta väsentliga krav, och särskilt kravet på att användningen ska ske på ett sätt som garanterar effektiviteten i telematikapplikationerna och kvaliteten på tjänsterna, ligger till grund för hela denna TSD och är inte begränsat till kapitel 4.2.10, 4.2.11 och 4.2.12.

3.4.3 Hälsa

Väsentligt krav 2.7.3 i bilaga III till direktiv 2008/57/EG[1]:

”Gränssnitten mellan systemen och användarna ska följa minimireglerna för ergonomi och hälsoskydd.”

I denna TSD anges inga ytterligare krav utöver befintliga nationella och europeiska bestämmelser om minimiregler för ergonomi och hälsoskydd när det gäller gränssnittet mellan dessa telematikapplikationer och användarna.

3.4.4 Säkerhet

Väsentligt krav 2.7.4 i bilaga III till direktiv 2008/57/EG[1]:

”Integritet och tillförlitlighet ska ligga på en tillräckligt hög nivå när det gäller lagring eller överföring av information som har samband med säkerheten.”

Hur detta väsentliga krav uppfylls beskrivs i följande kapitel:

—	Kapitel 4.2.10: Viktigaste referensdata.

—	Kapitel 4.2.11: Olika referensfiler och databaser.

—	Kapitel 4.2.12: Nätverk och kommunikation.

4. BESKRIVNING AV DELSYSTEMET

4.1 Inledning

Järnvägssystemet, som omfattas av direktiv 2008/57/EG och där delsystemet Telematikapplikationer utgör en del, är ett integrerat system vars enhetlighet måste kontrolleras. Enhetligheten måste kontrolleras särskilt med avseende på specifikationerna för delsystemet, dess gränssnitt mot det system det ingår i och reglerna för drift och underhåll.

Med beaktande av alla tillämpliga väsentliga krav, kan delsystemet Telematikapplikationer för godstrafik beskrivas enligt följande:

4.2 Delsystemets funktionella och tekniska specifikationer

Mot bakgrund av de väsentliga kraven i kapitel 3 (Väsentliga krav) inbegriper de funktionella och tekniska specifikationerna för delsystemet följande parametrar:

—	Uppgifter på fraktsedeln,

—	ansökan om tågläge,

—	iordningställande av tåg,

—	tågföringsprognos,

—	information om trafikstörning,

—	ETI/ETA för vagn/intermodal enhet,

—	vagnrörelse,

—	rapportering om utväxling,

—	datautväxling för kvalitetsförbättring,

—	viktigaste referensdata,

—	olika referensfiler och databaser och

—	nätverk och kommunikation.

De detaljerade dataspecifikationerna fastställs i den fullständiga datakatalogen. Den obligatoriska formaten för meddelanden och uppgifter i denna katalog fastställs i tillägg I, TSD TAF – Bilaga D.2: Andra befintliga standarder får dessutom användas för samma ändamål om de inblandade parterna har ett särskilt avtal om att tillåta användningen av dessa standarder, i synnerhet för EU-medlemsstater som gränsar till tredje land.

Allmänna anmärkningar om meddelandestrukturen

Meddelandena är till sin struktur uppdelade i två uppsättningar data:

— Kontrolldata: fastställs genom en obligatorisk meddelanderubrik för meddelanden i katalogen.

— Informationsdata: fastställs genom det obligatoriska/frivilliga innehållet i varje meddelande och den obligatoriska/frivilliga datauppsättningen i katalogen.

Om ett meddelande eller ett dataelement fastställs som frivilligt enligt denna förordning, bestämmer de berörda parterna om det ska användas eller inte. Tillämpningen av dessa meddelanden och dataelement ska omfattas av ett avtal. Om det i datakatalogen finns frivilliga element som under särskilda förhållanden är obligatoriska måste detta anges i datakatalogen.

4.2.1 Uppgifter på fraktsedeln

4.2.1.1 Kundens fraktsedel

Kunden ska sända en fraktsedel till LRU. Fraktsedeln ska innehålla alla uppgifter som behövs för att frakta en försändelse från avsändaren till mottagaren enligt Enhetliga rättsregler för avtal om internationell järnvägsbefordran av gods (CIM), Enhetliga rättsregler för användningsavtal för fordon i internationell järnvägstrafik (CUV) och gällande nationella bestämmelser. LRU ska tillhandahålla tilläggsinformation. En del av fraktsedeln, inklusive de extra uppgifter som anges i tillägg I, TSD TAF – Bilaga D. 2: Tillägg A (vagn/ILU färdplanering) och tillägg I, TSD TAF – Bilaga D. 2: Tillägg F – TSD TAF data och meddelandemodell [4]) som anges i tabellen i bilaga I till denna förordning.

Vid öppen tillgång har den LRU som kontrakteras av kunden all information efter att ha kompletterat de tillgängliga uppgifterna. Det krävs ingen utväxling av meddelanden med andra RU. Dessa uppgifter utgör också grunden för en ansökan om tågläge i korttidstilldelningsprocessen, om så krävs för att expediera fraktsedeln.

Följande meddelanden används när öppen tillgång inte föreligger. Innehållet i dessa meddelanden kan också utgöra grunden för ansökan om tågläge i korttidstilldelningsprocessen, om så krävs för att expediera fraktsedeln.

4.2.1.2 Fraktorder

Fraktordern är i huvudsak en delmängd av informationen på fraktsedeln. Den måste sändas vidare av LRU till de RU som ingår i transportkedjan. Av innehållet i fraktordern måste den relevanta information framgå som behövs för att en RU ska kunna sköta transporten på den sträcka den ansvarar för, till dess att överlämnande sker till nästa RU. Därför är innehållet beroende av den roll som RU har: ursprungs-, transit- eller leverans-RU.

Den obligatoriska uppgiftsstrukturen för fraktordern och de detaljerade formaten för detta meddelande förtecknas i ”fraktordermeddelande” i dokument ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

Huvudinnehållet i vagnorderna är följande:

—	Uppgifter om avsändare och mottagare

—	Dirigeringsinformation

—	Identifiering av försändelsen

—	Vagnsinformation

—	Uppgift om tid och plats.

Vissa uppgifter på fraktsedeln måste också vara tillgängliga för alla parter (t.ex. IM, vagninnehavare…) som ingår i transportkedjan, även kunder. Dessa uppgifter är för varje vagn följande:

—	Lastvikt (lastens bruttovikt)

—	KN/HS-nummer

—	Uppgifter om farligt gods

—	Transportenhet.

I undantagsfall kan pappersversion användas om informationen inte kan lämnas med hjälp av de meddelanden som anges ovan.

4.2.2 Ansökan om tågläge

4.2.2.1 Inledande anmärkningar

Tågläget definierar de begärda, godkända och faktiska uppgifter som ska lagras om ett tågläge och egenskaperna hos tåget för varje del av detta tågläge. I följande beskrivning anges vilka uppgifter som måste finnas tillgängliga för IM. Dessa uppgifter måste uppdateras så snart en ändring sker. Informationen i det årliga tågläget måste därför göra det möjligt att hämta uppgifter för kortfristiga ändringar. Framförallt måste kunden, om denne påverkas, informeras av LRU.

Ansökan om tågläge i korttidstilldelningsprocessen

På grund av oförutsedda händelser under tågets färd eller på grund av transportbehov med kort varsel, ska RU ha möjlighet att tilldelas ett ad hoc-tågläge i järnvägsnätet.

I det första fallet måste omedelbara åtgärder vidtas, varvid tågets faktiska sammansättning är känd med utgångspunkt från beskrivningen av tågsammansättningen.

I det andra fallet måste RU tillhandahålla IM alla nödvändiga uppgifter om när och var tåguppdraget behöver utföras, tillsammans med uppgifter om tågets fysiska egenskaper i den mån de har betydelse för samverkan med infrastrukturen.

Den grundläggande parametern ”Ansökningar om tågläge i korttidstilldelningsprocessen” bör hanteras mellan RU och IM. I denna grundparameter kan begreppet IM hänvisa till flera IM och i förekommande fall till tilldelningsorgan (se direktiv 2012/34/EU [3]).

Dessa krav gäller för alla ansökningar om tågläge i korttidstilldelningsprocessen.

Frågor angående trafikledning ingår inte i denna grundparameter. Tidsfristen mellan ändringar av tåglägen i korttidstilldelningsprocessen och tåglägen anordnade av trafikledningen omfattas av lokala överenskommelser.

RU måste tillhandahålla IM alla nödvändiga uppgifter om när och var tåget behöver framföras, tillsammans med uppgifter om tågets fysiska egenskaper i den mån de har betydelse för samverkan med infrastrukturen.

Varje IM är ansvarig för lämpligheten hos ett tågläge på den egna infrastrukturen och RU är skyldigt att kontrollera tågets egenskaper mot de värden som anges i specifikationen för det avtalade tågläget.

Utan att det påverkar villkoren för användningen av ett tågläge i järnvägsnätsbeskrivningarna, eller skyldigheterna vid eventuella infrastrukturbegränsningar som förklaras i TSD Drift och trafikledning, måste RU före iordningställandet av tåget få veta om det finns några begränsningar på linjeavsnitten eller stationerna (noderna) som har betydelse för den tågsammansättning som beskrivs i avtalet om tågläget.

Avtal om ett tågläge för en tågrörelse med kort varsel baseras på en dialog mellan RU och IM. Ansökningar om infrastrukturkapacitet får göras av sökande. För att använda en sådan infrastrukturkapacitet ska de sökande ge en RU ansvaret för att ingå en överenskommelse med IM i enlighet med direktiv 2012/34/EU [3]. Denna dialog omfattar alla RU och IM som är involverade i tågets rörelse längs det önskade tågläget, även om de bidrar i olika omfattning till processen att hitta ett tågläge.

4.2.2.2 Meddelandet Ansökan om tågläge

Detta meddelande skickas till IM av RU för att begära ett tågläge.

4.2.2.3 Meddelandet Specifikation av tågläge

IM sänder detta meddelande till RU som svar på RU:s ansökan om tågläge.

4.2.2.4 Meddelandet Bekräftat tågläge

Den RU som ansöker om tågläge använder detta meddelande för att boka/bekräfta det tågläge som IM har föreslagit.

4.2.2.5 Meddelandet Avvisad specifikation av tågläge

Den RU som ansöker om tågläge använder detta meddelande för att avvisa specifikation om tågläge som IM i fråga har föreslagit.

4.2.2.6 Meddelandet Inställt tågläge

Detta meddelande används av en RU för att avboka hela eller delar av ett bokat tågläge.

4.2.2.7 Meddelandet Tågläge inte tillgängligt

IM sänder detta meddelande till den avtalade RU om RU:s bokade tågläge inte längre är tillgängligt.

4.2.2.8 Meddelandet Kvitto på mottagande

Detta meddelande ska sändas från mottagaren av meddelandet till avsändaren av meddelandet för att bekräfta att det befintliga systemet har tagit emot meddelandet inom en viss tidsperiod.

4.2.3 Iordningställa tåg

4.2.3.1 Allmänna anmärkningar

Denna grundparameter specificerar de meddelanden som ska utväxlas vid iordningställande av tåget till dess start.

Iordningställande av ett tåg innefattar kontroll av kompatibiliteten mellan tåget och färdvägen. Kontrollen görs av RU utifrån information från berörda IM om infrastrukturbeskrivning och infrastrukturbegränsningar.

Under iordningställande av tåg måste RU skicka tågsammansättningen till efterföljande RU. Enligt avtal måste detta meddelande också skickas från RU till den/de IM som den har anlitat för ett tågläge eller del av tågläge.

Om tågets sammansättning ändras på någon plats, ska ansvarig RU skicka detta meddelande ännu en gång med uppdaterad information.

För att ställa i ordning tåget måste RU ha tillgång till information om infrastrukturbegränsningar, till tekniska vagndata (Referensdatabaserna för rullande materiel, avsnitt 4.2.10.2: Referensdatabaserna för rullande materiel), till information om farligt gods och den aktuella, uppdaterade informationen om vagnarnas status (avsnitt 4.2.11.2: Andra databaser Driftdatabas för vagnar och intermodala enheter). Detta gäller för alla vagnar i tåget. När det är klart ska RU sända tågsammansättningen till efterföljande berörda RU. Detta meddelande ska också sändas från RU till den/de IM som RU bokat ett tågläge eller del av tågläge hos, när så krävs enligt TSD Drift och trafikledning för konventionella tåg eller enligt avtal mellan RU och berörd(a) IM.

Om tågets sammansättning ändras på någon plats, ska ansvarig RU sända detta meddelande ännu en gång med uppdaterad information.

Vid varje punkt, t.ex. utgångs- och utväxlingspunkter, där ansvaret flyttas över från en RU till en annan, är dialogen för startproceduren mellan IM och RU ”Tåget klart – Tågföringsinformation” obligatorisk.

4.2.3.2 Meddelandet Tågets sammansättning

Detta meddelande ska sändas från RU till nästa RU och innehålla uppgifter om tågets sammansättning. Enligt järnvägsnätsbeskrivningarna ska detta meddelande också sändas från RU till berörd(a) IM. Så snart en ändring av sammansättningen sker under tågets färd, ska ansvarig RU uppdatera detta meddelande till LRU, som informerar alla berörda parter.

Vad som minst ska ingå i utväxlingen av meddelanden mellan RU och IM i fråga om tågets sammansättning anges i avsnitt 4.2.2.7.2 i beslut 2012/757/EU och TSD Drift och trafikledning.

4.2.3.3 Meddelandet Tåget klart

RU ska skicka meddelandet ”Tåget klart” till IM varje gång ett tåg är färdigt för tillträde till järnvägsnätet för första gången, såvida inte IM i enlighet med nationella regler godtar tidtabellen som ett sådant meddelande.

Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I. Andra befintliga standarder får dessutom användas för samma ändamål om de inblandade parterna har slutit ett särskilt avtal om att tillåta användningen av dessa standarder.

4.2.4 Tågföringsprognos

4.2.4.1 Allmänna anmärkningar

Denna grundparameter anger tågföringsinformation och tågföringsprognos. Den ska föreskriva hur dialogen mellan IM och RU för utbyte av tågföringsinformation och tågföringsprognoser ska upprätthållas.

Denna grundparameter anger hur IM, i rätt tid, ska sända tågföringsinformation till RU och nästa angränsande IM som är inblandad i tågdriften.

Tågföringsinformationen syftar till att tillhandahålla detaljerade uppgifter om tågets aktuella status vid avtalade rapporteringspunkter.

Tågföringsprognosen används för att tillhandahålla information om den beräknade tiden vid avtalade prognospunkter. Detta meddelande ska sändas från IM till RU och angränsande IM som är inblandad i tågets framförande.

I avtalen ska det fastställas rapporteringspunkter för tågets framförande.

Denna informationsutväxling mellan RU och IM sker alltid mellan den ansvariga IM och den RU som bokat det tågläge på vilket tåget framförs.

Enligt avtal ska LRU tillhandahålla kunden Tågföringsprognos och Tågföringsinformation. Rapporteringspunkterna kommer att bestämmas av parterna inom ramen för avtalet.

4.2.4.2 Meddelandet Tågföringsprognos

Detta meddelande ska utfärdas av IM till den RU som framför tåget, för överlämnandepunkter, utväxlingspunkter och tågets destination såsom beskrivs i avsnitt 4.2.4.1 (Tågföringsprognos, Allmänna anmärkningar).

Dessutom ska meddelandet utfärdas av IM till RU för andra rapporteringspunkter enligt avtal mellan RU och IM (t.ex. för hanteringspunkt eller station).

En tågföringsprognos kan också sändas innan tåget sätts i rörelse. För ytterligare förseningar som uppstår mellan två rapporteringspunkter ska ett tröskelvärde fastställas i ett avtal mellan RU och den IM till vilken en första eller en ny prognos ska sändas. Om förseningen inte är känd ska IM sända ett meddelande om trafikstörning (se avsnitt 4.2.5 Information om trafikstörning).

Meddelandet Tågföringsprognos ska ange den prognostiserade tiden för avtalad prognospunkt.

4.2.4.3 Meddelandet Tågföringsinformation och meddelandet Orsak till tågförsening.

Detta meddelande ska utfärdas av IM till de RU som framför tåget vid följande händelse:

—	Avgång från utgångspunkt, ankomst till destination.

—	Ankomst till och avgång från överlämnandepunkter, utväxlingspunkter och avtalade rapporteringspunkter (t.ex. hanteringspunkter).

Om orsaken till förseningen (första antagandet) finns ska det sändas i det separata meddelandet om orsak till tågförsening.

Definitionen av den obligatoriska uppgiftsstrukturen för dessa meddelanden och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.5 Information om trafikstörning

4.2.5.1 Allmänna anmärkningar

Denna grundparameter fastställer hur information om trafikstörningar hanteras mellan RU och IM.

Då RU får kännedom om en trafikstörning under tågföring för vilken den är driftsansvarig, måste den omedelbart underrätta berörd IM (detta kan ske muntligt). Om det sker ett avbrott i tågföringen ska IM sända meddelandet ”Avbrott i tågföringen” till RU som avtalat och nästa angränsande IM som är inblandad i tågföringen.

Om förseningens storlek är känd ska IM i stället sända meddelande om tågföringsprognos.

4.2.5.2 Meddelandet Avbrott i tågföringen

Om tågföringen avbryts ska IM utfärda detta meddelande till nästa angränsande IM som är inblandad i tågets framförande och till RU.

4.2.6 ETI/ETA för en försändelse

4.2.6.1 Inledande anmärkning

I avsnitt 4.2.2 (Ansökan om tågläge) beskrivs främst kommunikationen mellan RU och IM. Övervakning av individuella vagnar och intermodala enheter omfattas inte av detta informationsutbyte. Detta görs på RU/LRU-nivå med utgångspunkt i de tågrelaterade meddelandena och beskrivs i avsnitten 4.2.6 (ETI/ETA för en försändelse) till 4.2.8 (Rapportering om utväxling).

Utbytet och uppdateringen av information angående vagnar och intermodala enheter stöds huvudsakligen av lagring av ”färdplaner” och ”vagnrörelser” (se avsnitt 4.2.11.2: Andra databaser).

Såsom redan nämnts i avsnitt 2.3.2 (Berörda processer), är den viktigaste informationen för kunden alltid den beräknade ankomsttiden (ETA) för försändelsen. ETA liksom ETI för vagnar är också den grundläggande informationen i kommunikationen mellan LRU och RU. Denna information är det viktigaste instrumentet för LRU när det gäller att övervaka den fysiska transporten av en försändelse och kontrollera den i förhållande till åtagandet gentemot kunden.

De prognostiserade tiderna i de tågrelaterade meddelandena hänför sig alla till ett tågs ankomst till en viss punkt, som kan vara en överlämningspunkt, utväxlingspunkt, tågets destination eller en annan rapporteringspunkt. Alla dessa tider är beräknade ankomsttider för tåget (TETA). För de olika vagnar och intermodala enheter som ingår i tåget kan en sådan TETA ha olika innebörd. En TETA för en utväxlingspunkt, till exempel, kan vara en beräknad tidpunkt för utväxling (ETI) för vissa vagnar eller intermodala enheter. För andra vagnar som blir kvar i tåget för vidare transport med samma RU har denna TETA ingen särskild betydelse. Det ankommer på den RU som tar emot informationen om TETA att identifiera och behandla denna information, lagra den som en vagnrörelse i driftdatabasen för godsvagnar och intermodala enheter och meddela den till LRU, om tåget inte framförs i en situation med öppen tillgång. Detta beskrivs i de följande avsnitten.

Enligt avtal ska LRU ge kunden beräknad ankomsttid (ETA) och beräknad tidpunkt för utväxling (ETI) på försändelsenivå. Detaljnivån kommer att bestämmas av parterna inom ramen för avtalet.

I fråga om intermodala transporter kommer de datameddelanden som innehåller identifierare av lastenheter (t. ex. containrar, växelflak, påhängsvagnar) att antingen använda en BIC- eller en ILU-kod enligt ISO 6346 och EN 13044.

4.2.6.2 Beräkning av ETI/ETA

Beräkningen av ETI/ETA grundas på informationen från ansvarig IM som, inom ramen för meddelandet om tågföringsprognos, sänder den beräknade tiden för tågets ankomst (TETA) för angivna rapporteringspunkter (åtminstone för alla överlämningspunkter, utväxlingspunkter och destinationer inbegripet intermodala terminaler) längs det avtalade tågläget, t.ex. för överlämningspunkten från en IM till nästa IM (i detta fall är TETA lika med ETH).

För utväxlingspunkterna eller för andra angivna rapporteringspunkter på det avtalade tågläget, ska RU för nästa RU i transportkedjan ange den beräknade tidpunkten för utväxling (ETI) för vagnarna och/eller de intermodala enheterna.

Eftersom en RU kan ha vagnar med olika färdvägar och från olika LRU med i samma tåg, kan utväxlingspunkten för beräkning av ETI vara olika för olika vagnar. (En grafisk framställning av dessa scenarier och exempel återfinns i dokumentet ”TSD TAF – Bilaga A. 5: siffror och sekvensdiagram i TSD TAF-meddelanden” avsnitt 1.4, som förtecknas i bilaga I och ett sekvensdiagram baserat på exempel 1 för utväxlingspunkt C återfinns i dokumentet ”TSD TAF – Bilaga A. 5: siffror och sekvensdiagram i TSD TAF-meddelanden” avsnitt 5, som förtecknas i bilaga I).

Nästa RU beräknar i sin tur, med utgångspunkt från inkomna ETI från föregående RU, vagnarnas ETI för nästa utväxlingspunkt. Dessa steg utförs av varje efterföljande RU. När den sista RU (t.ex. RU n) i en vagns transportkedja mottar ETI från föregående RU (t.ex. RU n-1) med avseende på utväxlingspunkten mellan RU n-1 och RU n, ska den sista RU (RU n) fastställa den beräknade tiden för vagnarnas ankomst till slutdestinationen. Detta för att kunna ordna vagnarnas placering enligt fraktordern och enligt LRU:s åtagande gentemot kunden. Detta är ETA för vagnen och ska sändas till LRU. ETA ska lagras elektroniskt tillsammans med vagnrörelser. LRU ska ge relevanta data till kunden i enlighet med villkoren i avtalet.

Anmärkning om intermodala enheter: För intermodala enheter på en vagn är vagnens ETI också ETI för de intermodala enheterna. När det gäller ETA för intermodala enheter bör det noteras att RU inte har möjlighet att beräkna ETA annat än för järnvägsdelen av transporten. Därför kan RU endast tillhandahålla ETI med avseende på den intermodala terminalen.

LRU har ansvaret för att jämföra ETA med åtagandet gentemot kunden.

Avvikelser i fråga om ETA från åtagandet gentemot kunden ska hanteras i enlighet med avtalet och kan leda till en avvikelsehanteringsprocess från LRU:s sida. För överförande av information om resultatet av denna process används ett underrättelsemeddelande.

Som grundval för avvikelsehanteringsprocessen ska LRU ha möjlighet att göra en förfrågan om avvikelser beträffande vagnar. Även denna förfrågan från en LRU och svaret från en RU beskrivs nedan.

4.2.6.3 Meddelandet ETI/ETA för vagn

Syftet med detta meddelande är att sända ETI eller uppdaterad ETI från en RU till nästa RU i transportkedjan. Den sista RU i transportkedjan för vagnarna sänder ETA eller uppdaterad ETA till LRU. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.6.4 Underrättelsemeddelande

Efter jämförelse mellan ETA och åtagandet gentemot kunden, kan LRU sända ett underrättelsemeddelande till berörda RU. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D. 2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

Anmärkning: Vid öppen tillgång är beräkningen av ETI och ETA en intern process hos RU. I detta fall är RU själv LRU.

4.2.7 Vagnrörelse

4.2.7.1 Inledande anmärkningar

För rapportering av en vagns rörelse måste uppgifter i dessa meddelanden lagras och finnas elektroniskt tillgängliga. De ska även utbytas inom ramen för meddelanden på avtalsbasis till godkända parter.

—	Meddelande om frisläppande av vagn

—	Meddelande om vagns avgång

—	Vagns ankomst till bangård

—	Vagns avgång från bangård

—	Meddelande om vagnsavvikelse

—	Meddelande om vagns ankomst

—	Meddelande om leverans av vagn

—	Rapportering om utväxling av vagnar beskrivs separat i avsnitt 4.2.8: Rapportering om utväxling

Enligt avtal ska LRU ge kunden information om vagnrörelser med hjälp av de meddelanden som beskrivs nedan.

4.2.7.2 Meddelandet Meddelande om frisläppande av vagn

LRU är inte nödvändigtvis den första RU i tranportkedjan. I detta fall ska LRU meddela ansvarig RU att vagnen är klar att dras från kundens rangerbangård (utgångspunkt enligt LRU: s åtagande) vid den angivna frisläppandetiden (datum och tid för avgång).

Dessa händelser ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.3 Meddelandet Meddelande om vagns avgång

RU ska underrätta LRU om den faktiska tidpunkten då vagnen dragits från avgångsplatsen.

Dessa händelser ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Genom denna utväxling av meddelanden överförs ansvaret för vagnen från kunden till RU. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.4 Meddelandet Vagns ankomst till bangård

RU ska underrätta LRU om att vagnen anlänt till dess bangård. Detta meddelande kan grunda sig på ett meddelande om ”Tågföringsinformation” enligt avsnitt 4.2.4 (Tågföringsprognos). Denna händelse ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.5 Meddelandet Vagns avgång från bangård

RU ska underrätta LRU om att vagnen avgått från dess bangård. Detta meddelande kan grunda sig på ett meddelande om ”Tågföringsinformation” enligt avsnitt 4.2.4 (Tågföringsprognos). Denna händelse ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.6 Meddelande om vagnsavvikelse

RU ska underrätta LRU om något oförutsett händer med vagnen som kan påverka ETI/ETA eller kräver någon ytterligare åtgärd. För detta meddelande krävs i de flesta fall också en ny beräkning av ETI/ETA. Om LRU beslutar att det krävs en ny ETI/ETA, sänder den ett meddelande tillbaka till den RU som sänt detta meddelande, med angivelsen ”ETI/ETA efterfrågas” (meddelande: Förfrågan om ny ETI/ETA till följd av Meddelande om vagnsavvikelse). Den nya beräkningen av ETI/ETA ska följa det förfarande som beskrivs i avsnitt 4.2.6 (ETI/ETA för en försändelse).

Denna information ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.7 Meddelandet Meddelande om vagns ankomst

Den sista RU i en transportkedja av vagnar eller intermodala enheter ska underrätta LRU om att vagnen har anlänt till sin bangård (RU-position). Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.7.8 Meddelandet Meddelande om leverans av vagn

Den sista RU i en vagntransportkedja ska underrätta LRU om att vagnen har placerats på mottagarens rangerbangård.

Anmärkning: Vid öppen tillgång är den beskrivna vagnrörelsen en intern process hos RU (LRU). Trots det måste alla beräkningar och lagringen av data utföras, eftersom LRU har ett avtal med och ett åtagande gentemot kunden.

Sekvensdiagrammet för dessa meddelanden baserat på exempel 1 för beräkning av ETI för vagnarna 1 och 2 (se avsnitt 4.2.6.2 Beräkning av ETI/ETA) ingår i diagrammet för rapportering om utväxling i dokumentet ”TSD TAF – Bilaga A. 5: siffror och sekvensdiagram i TSD TAF-meddelanden” avsnitt 6, som förtecknas i tillägg I.

4.2.8 Rapportering om utväxling

4.2.8.1 Inledande anmärkning

Rapporteringen om utväxling omfattar de meddelanden som hör ihop med överlåtandet av ansvaret för en vagn från en RU till en annan, vilket sker vid utväxlingspunkter. Utväxlingen innebär också att den nya RU måste beräkna ETI och följa det förfarande som beskrivs i avsnitt 4.2.6 (ETI/ETA för en försändelse).

Följande meddelanden ska utbytas:

—	Meddelande om utväxling av vagn.

—	Delmeddelande om utväxling av vagn.

—	Vagn mottagen vid utväxlingspunkt.

—	Vagn avvisad vid utväxlingspunkt.

Dessa meddelandens informationsdata ska lagras i driftdatabasen för godsvagnar och intermodala enheter. I händelse av någon form av avvikelse ska en ny ETI/ETA fastställas och meddelas enligt avsnitt 4.2.6: ETI/ETA för en försändelse. Sekvensdiagrammet för dessa meddelanden visas i anslutning till meddelandena om vagnrörelser i dokumentet ”TSD TAF – Bilaga A.5: siffror och sekvensdiagram i TSD TAF-meddelanden” som förtecknas i tillägg I.

Meddelandena om utväxling av vagn och delmeddelandena om utväxling av vagn liksom meddelandena om vagn mottagen kan överföras som en lista för flera vagnar, särskilt om dessa vagnar ingår i samma tåg. I detta fall kan alla vagnarna listas inom ramen för ett överfört meddelande.

Vid öppen tillgång finns inga utväxlingspunkter. Vid en hanteringspunkt sker ingen förändring vad gäller ansvaret för vagnarna. Därför krävs ingen särskild utväxling av meddelanden. Men med utgångspunkt från tågföringsinformationen för tåget vid denna rapporteringspunkt ska uppgifter om vagnen eller den intermodala enheten – position och datum och tid för ankomst och avgång – behandlas och lagras i driftdatabasen för godsvagnar och intermodala enheter.

Enligt avtal ska LRU ge kunden information om utväxling med hjälp av de meddelanden som beskrivs nedan.

Definitionen av den obligatoriska strukturen i dessa meddelanden finns i dokumentet ”TSD TAF – Bilaga D. 2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.8.2 Meddelandet Meddelande om utväxling av vagn

Med ”Meddelande om utväxling av vagn” frågar en RU (RU 1) nästa RU (RU 2) i transportkedjan om denna accepterar att ta över ansvaret för en vagn. Med ”Delmeddelande om utväxling av vagn” underrättar RU 2 sin IM om att den accepterat att ta över ansvaret. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.8.3 Delmeddelandet om utväxling av vagn

Med ”Delmeddelande om utväxling av vagn” underrättar RU 2 IM om att den accepterat att ta över ansvaret för en viss vagn. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.8.4 Meddelandet Vagn mottagen vid utväxlingspunkt

Med meddelandet ”Vagn mottagen vid utväxlingspunkt” underrättar RU 2 RU 1 om att den accepterar att ta över ansvaret för vagnen. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.8.5 Meddelandet Vagn avvisad vid utväxlingspunkt

Med meddelandet ”Vagn avvisad vid utväxlingspunkt” underrättar RU 2 RU 1 om att den inte accepterar att ta över ansvaret för vagnen. Definitionen av den obligatoriska uppgiftsstrukturen för detta meddelande och de instruktioner som ska följas beskrivs i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.9 Datautväxling för kvalitetsförbättring

För att vara konkurrenskraftig måste den europeiska järnvägsindustrin kunna leverera högre tjänstekvalitet till sina kunder (se även artikel 2.7.1 i bilaga III till direktiv 2008/57/EG [1]). En utvärderingsprocess som genomförs efter färd är viktigt för att stödja kvalitetsförbättringar. Förutom att utvärdera den tjänstekvalitet som tillhandahållits kunden, ska LRU, RU och IM utvärdera kvaliteten av de olika tjänstekomponenter som tillsammans bildar den produkt som levererats till kunden. Processen omfattar berörda IM och RU (särskilt om de är LRU). Man väljer ut en enskild kvalitetsparameter, en färdväg eller position samt en mätperiod under vilken faktiska resultat jämförs mot förutbestämda kriterier som normalt fastställts inom ramen för ett avtal. Resultaten av utvärderingsprocessen ska tydligt visa den uppnådda nivån i förhållande till det mål som överenskommits mellan de avtalsslutande parterna.

4.2.10 Viktigaste referensdata

4.2.10.1 Förord

Uppgifter om infrastrukturen (järnvägsnätsbeskrivningarna och information om infrastrukturbegränsningar) och uppgifter om den rullande materielen (i referensdatabaserna för rullande materiel och i driftdatabasen för godsvagnar och intermodala enheter) är de viktigaste uppgifterna för driften av godstågstrafik på det europeiska järnvägsnätet. Båda dessa typer av uppgifter tillsammans möjliggör en bedömning av den rullande materielens kompatibilitet med infrastrukturen, bidrar till att undvika dubbel inmatning av data vilket höjer kvaliteten på uppgifterna, och ger en tydlig bild av alla tillgängliga anläggningar och utrustning vid varje tidpunkt, för snabba beslut under trafikens gång.

4.2.10.2 Referensdatabaserna för rullande materiel

Innehavaren av rullande materiel ansvarar för lagringen av data om den rullande materielen i en referensdatabas för rullande materiel.

Den information som måste finnas med i de enskilda referensdatabaserna för rullande materiel beskrivs i detalj i tillägg I, tillägg C. De måste innehålla alla detaljer om

—	identifiering av den rullande materielen,

—	bedömning av kompatibiliteten med infrastrukturen,

—	bedömning av relevanta lastningsegenskaper,

—	bromsegenskaper,

—	underhållsdata, och

—	miljöegenskaper.

Referensdatabaserna för rullande materiel ska ge enkel tillgång (en enda gemensam ingång via det gemensamma gränssnittet) till tekniska data, för att minimera den mängd data som överförs för varje operation. Innehållet i databaserna måste vara tillgängligt, enligt en struktur för tillträdesrätt som bygger på fastställda rättigheter, för alla IM, RU, tillhandahållare av logistik och vagnparksförvaltare, särskilt för sådana syften som vagnparksförvaltning och underhåll av rullande materiel.

Posterna i referensdatabasen för rullande materiel kan delas in enligt följande:

—

Administrativa uppgifter, som rör certifierings- och registreringsfrågor, såsom hänvisning till underlag för EG-registrering, identifiering av anmält organ etc. Detta kan omfatta historiska data angående ägarskap, uthyrning etc. Och dessutom, enligt artikel 5 i kommissionens förordning (EU) nr 445/2011, kan fordonsinnehavare lagra ECM-certifieringens identifieringsnummer i de enskilda referensdatabaserna för rullande materiel. Följande aspekter måste beaktas:

—	EG-certifiering.

—	Registrering i ”hemstaten”.

—	Datum för idrifttagande i registreringsstaten.

—	Registrering i andra länder för användning på deras nationella järnvägsnät.

—	Säkerhetscertifiering för all rullande materiel som inte överensstämmer med TSD Rullande materiel.

Innehavaren är skyldig att se till att dessa data finns tillgängliga och att bakomliggande förfaranden genomförts.

—

Konstruktionsdata, som ska omfatta alla konstitutiva (fysiska) beståndsdelar av den rullande materielen, inbegripet egenskaper som rör miljön, och all information som förväntas gälla under den rullande materielens hela livslängd – denna del kan innehålla historik över betydande modifieringar, större underhållsinsatser, översyner etc.

4.2.10.3 Driftdata om rullande materiel

Vid sidan av referensdata för rullande materiel, är uppgifter angående den rullande materielens aktuella status av största vikt för driften.

Dessa uppgifter ska omfatta tillfälliga uppgifter, såsom begränsningar, pågående och planerade underhållsåtgärder, km- och felräknare etc. och alla uppgifter som kan anses avse ”status” (tillfälliga hastighetsbegränsningar, broms bortkopplad, reparationsbehov och felbeskrivningar etc.).

För användning av driftdata om den rullande materielen måste tre olika enheter beaktas, med hänsyn till de olika parter som ansvarar för den rullande materielen under transporten:

—	RU, som uppdragstagare under den del av transporten det ansvarar för.

—	Innehavare av rullande materiel.

—	Användare (hyrestagare) av rullande materiel.

När det gäller alla dessa tre parter ska driftdata om den rullande materielen finnas tillgängliga för den auktoriserade användaren, ner till den nivå som definierats för den användaren, med hjälp av den identifikation som ges i form av vagn-ID (vagnsnumret).

Driftdata för den rullande materielen är en del av driftdatabasen för godsvagnar och intermodala enheter som beskrivs i avsnitt 4.2.11.2 Andra databaser.

4.2.11 Olika referensfiler och databaser

4.2.11.1 Referensfiler

För driften av godståg på det europeiska järnvägsnätet ska följande referensfiler finnas tillgängliga och vara åtkomliga för alla tjänsteleverantörer (IM, RU, tillhandahållare av logistik och vagnparksförvaltare). Dessa data ska vid varje tillfälle motsvara den faktiska statusen. Om en referensfil används gemensamt med TSD TAP [2], måste utveckling och ändringar vara förenliga med TSD TAP [2] för att optimera synergieffekterna.

Lokalt lagrade och administrerade:

a)	Referensfil över räddningstjänster, i relation till typen av farligt gods.

Centralt lagrade och administrerade:

b)	Referensfil över koder för alla IM, RU och tjänstelevererande företag.

c)	Referensfil över koder för transportkunder.

d)	Referensfil över koder för platser (huvud- och underplatser).

Europeiska järnvägsbyrån kommer att spara en kopia av referensfilen för koderna för platser och företagskoder. På individuell begäran och utan att det påverkar tillämpningen av immateriella rättigheter, ska dessa uppgifter vara tillgänglig för allmänheten.

Övriga förteckningar över koder definieras i dokumentet ”TSD TAF – Bilaga D.2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.11.2 Andra databaser

För att göra det möjligt att lokalisera tågs och vagnars rörelser ska de nedan angivna databaserna installeras och uppdateras vid varje relevant händelse i realtid. Behöriga enheter såsom innehavare av rullande materiel och vagnparksförvaltare ska ha tillgång till relevanta data för fullgörandet av sina uppgifter, i enlighet med villkoren i de bilaterala avtalen.

—	Driftdatabas för godsvagnar och intermodala enheter.

—	Färdplan för vagn/intermodal enhet.

Dessa databaser ska vara tillgängliga via det gemensamma gränssnittet (4.2.12.1: Allmän arkitektur och 4.2.12.6: Gemensamt gränssnitt).

Driftdatabas för godsvagnar och intermodala enheter

Kommunikationen mellan LRU och RU vid samarbete baserar sig på vagnarnas och/eller de intermodala enheternas enhetsnummer. Därför ska en RU, som kommunicerar med IM på tågnivå, bryta ned denna information till element på nivån för vagnar och intermodala enheter. Denna information om vagnar och intermodala enheter ska lagras i driftdatabasen för godsvagnar och intermodala enheter. Informationen om tågrörelser ger upphov till nya poster/uppdateringar i driftdatabasen för godsvagnar och intermodala enheter som ger information till kunden. Informationen om rörelse för en vagn eller intermodal enhet i databasen införs senast då uppgift erhålls om tiden för frisläppande av vagnar och intermodala enheter från kunden. Tiden för frisläppande är den första rörelseposten för en vagn som införs i driftdatabasen för godsvagnar och intermodala enheter med hänvisning till en faktisk transport. Meddelandena för vagnrörelser beskrivs i avsnitten 4.2.8 (Vagnrörelse) och 4.2.9 (Rapportering om utväxling). Denna databas ska vara tillgänglig via det gemensamma gränssnittet (4.2.12.1: Allmän arkitektur och 4.2.12.6: Gemensamt gränssnitt).

Driftdatabasen för godsvagnar och intermodala enheter är den viktigaste databasen för lokalisering av vagnar och därmed för kommunikationen mellan berörda RU och LRU. Denna databas visar vagnars och intermodala enheters rörelser från avgång och fram till slutlig leverans till kundens rangerbangård med ETI och faktiska tider vid olika platser fram till den slutliga ETA vid leverans. I databasen visas också olika status för den rullande materielen, enligt följande:

—	Status: lastning av rullande materiel Denna status behövs för informationsutväxlingen mellan RU och berörda IM samt för övriga RU som berörs av transporten.

—	Status: lastad vagn i trafik Denna status behövs för informationsutväxlingen mellan IM och RU samt för övriga IM och övriga RU som berörs av transporten.

—	Status: tom vagn i trafik Denna status behövs för informationsutväxlingen mellan IM och RU samt för övriga IM och RU som berörs av transporten.

—	Status: lossning av rullande materiel Denna status behövs för informationsutväxlingen mellan RU vid slutdestinationen och LRU för transporten.

—	Status: tom vagn under vagnparksförvaltares kontroll Denna status behövs för att få information om tillgång till fordon med angivna egenskaper.

Databaser över färdplaner för vagnar

Tågen kan bestå av vagnar från olika kunder. För varje vagn ska LRU (den RU som fungerar som samordnare för transporten) upprätta och uppdatera en färdplan som motsvarar tågläget på tåguppdragsnivå. Nya tåglägen för ett tåguppdrag – t.ex. vid avbrott i trafiken – leder till förändringar av färdplanerna för de berörda vagnarna. Tiden för upprättandet av en färdplan är tiden för mottagande av fraktsedeln från kunden.

Färdplanerna för vagnarna ska lagras av varje LRU i en databas. Dessa databaser ska vara tillgängliga via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.12.6: Gemensamt gränssnitt).

Anmärkning:

Utöver de obligatoriska databaser som nämns här ovan kan en tågdatabas inrättas hos varje IM.

Denna infrastrukturförvaltarens tågdatabas motsvarar rörelsedelen i driftdatabasen för godsvagnar och intermodala enheter. Huvudposten är tågrelaterade data från RU:s meddelande om tågets sammansättning. Alla tåghändelser leder till en uppdatering av denna tågrelaterade databas. En alternativ lagringsmöjlighet för dessa data är databasen över tåglägen (avsnitt 4.2.2: Ansökan om tågläge). Dessa databaser ska vara tillgängliga via det gemensamma gränssnittet (4.2.12.1: Allmän arkitektur och 4.2.12.6: Gemensamt gränssnitt).

4.2.11.3 Ytterligare krav på databaserna

Under nedanstående punkter listas de ytterligare krav som de olika databaserna ska uppfylla.

Följande ytterligare krav ska uppfyllas:

1.	Autentisering En databas måste stödja autentisering av systemanvändarna innan de kan få tillgång till databasen.

2.	Säkerhet En databas måste stödja säkerhetsaspekter i den mening att tillgången till databasen är kontrollerad. Kryptering av själva innehållet i databasen krävs inte.

3.	Enhetlighet En databas ska stödja ACID-principen (Atomicity, Consistency, Isolation, Durability).

Accesskontroll

En databas måste ge tillgång till uppgifter för användare eller system som fått tillstånd för detta. Accesskontroll ska stödjas ner till nivån för enskilda attribut för en datapost. Databasen ska stödja konfigurerbar, rollbaserad accesskontroll för införande, uppdatering eller borttagning av data.

5.	Spårning En databas måste stödja loggning av alla åtgärder som vidtagits i databasen för att det ska vara möjligt att spåra detaljerna kring en datapost (av vem, för vad och när gjordes ändringen av innehållet).

6.	Låsstrategi En databas måste tillämpa en låsstrategi som gör att alla data är tillgängliga även samtidigt som andra användare för in ändringar.

7.	Samtidig tillgång En databas måste stödja att data samtidigt är tillgängliga för flera användare och system.

8.	Tillförlitlighet Tillförlitligheten hos en databas måste uppfylla de krav för tillgänglighet som ställs.

9.	Tillgänglighet En databas måste ha en tillgänglighet vid förfrågan på minst 99,9 %.

10.	Underhållsmässighet Underhållsmässigheten hos en databas måste stödja den tillgänglighet som krävs.

11.	Säkerhet Databaserna är i sig inte säkerhetsrelaterade. Därför är säkerhetsaspekter inte relevanta. Detta ska inte förväxlas med det faktum att vissa data – t.ex. felaktiga eller inaktuella data – kan påverka säkerheten vid drift av ett tåg.

12.	Kompatibilitet En databas måste stödja ett programspråk som är allmänt accepterat, t.ex. SQL eller XQL.

13.	Importmöjligheter En databas ska vara så utformad att det går att importera formaterade data för att fylla i databasen istället för manuell inmatning.

14.	Exportmöjligheter En databas ska vara utformad så att det går att exportera innehållet i hela eller delar av databasen som formaterade data.

15.	Obligatoriska fält En databas måste stödja obligatoriska fält som måste fyllas i innan en registrering accepteras som en inmatning i databasen.

16.	Rimlighetskontroll En databas måste stödja konfigurerbara rimlighetskontroller innan införande, uppdatering eller borttagning av registrerade data accepteras.

17.	Svarstider En databas måste ha svarstider som gör att användare kan föra in, uppdatera eller ta bort registrerade data utan oacceptabla fördröjningar.

18.	Prestandaaspekter Referensfiler och databaser ska på ett kostnadseffektivt sätt tillåta att de frågor ställs som krävs för att alla relevanta tågrörelser och vagnrörelser som omfattas av bestämmelserna i denna TSD ska kunna genomföras effektivt.

19.

Kapacitetsaspekter

En databas ska stödja lagringen av relevanta data för alla godsvagnar respektive hela järnvägsnätet. Det ska vara möjligt att utöka kapaciteten med enkla medel (dvs. genom att lägga till mer lagringskapacitet och datorer). Utökning av kapaciteten ska inte kräva att delsystemet byts ut.

20.	Historiska data En databas ska stödja hanteringen av historiska data i den meningen att data överförs till ett arkiv och hålls tillgängliga.

21.	Backupstrategi En backupstrategi ska finnas som gör att allt innehåll i databasen för upp till 24 timmar kan återställas.

22.	Kommersiella aspekter Ett databassystem som används ska finnas tillgängligt som hyllvara (COTS-produkt) eller vara fritt tillgängligt i public domain (öppen källa).

Anmärkningar:

Ovan nämnda krav måste hanteras av ett standardsystem för databashantering (DBMS).

Användningen av de olika databaserna ingår i olika arbetsflöden som beskrivits ovan. Det generella arbetsflödet är en fråga/svar-mekanism där en berörd part efterfrågar information från databasen via det gemensamma gränssnittet (4.2.12.1: Allmän arkitektur och 4.2.12.6: Gemensamt gränssnitt). DBMS svarar på denna förfrågan antingen genom att tillhandahålla efterfrågade data eller genom att svara att inga data kan tillhandahållas (inga sådana data existerar eller tillgång nekas på grund av accesskontroll).

4.2.12 Nätverk och kommunikation

4.2.12.1 Allmän arkitektur

Detta delsystem kommer med tiden att växa och bilda ett stort och komplext samverkande telematiksystem inom ramen för ett gemensamt driftskompatibelt järnvägsnät, med hundratals deltagande aktörer (RU, IM m.fl.) som konkurrerar och/eller samarbetar om att tillgodose marknadens behov.

Infrastrukturen för nätverk och kommunikation inom ett sådant gemensamt driftskompatibelt järnvägsnät ska bygga på en gemensam arkitektur för informationsutväxling som är känd av och har anammats av alla deltagande aktörer.

Den föreslagna arkitekturen för informationsutväxling

—	är utformad för att göra heterogena informationsmodeller förenliga genom att semantiskt transformera de data som utbyts mellan systemen samt överbrygga skillnaderna i affärsprocesser och protokoll på applikationsnivå,

—	har minimal inverkan på de olika aktörernas befintliga IT-arkitekturer, och

—	säkrar redan gjorda IT-investeringar.

Arkitekturen för informationsutbyte stödjer främst en peer-to-peer-baserad typ av samverkan mellan alla aktörer, men garanterar samtidigt en övergripande tillförlitlighet och enhetlighet i det gemensamma driftskompatibla järnvägsnätet genom att tillhandahålla en uppsättning centraliserade tjänster.

En peer-to-peer-modell för samverkan möjliggör den bästa kostnadsfördelningen mellan de olika aktörerna, baserad på faktisk användning, och den kommer generellt att innebära färre skalbarhetsproblem. En grafisk framställning av den allmänna arkitekturen finns i dokumentet ”TSD TAF – Bilaga A. 5: siffror och sekvensdiagram i TSD TAF-meddelanden”, kapitel 1.5, som förtecknas i bilaga I.

4.2.12.2 Nätverk

Med nätverk avses här kommunikationsmetoden och -idén, inte det fysiska nätet.

Driftskompatibilitet inom järnvägssystemet bygger på en gemensam arkitektur för informationsutväxling som är känd av och har anammats av alla deltagare, vilket uppmuntrar och minskar hindren för nya deltagare, särskilt kunder.

Säkerhetsfrågan hanteras därför inte på nätnivå (VPN, tunnlar etc.), utan genom utväxling och hantering av i sig säkra meddelanden. Ett VPN-nät krävs därför inte (administrationen av ett stort VPN-nät skulle bli komplex och kostsam att hantera) vilket gör att problem rörande ansvar och ägande undviks. VPN-tunnlar anses inte vara nödvändiga för att uppnå en tillräcklig säkerhetsnivå.

Aktörer som redan har eller vill införa olika säkerhetsnivåer i valda delar av nätet kan dock göra det.

Det är möjligt att genomföra en hybridartad peer-to-peer-modell över det publika internet med ett gemensamt gränssnitt vid varje aktörs nod och en central certifikatutfärdare.

Sedan genomförs en peer-to-peer-kommunikation mellan de berörda aktörerna.

Peer-to-peer-kommunikationen grundar sig på tekniska standarder för det gemensamma gränssnitt som beskrivs i dokumentet ”TSD TAF – Bilaga D. 2: Tillägg F – TSD TAF data och meddelandemodell” som förtecknas i tillägg I.

4.2.12.3 Säkerhet

För att uppnå en hög säkerhetsnivå ska alla meddelanden vara självständiga (self contained), vilket betyder att informationen i meddelandet är skyddad och att mottagaren kan verifiera meddelandets äkthet. Detta kan göras genom en metod för kryptering och signering liknande den som används för kryptering av e-post.

4.2.12.4 Kryptering

Man ska använda antingen asymmetrisk kryptering eller en hybridlösning baserad på symmetrisk kryptering och öppen nyckel, eftersom ett system med en för många aktörer gemensam hemlig nyckel kommer att fallera förr eller senare. Det är lättare att uppnå en högre säkerhetsnivå om alla aktörer tar ansvar för sina egna nyckelpar, även om det krävs en hög integritetsnivå för den centrala datakatalogen (nyckelservern).

4.2.12.5 Den centrala datakatalogen

Den centrala datakatalogen ska kunna hantera

—	metadata – strukturerade data som beskriver meddelandenas innehåll,

—	infrastruktur för kryptering med öppna nycklar (PKI – Public Key Infrastructure),

—	certifieringsinstans (CA).

Förvaltningen av den centrala datakatalogen bör skötas av en icke-kommersiell sameuropeisk organisation. Om den centrala datakatalogen används i samband med TSD TAF [2] ska utveckling och ändringar ske i linje med TSD TAF:en [2] så att optimala synergieffekter kan åstadkommas.

4.2.12.6 Gemensamt gränssnitt

Ett gemensamt gränssnitt är obligatoriskt för alla aktörer som vill delta i det gemensamma driftskompatibla järnvägsnätet.

Ett gemensamt gränssnitt ska kunna hantera

—	formatering av utgående meddelanden enligt metadata,

—	signering och kryptering av utgående meddelanden,

—	adressering av utgående meddelanden,

—	verifiering av inkommande meddelandens äkthet,

—	dekryptering av inkommande meddelanden,

—	kontroll av att inkommande meddelanden överensstämmer med metadata,

—	åtkomsten till olika databaser via en enda gemensam ingång.

Varje instans av det gemensamma gränssnittet ska ha tillgång till alla de data som krävs enligt TSD inom varje fordonsinnehavare, LRU, RU, IM etc., oavsett om de relevanta databaserna är centrala eller individuella (se även dokumentet ”TSD TAF – Bilaga A. 5: siffror och sekvensdiagram i TSD TAF-meddelanden”, kapitel 1.6, som förtecknas i bilaga I).

Om det gemensamma gränssnittet används tillsammans med TSD TAF [2] ska utveckling och ändringar ske i linje med TSD TAF [2] så att optimala synergieffekter kan åstadkommas. På grundval av resultaten av äkthetsverifieringen av inkommande meddelanden kan en miniminivå för meddelandekvittens genomföras:

i)	positiv sänd ACK,

ii)	negativ sänd NACK.

Det gemensamma gränssnittet använder informationen i den centrala datakatalogen för att sköta ovan nämnda uppgifter.

En aktör kan ha en lokal ”spegling” av den centrala datakatalogen för att förkorta svarstiderna.

4.3 Funktionella och tekniska specifikationer för gränssnitten

Mot bakgrund av de väsentliga kraven i kapitel 3, gäller följande funktionella och tekniska specifikationer för gränssnitten:

4.3.1 Gränssnitt till TSD Infrastruktur

Delsystemet infrastruktur omfattar system för trafikledning, lokalisering och navigering: tekniska installationer för databehandling och telekommunikation för långväga persontransporter och godstransporter på järnvägsnätet för att garantera säker och samstämd drift av nätet och effektiv trafikledning.

Delsystemet Telematikapplikationer för godstrafik använder nödvändiga data i driftsyfte, med utgångspunkt från vad som anges i avtalet om tågläge, och kompletteras eventuellt av data med information om infrastrukturbegränsningar som tillhandahålls av IM. Därmed finns inget direkt gränssnitt mellan denna TSD och TSD Infrastruktur.

4.3.2 Gränssnitt till delsystemet TSD Trafikstyrning och signalering

Den enda kopplingen till trafikstyrningen och signaleringen är via

—	avtalet om tågläge, där relevant information om användbar trafikstyrnings- och signaleringsutrustning anges i beskrivningen av linjeavsnittet,

—	de olika referensdatabaserna för rullande materiel, där uppgifter om den rullande materielens trafikstyrnings- och signaleringsutrustning ska lagras.

4.3.3 Gränssnitt till delsystemet Rullande materiel

Delsystemet Telematikapplikationer för godstrafik identifierar de tekniska data och driftdata om den rullande materielen som ska vara tillgängliga.

I TSD Rullande materiel specificeras en vagns egenskaper. Om en vagns egenskaper ändras, måste motsvarande uppdatering göras i referensdatabaserna för rullande materiel inom ramen för det normala underhållet av databaserna. Därmed finns inget direkt gränssnitt mellan denna TSD och TSD Rullande materiel.

4.3.4 Gränssnitt till TSD Drift och trafikledning

Delsystemet Drift och trafikledning specificerar de förfaranden och utrustning som krävs för en sammanhängande drift av de olika strukturella delsystemen, både under normala förhållanden och vid störd drift, inbegripet framförande av tåg, trafikplanering och trafikledning.

Delsystemet Telematikapplikationer för godstrafik specificerar i huvudsak applikationer för godstrafik vilket omfattar realtidsövervakning av försändelser och tåg och hantering av anslutningar till andra transportsätt.

För att garantera samstämmighet mellan dessa båda TSD ska följande förfarande tillämpas:

När de specifikationer i TSD Drift och trafikledning som rör kraven i denna TSD ska formuleras och/eller ändras, måste det ansvariga organet för denna TSD rådfrågas.

I det fall de specifikationer i denna TSD som rör driftskraven i TSD Drift och trafikledning skulle bli föremål för ändringar, måste det ansvariga organet för TSD Drift och trafikledning rådfrågas.

4.3.5 Gränssnitt till delsystemet Telematikapplikationer för persontrafik

Gränssnitt

Hänvisning till TSD Telematikapplikationer för godstrafik

Hänvisning till TSD Telematikapplikationer för persontrafik

Tåget klart

4.2.3.3

Meddelandet Tåget klart

4.2.14.1

Meddelandet ”Tåget klart” för alla tåg

Tågföringsprognos

4.2.4.2

Meddelandet Tågföringsprognos

4.2.15.2

Meddelandet ”Tågföringsprognos” för alla tåg

Tågföringsinformation

4.2.4.3

Tågföringsinformation

4.2.15.1

Meddelandet ”Tågföringsinformation” för alla tåg

Avbrott i tågföringen till RU

4.2.5.2

Avbrott i tågföringen

4.2.16.2

Meddelandet ”Avbrott i tågföringen” för alla tåg

Hantering av tidtabellsdata för tåglägen i korttidstilldelningsprocessen

4.2.2

Ansökan om tågläge

4.2.17

Hantering av tidtabellsdata för tåglägen i korttidstilldelningsprocessen

Gemensamt gränssnitt

4.2.12.6

Gemensamt gränssnitt

4.2.21.7

Gemensamt gränssnitt för RU/IM-kommunikation

Den centrala datakatalogen

4.2.12.5

Den centrala datakatalogen

4.2.21.6

Den centrala datakatalogen

Referensfiler

4.2.11.1

Referensfiler

4.2.19.1

Referensfiler

4.4 Driftsregler

Mot bakgrund av de väsentliga kraven i kapitel 3, gäller följande särskilda driftsregler för det delsystem som omfattas av denna TSD:

4.4.1 Uppgifternas kvalitet

I syfte att kvalitetssäkra uppgifterna, ska varje avsändare av TDS-meddelande vara ansvarig för att uppgiftsinnehållet i meddelandet är korrekt då det meddelandet sänds. Om källdata för kvalitetssäkring av uppgifterna är tillgängliga via de databaser som inrättats i enlighet med denna TSD, ska uppgifterna i de databaserna användas för kvalitetssäkring av uppgifterna.

Om källdata för kvalitetssäkring av uppgifterna inte är tillgängliga via de databaser som inrättats i enlighet med denna TSD, ska meddelandets avsändare göra en kvalitetssäkringskontroll med hjälp av egna resurser.

Kvalitetssäkring av uppgifter omfattar jämförelser med uppgifter i databaser som inrättats i enlighet med denna TSD såsom beskrivits ovan, plus, där så är tillämpligt, logikkontroller för att säkra uppgifternas och meddelandenas aktualitet och kontinuitet.

Uppgifterna håller hög kvalitet om de passar för sina avsedda syften, vilket innebär att de

—	är felfria: tillgängliga, korrekta, aktuella, fullständiga, samstämmiga med andra källor etc.,

—	har önskade egenskaper: relevans, utförlighet, lämplig detaljnivå, är lättlästa och lättolkade etc.

Uppgifternas kvalitet bestäms i huvudsak av följande faktorer:

—	Korrekthet.

—	Fullständighet.

—	Samstämmighet.

—	Aktualitet.

Korrekthet:

Den information (data) som krävs måste samlas in på ett så ekonomiskt sätt som möjligt. Detta är möjligt endast om primärdata endast registreras vid ett enda tillfälle för hela transporten. Därför bör primärdata införas i systemet så nära källan som möjligt så att alla dessa data kan användas i all behandling längre fram.

Fullständighet:

Innan meddelanden sänds ut ska fullständigheten och syntaxen kontrolleras med hjälp av metadata. På så sätt undviks också onödig informationstrafik på nätet.

Alla inkommande meddelanden ska också kontrolleras med avseende på fullständighet med hjälp av metadata.

Samstämmighet:

Affärsregler måste införas för att garantera samstämmighet. Dubbel inmatning bör undvikas och uppgifternas ägare ska vara tydligt identifierad.

På vilket sätt dessa regler ska genomföras beror på komplexiteten i respektive regel. För enkla regler är databasrestriktioner och triggrar tillräckliga. När det gäller mer komplexa regler som kräver data från flera olika tabeller, måste valideringsförfaranden införas som kontrollerar samstämmigheten i dataversionen innan gränssnittsdata genereras och den nya dataversionen kommer i drift. Det måste garanteras att överförda data valideras enligt de fastställda affärsreglerna.

Aktualitet:

Tillhandahållandet av information i rätt tid är en viktig aspekt. I den mån som datalagring eller sändning av meddelanden triggas direkt av händelser i IT-systemen är aktualiteten hos uppgifterna inget problem, förutsatt att systemet är välutformat i enlighet med affärsprocessernas krav. Men i de flesta fall sker sändningen av ett meddelande på initiativ av en operatör, eller åtminstone krävs det att en operatör tillför information, (till exempel när tågets sammansättning sänds eller när tåg- eller vagnrelaterade data uppdateras). För att tillgodose kraven på aktualitet måste uppdateringen av data ske så snart som möjligt, också för att garantera att de meddelanden som sänds ut automatiskt av systemet innehåller aktuella uppgifter.

Mätkriterier för datakvalitet

För fullständigheten (procent av datafälten som fyllts i med värden) när det gäller obligatoriska uppgifter och för samstämmigheten i uppgifterna (procent överensstämmande värden i olika tabeller/filer/dokument) måste en nivå på 100 % uppnås.

För aktualiteten hos uppgifterna (procent av uppgifterna som är tillgängliga inom angivna tidsramar) måste en nivå på 98 % uppnås. I den mån tröskelvärden inte fastställs i denna TSD, ska sådana värden anges i avtalen mellan berörda parter.

Den korrekthet som krävs (procent av lagrade värden som är korrekta när de jämförs med faktiska värden) ska ligga över 90 %. Det exakta värdet och kriterier ska fastställas i avtalen mellan berörda parter.

4.4.2 Driften av den centrala datakatalogen

Den centrala datakatalogens funktioner beskrivs i avsnitt 4.2.12.5 (Den centrala datakatalogen). I syfte att kvalitetssäkra uppgifterna ska det organ som driver den centrala datakatalogen vara ansvarigt för uppdateringen av och kvaliteten på metadata samt för administrationen av accesskontrollen. Kvaliteten på metadata med avseende på fullständighet, samstämmighet, aktualitet och korrekthet ska möjliggöra att denna TSD fungerar på lämpligt sätt.

4.5 Underhållsregler

Mot bakgrund av de väsentliga kraven i kapitel 3, gäller följande särskilda underhållsregler för det delsystem som omfattas av denna TSD:

Kvaliteten på transporttjänsterna måste garanteras även om det skulle uppstå driftstopp på hela eller delar av databehandlingsutrustningen. Det är därför tillrådligt att installera duplexsystem eller datorer med mycket hög tillförlitlighetsnivå, som garanterat kan fungera utan avbrott även i samband med underhåll.

Underhållsaspekterna när det gäller de olika databaserna tas upp i avsnitt 4.2.11.3 (Ytterligare krav på databaserna), punkterna 10 och 21.

4.6 Yrkeskvalifikationer

För den personal som ska svara för driften och underhållet av delsystemet och för genomförandet av TSD krävs följande yrkeskvalifikationer:

Genomförandet av denna TSD kräver inte något helt nytt hårdvaru- och mjukvarusystem som sköts av ny personal. Uppfyllandet av kraven i TSD medför endast förändringar, uppgraderingar eller utökad funktionalitet med avseende på den drift som redan sköts av befintlig personal. Därför tillkommer inga ytterligare krav utöver de nationella och europeiska bestämmelserna angående yrkeskvalifikationer.

Om vidareutbildning anses nödvändig, ska denna inte endast bestå i att man visar personalen hur de ska använda utrustningen. Alla i personalen måste också känna till och förstå den specifika roll de spelar i den övergripande transportprocessen. Personalen måste framför allt vara medveten om kravet att en hög nivå på yrkesskicklighet upprätthålls, eftersom detta är en avgörande faktor för tillförlitligheten hos den information som ska behandlas i senare led.

De yrkeskvalifikationer som krävs för sammansättning och drift av tåg anges i TSD Drift och trafikledning.

4.7 Hälso- och säkerhetskrav

Följande hälso- och säkerhetskrav gäller för den personal som ska svara för driften och underhållet av det berörda delsystemet (eller det tekniska tillämpningsområdet så som det definieras i avsnitt 1.1) och för genomförandet av TSD:

Det tillkommer inga ytterligare krav utöver de nationella och europeiska bestämmelserna angående hälsa och säkerhet.

5. DRIFTSKOMPATIBILITETSKOMPONENTER

5.1 Definition

Enligt artikel 2 f i direktiv 2008/57/EG [1]:

avses med driftskompatibilitetskomponenter: ”alla grundläggande komponenter, grupper av komponenter, underenheter eller kompletta enheter av materiel som har införlivats eller avses att införlivas i ett delsystem och som driftskompatibiliteten hos järnvägssystemet är direkt eller indirekt beroende av; begreppet ’komponent’ omfattar såväl materiella föremål som immateriella föremål, t.ex. programvara.”

5.2 Förteckning över komponenter

Driftskompatibilitetskomponenterna behandlas i de tillämpliga bestämmelserna i direktiv 2008/57/EG [1].

Det finns inga fastställda driftskompatibilitetskomponenter när det gäller delsystemet Telematikapplikationer för godstrafik.

För uppfyllandet av kraven i denna TSD krävs endast standard-IT-utrustning, utan några särskilda driftskompatibilitetsaspekter med avseende på järnvägsmiljön. Detta gäller för hårdvarukomponenter och för den standardmjukvara som används, som operativsystem och databaser. Applikationsprogrammet kan vara olika hos olika användare och kan anpassas och förbättras i enlighet med individuella faktiska funktioner och behov. Den föreslagna ”arkitekturen för programintegrering” utgår ifrån att programmen inte nödvändigtvis bygger på samma interna informationsmodell. Programintegrering definieras som processen att få individuellt utformade applikationssystem att fungera ihop.

5.3 Prestanda och specifikationer för komponenterna

Se avsnitt 5.2, ej relevant för TSD Telematikapplikationer för godstrafik.

6. BEDÖMNING AV KOMPONENTERNAS ÖVERENSSTÄMMELSE OCH/ELLER LÄMPLIGHET OCH KONTROLL AV DELSYSTEMET

6.1 Driftskompatibilitetskomponenter

6.1.1 Bedömningsförfaranden

Förfarandena för bedömning av komponenternas överensstämmelse eller lämplighet ska grunda sig på europeiska specifikationer eller specifikationer som godkänts i enlighet med direktiv 2008/57/EG [1].

När det gäller komponenternas lämplighet, anges i dessa specifikationer alla de parametrar som ska mätas, övervakas eller kontrolleras, och tillhörande testmetoder och förfaranden för mätning beskrivs, antingen för provning genom simulering i testbänk eller för provning i verklig järnvägsmiljö.

Förfaranden för bedömning av överensstämmelse och/eller lämplighet:

Förteckning över specifikationer, beskrivning av testmetoder:

Ej relevant för TSD Telematikapplikationer för godstrafik.

6.1.2 Modul

Förfarandet ska utföras av ett anmält organ som valts ut av tillverkaren eller dennes i gemenskapen etablerade ombud, i enlighet med bestämmelserna i relevanta moduler i kommissionens beslut 2010/713/EU som de angetts, ändrats och kompletterats i bilagan till denna TSD.

Modulerna bör kombineras och användas selektivt beroende på den enskilda komponenten.

Ej relevant för TSD Telematikapplikationer för godstrafik.

6.1.3 Delsystemet Telematikapplikationer för godstrafik

På begäran av en upphandlande enhet eller dess ombud i gemenskapen genomför det anmälda organet en EG-kontroll i enlighet med bilaga VI till direktiv 2008/57/EG [1].

Enligt bilaga II till direktiv 2008/57/EG [1] indelas delsystemen i strukturellt definierade och funktionellt definierade områden.

Bedömning av överensstämmelse är obligatorisk för TSD:er inom det strukturellt definierade området. Delsystemet Telematikapplikationer för godstrafik hör till det funktionellt definierade området och i denna TSD fastställs inga moduler för bedömning av överensstämmelse.

Emellertid utgör den centrala datakatalogen och det gemensamma gränssnittet vid varje användares nod en stomme för programintegreringen. Modellen för informationsutväxlingen finns lagrad i den centraliserade datakatalogen för programintegrering, där gränssnittets metadata finns lagrade på en fysisk plats. Metadata innehåller information om innehållet i kommunikationen (vad innehåller de data som sänds), identiteterna för avsändare och mottagare och affärsreglerna på applikationsnivå för samspelsprocessens mekanismer.

Följande punkter understryks:

—	Den centrala datakatalogen innehåller också certifieringsinstansen (CA för öppen PKI). Detta är i huvudsak en administrativ åtgärd som är fysiskt genomförd. Felaktiga inmatningar uppdagas omedelbart. Inget bedömningsförfarande krävs.

—

Den centrala datakatalogen innehåller de metadata för meddelandena (enligt dokumentet ”TSD TAF – Bilaga D. 2: Tillägg F– TSD TAF data- och meddelandemodell”, som förtecknas i tillägg I) som utgör grunden för utväxlingen av meddelanden i en heterogen informationsmiljö. Metadata måste administreras och uppdateras i den centrala datakatalogen. All inkompatibilitet i meddelandestrukturen eller innehållet i de meddelanden som används för att sända och ta emot uppgifter uppdagas omedelbart och överföringen vägras. Inget bedömningsförfarande krävs.

—

Det gemensamma gränssnittet vid varje aktörs nod innehåller huvudsakligen en lokal ”spegel” av den centrala datakatalogen för att korta svarstiderna och minska trycket på den centrala datakatalogen. Det måste garanteras att dataversionerna i den centrala datakatalogen och i det gemensamma gränssnittet alltid är desamma. Därför måste uppdateringen av data göras på central nivå och nya versioner laddas ned därifrån. Inget bedömningsförfarande krävs.

7. GENOMFÖRANDE

7.1 Metoder för tillämpning av denna TSD

7.1.1 Inledning

Denna TSD avser delsystemet Telematikapplikationer för godstrafik. Detta delsystem är funktionellt enligt bilaga II till direktiv 2008/57/EG [1]. Tillämpningen av denna TSD utgår därför inte från begreppet nytt, moderniserat eller ombyggt delsystem, vilket är brukligt för TSD:er i samband med strukturella delsystem, förutom där det är angivet i TSD:n.

TSD:n genomförs i följande etapper:

—	Fas 1: Detaljerade IT-specifikationer och översiktsplan.

—	Fas 2: Utveckling.

—	Fas 3: Införande.

7.1.2 Fas 1 – Detaljerade IT-specifikationer och översiktsplan

De funktionella kravspecifikationer som ska användas som grund för den ovan nämnda tekniska strukturen under utvecklingen och införandet av det datoriserade systemet anges i tilläggen A–F som förtecknas i tillägg I till denna förordning.

Den obligatoriska översiktsplanen från koncept till leverans av datorsystemet, som är baserad på den strategiska europeiska genomförandeplan som utarbetats av järnvägssektorn, inkluderar systemets grundläggande strukturkomponenter och identifierar de viktigaste aktiviteter som ska utföras.

7.1.3 Fas 2 och 3 – Utveckling och införande

Järnvägsföretag, infrastrukturförvaltare och fordonsinnehavare ska utveckla och införa TAF-datorsystemet i enlighet med bestämmelserna i detta kapitel.

7.1.4 Ledning, roller och ansvarsfördelning

Utvecklingen och införandet ska ske inom ramen för en ledningsstruktur med följande aktörer:

Styrkommittén

Styrkommittén ska ha följande funktioner och ansvarsområden:

Styrkommittén ska fastställa strukturen för strategisk förvaltning för att på ett effektivt sätt kunna förvalta och samordna arbetet med genomförandet av TAF–TSD. Det ska inbegripa utformning av politiken och den strategiska inriktningen samt fastställande av prioriteringar. De intressen som små företag, nya aktörer och järnvägsföretag som tillhandahåller särskilda tjänster har ska i detta sammanhang också beaktas av styrkommittén.

Styrkommittén ska övervaka hur genomförandet framskrider. Den ska minst fyra gånger om året regelbundet rapportera till Europeiska kommissionen om de framsteg som gjorts i förhållande till översiktsplanen. Styrkommittén ska vid avvikelse från översiktsplanen vidta nödvändiga åtgärder för att anpassa utvecklingen.

Styrkommittén ska bestå av följande:

—	De organ som företräder järnvägssektorn på europeisk nivå, enligt definitionen i artikel 3.2 i förordning (EG) nr 881/2004 (nedan kallade de organ som företräder järnvägssektorn).

—	Europeiska järnvägsbyrån.

—	Kommissionen.

2.	Styrkommittén ska ledas gemensamt av a) kommissionen och b) en person som utsetts av de organ som företräder järnvägssektorn. Kommissionen ska med bistånd av styrkommitténs medlemmar utarbeta kommitténs arbetsordning, som styrkommittén ska enas om.

3.	Medlemmarna i styrkommittén får föreslå för styrkommittén att andra organisationer ska få delta som observatörer om det finns välgrundade tekniska och organisatoriska skäl för detta.

Berörda parter

Järnvägsföretag, infrastrukturförvaltare och fordonsinnehavare ska inrätta en effektiv projektledningsstruktur som gör det möjligt att utveckla och införa TAF-system på ett effektivt sätt.

De berörda parterna ska

—	vidta nödvändiga åtgärder och tillhandahålla de resurser som krävs för att genomföra denna förordning,

—	efterleva principerna om tillgång till gemensamma komponenter för TSD TAF som ska vara tillgängliga för alla marknadsaktörer till enhetlig, transparent och lägsta möjliga kostnad för tjänsterna,

—	säkerställa att alla marknadsaktörer har tillgång till allt informationsutbyte som krävs för att fullgöra sina juridiska skyldigheter och utföra uppgifterna i enlighet med funktionskraven för TSD TAF,

—	tillgodose sekretesskyddet vid kundrelationer,

—

inrätta en mekanism som gör det möjligt för ”nytillkomna” att ansluta sig till TAF-utvecklingen och dra nytta av de framsteg som gjorts på detta område vad gäller gemensamma komponenter på ett tillfredsställande sätt både för ovan nämnda intressenter och ”nytillkomna”, i synnerhet när det gäller en rättvis modell för kostnadsfördelning,

—	rapportera till TAF-styrkommittén om hur arbetet med att genomföra planerna fortskrider. I denna rapportering ingår också – i tillämpliga fall – avvikelser från översiktsplanen.

Organ som företräder järnvägssektorn

De organ som företräder järnvägssektorn på europeisk nivå i enlighet med definitionen i artikel 3.2 i Europaparlamentets och rådets förordning (EG) nr 881/2004/EG (1) ska ha följande funktioner och ansvarsområden:

—	Företräda de enskilda medlemmarna i TSD TAF-styrkommittén.

—	Öka medvetenheten hos medlemmarna om deras skyldigheter i samband med tillämpningen av denna förordning.

—	Säkerställa löpande och fullständig tillgång för alla ovannämnda intressenter till aktuell information om arbetet i styrkommittén och andra grupper för att tillgodose varje företrädares intressen i samband med genomförandet av TSD TAF.

—	Säkerställa ett effektivt informationsflöde från enskilda medlemmar i TAF-styrkommittén så att de berörda parternas intressen vederbörligen beaktas vid beslut som påverkar utvecklingen och införandet av TAF.

—	Säkerställa ett effektivt informationsflöde från TAF-styrkommittén till företrädarna för enskilda berörda parter så att de informeras om beslut som påverkar utvecklingen och införandet av TAF.

7.2 Förändringshantering

7.2.1 Förändringshanteringsprocess

Förändringshanteringsprocesserna bör utformas så att kostnaderna för och nyttan med ändringarna analyseras ordentligt och så att ändringarna genomförs på ett kontrollerat sätt. Dessa processer ska definieras, inrättas, stödjas och utföras under ledning av Europeiska järnvägsbyrån och ska omfatta följande:

—	Identifiering av de tekniska begränsningar som ligger till grund för ändringen.

—	Redogörelse för vem som ansvarar för förändringshanteringsprocessen.

—	Valideringsprocess för de ändringar som ska genomföras.

—	Policy för förändringshantering, frisläppande, övergång och spridning.

—	Ansvarsfördelning för hanteringen av de detaljerade specifikationerna och för både kvalitetssäkring och konfigurationsstyrning av dem.

Förändringskontrollgruppen (CCB) ska bestå av Europeiska järnvägsbyrån, organ som företräder järnvägssektorn och de nationella säkerhetsmyndigheterna. Ett sådant deltagande från parterna ska ge perspektiv på de ändringar som behöver göras och en övergripande bedömning av ändringarnas effekter. Kommissionen får utvidga förändringskontrollgruppen med fler parter om deras deltagande anses vara nödvändigt. CCB kommer slutligen att ställas under Europeiska järnvägsbyråns kontroll.

7.2.2 Särskild förändringshanteringsprocess för dokument som förtecknas i tillägg I till denna förordning

Förändringshanteringsprocessen för de dokument som förtecknas i tillägg I till denna förordning ska fastställas av Europeiska järnvägsbyrån i enlighet med följande kriterier:

Ändringsbegäran som påverkar dokumenten lämnas in antingen via de nationella säkerhetsmyndigheterna, eller via de organ som företräder järnvägssektorn på europeisk nivå enligt definitionen i artikel 3.2 i förordning (EG) nr 881/2004/EG, eller genom styrkommittén för TSD TAF. Kommissionen får inkludera fler parter som lämnar in en begäran om deras medverkan anses nödvändig.

2.	Europeiska järnvägsbyrån ska samla in och lagra ändringsbegäran.

3.	Europeiska järnvägsbyrån ska lägga fram ändringsbegäran för byråns särskilda arbetsgrupp som gör en utvärdering, utarbetar ett förslag och gör en ekonomisk bedömning, där så är lämpligt.

4.	Därefter ska Europeiska järnvägsbyrån lägga fram ändringsbegäran och det tillhörande förslaget för ändringshanteringsgruppen som beslutar huruvida ändringsbegäran ska valideras eller skjutas upp.

5.	Om ändringsbegäran inte valideras, ska Europeiska järnvägsbyrån till den sökande skicka antingen skälet för avslaget eller en begäran om ytterligare information om utkastet till ändringsbegäran.

6.	Dokumentet ska ändras på grundval av den godkända ändringsbegäran.

7.	Europeiska järnvägsbyrån ska för kommissionen lägga fram en rekommendation om uppdatering av tillägg I med förslag till ny version av dokumentet, ändringsbegäran och deras ekonomiska utvärdering.

8.	Europeiska järnvägsbyrån ska lägga upp förslaget till ny version av dokumentet och den godkända ändringsbegäran på sin webbplats.

När uppdatering av tillägg I har offentliggjorts i Europeiska unionens officiella tidning ska Europeiska järnvägsbyrån lägga upp den nya versionen av dokumentet på sin webbplats.

Om förändringshanteringsprocessen påverkar delar som används genomgående i TSD TAP [2], ska ändringarna göras så att de i största möjliga utsträckning överensstämmer med den genomförda TSD TAP [2] för att optimera synergieffekterna.

(1) Europaparlamentets och rådets förordning (EG) nr 881/2004/EG av den 29 april 2004 om inrättande av en europeisk järnvägsbyrå (järnvägsbyråförordningen) (EUT L 164, 30.4.2004, s. 1).

Tillägg I

Förteckning över tekniska dokument

Nr	Referens	Titel	Version	Datum
1	ERA-TD-100	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – BILAGA A.5: SIFFROR OCH SEKVENSDIAGRAM I TSD TAF-MEDDELANDEN	2.0	17.10.2013
2	ERA-TD-101	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – Bilaga D.2: Tillägg A (vagn/ILU-färdplanering)	2.0	17.10.2013
3	ERA-TD-102	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – Bilaga D.2: Tillägg B – vagnar och driftsdatabas för intermodala enheter (WIMO)	2.0	17.10.2013
4	ERA-TD-103	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – Bilaga D.2: Tillägg C – referensfiler	2.0	17.10.2013
5	ERA-TD-104	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – Bilaga D.2: Tillägg E – Gemensamt gränssnitt	2.0	17.10.2013
6	ERA-TD-105	TSD:n avseende delsystemet Telematikapplikationer för godstrafik – Bilaga D.2: Tillägg F – Data och meddelandemodell för TSD:n avseende delsystemet Telematikapplikationer för godstrafik	2.0	17.10.2013

Tillägg II

Ordlista

Term

Beskrivning

ACID

Atomicitet, konsistens, isolering, beständighet

De fyra grundläggande egenskaper som ska garanteras för varje transaktion:

Atomicitet. I en transaktion som berör två eller flera separata uppgifter, ska antingen alla eller ingen av uppgifterna utföras.

Konsistens. Antingen leder en transaktion till en ny giltig datastatus, eller också, om något fel uppstår, återställs alla data till den status som rådde innan transaktionen inleddes.

Isolering. En pågående transaktion som ännu inte slutförts ska hållas isolerad från andra transaktioner.

Beständighet. Bekräftade data sparas av systemet på ett sådant sätt att alla data, även i händelse av avbrott och omstart av systemet, förblir tillgängliga i sin korrekta status.

ACID-konceptet beskrivs i ISO/IEC 10026-1:1992 del 4. Alla dessa egenskaper kan mätas mot riktmärken. I allmänhet har dock en transaktionshanterare eller transaktionsövervakare utsetts för att förverkliga ACID-konceptet. I ett distribuerat system är ett sätt att uppnå ACID att tillämpa tvåfas-commit (2PC), vilket säkerställer att alla inblandade parter måste åta sig att slutföra transaktionen eller att ingen gör det och transaktionen avbryts.

Tilldelningsorgan

Se ”IM”.

Sökande:

en RU eller en internationell sammanslutning av RU eller andra fysiska eller juridiska personer, såsom till exempel behöriga myndigheter enligt förordning (EG) nr 1370/2007 och befraktare, speditörer samt operatörer för kombinerade transporter, som har ett allmännyttigt eller kommersiellt intresse av att ansöka om infrastrukturkapacitet (direktiv 2012/34/EU [3]). För tilldelningsorgan: Se ”IM”-definition.

Heltåg

En särskild form av direkttåg med endast så många vagnar som krävs, som framförs mellan två omlastningspunkter utan mellanliggande rangering.

Bokning

Processen att reservera utrymme på ett transportmedel för förflyttning av gods.

Certifieringsinstans

KN-nummer

Åttasiffrig kod enligt en produktförteckning som används av tullen.

Kombinerad väg- och järnvägstransport

Intermodal transport där större delen av färden inom Europa sker på järnväg, medan de initiala och/eller slutliga sträckorna på väg är så korta som möjligt.

Mottagare

Den part som ska ta emot godset.

Synonym: Godsmottagare

Försändelse

Gods som skickas inom ramen för ett enda transportavtal. Vid kombinerad transport kan denna term användas för statistiska ändamål, för att mäta lastenheter eller vägfordon.

Fraktsedel

Ett dokument som bestyrker en överenskommelse om att ett transportföretag ska transportera en försändelse från en namngiven inlämningsplats till en namngiven leveransplats. Fraktsedeln innehåller uppgifter om den försändelse som ska transporteras.

Avsändare

Den part som, genom avtal med en transportsamordnare, skickar gods med ett transportföretag.

Synonymer: godsavsändare.

Samarbete

Tågdrift där flera RU samarbetar under ledning av en RU (LRU). Varje berörd RU avtalar själv om det tågläge som krävs för transporten.

COTS-produkt

Hyllvara (Commercially off the shelf).

Kund

Den enhet som har utfärdat en fraktsedel till LRU.

Datum och tid för avgång, faktiskt

Datum (och tid) för avgång för ett transportmedel.

Direkttåg

Ett tåg med tillhörande vagnar som framförs mellan två omlastningspunkter (ursprunglig källa–slutdestination) utan mellanliggande rangering.

Ansvarig

En fysisk eller juridisk person som ansvarar för den risk som denne tillför på nätet, dvs. RU.

Kryptering

Kodning av meddelanden.

Dekryptering: konvertering av krypterade data tillbaka till ursprunglig form.

Väsentliga krav

Med väsentliga krav avses alla krav i bilaga III till Europaparlamentets och rådets direktiv 2001/16/EG (*1) och som ska uppfyllas av det transeuropeiska järnvägssystemet för konventionella tåg, delsystemen, driftskompatibilitetskomponenterna och även gränssnitten.

ETA

Beräknad ankomsttid.

ETH

Beräknad tidpunkt för överlämnande – Estimated Time of Handover (av ett tåg från en IM till en annan).

ETI

Beräknad tidpunkt för utväxling (Estimated Time of Interchange) av vagnar från en RU till en annan.

Prognostiserad tid

Bästa beräkning av ett tågs tid för avgång, ankomst eller passering.

FTP

File Transfer Protocol

Ett protokoll för filöverföring mellan datorsystem i TCP/IP-nätverk.

Omlastningsplats

Station inom en färd för ett tåg med intermodala enheter, där lasten flyttas mellan vagnar.

GGP

Gateway to Gateway Protocol.

Se även IP

Lastens bruttovikt

Bokad/faktisk totalvikt (massa) av gods, inklusive emballage men exklusive transportutrustning.

Hanteringspunkt

Station där RU kan ändra tågets sammansättning, men där samma RU förblir ansvarig för vagnarna – ingen förändring av ansvarigheten.

Överlämningspunkt

Punkt där ansvaret övergår från en IM till en annan.

Åkerinäring

Vägtransport

Hyrestagare

Varje fysisk eller juridisk person som definieras som sådan av en vagns innehavare/ägare.

HS-nummer

6-siffrig kod enligt en produktförteckning som används av tullen, identisk med de första 6 siffrorna i KN-numret.

HTTP

Hypertext Transfer Protocol

Det klient/serverprotokoll som används för att kommunicera med servrar på Internet.

ICMP

Internet Control Message Protocol (ICMP)

Ibland måste en gateway (se GGP) eller destinationsvärddator (se IP) kommunicera med en källvärddator, till exempel för att rapportera ett fel i datapaketförmedlingen. Detta protokoll, Internet Control Message Protocol (ICMP), används för detta syfte. ICMP stödjer sig på IP, som om det vore ett protokoll på högre nivå, men ICMP är egentligen en del av IP, och måste implementeras av varje IP-modul. ICMP-meddelanden sänds i flera olika situationer: till exempel när ett datapaket inte kan nå fram till sin destination, när gatewayen inte har tillräcklig buffringskapacitet för att förmedla ett datapaket, eller när gatewayen kan anvisa värddatorn att skicka trafik en kortare väg. Internet Protocol är inte utformat för att vara fullständigt tillförlitligt. Syftet med dessa kontrollmeddelanden är att tillhandahålla återkoppling angående problem i kommunikationsmiljön, inte att göra IP tillförlitligt. Det finns fortfarande inga garantier för att ett datapaket levereras eller för att ett kontrollmeddelande sänds tillbaka. Vissa datapaket kan förbli olevererade, utan någon rapport om deras försvinnande. De protokoll på högre nivå som använder IP måste bygga in egna procedurer för att säkra tillförlitligheten om tillförlitlig kommunikation krävs. ICMP-meddelanden rapporterar i allmänhet om fel i förmedlingen av datapaket. För att undvika en evig återkoppling av meddelanden om meddelanden etc., skickas inga ICMP-meddelanden om ICMP-meddelanden. ICMP-meddelanden sänds också bara angående fel i hanteringen av fragment 0 av fragmenterade paket. (Fragment 0 har offset 0).

Infrastrukturförvaltare: varje organ eller företag som särskilt ansvarar för att anlägga, förvalta och underhålla järnvägsinfrastruktur, inklusive trafikledning, trafikstyrning och signalering. Infrastrukturförvaltarens uppgifter med avseende på järnvägsnät eller del av ett järnvägsnät får tilldelas olika organ eller företag. Om infrastrukturförvaltaren inte är oberoende i förhållande till samtliga järnvägsföretag, till sin juridiska form och med avseende på organisation eller beslutsfattande, ska de uppgifter som avses i avsnitt 2 och 3 i kapitel IV utföras av ett avgiftsorgan respektive av ett tilldelningsorgan som är oberoende i förhållande till samtliga järnvägsföretag till sin juridiska form och med avseende på organisation och beslutsfattande. (Direktiv 2012/34/EU [3])

Infrastrukturförvaltare (IM)

Se ”IM”.

Överföring

Överföringen av kontrollen från ett järnvägsföretag till ett annat av praktiska driftsmässiga eller säkerhetsrelaterade skäl. Som exempel kan nämnas följande:

—	Blandade tjänster.

—	Transporter med delat ansvar för driften.

—	Överföring av information mellan olika järnvägsförvaltningar.

—	Överföring av information mellan vagnägare/-innehavare och tågoperatörer.

Utväxlingspunkt

Position där ansvaret för vagnarna i ett tåg överförs från en RU till en annan RU.

När det gäller ett tåg under framförande, tas tåget över från en RU till en annan RU som då är innehavare av tågläget för nästa delsträcka.

Mellanliggande punkt

Position som anger utgångspunkt eller destination för en delsträcka. Detta kan vara t.ex. en utväxlings-, överlämnings-, eller hanteringspunkt.

Operatör för intermodala transporter

Enhet som ingår ett multimodalt transportavtal och tar på sig hela ansvaret för transport av intermodala lastenheter.

Samordnare för intermodala transporter

Organ eller företag som har slutit avtal med kunder för transport av intermodala enheter. Samordnaren upprättar speditörsfraktsedlar, hanterar kapaciteten i heltåg etc.

Intermodal terminal

Plats med avsett utrymme, utrustning och driftsmiljö för överföring av lastenheter (fraktcontainrar, växelflak, semitrailers eller trailers).

Intermodala transporter

Förflyttning av gods i en och samma lastenhet eller fordon som använder flera transportsätt i följd utan någon hantering av godset i sig vid övergångarna mellan transportsätten.

Intermodala enheter

En lastenhet som kan transporteras med olika transportsätt t.ex. container, växelflak, semitrailer, trailer.

Internet

—	Ett stort nätverk uppbyggt av flera mindre nätverk.

—	En grupp av nätverk som är sammankopplade så att de fungerar som ett enda sammanhängande stort nätverk till vilket sömlös anslutning kan uppnås i OSI-referensmodellens nätverksskikt genom routrar.

—	Det industriella namnet på det nätverk som används som referensresurs för e-post och chatrum med användare över hela världen.

Driftskompatibilitetskomponent

Alla grundläggande komponenter, grupper av komponenter, underenheter eller kompletta enheter av materiel som har införlivats eller avses att införlivas i ett delsystem och som driftskompatibiliteten hos det transeuropeiska järnvägssystemet för konventionella tåg är direkt eller indirekt beroende av. Begreppet ”komponent” omfattar såväl materiella föremål som immateriella föremål, t.ex. programvara.

Internetprotokoll

Internet Protocol (IP) används för att skicka datapaket mellan värddatorer i ett system av sammankopplade nätverk.

Anslutningsenheterna till nätverket kallas gatewayer. Gatewayerna kommunicerar sinsemellan i kontrollsyfte via Gateway to Gateway Protocol (GGP).

Färd

En ”färd” anger rumslig befordran av en lastad eller tom vagn från avsändningsstation till destinationsstation.

Delsträcka

Del av en färd som äger rum på ett avsnitt av en infrastrukturförvaltares infrastruktur eller

del av en färd, från en överlämningspunkt där inträde på en infrastrukturförvaltares infrastruktur sker och till en överlämningspunkt där utträde från samma infrastruktur sker.

Innehavare

Den person som, i egenskap av ägare eller innehavare av nyttjanderätten till ett fordon, på permanent basis använder fordonet i ekonomisk verksamhet som ett transportmedel, och som är registrerad som sådan i Registret för rullande materiel.

Huvudansvarigt järnvägsföretag, LRU (Lead Railway Undertaking)

Ansvarig RU, som organiserar och hanterar transportkedjan i enlighet med åtagandet gentemot kunden. LRU är kundens enda kontaktpunkt. Om mer än en RU ingår i transportkedjan, ansvarar LRU för samordningen mellan de olika RU. En kund kan, särskilt när det gäller intermodala transporter, vara en samordnare för intermodala transporter.

Loknummer

Ett dragfordons unika identifieringsnummer.

LRU

Se Huvudansvarigt järnvägsföretag, LRU (Lead Railway Undertaking)

KAN/FÅR

Dessa ord, eller adjektivet ”FRIVILLIG(T)”, innebär att ett moment verkligen är frivilligt. En leverantör kan välja att ta med momentet, eftersom en viss marknadsplats kräver detta, eller för att leverantören anser att det höjer värdet på produkten då andra leverantörer kan välja att utesluta samma moment.

En implementering som inte inbegriper ett visst alternativ MÅSTE kunna fungera ihop med en annan implementering som inbegriper alternativet, dock eventuellt med nedsatt funktionalitet. På samma sätt

MÅSTE en implementering som inbegriper ett visst alternativ kunna fungera ihop med en annan implementering som inte inbegriper alternativet (förutom, naturligtvis, vad gäller den egenskap som alternativet tillför).

Metadata

Enkelt beskrivet data om data. Metadata beskriver data, mjukvarutjänster och andra komponenter som ingår i en verksamhets informationssystem. Exempel på typer av metadata är definitioner av standarddata, positions- och routing-information samt synkroniseringshantering för distribution av delade data.

MÅSTE

Detta ord eller termerna ”KRÄVS” eller ”SKA” innebär ett absolut krav enligt specifikationerna.

FÅR INTE

Denna fras eller frasen ”SKA INTE” innebär ett absolut förbud enligt specifikationerna.

NFS

Network File System (NFS) är ett protokoll för distribuerade filsystem.

NFS-protokollet tillhandahåller transparent fjärrtillgång till delade filsystem över nätverk. NFS-protokollet är konstruerat för att vara oberoende av dator, operativsystem, nätverksarkitektur, säkerhetsmekanism och transportprotokoll. Detta oberoende åstadkoms genom användning av fjärrproceduranrop (Remote Procedure Call, RPC) som byggs ovanpå en extern datarepresentation (XDR).

Anmälda organ

Organ som ansvarar för att bedöma driftskompatibilitetskomponenternas överensstämmelse och lämplighet eller för att utvärdera EG:s förfarande för kontroll av delsystemen. (Rådets direktiv 91/440/EEG av den 29 juli 1991 om utvecklingen av gemenskapens järnvägar (1).

One Stop Shop (OSS)

Ett internationellt partnerskap mellan järnvägsinfrastrukturförvaltare som tillhandahåller en gemensam kontaktpunkt för järnvägskunder för följande syften:

—	Bokning av specifika tåglägen för internationell godstrafik.

—	Övervakning av hela tågrörelsen.

—	I allmänhet även fakturering av banavgifter på IM:s vägnar.

Öppen tillgång

Typ av tågdrift som involverar endast en RU, vilken framför tåget på olika infrastrukturer. Denna RU avtalar om de tåglägen som krävs med alla berörda IM.

OSI

Open Systems Interconnection

Beskriver ett kommunikationsprotokoll för öppna system baserat på OSI-referensmodellen. Öppna system kan kommunicera oberoende av leverantörsspecifika lösningar.

OSI-referensmodellen

Standardiserad beskrivning av hur meddelanden bör överföras mellan två punkter i ett nätverk. OSI-modellen definierar 7 skikt med var sin funktion som äger rum i bägge ändar av en kommunikation. Dessa skikt är det enda internationellt erkända ramverket för kommunikationsstandarder.

OSS

One Stop Shop

Tågläge

Den infrastrukturkapacitet som krävs för att framföra ett tåg mellan två platser inom en viss tidsperiod (färdväg definierad i tid och rum).

Kombination av tåglägen

Sammanfogning av enskilda tåglägen för att utöka ett tågläge i fråga om tid och rum.

Tåglägesidentitet

Nummer på ett angivet tågläge.

Peer-to-peer

Termen ”peer-to-peer” refererar till en typ av system och applikationer som använder distribuerade resurser för att utföra en kritisk funktion på ett decentraliserat sätt. Resurserna omfattar datorkraft, data (lagring och innehåll), nätverksbandbredd samt närvaro (datorer, människor och andra resurser). Den kritiska funktionen kan vara distribuerad databehandling, data-/innehållsdelning, kommunikation och samarbete eller plattformstjänster. Decentralisering kan gälla algoritmer, data och metadata, eller alla dessa. Detta utesluter inte att centralisering kan behållas för vissa delar av systemen och applikationerna om så krävs.

PKI

Infrastruktur för öppen nyckel-kryptering (public key infrastructure)

Leveransplats

Plats där leverans sker (avgångsjärnvägsstation ska anges). En plats där ansvaret för vagnen ändras.

Utgångspunkt

Plats varifrån ett transportmedel ska avgå enligt tidtabell eller har avgått.

Destination

Plats till vilken ett transportmedel ska ankomma eller har ankommit.

Synonymer: Ankomstplats

Perioden före avgång

Deltatiden före avgångstid enligt tidtabell. Perioden före avgång börjar vid avgångstiden enligt tidtabell minus deltatiden och slutar vid avgångstiden enligt tidtabell.

Primärdata

Grundläggande data som referensindata för meddelanden eller som grund för funktionalitet och beräkning av härledda data.

Idrifttagande

Ett förfarande som är beroende av ett tekniskt godkännande av en vagn samt ett avtal om användning med en RU, som tillåter att vagnen tas i kommersiell drift.

Järnvägsföretag, RU (Railway Undertaking)

Järnvägsföretag (direktiv 2004/49/EG) [9]: järnvägsföretag enligt definitionen i direktiv 2001/14/EG, samt andra offentliga eller privata företag vars verksamhet består i att tillhandahålla gods- och/eller persontrafik på järnväg med krav på att företaget ska sörja för traktion (dragkraft); Detta gäller även företag som endast tillhandahåller dragkraft.

RAMS

Se Tillförlitlighet, tillgänglighet, underhållsmässighet, säkerhet (RAMS).

RARP

Reverse Address Resolution Protocol (RARP)

Datum och tid för frisläppande

Datum och tid då godset väntas frisläppas eller frisläpptes av kunden.

Tiden för frisläppande av vagnar

Datum och tid då vagnarna är klara att dras från en angiven plats på kundens rangerbangård.

Tillförlitlighet, tillgänglighet, underhållsmässighet, säkerhet (RAMS)

Tillförlitlighet (reliability)– Förmågan att starta och fortsätta att fungera under angivna driftsförhållanden under en angiven tidsperiod, matematiskt uttryckt.

Tillgänglighet (availability)– Tid i drift jämfört med tid ur drift, matematiskt uttryckt.

Underhållsmässighet (maintainability)– Förmågan hos ett system att återgå i drift efter ett avbrott, matematiskt uttryckt.

Säkerhet (safety)– Sannolikheten att en riskfylld händelse initieras av systemet, matematiskt uttryckt.

Rapporteringspunkt

Position längs tågets färd, där ansvarig IM ska utfärda ett ”meddelande om tågföringsprognos” med TETA till den RU som avtalat om tågläget.

Datakatalog

En datakatalog (”repository”) liknar en databas och ett ”data dictionary”, men inbegriper vanligtvis ett omfattande informationshanteringssystem. Den måste innehålla inte bara beskrivningar av datastrukturer (dvs. enheter och element), utan också metadata av intresse för företaget, skärmvyer, rapporter, program, och system. I typfallet innehåller den en intern uppsättning programverktyg, en DBMS, en metamodell, ifyllda metadata samt laddnings- och hämtningsprogram för tillgång till data i datakatalogen.

RIV

Föreskrifter om ömsesidigt utnyttjande av godsvagnar i internationell järnvägstrafik.

Föreskrifter om ömsesidigt utnyttjande av lastutrustning, containrar och lastpallar i internationell järnvägstrafik.

Färdväg

Den geografiska väg som ska tas från en utgångspunkt till en destination.

Färdvägsavsnitt

En del av en färdväg.

RPC

Remote Procedure Call

RPC-protokollet beskrivs i Remote Procedure Call Protocol Specification Version 2 [RFC1831].

Se Järnvägsföretag, RU (Railway Undertaking)

Avgångstid enligt tidtabell

Datum och tid enligt tilldelat tågläge.

Tidtabell

Kronologiskt definierad beläggning av järnvägsinfrastrukturen för en tågrörelse på linjen eller inom stationer. Tidtabellsändringar ska tillhandahållas av IM minst 2 dagar före inledningen av den dag då tåget ska avgå från sin utgångsplats. Denna tidtabell gäller för en viss angiven dag. Kallas i vissa länder Operational Timetable.

Tjänsteleverantör

Ansvarigt transportföretag för ett specifikt transportsteg. Part som tar emot och hanterar bokningen.

Försändelse

Ett godskolli från en avsändare till en mottagare, som lastas i en eller flera hela intermodala enheter eller som lastas på en eller flera hela vagnar.

Exempelvis

Ansökan om tågläge i korttidstilldelningsprocessen

Ad hoc-ansökan om enskilt tågläge i enlighet med artikel 23 i direktiv 2001/14/EG med anledning av ytterligare transportbehov eller driftsbehov.

BÖR

Detta ord, eller adjektivet ”REKOMMENDERAD”, innebär att det kan finnas giltiga skäl under vissa omständigheter att ignorera ett visst moment, men de fullständiga följderna måste vara kända och noggrant övervägda innan en annan kurs väljs.

BÖR INTE

Denna fras, eller frasen ”INTE REKOMMENDERAD” innebär att det kan finnas giltiga skäl under vissa omständigheter som gör att ett visst beteende är acceptabelt eller till och med lämpligt, men de fullständiga följderna måste vara kända och fallet noga övervägt innan något beteende som beskrivs under denna beteckning implementeras.

SMTP

Simple Mail Transfer Protocol.

SNMP

Simple Network Management Protocol.

SQL

Structured Query Language.

Ett språk konstruerat av IBM, senare standardiserat av ANSI och ISO, som används för att skapa, hantera och hämta data i relationsdatabaser.

Berörda parter

Personer eller organisationer med skäliga intressen i tillhandahållandet av tågtjänster t.ex.

järnvägsföretag (RU),

tillhandahållare av övervakning av försändelser,

tillhandahållare av lok,

tillhandahållare av vagnar,

tillhandahållare av förare/tågpersonal,

tillhandahållare av rangerbangårdar,

tillhandahållare av växlingslok,

transportsamordnare,

tillhandahållare av tåglägen (IM),

tågledare (IM),

trafikledare,

vagnparksförvaltare,

tillhandahållare av färjor,

vagns- och lokinspektörer,

tillhandahållare av vagns- och lokreparationer,

godshanterare,

tillhandahållare av växling och vallväxling,

tillhandahållare av logistik,

godsmottagare,

avsändare

för intermodala transporter tillkommer

tillhandahållare av containrar,

operatörer för intermodala terminaler,

tillhandahållare av lastbilssläp/åkeriföretag,

fartyg,

pråmar.

TCP

Transmission Control Protocol (TCP)

Tekniska specifikationer för driftskompatibilitet

Specifikationer som beskriver hur ett delsystem eller del av ett delsystem ska uppfylla de väsentliga kraven och garantera driftskompatibilitet inom det transeuropeiska järnvägssystemet för konventionella tåg.

TETA

Se Beräknad tid för tågets ankomst (Train Estimated Time of Arrival)

Spårning

Aktivitet som innebär att man på begäran letar upp och rekonstruerar transporthistorien för en viss försändelse, fordon, utrustning, kolli eller last.

Lokalisering

Aktivitet som innebär att man systematiskt övervakar och registrerar aktuell position och status för en viss försändelse, fordon, utrustning, kolli eller last.

Beräknad tid för tågets ankomst (TETA)

Beräknad tid för ett tågs ankomst till en viss punkt, t.ex. en hanteringspunkt, en utväxlingspunkt eller tågets destination.

Tågläge

Ett tågs färdväg definierad i tid och rum.

Tågläge

En beskrivning av ett tågs färdväg i termer av tider och platser (hållpunkter) för färdvägens början och slut, tillsammans med uppgifter om de platser längs vägen där tåget ska passera eller göra uppehåll. Beskrivningen kan också omfatta aktiviteter som ska ske längs tågets färd, till exempel byten av tågpersonal, lok eller annat.

Det transeuropeiska järnvägsnätet

Det järnvägsnät som beskrivs i bilaga 1 till direktiv 2001/16/EG (*1).

Omlastning

Momentet att flytta intermodala lastenheter från ett transportmedel till ett annat.

Färdplan

En referensplan som visar den planerade färden för en vagn eller intermodal enhet.

TSD

Se Tekniska specifikationer för driftskompatibilitet.

Tunnling

En process varigenom privata IP-paket kapslas in i ett publikt IP-paket.

UDP

User Datagram Protocol

Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs) (STUN) är ett lättviktigt protokoll som gör att applikationer kan upptäcka förekomsten och typen av NAT-enheter och brandväggar mellan dem och det publika Internet. Det ger också möjlighet för applikationer att fastställa vilka IP-adresser de tilldelats via NAT. STUN fungerar med många befintliga NAT-enheter och kräver inget särskilt beteende från dem. Därmed gör STUN att många olika applikationer kan fungera via befintlig NAT-infrastruktur.

UIC

Internationella järnvägsunionen.

UITP

UITP är den internationella unionen för kollektivtrafik.

UNIFE

UNIFE är en organisation som tillvaratar intressen för leverantörer till järnvägssektorn. För närvarande är omkring 100 leverantörer och underleverantörer direkt representerade och omkring 1 000 indirekt genom nationella organisationer.

Använd kapacitet i enheten

Uttryck för i vilken utsträckning utrustningen är lastad eller tom. (t.ex. full, tom, LCL).

Lastenhet

Ett antal enskilda paket som satts ihop, lastats på en pall eller bundits samman så att de formar en enda enhet för effektivare hantering med hjälp av mekanisk utrustning.

Systemtåg

Ett godståg som skickas i väg på grundval av en enda fraktsedel och med endast en typ av gods och som består av enhetliga vagnar som framförs från en avsändare till en mottagare utan mellanliggande rangering.

VPN

Virtual Private Network (virtuellt privat nät)

Termen Virtual Private Network har använts för att beskriva nästan alla typer av fjärranslutningssystem, såsom det allmänna telefonnätet och Frame Relay-PVC:er.

I och med internets intåg, har VPN blivit synonymt med IP-baserad fjärranslutning till datanätverk. Enkelt uttryckt består ett VPN av två eller flera privata nätverk som kommunicerar säkert över ett publikt nätverk.

VPN kan upprättas mellan en enskild dator och ett privat nätverk (klient-till-server) eller ett fjärrnätverk och ett privat nätverk (server-till-server). De privata nätverken kan anslutas med hjälp av tunnling. Ett VPN använder i allmänhet internet som ett underliggande transportnät, men krypterar de data som sänds mellan en VPN-klient och en VPN-gateway för att se till att de inte kan läsas även om de skulle läsas av under överföringen.

Vagnslast

En lastenhet där enheten är en vagn.

Fraktorder

En del av fraktsedeln som visar den information som en RU behöver för att utföra transporten under sitt ansvar fram till överlämning till nästa RU.

Instruktion för transporten av en vagnförsändelse.

Speditörsfraktsedel

Dokument som utfärdas av transportören eller för dennes räkning som bevis på avtalad transport av gods.

Webben

World Wide Web.

En internettjänst som länkar dokument genom att tillhandahålla hypertextlänkar från server till server så att en användare kan gå från ett dokument till ett relaterat dokument oberoende av var detta är lagrat på Internet.

XDR

External Data Representation.

XDR-protokollet beskrivs i External Data Representation Standard [RFC1832].

XDR är en standard för beskrivning och kodning av data. Det är användbart för överföring av data mellan olika dataarkitekturer. XDR passar in i OSI-modellens presentationsskikt, och är till sitt syfte i grova drag analogt med X.409, ISO Abstract Syntax Notation. Den största skillnaden mellan dessa två är att XDR använder implicit typning, medan X.409 använder explicit typning. XDR använder ett språk för att beskriva dataformat. Språket kan endast användas för att beskriva data. Det är inte ett programmeringsspråk. Detta språk möjliggör beskrivningar av komplicerade dataformat på ett koncist sätt. Alternativet att använda grafiska representationer (i sig ett informellt språk) blir snabbt obegripligt när komplexiteten ökar. XDR-språket i sig liknar C-språket. Protokoll som ONC RPC (Remote Procedure Call) och NFS (Network File System) använder XDR för att beskriva formatet på deras data. XDR-standarden gör följande antagande: att bytes (oktetter) är portabla, där en byte definieras som 8 bitar (bits). En viss hårdvaruenhet bör koda bytes på de olika medierna på ett sådant sätt att andra hårdvaruenheter kan avkoda dem utan meningsförlust.

XML-RPC

XML-RPC står för Extensible Mark-up Language-Remote Procedure Calling och är ett protokoll som fungerar över internet. Det definierar ett XML-format för meddelanden som överförs mellan klienter och servrar med hjälp av HTTP. Ett XML-RPC-meddelande kodar antingen en procedur som ska invokeras av servern, tillsammans med parametrar som ska användas i invokationen, eller resultatet av en invokation. Procedurparametrar och resultat kan vara skalärer, tal, strängar, datum, etc., men de kan också vara komplexa register- och liststrukturer. I detta dokument specificeras hur man använder Blocks Extensible Exchange Protocol (BEEP) för att överföra meddelanden kodade i XML-RPC-format mellan klienter och servrar.

XQL

Extended Structured Query Language.

(*1) Europaparlamentets och rådets direktiv 2001/16/EG av den 19 mars 2001 om driftskompatibiliteten hos det transeuropeiska järnvägssystemet för konventionella tåg (EGT L 110, 20.4.2001, s. 1).

(1) EGT L 237, 24.8.1991, s. 25.

Tillägg III

Uppgifter som ska utföras av den nationella kontaktpunkten för telematikapplikationer för godstrafik/persontrafik

Fungera som kontaktpunkt mellan byrån, styrkommittén för Telematikapplikationer för godstrafik/persontrafik och järnvägsaktörer (infrastrukturförvaltare, järnvägsföretag, fordonsinnehavare, stationsförvaltare, biljettåterförsäljare, operatörer för intermodala transporter, godstransportkunder och relevanta sammanslutningar) i medlemsstaten, för att se till att järnvägsaktörerna görs delaktiga på området telematikapplikationer för godstrafik/persontrafik och hålls informerade om den allmänna utvecklingen och styrkommitténs beslut.

Förmedla frågor och problem från järnvägsaktörerna i medlemsstaten till TAF/TAP-styrkommittén via dess delade ledningsfunktion.

Hålla kontakten med medlemsstatens representant i RISC-kommittén (Railway Interoperability and Safety Committee) och se till att RISC-representanten hålls informerad om nationella frågor som rör telematikapplikationer för godstrafik/persontrafik inför varje möte i RISC-kommittén samt se till att information om RISC-kommitténs beslut på området telematikapplikationer för godstrafik/persontrafik förmedlas på lämpligt sätt till berörda järnvägsaktörer.

Medlemsstaten ska se till att alla järnvägsföretag med tillstånd och andra järnvägsaktörer (infrastrukturförvaltare, järnvägsföretag, fordonsinnehavare, stationsförvaltare, operatörer för intermodala transporter, godstransportkunder och relevanta sammanslutningar) kontaktas och informeras om den nationella kontaktpunkten samt uppmanas att ta kontakt med den nationella kontaktpunkten om inte kontakt redan etablerats.

I den mån som järnvägsaktörer i medlemsstaten är kända, informera dem om de skyldigheter de har och som ska fullgöras enligt gällande förordningar om telematikapplikationer för godstrafik och persontrafik.

Arbeta med medlemsstaten för att se till att ett organ utses som ansvarigt för att föra in koder för huvudplatser i Central Reference Domain. Namnet på det utsedda organet ska rapporteras till GD Transport och rörlighet, för lämplig distribution.

Underlätta informationsdelning mellan järnvägsaktörer (infrastrukturförvaltare, järnvägsföretag, fordonsinnehavare, stationsförvaltare, biljettåterförsäljare, operatörer för intermodala transporter, godstransportkunder och relevanta sammanslutningar) i medlemsstaten.