BILAGA

Teknisk specifikation för driftskompatibilitet (TSD) avseende delsystemet ”Telematikapplikationer för godstrafik” i det transeuropeiska järnvägssystemet för konventionella tåg

INNEHÅLL

1.

INLEDNING

1.1	Tekniskt tillämpningsområde

1.2	Geografiskt tillämpningsområde

1.3	Innehållet i denna TSD

2.	DEFINITION AV DELSYSTEMET/TILLÄMPNINGSOMRÅDET

2.1	Funktioner som omfattas av denna TSD

2.2	Funktioner som inte omfattas av denna TSD

2.3	Översiktlig beskrivning av delsystemet

2.3.1

Berörda enheter

2.3.2

Berörda processer

2.3.3

Allmänna anmärkningar

3.	VÄSENTLIGA KRAV

3.1	Uppfyllande av väsentliga krav

3.2	De väsentliga kravens olika aspekter

3.3	Aspekter som hänför sig till de allmänna kraven

3.3.1

Säkerhet

3.3.2

Tillförlitlighet och tillgänglighet

3.3.3

Hälsa

3.3.4

Miljöskydd

3.3.5

Teknisk kompatibilitet

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

3.4.2

Tillförlitlighet och tillgänglighet

3.4.3

Hälsa

3.4.4

Säkerhet

4.	BESKRIVNING AV DELSYSTEMET

4.1

Inledning

4.2	Funktionella och tekniska specifikationer för delsystemet

4.2.1

Uppgifter på fraktsedeln

4.2.2

Begäran om tågläge

4.2.3

Iordningställande av tåg

4.2.4

Tågföringsprognos

4.2.5

Information om trafikstörning

4.2.6

Tågposition

4.2.7

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

4.2.8

Vagnrörelse

4.2.9

Rapportering om utväxling

4.2.10

Datautväxling för kvalitetsförbättring

4.2.11

Viktigaste referensdata

4.2.12

Olika referensfiler och databaser

4.2.13

Elektronisk överföring av dokument

4.2.14

Nätverk och kommunikation

4.3	Funktionella och tekniska specifikationer för gränssnitten

4.3.1

Gränssnitt till TSD Infrastruktur

4.3.2

Gränssnitt till delsystemet Trafikstyrning och signalering

4.3.3

Gränssnitt till delsystemet Rullande materiel

4.3.4

Gränssnitt till TSD Drift och trafikledning

4.4	Driftsregler

4.4.1

Uppgifternas kvalitet

4.4.2

Driften av den centrala datakatalogen

4.5	Underhållsregler

4.6	Yrkeskvalifikationer

4.7	Hälso- och säkerhetskrav

4.8	Registren över infrastruktur och rullande materiel

5.	DRIFTSKOMPATIBILITETSKOMPONENTER

5.1	Definition

5.2	Förteckning över komponenter

5.3	Prestanda och specifikationer för komponenterna

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

6.1	Driftskompatibilitetskomponenter

6.1.1

Bedömningsförfaranden

6.1.2

Modul

6.2	Delsystemet Telematikapplikationer för godstrafik

7.	GENOMFÖRANDE

7.1	Metoder för tillämpning av denna TSD

7.1.1

Inledning

7.1.2

Strategisk europeisk genomförandeplan (SEDP)

7.1.3

Metoder för genomförande

7.2	Övergångsstrategi

7.3	Förändringshantering

7.3.1

Inledning

7.3.2

Ta fram grundstrukturer

7.3.3

Grundstrukturreleaser

7.3.4

Utveckling av nya grundstrukturer

7.3.5

Förändringshanteringsprocessen – krav som ställs

7.3.6

Plan för konfigurationsstyrning – krav

7.4	Specialfall

7.4.1

Inledning

7.4.2

Förteckning över specialfall

BILAGA A:

FÖRTECKNING ÖVER MEDFÖLJANDE DOKUMENT

BILAGA B:

ORDLISTA

TABELLER:

Tabell 1:

Begäran om tågläge

Tabell 2:

RU: s annullering av tågläge

Tabell 3:

IM: s annullering av tågläge

Tabell 4:

Kvitto på mottagande

Tabell 5:

Iordningställande av tåg

Det transeuropeiska järnvägssystemet för konventionella tåg

Tekniska specifikationer för driftskompatibilitet avseende delsystemet Telematikapplikationer för godstrafik

1.   INLEDNING

1.1   Tekniskt tillämpningsområde

Denna TSD rör delsystemet Telematikapplikationer för godstrafik, som ingår i förteckningen i punkt 1 b i bilaga II till direktiv 2001/16/EG.

Kommersiell drift av tåg, vagnar och intermodala enheter inom det transeuropeiska järnvägsnätet förutsätter en effektiv informationsutväxling mellan olika infrastrukturförvaltare, järnvägsföretag och andra tjänsteleverantörer. Prestanda, säkerhet, tjänstekvalitet och kostnader är beroende av sådan utväxling, och det är också en av förutsättningarna för driftskompatibilitet hos det transeuropeiska järnvägssystemet för konventionella tåg.

De tekniska specifikationerna för driftskompatibilitet 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.

Sist men inte minst ses driftskompatibiliteten hos järnvägssystemet för konventionella tåg som en viktig faktor för att förbättra förutsättningarna för driftskompatibilitet mellan olika transportsätt, framför allt mellan konventionell och kombinerad järnvägstransport.

Syftet med denna TSD är också att se till att en effektiv informationsutväxling hela tiden upprätthålls och på bästa sätt anpassas till nya krav, med avseende på kvalitet och kvantitet, så att transportprocessen förblir så ekonomiskt bärkraftig som möjligt och järnvägstransporterna behåller sin ställning på marknaden trots den hårda konkurrensen.

Allt detta ingår i anläggningen och ombyggnaden av det transeuropeiska järnvägssystemet för konventionella järnvägstransporter och intermodala transporter. Behovet av att bygga om järnvägsdelen av transportsystemet kan också ses mot bakgrund av en jämförelse mellan de kritiska punkterna (gränssnitten mellan de olika involverade parterna) inom godstransporter på väg och de kritiska punkterna inom godstransporter på järnväg, i ett förenklat scenario såsom visas i bilaga A index 5 avsnitt 1.1.

Att försändelser genom ett system med så många gränssnitt skall kunna hanteras med hjälp av informationsutväxling i enlighet med Europaparlamentets och rådets direktiv 2001/14/EG (1) och 2001/16/EG är det slutliga syftet med denna TSD.

Denna korta beskrivning av tillämpningsområdet för det konventionella järnvägssystemets TSD för telematikapplikationer för godstrafik visar också skillnaden i förhållande till det konventionella järnvägssystemets TSD för drift och trafikledning. TSD Drift och trafikledning omfattar – med särskilt hänseende till säkerheten – de förfaranden och den utrustning som krävs för en sammanhängande drift av de olika strukturella delsystemen, inbegripet bland annat framförande av tåg, trafikplanering och trafikledning, vilket ingår i ett järnvägsföretags huvudsakliga verksamhet enligt definitionen (se avsnitt 2.3: Översiktlig beskrivning av delsystemet).

TSD Telematikapplikationer 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äkerhetsaspekter beaktas bara i den mån vissa data, t.ex. felaktiga eller inaktuella värden, kan påverka säkerheten vid drift av ett tåg.

1.2   Geografiskt tillämpningsområde

Det geografiska tillämpningsområdet för denna TSD är det transeuropeiska järnvägssystemet för konventionella tåg, såsom det beskrivs i bilaga I till direktiv 2001/16/EG. Men denna TSD kan också tillämpas på EU: s medlemsstaters järnvägsnät för godstrafik i sin helhet, med den begränsningen att kraven i denna TSD inte är obligatoriska för godstransporter från eller till ett land utanför EU.

1.3   Innehållet i denna TSD

Denna TSD uppfyller kraven i artikel 5.3 i direktiv 2001/16/EG genom att

a)	ange det tillämpningsområde som avses, nämligen delsystemet Telematikapplikationer för godstrafik – kapitel 2: Definition av delsystemet/tillämpningsområdet,

b)	ange de väsentliga kraven för detta delsystem och dess gränssnitt mot andra delsystem – kapitel 3: Väsentliga krav,

c)	fastställa funktionella och tekniska specifikationer som skall följas när det gäller delsystemet och dess gränssnitt mot andra delsystem – kapitel 4: Beskrivning av delsystemet,

d)	ange vilka driftskompatibilitetskomponenter och gränssnitt som är föremål för europeiska specifikationer, däribland europeiska standarder, vilka krävs för att uppnå driftskompatibilitet hos det transeuropeiska järnvägssystemet för konventionella tåg – kapitel 5:Beskrivning av delsystemet,

e)

för varje tänkbart fall ange vilka förfaranden som skall tillämpas för att bedöma överensstämmelsen eller lämpligheten; detta omfattar, bland annat, de moduler som anges i rådets beslut 93/465/EEG (2) eller, i förekommande fall, de specifika förfaranden som skall tillämpas vid bedömning av driftskompatibilitetskomponenters överensstämmelse eller lämplighet, och EG-kontrollen av delsystem – kapitel 6: Bedömning av komponenternas överensstämmelse och/eller lämplighet och kontroll av delsystemet,

f)	ange strategin för genomförande av TSD; bland annat anges de etapper som skall slutföras för en stegvis övergång från den nuvarande situationen till den slutliga situationen, då TSD iakttas generellt – kapitel 7: Genomförande,

g)	för den berörda personalen ange de yrkesmässiga kvalifikationer och de villkor avseende hälsa och säkerhet som krävs för drift och underhåll av detta delsystem samt för genomförandet av TSD – kapitel 4: Beskrivning av delsystemet.

Vidare anges, i enlighet med artikel 5.5, specialfall för denna TSD. Dessa beskrivs i avsnitt 7.4:Specialfall .

Slutligen innehåller denna TSD 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 avsnitten 1.1 (Tekniskt tillämpningsområde) och 1.2 (Geografiskt tillämpningsområde) ovan.

2.   DEFINITION AV DELSYSTEMET/TILLÄMPNINGSOMRÅDET

2.1   Funktioner som omfattas av denna TSD

Delsystemet Telematikapplikationer för godstrafik definieras i punkt 2.5 b i bilaga II till direktiv 2001/16/EEG.

Det inbegriper bland annat

—	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 avsnitt 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):

—

Vagnar.

—

Lok.

—

Förare.

—	Växling och vallväxling.

—	Fördelning 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 2001/14/EG och 2001/16/EG. Eftersom hänsyn måste tas till båda dessa direktiv, beaktas i denna TSD särskilt följande definitioner (se även bilaga A index 6):

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.

Det organ eller företag till vilket IM tilldelar ett tågläge definieras enligt direktiv 2001/14/EG som en sökande.

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 13 i direktiv 2001/14/EG beaktas:

När det gäller scenarierna för kommunikation mellan infrastrukturförvaltare och sökande i verkställandefasen 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 verkställandefasen 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.

Såsom redan nämnts måste olika tjänster 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 i sin tur kan 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 huvudjä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 ovan) 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 2001/16/EG till IM och RU/LRU med hänvisning till deras direkta kunder.

Vid genomfö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 skall kontaktas och vid vilken tidpunkt utväxlingen från en RU till en annan kan ske. LRU upprättar sedan preliminära vagnorder, för var och en av de berörda RU, vilka utgör delar av den fullständiga fraktsedeln. Vagnorderna beskrivs närmare i avsnitt 4.2.1 (När det gäller tilldelning ).

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ågets drift. När det gäller tågläget kan de använda redan bokade tåglägen (i planeringsfasen) eller också begära 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 bilaga A index 5 avsnitt 1.2 ges ett exempel på scenario för begäran 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åg- och tåglägesidentiteter, med vars hjälp IM kommunicerar med den RU som bokat tågläget på IM: s infrastruktur (se även bilaga A index 5 avsnitt 1.2).

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. I denna TSD beaktas båda dessa fall, vilket visas i avsnitt 4.2.2.1:Begäran 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 avsnitt 4.2.2 (Begäran om tågläge). Denna funktion hänför sig till artikel 23.1 i direktiv 2001/14/EG. Denna dialogprocess omfattar inte utfärdandet av tillstånd för RU som tillhandahåller tjänster i enlighet med Europaparlamentets och rådets direktiv 2001/13/EG (3), utfärdandet av säkerhetsintyg enligt direktiv 2001/14/EG eller rätt till tillgång till infrastruktur enligt rådets direktiv 91/440/EEG (4).

I avsnitt 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 avsnitt 4.2.4 (Tågföringsprognos) och meddelanden för undantagsfall beskrivs i avsnitt 4.2.5 (Information om trafikstörning). Spårning av information angående tågposition beskrivs i avsnitt 4.2.6 (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 alltid 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 med 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 (avsnitt 4.2.7 ETI/ETA för en försändelse).

LRU kan, även det med utgångspunkt från informationsutväxlingen mellan IM och RU, till exempel veta

—	när vagnarna avgick ifrån eller ankom till en bangård eller en viss bestämd position (avsnitt 4.2.8) eller

—	när ansvaret för vagnarna överfördes från en RU till nästa RU i transportkedjan (avsnitt 4.2.9).

Med utgångspunkt från 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 – skall kunna planera produktionsprocessen mer i detalj och

—	för att man – på lång sikt – skall 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 (avsnitt 4.2.10 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å vagnorder, varvid de tomma vagnarnas vagnparksförvaltare ses som en kund.

2.3.3   Allmänna anmärkningar

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 skall 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 avsnitt 4.2.11 (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,

—	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 avsnitt 4.2.12 (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 avsnitt 4.2.13 (Elektronisk överföring av dokument) beskrivs kraven angående elektronisk överföring av dokument.

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 avsnitt 4.2.14 (Nätverk och kommunikation), med hänsyn tagen till

—	gränssnittet mot delsystemet Drift och trafikledning inom det transeuropeiska järnvägssystemet för konventionella tåg, i enlighet med artikel 5.3 i rådets direktiv 2001/16/EG,

—	kraven angående innehållet i järnvägsnätsbeskrivningen, vilka anges i direktiv 2001/14/EG, artikel 3 och bilaga I,

—	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/ETSC-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 (avsnitt 4.2.11.3: 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 (avsnitt 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 (avsnitt 4.2.11.2: Databaserna över information om infrastrukturbegränsningar).

3.   VÄSENTLIGA KRAV

3.1   Uppfyllande av väsentliga krav

Enligt artikel 4.1 i direktiv 2001/16/EG skall det transeuropeiska järnvägssystemet för konventionella tåg, dess delsystem och driftskompatibilitetskomponenter uppfylla de väsentliga krav som i allmänna ordalag definieras i bilaga III till direktivet.

Enligt denna TSD uppfylls de relevanta väsentliga kraven för detta delsystem, vilka anges i kapitel 3 i denna TSD, 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,

—	teknisk kompatibilitet.

De väsentliga kraven kan enligt direktiv 2001/16/EG vara allmänna och tillämpliga på hela det transeuropeiska järnvägssystemet för konventionella tåg, eller specifika för varje delsystem och dess komponenter.

3.3   Aspekter som hänför sig till de allmänna kraven

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

3.3.1   Säkerhet

Enligt bilaga III till direktiv 2001/16/EG är följande väsentliga krav för säkerheten tillämpliga på delsystemet Telematikapplikationer för godstrafik:

—

Väsentligt krav 1.1.1 i bilaga III till direktiv 2001/16/EG: ”Utformning, uppförande eller tillverkning samt underhåll och övervakning av säkerhetskritiska komponenter och särskilt av komponenter som är av betydelse för tågtrafiken skall ske på ett sätt som garanterar en säkerhetsnivå motsvarande de mål som ställts upp för nätet, också i vissa angivna nöddriftssituationer.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.1.2 i bilaga III till direktiv 2001/16/EG: ”Parametrar som avser kontaktytan hjul–räls skall följa de kriterier för körstabilitet som är nödvändiga för att garantera säker trafik vid högsta tillåtna hastighet.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.1.3 i bilaga III till direktiv 2001/16/EG: ”De komponenter som används skall under hela sin livslängd kunna motstå angivna, normala eller exceptionella påkänningar. Genom lämpliga åtgärder skall de säkerhetsmässiga konsekvenserna av oförutsedda fel i komponenterna begränsas.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.1.4 i bilaga III till direktiv 2001/16/EG: ”Fasta installationer och rullande materiel skall utformas och material för dessa väljas på ett sådant sätt att uppkomst, spridning och följderna av eld och rök begränsas i händelse av brand.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.1.5 i bilaga III till direktiv 2001/16/EG: ”Anordningar som är avsedda att hanteras av användarna skall vara så utformade att de är ofarliga att använda och inte medför någon hälso- eller säkerhetsrisk för användarna vid en förutsägbar användning i strid med anvisningarna.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

3.3.2   Tillförlitlighet och tillgänglighet

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

Avsnitt 4.2.11: Viktigaste referensdata.

Avsnitt 4.2.12: Olika referensfiler och databaser.

Avsnitt 4.2.14: Nätverk och kommunikation.

3.3.3   Hälsa

—

Väsentligt krav 1.3.1 i bilaga III till direktiv 2001/16/EG: ”Material som vid normal användning kan komma att innebära en hälsofara för personer som utsätts för dem får inte användas i tågen eller i järnvägsinfrastrukturerna.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.3.2 i bilaga III till direktiv 2001/16/EG: ”Materialen skall väljas, iordningställas och användas på så sätt att utsläpp av rök eller skadliga och farliga gaser begränsas, särskilt i händelse av brand.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

3.3.4   Miljöskydd

—

Väsentligt krav 1.4.1 i bilaga III till direktiv 2001/16/EG: ”Den miljöpåverkan som anläggning och drift av det transeuropeiska järnvägssystemet för konventionella tåg medför skall bedömas och beaktas vid utformningen av detta system i enlighet med gällande gemenskapsbestämmelser.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.4.2 i bilaga III till direktiv 2001/16/EG: ”De material som används i tågen och i infrastrukturen får inte medföra utsläpp av rök eller gaser som är skadliga och farliga för miljön, särskilt i händelse av brand.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.4.3 i bilaga III till direktiv 2001/16/EG: ”Rullande materiel och energiförsörjningssystem skall utformas och byggas på så sätt att de är elektromagnetiskt kompatibla med installationer, anläggningar och utrustning samt allmänna och privata nät med vilka det föreligger risk för interferens.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—	Väsentligt krav 1.4.4 i bilaga III till direktiv 2001/16/EG: ”Det transeuropeiska järnvägssystemet för konventionella tåg skall drivas under iakttagande av föreskrivna gränsvärden för buller.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

—

Väsentligt krav 1.4.5 i bilaga III till direktiv 2001/16/EG: ”Det transeuropeiska järnvägssystemet för konventionella tåg får inte ge upphov till markvibrationer som är oacceptabla för verksamhet och omgivningar som ligger nära infrastrukturen och som är normalt underhållna.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

3.3.5   Teknisk kompatibilitet

—

Väsentligt krav 1.5 i bilaga III till direktiv 2001/16/EG: ”Infrastrukturens och de fasta installationernas tekniska egenskaper skall vara kompatibla inbördes och med de tekniska egenskaperna hos tåg som skall trafikera det transeuropeiska järnvägssystemet för konventionella tåg. När det på vissa delar av nätet visar sig svårt att ta hänsyn till dessa egenskaper kan tillfälliga lösningar som garanterar framtida kompatibilitet utnyttjas.” Detta väsentliga krav är inte relevant för delsystemet Telematikapplikationer för godstrafik.

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 2001/16/EG: ”De väsentliga kraven för telematikapplikationer avsedda att garantera resande och godskunder en lägsta servicenivå gäller i första hand den tekniska kompatibiliteten.” När det gäller dessa applikationer måste följande uppnås: — Databaser, programvara och dataöverföringsprotokoll skall utarbetas för största möjliga datautväxling mellan de olika applikationerna och mellan operatörerna, men utväxlingen skall 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 avsnitt: — Avsnitt 4.2.11: Viktigaste referensdata. — Avsnitt 4.2.12: Olika referensfiler och databaser. — Avsnitt 4.2.14: Nätverk och kommunikation.

3.4.2   Tillförlitlighet och tillgänglighet

—

Väsentligt krav 2.7.2 i bilaga III till direktiv 2001/16/EG: ”Användning, handhavande, uppdatering och underhåll av databaserna, programvaran och dataöverföringsprotokollen skall ske för högsta möjliga effektivitet och kvalitet.” Hur detta krav uppfylls beskrivs i följande avsnitt: — Avsnitt 4.2.11: Viktigaste referensdata. — Avsnitt 4.2.12: Olika referensfiler och databaser. — Avsnitt 4.2.14: Nätverk och kommunikation. Detta väsentliga krav, och särskilt kravet på att användningen skall ske på ett sätt som garanterar effektiviteten i telematikapplikationerna och kvaliteten på tjänsterna, ligger emellertid till grund för hela denna TSD och är inte begränsat till ovan nämnda avsnitt.

3.4.3   Hälsa

—

Väsentligt krav 2.7.3 i bilaga III till direktiv 2001/16/EG: ”Gränssnitten mellan systemen och användarna skall 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 2001/16/EG: ”Integritet och tillförlitlighet skall 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 krav uppfylls beskrivs i följande avsnitt: — Avsnitt 4.2.11: Viktigaste referensdata. — Avsnitt 4.2.12: Olika referensfiler och databaser. — Avsnitt 4.2.14: Nätverk och kommunikation.

4.   BESKRIVNING AV DELSYSTEMET

4.1   Inledning

Det transeuropeiska järnvägssystemet för konventionella tåg, som omfattas av direktiv 2001/16/EG och där delsystemet Telematikapplikationer för godstrafik 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   Funktionella och tekniska specifikationer för delsystemet

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

—	Uppgifter på fraktsedeln.

—	Begäran om tågläge.

—	Iordningställande av tåg.

—	Tågföringsprognos.

—	Information om trafikstörning.

—	Tågposition.

—	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.

—	Elektronisk överföring av dokument.

—	Nätverk och kommunikation.

De detaljerade specifikationerna anges nedan. Ytterligare detaljer och regler angående meddelandenas format anges i bilaga A index 1.

Allmänna anmärkningar om meddelandestrukturen

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

—	Kontrolldata: se förklaring nedan

—	Informationsdata: uppgiftsinformation

Kontrolldata visar följande:

—	Status: ett meddelandes status kan vara — ”Nytt meddelande”, om det rör sig om ett nytt meddelande, — ”Ändring”, om det rör sig om en ändring av ett tidigare sänt meddelande, — ”Borttagande”, om ett tidigare sänt meddelande skall tas bort.

—	Meddelandereferens, med angivelse av — Meddelandetyp: t.ex. ”begäran om tågläge” eller ”förfrågan om tågföring”, — Datum och tid: det faktiska datumet och tiden då meddelandet sändes, — Meddelandenummer: ett nummer som skapas av meddelandets avsändare.

—

Svarsreferens, endast om meddelandet är ett svar på ett tidigare mottaget meddelande (identisk med ”meddelandereferensen” för det mottagna meddelandet) med angivelse av — Svar på typ: det mottagna meddelandets meddelandetyp, — Svar på datum och tid: det mottagna meddelandets datum och tid, — Svar på nummer: det mottagna meddelandets meddelandenummer.

—	Meddelandets avsändare.

—	Meddelandets mottagare.

I de följande kapitlen behandlas främst statusen ”nytt meddelande”. I avsnitt 4.2.2 hänvisas också till statusen ”borttagande” i fråga om ett meddelande om begäran om tågläge.

4.2.1   Uppgifter på fraktsedeln

4.2.1.1   Kundens fraktsedel

Kunden skall sända en fraktsedel till LRU. Fraktsedeln skall innehålla alla uppgifter som behövs för att frakta en försändelse från avsändaren till mottagaren. LRU skall komplettera dessa uppgifter med ytterligare information. Uppgifterna, inbegripet de kompletterande uppgifterna, (för en beskrivning av uppgifterna se bilaga A index 3) förtecknas i tabellen i bilaga A index 3, med en angivelse på raden ”Data in Consignment Note” om huruvida de är obligatoriska eller frivilliga och huruvida de skall anges av avsändaren eller kompletteras av LRU.

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 begäran om tågläge med kort varsel, 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 begäran om tågläge med kort varsel, om så krävs för att expediera fraktsedeln.

4.2.1.2   Vagnorder

Vagnordern är i huvudsak en delmängd av informationen på fraktsedeln. Den måste sändas vidare till de RU som ingår i transportkedjan, eftersom den kan komma att ligga till grund för en ad hoc-begäran om tågläge (avsnitt 4.2.2: Begäran om tågläge). Av innehållet i vagnsorden måste den relevanta information framgå som behövs för att en RU skall 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 järnvägsföretaget skall spela: ursprungs-, transit- eller leverans-RU (ORU, TRU, DRU).

—	Vagnorder för ursprungs-RU (Origin Railway Undertaking, ORU).

—	Vagnorder för transit-RU (Transit Railway Undertaking, TRU).

—	Vagnorder för leverans-RU (Delivery Railway Undertaking, DRU).

De uppgifter som skall ingå i vagnorderna beroende på vilken roll RU har, förtecknas i detalj i bilaga A index 3, med angivelse om huruvida de är obligatoriska eller frivilliga. Detaljer angående meddelandenas format anges i bilaga A index 1.

Huvudinnehållet i vagnorderna är

—	uppgifter om avsändare och mottagare,

—	dirigeringsinformation,

—	identifiering av försändelsen,

—	vagnsinformation,

—	uppgifter 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 inbegripet kunder. Dessa uppgifter är, specificerat för varje vagn

—	lastvikt (lastens bruttovikt),

—	KN/HS-nummer,

—	uppgifter om farligt gods,

—	transportenhet.

4.2.2   Begäran om tågläge

4.2.2.1   Inledande anmärkningar

Långsiktig planering

Tågläget definierar de begärda, godkända och faktiska data som skall 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 infrastrukturförvaltaren. För en mer utförlig beskrivning se bilaga A index 4.

Dessa uppgifter måste uppdateras så snart en ändring sker.

Huvuduppgifterna om tågläget är följande:

—

Identifiering av tågläget (tåglägesidentitet). Ett tågläge kan innebära antingen den planerade användningen av kapacitet längs ett avsnitt av färdvägen, eller den faktiska dirigeringen av ett tåg längs en specificerad linje inom en färdväg. Den exakta innebörden beror på vilka förfaranden som används inom en IM.

—	Tåglägets utgångspunkt, vilket innebär uppgift om den plats där tågläget börjar tillsammans med uppgifter om datum och tid för avgång för ett tåg som skall använda tågläget.

—	Tåglägets destination, vilket innebär uppgift om den plats där tågläget slutar tillsammans med uppgifter om datum och tid när ett tåg skall ankomma till denna destination.

—

Beskrivning av delsträckan, vilket innebär uppgifter som IM tillhandahåller för varje godkänd delsträcka – från start till första uppehåll, ytterligare uppehåll och från sista uppehåll till slutet av den godkända färden. Denna beskrivning kan innehålla följande. — Punkter för uppehåll eller andra angivna punkter längs det föreslagna tågläget med uppgift om datum och tid för ankomst till, avgång från eller passering av dessa punkter tillsammans med en aktivitetskod som anger en åtgärd som skall vidtas vid en sådan mellanliggande punkt längs färdvägen. — Identifiering av den IM som ansvarar för trafikledningen på den aktuella delsträckan och identifiering av den IM som ansvarar för trafikledningen på nästa delsträcka. — Beskrivning av den utrustning (styr- och kontrollsystem, radiosystem, etc.) som skall finnas på tåget. Denna utrustning måste vara kompatibel med infrastrukturen för att tåget skall kunna drivas och kontrolleras och för att meddelanden skall kunna sändas från tåget till IM: s tågledningscentral. — Tågrelaterade data för delsträckan: maxvikt, maxlängd, högsta tillåtna hastighet, högsta tillåtna axeltryck, minsta bromskraft, maxvikt per meter, information om särskild lastprofilsbegränsning, uppgift om ej tillåtet farligt gods. — Tåglägesidentitet. — Tillagd användningstid för färdvägsavsnittet, för inhämtning av förseningar, problem längs tågläget etc.

Verkställande av tåglägesavtal: Innan ett tåg framförs måste delsträckan uppdateras och kompletteras med aktuella värden. Verkställandefasen är fristående från planeringsfasen.

Begäran om tågläge med kort varsel

På grund av oförutsedda händelser under tågets framförande eller på grund av transportbehov med kort varsel, skall järnvägsföretag ha möjlighet att få ett ad hoc-tågläge i nä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 tåglistan.

I det andra fallet måste järnvägsföretaget tillhandahålla infrastrukturförvaltaren 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. Dessa uppgifter ges huvudsakligen i den kompletterade fraktsedeln, eller i vagnorderna.

Avtal om ett tågläge för en tågrörelse med kort varsel baseras på en dialog mellan RU och IM. 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. Enligt artikel 13 i direktiv 2001/14/EG kan i allmänhet två olika scenarier urskiljas när det gäller godstransporter på infrastruktur som handhas av flera olika IM (se även bilaga A index 5 avsnitt 1.3).

—	Scenario A: RU kontaktar alla berörda IM, direkt (fall A) eller genom en OSS (fall B), för att organisera tåglägena för hela färden. I detta fall skall RU även ansvara för driften av tåget under hela färden i enlighet med artikel 13 i direktiv 2001/14/EG.

—	Scenario B: Varje RU som berörs av transporten kontaktar de lokala IM direkt eller genom OSS för att begära ett tågläge för den delsträcka där de ansvarar för driften av tåget.

Anmärkning: Såsom redan nämnts i kapitel 2 (Definition av delsystemet/tillämpningsområdet) kommunicerar IM i verkställandefasen alltid med den RU som bokat tågläget. Därför har ”innehavet av tågläget” betydelse för utväxlingen av meddelanden då tåget är i drift.

I båda scenarier skall förfarandet för att boka ett tågläge med kort varsel följa den dialog mellan berörda RU och IM som beskrivs på nästa sida.

Följande tabell visar de meddelanden som används i dialogen för begäran om tågläge:

Tabell 1

Begäran om tågläge

Meddelande	Förklaring
Meddelanden som används i dialogen för begäran om tågläge
Begäran om tågläge	RU till berörd(a) IM, detta meddelande skall sändas vid begäran om tågläge med kort varsel.
Specifikation av tågläge	Detta meddelande skall sändas från berörd(a) IM till RU som svar på RU: s ”Begäran om tågläge” med bekräftelse av specifikationerna för tågläget, eventuellt med ändrade värden eller, om IM inte kan erbjuda ett tågläge som motsvarar begäran, men angivelsen ”Inga alternativ tillgängliga”.
Bekräftat tågläge	Detta meddelande skall sändas från RU till IM för godkännande av den ”Specifikation av tågläge” som IM sänt som svar på RU: s ursprungliga begäran.
Avvisad specifikation av tågläge	Detta meddelande skall sändas från RU till IM om RU inte godkänner den ”Specifikation av tågläge” som sänts från IM som svar på RU: s ursprungliga begäran, då värden har ändrats som RU inte kan godta.

Dialogen avslutas av RU genom meddelandet Bekräftat tågläge eller genom borttagande av begäran om tågläge (meddelande om begäran om tågläge med status ”Borttagande”, se avsnitt 4.2: Funktionella och tekniska specifikationer för delsystemet, Allmänna anmärkningar om meddelandestrukturen). Ett meddelande om avvisad specifikation av tågläge från RU måste alltid besvaras med ett nytt meddelande om specifikation av tågläge. Om IM i sitt meddelande om specifikation av tågläge inte kan erbjuda ett nytt förslag som motsvarar begäran om tågläge, måste IM sända ett meddelande om specifikation av tågläge med angivelsen ”Inga alternativ tillgängliga”, vilket innebär att IM avslutar dialogen.

Oavsett om tågläget bokats inom ramen för den långsiktiga planeringen eller med kort varsel, måste RU alltid ha möjlighet att annullera ett bokat tågläge. För annullering av ett bokat tågläge skall följande meddelande användas.

Tabell 2

RU: s annullering av tågläge

Meddelande	Förklaring
Meddelande från RU för att annullera ett bokat tågläge
Annullerat tågläge	Meddelande från RU till IM om annullering av ett tidigare bokat tågläge eller del av tågläge.

Med avtalet om tågläge som grund, kan RU förvänta sig att ett bokat tågläge också är tillgängligt. Om något händer som gör att det bokade tågläget inte längre är tillgängligt, måste IM därför informera RU så snart IM får vetskap om detta faktum. En anledning kan till exempel vara att ett avbrott uppstått längs tågläget. Detta kan hända vid vilken tidpunkt som helst från det att tågläget avtalas och fram till tågets avgång. Tillsammans med meddelandet om att tågläget inte är tillgängligt måste IM sända ett förslag till alternativt tågläge. Om detta inte är möjligt måste IM sända förslaget så snart som möjligt. Genom meddelandet Tågläget inte tillgängligt startas en dialog för ett nytt avtal om tågläge som initieras av IM.

Meddelanden som används i dialogen för att annullera ett tågläge från IM: s sida.

Tabell 3

IM: s annullering av tågläge

Meddelande	Förklaring
Meddelanden som används i processen för att annullera ett tågläge på IM: s initiativ
Tågläge inte tillgängligt	Meddelande från IM till RU om att det bokade tågläget inte är tillgängligt
Specifikation av tågläge	Detta meddelande skall sändas från berörd(a) IM till RU och innehålla ett förslag till alternativt tågläge, efter att ett meddelande sänts från IM till RU om att det bokade tågläget inte är tillgängligt.
Bekräftat tågläge	Detta meddelande skall sändas från RU till IM för godkännande av det föreslagna tågläget i meddelandet Tågläge inte tillgängligt.
Avvisad specifikation av tågläge	Detta meddelande skall sändas från RU till IM om RU inte godkänner det föreslagna tågläget i meddelandet Tågläge inte tillgängligt. I detta fall måste IM sända ett nytt förslag. Denna dialog avslutas av RU med meddelandet Annullerat tågläge med referens till IM: s Tågläge inte tillgängligt-meddelande.

Generellt gäller att om mottagaren av en begäran eller förfrågan inte kan ge svar i realtid, måste han informera meddelandets avsändare om detta (till exempel kan meddelandet Specifikation av tågläge som svar på en begäran om tågläge inte sändas omedelbart). Detta skall göras med användning av följande meddelande:

Tabell 4

Kvitto på mottagande

Meddelande	Förklaring
Detta meddelande gäller generellt
Kvitto på mottagande	Detta meddelande skall sändas från mottagaren av ett meddelande till avsändaren av meddelandet då det begärda svaret inte kan ges inom det tidsintervall som anges under rubriken ”Aktualitet” i avsnitt 4.4 (Driftsregler).

I de följande kapitlen ges en beskrivning av dessa meddelanden, i form av en översikt över huvudpunkterna i respektive meddelande. Detaljer angående formatet anges i bilaga A index 1. Den logiska följordningen för dessa meddelanden framgår av diagrammen i bilaga A index 5 avsnitten 2.1–2.3.

4.2.2.2   Meddelandet Begäran om tågläge

Detta är begäran från RU till IM om ett tågläge. En sådan begäran måste innehålla följande uppgifter:

—	Tåglägets utgångspunkt: platsen där det föreslagna tågläget börjar.

—	Datum och tid för avgång: datum och klockslag från när begäran om tågläge avser.

—	Tåglägets destination: destination för tåget på det tågläge som begäran avser.

—	Datum och tid för ankomst till tåglägets destination: datum och klockslag när det föreslagna tåget skall ankomma till tåglägets destination.

—

Uppgifter om den delsträcka begäran avser: — Punkter för uppehåll eller andra angivna mellanliggande punkter längs det föreslagna tågläget med angivelser om datum och tid när det föreslagna tåget skall ankomma till en angiven punkt och datum och tid när tåget skall avgå från samma punkt. Om fältet lämnas blankt anger detta att tåget inte kommer at stanna vid den punkten. — Tillgänglig utrustning på tåget: typ av drivning, styr- och kontrollsystem inbegripet radioutrustning ombord. — Tågvikt. — Tåglängd. — Bromssystem som skall användas och bromsprestanda. — Tågets högsta tillåtna hastighet. — Tågets högsta tillåtna axeltryck. — Maxvikt per meter. — Information om särskild lastprofilsbegränsning. — UN/RID-nummer med avseende på eventuellt farligt gods. — Definiering av eventuella åtgärder som skall vidtas vid angivna mellanliggande punkter längs färdvägen. — Ansvarig RU: identifiering av den RU som ansvarar för tåget på delsträckan i fråga. — Ansvarig IM: identifiering av den IM som ansvarar för tåget på delsträckan i fråga. — Nästa ansvarig IM: identifiering av den IM som ansvarar för tåget på nästa delsträcka (om tillämpligt).

Vid formuleringen av begäran om tågläge, kan RU konsultera järnvägsnätsbeskrivningen för den aktuella sträckan, för att kontrollera huruvida det tilltänkta tågets egenskaper är kompatibla med infrastrukturen. Andra data, såsom uppgifter om farligt gods, måste också beaktas.

Vagninnehavarna måste ge RU tillgång till tekniska vagndata.

RU måste i sin tur se till att ge tillgång till referensfilerna, t.ex. till referensfilen angående farligt gods, om så krävs.

4.2.2.3   Meddelandet Specifikation av tågläge

Detta meddelande är svaret från en IM på meddelandet Begäran om tågläge från en RU. Om IM inte kan erbjuda ett tågläge som motsvarar begäran, skall IM sända detta meddelande med angivelsen ”Inga alternativ tillgängliga”. I annat fall skall IM besvara RU: s begäran genom att sända tillbaka en tåglägesidentitet tillsammans med samma uppgifter som i begäran om tågläge, eventuellt med vissa ändrade värden.

För det tågläge som IM föreslår skall följande uppgifter sändas:

—	Ny tåglägesidentitet.

—	Tåglägets utgångspunkt: platsen där det föreslagna tågläget börjar.

—	Datum och tid för avgång: datum och klockslag för det föreslagna tåglägets början.

—	Tåglägets destination: destination för tåget på det föreslagna tågläget.

—	Datum och tid för ankomst till tåglägets destination: datum och klockslag när tåget skall ankomma till tåglägets destination.

—

Ändrade uppgifter om delsträckan: — Punkter för uppehåll eller andra angivna mellanliggande punkter längs det föreslagna tågläget med angivelser om datum och tid när det föreslagna tåget skall ankomma till en angiven punkt och datum och tid när tåget skall avgå från samma punkt. Om fältet lämnas blankt anger detta att tåget inte kommer at stanna vid den punkten. — Utrustning som måste finnas på tåget: typ av drivning, styr- och kontrollsystem inbegripet radioutrustning ombord. — Tågvikt. — Tåglängd. — Bromssystem som skall användas och bromsprestanda. — Tågets högsta tillåtna hastighet. — Tågets högsta tillåtna axeltryck. — Maxvikt per meter. — Information om särskild lastprofilsbegränsning. — UN/RID-nummer med avseende på eventuellt farligt gods. — Definiering av eventuella åtgärder som skall vidtas vid angivna mellanliggande punkter längs färdvägen. — Ansvarig RU: identifiering av den RU som ansvarar för tåget på delsträckan i fråga. — Ansvarig IM: identifiering av den IM som ansvarar för tåget på delsträckan i fråga. — Nästa ansvarig IM: identifiering av den IM som ansvarar för tåget på nästa delsträckan (om tillämpligt).

4.2.2.4   Meddelandet Bekräftat tågläge

Detta meddelande skall sändas från en RU till en IM för att godkänna ett tågläge som föreslagits som svar på RU: s ursprungliga begäran. Genom detta meddelande är tågläget bokat. Huvudinnehållet i meddelandet är följande:

—	Tåglägesidentitet för identifiering av tågläget.

—	Tåglägets utgångspunkt: platsen varifrån tåget skall avgå.

—	Datum och tid för avgång: datum och klockslag från när begäran om tågläge avser.

—	Tåglägets destination: destination för tåget på det tågläge som begäran avser.

—	Datum och tid för ankomst till tåglägets destination: datum och klockslag när tåget skall ankomma till tåglägets destination.

—	Angivelse om att RU godkänner det föreslagna tågläget.

4.2.2.5   Meddelandet Avvisad specifikation av tågläge

Om RU inte godkänner det tågläge som IM föreslagit i sin ”Specifikation av tågläge”, skall RU sända detta meddelande till IM för att meddela IM att RU inte godkänner det föreslagna tågläget enligt meddelandet Specifikation av tågläge. Huvuduppgifterna i detta meddelande är följande:

—	Tåglägesidentitet för identifiering av tågläget.

—	Angivelse om att specifikationen av tågläget avvisas.

Som kompletterande information kan följande uppgifter sändas:

—	Tåglägets utgångspunkt: platsen varifrån tåget skall avgå.

—	Datum och tid för avgång: datum och klockslag från när begäran om tågläge avser.

—	Tåglägets destination: destination för tåget på det tågläge som begäran avser.

—	Datum och tid för ankomst till tåglägets destination: datum och klockslag när det föreslagna tåget skall ankomma till tåglägets destination.

4.2.2.6   Meddelandet Annullerat tågläge

Detta är ett meddelande från RU om att annullera ett tidigare bokat tågläge. Tillsammans med indikeringen om annullering (motsvarar meddelandetypen), skall tåglägesidentiteten sändas för att det specifika tågläget skall kunna identifieras. Detta gäller för tåglägen som bokats såväl i planeringsfasen som med kort varsel:

—	Tåglägesidentitet för identifiering av tågläget.

—	Tågidentitet (om den redan är känd för IM).

—	Angivelse om att det bokade tågläget annulleras.

Som kompletterande information kan följande uppgifter sändas:

—	Tåglägets utgångspunkt: platsen varifrån tåget skall avgå.

—	Datum och tid för avgång: datum och klockslag från när begäran om tågläge avser.

—	Tåglägets destination: destination för tåget på det tågläge som begäran avser.

—	Datum och tid för ankomst till tåglägets destination: datum och klockslag när det föreslagna tåget skall ankomma till tåglägets destination.

4.2.2.7   Meddelandet Tågläge inte tillgängligt

IM skall informera RU så snart IM får vetskap om att ett tågläge inte är tillgängligt. Meddelandet Tågläge inte tillgängligt kan sändas vid vilken tidpunkt som helst från det att tågläget avtalas och fram till tågets avgång. En anledning att sända detta meddelande kan t.ex. vara att ett avbrott uppstått längs tågläget. Huvudinnehållet i detta meddelande är följande:

—	Tåglägesidentitet på det tågläge som inte är tillgängligt.

—	Tågidentitet för tåg som planerats för det annullerade tågläget (om redan känd för IM).

—	Tåglägets utgångspunkt med datum och klockslag för det bokade tåglägets början.

—	Tåglägets destination med datum och klockslag när tåget skulle ankomma till destinationen.

—	Angivelse om att tågläget inte är tillgängligt.

—	Angivelse av orsaken.

Tillsammans med detta meddelande eller så snart som möjligt måste IM sända ett alternativt förslag till tågläge, utan någon ny begäran från RU. Detta görs med hjälp av meddelandet Specifikation av tågläge, med referens till detta Tågläge inte tillgängligt-meddelande.

4.2.2.8   Meddelandet Kvitto på mottagande

Detta meddelande skall sändas från mottagaren av ett meddelande till avsändaren av meddelandet då det begärda svaret inte kan ges inom det tidsintervall som anges i avsnitt 4.4 (Driftsregler). Detta meddelande måste innehålla en uppgift om vilket meddelande det refererar till (poster i Svarsmeddelande, se avsnitt 4.2:, Allmänna anmärkningar om meddelandestrukturen) och följande angivelse: (på uppgiftsnivå)

—	Meddelandet mottaget: innebär att mottagaren har tagit emot meddelandet och kommer att vidta nödvändiga åtgärder enlighet med det.

4.2.3   Iordningställande av tåg

4.2.3.1   Allmänna anmärkningar

I detta avsnitt beskrivs de meddelanden som skall utbytas under iordningställandet av tåget fram till dess start. Meddelandena visas i tabell 5.

För tågets iordningställande måste RU ha tillgång till information om infrastrukturbegränsningar, tekniska vagndata (Referensdatabaser för rullande materiel, avsnitt 4.2.11.3: Referensdatabaserna för rullande materiel), referensfilen angående farligt gods och aktuell uppdaterad information om vagnarnas status (avsnitt 4.2.12.2: Driftdatabasen för godsvagnar och intermodala enheter). Detta gäller för alla vagnar i tåget. När det är klart skall RU sända tågsammansättningen till efterföljande berörda RU. Detta meddelande skall 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, skall 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.

Följande meddelanden används i denna dialog:

Tabell 5

Iordningställande av tåg

Meddelande		Förklaring
Tågets sammansättning.		RU till IM. Detta meddelande skall sändas enligt beskrivningen ovan.
	När IM har mottagit ett obligatoriskt meddelande om tågets sammansättning från RU, kan IM sända något av följande:
	Tåget godkänt	IM till RU. Detta meddelande är frivilligt, om inte annat avtalats mellan IM och RU.	Iordningställandet av tåget kan slutföras.
	Tåget är inte lämpligt	IM till RU. Detta meddelande kan sändas av IM, om denne finner att så är fallet.	RU: s möjligheter:   ändra tågsammansättningen eller   annullera tågläget och begära ett nytt tågläge
Tåget klart		RU till IM. Detta meddelande måste sändas.
Tågposition		IM till RU. Anger exakt var och när tåget skall inträda på nätet. Detta meddelande kan sändas beroende på nationella bestämmelser.
Tåg vid start		RU till IM. Detta meddelande kan sändas för att ange att tåget startat sin färd, som svar på meddelandet Tågposition. Detta meddelande kan sändas beroende på nationella bestämmelser.
Tågföringsinformation		Från IM till RU. Detta meddelande skall sändas för att ange att tåget anlänt till infrastrukturen.

I de följande kapitlen ges en beskrivning av dessa meddelanden, i form av en översikt över huvudpunkterna i respektive meddelande. Detaljer angående formatet anges i bilaga A index 1. Den logiska följordningen visas i bilaga A index 5 kapitel 3.

Anmärkning: Under tågets iordningställande kan också ett Tågläge inte tillgängligt-meddelande inkomma, eftersom det meddelandet kan sändas vid vilken tidpunkt som helst från det att tågläget avtalas och fram till tågets avgång. Förfarandet för detta beskrivs i avsnitt 4.2.2 (Begäran om tågläge).

4.2.3.2   Meddelandet Tågets sammansättning

Detta meddelande skall sändas från RU till nästa RU och innehålla uppgifter om tågets sammansättning. Detta meddelande skall också sändas från RU till berörd(a) IM när så krävs enligt TSD Drift och trafikledning för konventionella tåg eller enligt avtal mellan IM och RU. Så snart en ändring av sammansättningen sker under tågets färd, skall ansvarig RU uppdatera detta meddelande till alla berörda parter.

De uppgifter som skall sändas och vara tillgängliga är följande:

—	Tågidentitet och tåglägesidentitet för identifiering av tågläget.

—	Tåglägets utgångspunkt med datum och tid för det bokade tågläget.

—	Tåglägets destination med datum och klockslag när det föreslagna tåget skall ankomma till destinationen.

—	Identifiering av lok och lokets(lokens) position i tåget.

—	Tåglängd, tågvikt, högsta tillåtna hastighet för tåget.

—	Tågsammansättning, med uppräkning av fordonsnummer.

—	Styr- och kontrollsystem inbegripet typ av radioutrustning.

—	Information om särskild lastprofilsbegränsning.

—	UN/RID-nummer för farligt gods.

—	Angivelse om huruvida boskap eller personer (utöver tågpersonalen) kommer att transporteras.

—	Bromssystem som skall användas.

—

Vagndata.

När IM har mottagit tågsammansättningen kan IM kontrollera posterna gentemot det avtalade tågläget, om avtalet mellan IM och RU uttryckligen tillåter detta. I det fallet måste IM enkelt ha tillgång till information om eventuella begränsningar när det gäller den berörda infrastrukturen, tekniska vagndata (avsnitt 4.2.11.3:Referensdatabaserna för rullande materiel), referensfilen angående farligt gods och aktuell uppdaterad information om vagnarnas status (avsnitt 4.2.12.2: Andra databaser, driftdatabasen för godsvagnar och intermodala enheter). Detta gäller för alla vagnar i tåget. I det fallet måste också IM, som förvaltar sina tåglägen och håller den aktuella statusen på informationen om tåglägena uppdaterad, lägga till uppgifterna om tågets sammansättning till de uppgifter om tågläget och tåget som omnämns i avsnitt 4.2.2.1 (Begäran om tågläge, Inledande anmärkningar).

4.2.3.3   Meddelandet Tåget godkänt

Beroende på avtalet mellan IM och RU och fastställda krav kan IM även meddela RU om tågets sammansättning kan godkännas för det bokade tågläget. Det görs med detta meddelande.

Huvudinnehållet i detta meddelande är följande:

—	Tåg- och tåglägesidentiteter.

—	Tåglägets utgångspunkt med datum och tid för det bokade tågläget.

—	Tåglägets destination med datum och klockslag när det föreslagna tåget skall ankomma till destinationen.

—	Angivelse om att IM godkänner tågsammansättningen som lämplig för det avtalade tågläget.

4.2.3.4   Meddelandet Tåget är inte lämpligt

Om tåget inte är lämpligt för det tidigare avtalade tågläget, kan IM underrätta RU med detta meddelande. I detta fall måste RU kontrollera tågets sammansättning på nytt. Huvudinnehållet i detta meddelande är följande:

—	Tåg- och tåglägesidentiteter.

—	Tåglägets utgångspunkt med datum och tid för det bokade tågläget.

—	Tåglägets destination med datum och klockslag när det föreslagna tåget skall ankomma till destinationen.

—	Angivelse om att tåget inte är lämpligt, vilket anger att tåget inte överensstämmer med kraven för det tilldelade tågläget och därför inte får framföras.

—	Angivelse av orsaken.

4.2.3.5   Meddelandet Tåget klart

Detta meddelande skall sändas från RU till IM för att ange att tåget är klart för tillträde till nätet. Huvudinnehållet i detta meddelande är följande:

—	Tåg- och tåglägesidentiteter.

—	Tåglägets utgångspunkt med datum och tid för det bokade tågläget.

—	Tåglägets destination med datum och klockslag när det föreslagna tåget skall ankomma till destinationen.

—	Angivelse om att tåget är klart, vilket anger att tåget har iordningställts och är färdigt att framföras.

—	Kommunikations-ID för all kommunikation mellan tåg och tågledning.

—

Om avtalet mellan RU och IM inte kräver utväxling av meddelandena ”Tågposition/Tåg vid start”, måste tågfärdens startdatum och -tid, som underrättar IM om det datum och den tidpunkt när tåget beräknas inträda på nätet, anges i detta meddelande. Om utväxling av meddelandena ”Tågposition/Tåg vid start” krävs, skall denna uppgift inte sändas.

4.2.3.6   Meddelandet Tågposition

Detta meddelande kan IM sända till RU för att ange exakt när och var tåget skall inträda på nätet som svar på meddelandet om att tåget är klart. Huruvida detta meddelande skall överföras beror på avtalet mellan RU och IM. I det fall överföring krävs, är huvudinnehållet i detta meddelande följande:

—	Tåg- och tåglägesidentiteter.

—	Tåglägets utgångspunkt med datum och tid för det bokade tågläget.

—	Tåglägets destination med datum och klockslag när det föreslagna tåget skall ankomma till destinationen.

—	Spåridentifiering, som informerar RU om spårnummer för det spår på vilket tåget skall inträda på nätet.

—	Tågfärdens startdatum och -tid, som underrättar RU om det datum och den tidpunkt när tåget skall inträda på nätet

—	Kommunikations-ID.

4.2.3.7   Meddelandet Tåg vid start

Detta meddelande kan RU sända till IM då man mottagit ett Tågposition-meddelande från IM, för att ange att tåget påbörjat sin färd. Detta meddelande måste innehålla en uppgift om vilket meddelande det refererar till, samt indikeringen:

—	Tåg vid start: Datum och klockslag när tåget påbörjade sin färd.

4.2.3.8   Tågföringsinformation

Så snart tåget befinner sig på IM: s infrastruktur, vilket innebär att tåget har lämnat avgångsstationen, sänder IM detta meddelande till den RU som bokat tågläget. Detta meddelande beskrivs i avsnitt 4.2.4 (Tågföringsprognos).

4.2.4   Tågföringsprognos

4.2.4.1   Allmänna anmärkningar

I detta avsnitt beskrivs de meddelanden som skall utbytas under ett tågs normala framförande utan avbrott.

Meddelandena i fråga är följande:

Tågföringsprognos.

Tågföringsinformation.

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. Vid öppen tillgång, som innebär att tåglägena för hela färden bokats av en RU (denna RU ansvarar även för driften av tåget under hela färden), sänds alla meddelanden till denna RU. Detsamma gäller om tåglägena för färden bokats av en RU genom OSS.

För en närmare beskrivning exemplifieras nedan en rad olika scenarier, där hänsyn tas till de olika kommunikationsrelationerna mellan RU och IM, vilka följer av de olika scenarierna för bokning av tågläge i avsnitt 4.2.2.1 (, scenario A resp. B):

—	Tåget närmar sig en överlämningspunkt mellan IM nr 1 och den angränsande IM nr 2

Det förutsätts att överlämningspunkten inte samtidigt är en utväxlingspunkt (endast scenario B) eller en hanteringspunkt. Således är överlämningspunkten en punkt på en RU: s bokade tåglägen, och RU har redan sänt tågsammansättningen till IM nr 2, samtidigt som det meddelandet sändes till IM nr 1.

Efter avgång från utgångspunkten (5), skall IM nr 1 sända ett meddelande om tågföringsprognos till IM nr 2, med den beräknade tidpunkten för överlämnandet (ETH). Detta meddelande sänds samtidigt till RU.

När tåget lämnar IM nr 1: s infrastruktur vid överlämningspunkten sänder denna IM ett meddelande om tågföringsinformation med den faktiska tidpunkten för överlämnandet vid denna punkt till den RU som bokat tågläget.

När tåget inträder på IM nr 2: s infrastruktur vid överlämningspunkten sänder denna IM ett meddelande om tågföringsinformation med den faktiska tidpunkten för överlämnandet från denna punkt till den RU som bokat tågläget.

—	Tåget närmar sig en utväxlingspunkt mellan RU 1 och nästa RU 2 (endast scenario B)

I avtalet om tågläge skall en utväxlingpunkt alltid definieras som en rapporteringspunkt. (TETA vid rapporteringspunkter fastställs av IM enligt angivelserna i deras avtal med RU.)

För denna punkt sänder ansvarig IM, så snart tåget lämnat den föregående rapporteringspunkten, ett meddelande om tågföringsprognos med TETA för denna utväxlingspunkt till den RU som avtalat om tågläget med IM (t.ex. RU 1). RU 1 vidarebefordrar detta meddelande till nästa RU (t.ex. RU 2) som skall ta över tåget. Dessutom sänds detta meddelande också till LRU för transporten, om det finns en sådan och om detta anges i samarbetsavtalet mellan de båda RU.

Om utväxlingspunkten också är en överlämningspunkt mellan t.ex. IM nr 1 och IM nr 2, sänder IM nr 1 meddelandet om tågföringsprognos redan efter avgång från utgångspunkten eller från föregående utväxlingspunkt till IM nr 2 med den beräknade tidpunkten för överlämnandet (ETH). Detta meddelande sänds även till den RU som avtalat om tågläget t.ex. RU 1. För RU är ETH lika med TETA vid utväxlingspunkten. RU 1 vidarebefordrar detta meddelande till den angränsande RU 2, och till LRU för transporten om det finns en sådan och om detta anges i samarbetsavtalet mellan de båda RU.

När tåget ankommer till en utväxlingspunkt, skall IM sända ett meddelande om tågföringsinformation till den RU som IM avtalat om tågläge med, till exempel RU 1, med den faktiska ankomsttiden till den punkten.

Innan tåget lämnar utväxlingspunkten, skall RU 2 sända ett nytt meddelande om tågets sammansättning till den IM som tilldelat tågläget och följa den avgångsprocedur som beskrivs i avsnitt 4.2.3 (Iordningställande av tåg).

—	Tåget närmar sig en hanteringspunkt för en RU (scenario A)

En hanteringspunkt skall i avtalet om tågläget alltid definieras som en rapporteringspunkt.

För denna punkt måste ansvarig IM sända ett meddelande om tågföringsprognos med en TETA endast i det fall detta anges i avtalet mellan IM och RU.

Men om hanteringspunkten också är en överlämningspunkt mellan, till exempel, IM nr 1 och IM nr 2, skall IM nr 1 sända meddelandet om tågföringsprognos efter avgång från utgångspunkten eller från föregående utväxlingspunkt till IM nr 2 med den beräknade tidpunkten för överlämnandet (ETH). Detta meddelande sänds även till RU. För RU är ETH lika med TETA vid hanteringspunkten.

När tåget ankommer till hanteringspunkten, skall IM sända ett meddelande om tågföringsinformation med den faktiska ankomsttiden till denna punkt till RU.

Innan tåget lämnar hanteringspunkten skall RU och IM följa den avgångsprocedur som beskrivs i avsnitt 4.2.3 (Iordningställande av tåg).

—	Tåget ankommer till destinationen

När tåget ankommer till sin destination sänder ansvarig IM ett meddelande om tågföringsinformation med den faktiska ankomsttiden till den RU som avtalat om tågläget.

Anmärkning: I avtalet om tågläge kan även andra positioner anges för vilka det krävs en tågföringsprognos med TETA och meddelanden om tågföringsinformation med faktiska tider. För dessa punkter sänder ansvarig IM dessa meddelanden i enlighet med vad som anges i avtalet. Ytterligare utvärdering och behandling av levererade ETH och TETA beskrivs i avsnitten 4.2.7 (ETI/ETA för en försändelse) till 4.2.9 (Rapportering om utväxling).

I de följande avsnitten beskrivs meddelandena ”Tågföringsprognos” och ”Tågföringsinformation” endast genom att huvudinnehållet tas upp. Detaljer angående formatet anges i bilaga A index 1. Den logiska följdordningen för denna utväxling av meddelanden, i relation till de olika kommunikationsscenarierna, visas i bilaga A index 5 kapitel 4 med anmärkningen att när det gäller kommunikationsrelationerna mellan RU och IM för tågföring, är de båda scenarierna för begäran om tågläge A(fall A) och A(fall B) (avsnitt 4.2.2.1: Begäran om tågläge, Inledande anmärkningar) identiska, eftersom berörda IM i bägge fallen har kontakt med bara en RU t.ex. RU 1 som ansvarar för driften av tåget längs hela tågläget och som också ansvarar för den nya tågsammansättningen vid hanteringspunkterna.

4.2.4.2   Meddelandet Tågföringsprognos

Detta meddelande skall utfärdas av IM 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 skall meddelandet utfärdas av IM till RU för andra rapporteringspunkter enligt avtal RU–IM (t.ex. för hanteringspunkter).

Huvuduppgifterna i meddelandet är följande:

—	Tåglägesidentitet och tågidentitet.

—	Datum och tid för avgång enligt lokal tidtabell (eller tidpunkt för överlämnande enligt tidtabell till nästa IM).

—	Identifiering av rapporteringspunkt.

—	Prognostiserat datum och tid vid rapporteringspunkt.

4.2.4.3   Meddelandet Tågföringsinformation

Detta meddelande skall utfärdas vid följande händelser:

—	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). Huvuduppgifterna i meddelandet är följande: — Tåglägesidentitet och tågidentitet. — Datum och tid för avgång enligt lokal tidtabell. — Identifiering av senaste rapporteringspunkt. — Faktisk tid vid rapporteringspunkt. — Status för rapporteringspunkten för tåget (Ankomst, Avgång, Passering, Inte specificerad, Avgång från utgångspunkt, Ankomst till destination). — Ankomstspår vid positionen. — Avgångsspår från positionen. — Delta-avvikelse i minuter i förhållande till bokad tid enligt tidtabell. — Aktuell tidtabell om flera tidtabellsändringar skett. — För varje avvikelse från bokad tid enligt tidtabell vid den rapporteringspositionen: — orsakskod (eventuellt flera), — avvikelse i tid för varje orsakskod (flera orsaker kan listas för samma rapporteringspunkt), — fri text som kan läggas till om avvikelsen.

4.2.5   Information om trafikstörning

4.2.5.1   Allmänna anmärkningar

Då RU får kännedom om en trafikstörning under ett tågs framförande för vilket den är driftsansvarig, skall RU omedelbart underrätta IM (inget IT-meddelande, t.ex. muntligt meddelande från föraren). Om nödvändigt uppdaterar RU driftdatabasen för godsvagnar och intermodala enheter. Om nödvändigt uppdaterar IM uppgifterna om infrastrukturen i databasen över information om infrastrukturbegränsningar och/eller tågläges- respektive tågdatabasen.

Om fördröjningen överstiger x minuter (detta värde skall bestämmas i avtalet mellan RU och IM) skall den berörda IM till RU sända ett meddelande om tågföringsprognos med avseende på nästa rapporteringspunkt.

Om tåget ställs in, sänder IM ett meddelande om avbrott i tågföringen enligt vad som beskrivs nedan.

I de fall oförutsedda händelser inträffar som gör att RU eller IM inte kan framföra tåget den prognostiserade tiden, skall ett nytt tågläge enligt avsnitt 4.2.2 (Begäran om tågläge) avtalas.

4.2.5.2   Meddelandet Avbrott i tågföringen.

Om tåget ställs in, utfärdar IM detta meddelande till angränsande IM och till den RU som avtalat om tågläget.

Huvuduppgifterna i detta meddelande är följande:

—	Tågläges- och tågidentiteter.

—	Identifiering av position.

—	Datum och tid för avgång enligt tidtabell från denna position.

—	Orsak till avbrottet.

—	Beskrivning av avbrottet.

4.2.6   Tågposition

4.2.6.1   Inledning

I detta avsnitt beskrivs möjligheten till spårning för att få uppgift om tågposition. RU kan när som helst sända en förfrågan om sina tåg till IM. RU kan fråga om

—	tågets framförande (senast registrerade position, fördröjningar, orsaker till fördröjningar),

—	tågets resultat (fördröjningar, orsaker till fördröjningar, positioner för fördröjningar),

—	alla identiteter för ett visst tåg,

—	tågföringsprognos vid en viss position,

—	alla tågföringsprognoser för en viss position.

Tillgången till denna information skall vara oberoende av kommunikationsrelationen mellan RU och IM under tågets framförande, vilket betyder att RU måste ha tillgång till informationen via en enda adress (6). Informationen grundar sig främst på den lagrade utväxlingen av meddelanden såsom nämnts ovan.

4.2.6.2   Meddelanden för förfrågan om tågföring

Syfte	:	RU frågar om senast registrerad status (position, fördröjningar och orsaker till fördröjningar) för ett visst tåg på en viss IM: s infrastruktur.
Förfrågan	:	Huvuduppgifter: — Tågidentitet. — Identifiering av IM. — Datum och tid för avgång enligt lokal tidtabell.
Svar	:	Informationsdata: — Senast rapporterade position. — Faktisk tid vid rapporteringspunkt. — Status för rapporteringspunkten för tåget (Ankomst, Avgång, Passering, Inte specificerad, Avgång från utgångspunkt, Ankomst till destination). — Ankomstspår vid positionen. — Avgångsspår från positionen. — Bokad tid enligt tidtabell. — Delta-fördröjning i förhållande till bokad tid enligt tidtabell. — Ändrad tid (i förhållande till aktuell tidtabell om flera tidtabellsändringar skett). — För varje fördröjning, vid den rapporteringspositionen: — Orsakskod och tidsfördröjning för denna orsakskod.

4.2.6.3   Meddelanden för förfrågan om tågs fördröjning/resultat

Syfte	:	RU frågar om alla fördröjningar för ett visst tåg som berör en viss IM.
Förfrågan	:	Huvuduppgifter: — Tågidentitet. — Identifiering av IM. — Datum och tid för avgång enligt lokal tidtabell.
Svar	:	Informationsdata (samma uppgifter som vid ”Förfrågan om tågföring”, men inte bara för den senaste punkten utan för varje rapporteringspunkt för tåget på den berörda IM: s infrastruktur): — För varje rapporteringspunkt: — Rapporterad position. — Faktisk tid vid rapporteringspunkt. — Status för rapporteringspunkten för tåget (Ankomst, Avgång, Passering, Inte specificerad, Avgång från utgångspunkt, Ankomst till destination). — Ankomstspår vid positionen. — Avgångsspår från positionen. — Bokad tid enligt tidtabell. — Delta-fördröjning i förhållande till bokad tid enligt tidtabell. — Ändrad tid (i förhållande till aktuell tidtabell om flera tidtabellsändringar skett). — För varje fördröjning, vid den rapporteringspositionen: — Orsakskod och tidsfördröjning för denna orsakskod.

4.2.6.4   Meddelanden för förfrågan om tågidentitet

Syfte	:	RU frågar om tågets aktuella tågidentitet och dess tidigare tågidentiteter. Vilken som helst av ett visst tågs tågidentiteter kan användas vid förfrågan.
Förfrågan	:	Huvuduppgifter: — Känd tågidentitet. — Identifiering av IM. — Datum och tid för avgång enligt lokal tidtabell.
Svar	:	Informationsdata: — Aktuell tågidentitet: — Tågidentitet. — Datum och tid för avgång enligt lokal tidtabell. — För varje annan tågidentitet: — Tågidentitet. — Datum och tid för avgång enligt lokal tidtabell.

4.2.6.5   Meddelanden för förfrågan till IM om tågföringsprognos

Syfte	:	RU frågar om den prognostiserade tiden för ett visst tåg vid en viss rapporteringsposition eller, genom att utelämna rapporteringspositionen, om den planerade tiden vid överlämningspunkten från IM.
Förfrågan	:	Huvuduppgifter: — Tågidentitet. — Datum och tid för avgång enligt lokal tidtabell. — Identifiering av rapporteringspositionen. (Den rapporteringsposition som förfrågan om prognos avser. Detta är frivilligt och om inte annat anges hänför sig svaret till den sista rapporteringspunkten för ifrågavarande IM för detta tåg.)
Svar	:	Informationsdata: — IM-kod. — Identifiering av rapporteringspunkt. — Prognostiserat datum och tid vid rapporteringspunkt.

4.2.6.6   Meddelanden för förfrågan till IM om tåg vid rapporteringsposition

Syfte	:	RU frågar om alla sina tåg vid en viss rapporteringsposition på en viss IM: s infrastruktur.
Förfrågan	:	Huvuduppgifter: — IM-kod. — Identifiering av rapporteringspositionen. (Den rapporteringsposition som förfrågan om prognos avser. Detta är frivilligt och om inte annat anges hänför sig svaret till den sista rapporteringspunkten för ifrågavarande IM för detta tåg.)
Svar	:	Informationsdata: — För vart och ett av denna förfrågares tåg: — Tågidentitet. — Datum och tid för avgång enligt lokal tidtabell eller tidpunkt för överlämnande enligt tidtabell. — IM-kod. — Identifiering av rapporteringspunkt. — Prognostiserat datum och tid vid rapporteringspunkt.

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

4.2.7.1   Inledande anmärkning

I avsnitten 4.2.2 (Begäran om tågläge) till 4.2.6 (Begäran om tågläge) har främst kommunikationen mellan RU och IM beskrivits. Eftersom infrastrukturförvaltarens uppgift är att övervaka och leda tågen, är nyckelelementet i denna kommunikation tågidentiteten. Vagnsinformationen i meddelandet om tågets sammansättning är relevant för att kontrollera tågsammansättningen gentemot tåglägesavtalet mellan RU och IM samt vid oförutsedda händelser.

Övervakning av individuella vagnar och intermodala enheter omfattas inte av denna utväxling av information. Detta görs på RU/LRU-nivå med utgångspunkt från de tågrelaterade meddelandena och beskrivs i avsnitten 4.2.7 (ETI/ETA för en försändelse) till 4.2.9 (Rapportering om utväxling) nedan.

Utväxlingen och uppdateringen av information angående vagnar och intermodala enheter stöds huvudsakligen av lagring av ”färdplaner” och ”vagnrörelser” (avsnitt 4.2.12.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.

4.2.7.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 (som minst 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, skall 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. Detta förklaras i följande två förenklade exempel (en grafisk framställning av dessa scenarier finns i bilaga A index 5 avsnitt 1.4 och ett sekvensdiagram baserat på exempel 1 för utväxlingspunkt C återfinns i bilaga A index 5 kapitel 5).

Exempel 1	:	RU 1 har vagnarna nr 1 och 2 från LRU 1 och vagnarna nr 3–5 från LRU 2 i samma tåg. Vid utväxlingspunkten C kommer den vidare transporten av vagnarna 1 och 2 att tas över av RU 2 och den vidare transporten av vagnarna 3–5 tas över av RU 3. I detta fall skall RU 1 med avseende på utväxlingspunkten C beräkna ETI för vagnarna 1 och 2 och sända dessa värden till LRU 1. RU 1 skall också med avseende på samma utväxlingspunkt C beräkna ETI för vagnarna 3–5 och sända dessa värden till LRU 2.
Exempel 2	:	RU 1 har vagnarna nr 1 och 2 från LRU 1 och vagnarna nr 3–5 från LRU 2 i samma tåg. Vid utväxlingspunkten C kommer den vidare transporten av vagnarna 3–5 att tas över av RU 3 medan vagnarna 1 och 2 blir kvar i RU 1: s tåg fram till utväxlingspunkten E, där ansvaret för dessa vagnar tas över av RU 2. I detta fall skall RU 1 med avseende på utväxlingspunkten C beräkna ETI endast för vagnarna 3–5 och sända dessa värden till LRU 2. För vagnarna 1 och 2 är utväxlingspunkten C inte relevant. Nästa relevanta utväxlingspunkt för dessa vagnar är E och med avseende på denna punkt skall RU 1 beräkna ETI och sända dessa värden till LRU 1.

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, skall 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 vagnordern och enligt LRU: s åtagande gentemot kunden. Detta är ETA för vagnen och skall sändas till LRU. ETA skall lagras elektroniskt tillsammans med vagnrörelser. LRU skall ge kunden tillgång till relevanta data, 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 skall hanteras i enlighet med avtalet och kan leda till en avvikelsehanteringsprocess från LRU: s sida. För överförandet av information om resultatet av denna process används ett underrättelsemeddelande.

Som grundval för avvikelsehanteringsprocessen skall 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.7.3   Meddelandet ETI/ETA för vagn.

Syfte	:	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.
Huvuduppgifter	:	— Identifiering av den RU som fastställt ETI eller ETA. — Utgångspunkt eller föregående utväxlingspunkt (ETI eller avgångstid från ursprungsstation). — Tågidentitet från utgångspunkt eller föregående utväxlingspunkt (från ETI eller avgångstid från ursprungsstation). — Faktiskt datum och tid för avgång för tåget. — Ankomst till slutstation eller nästa utväxlingsstation (ETI/ETA slut). — Tågidentitet vid ankomst till den station som ETI/ETA slut avser (slutstation eller nästa utväxlingsstation). — Datum och tid för vagnens ankomst (ETI eller ETA).

4.2.7.4   Underrättelsemeddelande

Syfte	:	Efter jämförelse mellan ETA och åtagandet gentemot kunden, kan LRU sända ett underrättelsemeddelande till berörda RU.
Huvuduppgifter	:	— Vagnnummer. — Åtagande gentemot kunden: datum och tid för ankomst. — Aktuell ETA: datum och tid.

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.5   Meddelanden för förfrågan om avvikelser beträffande vagnar

Syfte	:	LRU frågar om avvikelser med avseende på en viss vagn.
Förfrågan	:	Huvuduppgifter — Vagnnummer. — Identifiering av LRU.
Svar	:	Informationsdata: — För varje rapporteringspunkt: — Rapporteringsposition. — Status för rapporteringspunkten för vagnen (avgång, ankomst till bangård, avgång från bangård, ankomst till utväxlingspunkt, ankomst till destinationsbangård). — Ansvarig RU vid rapporteringsposition och enligt status för rapporteringspunkten för vagnen. — Ändrad tid (i förhållande till aktuell tidtabell om flera tidtabellsändringar skett). — ETI, om rapporteringspunkten är en utväxlingspunkt. — Faktisk tid vid rapporteringspunkt. — För varje avvikelse, vid den rapporteringspunkten: — Orsakskod och tidsfördröjning för denna orsak.

4.2.8   Vagnrörelse

4.2.8.1   Inledande anmärkningar

För rapportering av en vagns rörelse måste nedanstående data lagras och finnas tillgängliga elektroniskt. De skall även utbytas inom ramen för meddelanden på avtalsbasis till godkända parter. Detaljer angående formatet anges i bilaga A index 1.

—	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

—	Bekräftelse av leverans av vagn

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

4.2.8.2   Meddelandet Meddelande om frisläppande av vagn

Syfte	:	LRU till RU. LRU är inte nödvändigtvis den första RU i tranportkedjan. I detta fall skall 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). Denna händelse skall lagras i driftdatabasen för godsvagnar och intermodala enheter.
Huvuduppgifter	:	— Vagnnummer. — Plats, datum och tid för avgång (plats varifrån en transport skall avgå enligt tidtabell). Följande uppgifter skall lagras i databaser och vara lätt åtkomliga för RU och LRU: — Transportenhet, identifiering, storlek och typ. — Använd kapacitet i enheten. — Totalvikt (bokad/faktisk totalvikt (massa) av gods, inklusive emballage och transportutrustning). — Angivelse om farligt gods.

4.2.8.3   Meddelandet Meddelande om vagns avgång

Syfte	:	RU till LRU. RU skall underrätta LRU om den faktiska tidpunkten då vagnen dragits från avgångsplatsen. Denna händelse skall 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 the RU.
Huvuduppgifter	:	— Vagnnummer. — Plats, datum och tid för avgång (plats varifrån en transport skall avgå enligt tidtabell). Följande uppgifter skall lagras i databaser och vara lätt åtkomliga för RU och LRU: — Transportenhet, identifiering, storlek och typ. — Använd kapacitet i enheten. — Totalvikt (bokad/faktisk totalvikt (massa) av gods, inklusive emballage och transportutrustning). — Angivelse om farligt gods.

4.2.8.4   Meddelandet Vagns ankomst till bangård

Syfte	:	RU skall underrätta LRU om att vagnen anlänt till RU: s 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 skall lagras i driftdatabasen för godsvagnar och intermodala enheter.
Huvuduppgifter	:	— Vagnnummer. — Identifiering av ankomstbangård. — Datum och tid för ankomst till bangården.

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

Syfte	:	RU skall underrätta LRU om att vagnen avgått från RU: s 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 skall lagras i driftdatabasen för godsvagnar och intermodala enheter.
Huvuduppgifter	:	— Vagnnummer. — Identifiering av avgångsbangård. — Datum och tid för avgång från bangården.

4.2.8.6   Meddelande om vagnsavvikelse

Syfte	:	RU skall 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:). Den nya beräkningen av ETI/ETA skall följa det förfarande som beskrivs i avsnitt 4.2.7 (ETI/ETA för en försändelse). Denna information skall lagras i driftdatabasen för godsvagnar och intermodala enheter.
Huvuduppgifter	:	— Vagnnummer. — Plats, datum och tid för trafikstörning (plats där något oförutsett inträffat under transporten). — Orsaks-/trafikstörningskod. Dessutom måste följande uppgifter lagras i databaser och finnas lätt tillgängliga: — Identifiering av transportenhet. — Angivelse om farligt gods.

4.2.8.7   Förfrågan om ny ETI/ETA till följd av Meddelande om vagnsavvikelse

Syfte	:	LRU kan sända detta meddelande till den RU som sänt meddelandet om vagnsavvikelse, för att begära en ny beräkning av ETI/ETA. LRU sänder detta meddelande även till alla efterföljande RU för att underrätta dem om avvikelserna. LRU avgör huruvida det krävs en ny beräkning av ETI/ETA, vilket inte är nödvändigt i samtliga fall.
Huvuduppgifter	:	— Vagnnummer. — Plats, datum och tid för trafikstörning (plats där något oförutsett inträffat under transporten). — Orsaks-/trafikstörningskod. — Förfrågan om ny ETI/ETA. Dessutom måste följande uppgifter lagras i databaser och finnas lätt tillgängliga: — Identifiering av transportenhet. — Angivelse om farligt gods.

4.2.8.8   Meddelandet Meddelande om vagns ankomst

Syfte	:	Den sista RU i en transportkedja av vagnar eller intermodala enheter skall underrätta LRU om att vagnen har anlänt till RU: s bangård.
Huvuduppgifter	:	— Vagnnummer. — Identifiering av RU: s bangård. — Datum och tid för ankomst.

4.2.8.9   Meddelandet Meddelande om leverans av vagn

Syfte	:	Den sista RU i en vagntransportkedja skall underrätta LRU om att vagnen har placerats på mottagarens rangerbangård.
Huvuduppgifter	:	— Vagnnummer. — Identifiering av placering på mottagarens rangerbangård (position, område, spår, spåravsnitt). — Datum och tid för placering.

Meddelandet om leverans av vagn kan sändas en andra gång som en ”Bekräftelse av leverans av vagn” med följande ytterligare uppgifter:

—	Identifiering av kunden.

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.7.2) ingår i diagrammet för rapportering om utväxling i bilaga A index 5 kapitel 6.

4.2.9   Rapportering om utväxling

4.2.9.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 ett järnvägsföretag till ett annat, 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.7 (ETI/ETA för en försändelse).

Följande meddelanden skall utbytas:

—	Meddelande om utväxling av vagn.

—	Meddelande om utväxling av vagn/Sub.

—	Vagn mottagen vid utväxlingspunkt.

—	Vagn avvisad vid utväxlingspunkt.

Dessa meddelandens informationsdata skall lagras i driftdatabasen för godsvagnar och intermodala enheter. I händelse av någon form av avvikelse skall en ny ETI/ETA fastställas och meddelas enligt det förfarande som beskrivs i avsnitt 4.2.7: ETI/ETA för en försändelse. Sekvensdiagrammet för dessa meddelanden visas i anslutning till meddelandena om vagnrörelser i bilaga A index 5 kapitel 6.

Meddelandena om utväxling av vagn och meddelandena om utväxling av vagn/Sub 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 skall 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.

Innehållet i dessa meddelanden beskrivs nedan.

4.2.9.2   Meddelandet Meddelande om utväxling av vagn

Syfte	:	Med ”Meddelande om utväxling av vagn” frågar ett järnvägsföretag (RU 1) nästa järnvägsföretag (RU 2) i transportkedjan om detta accepterar att ta över ansvaret för en vagn. Med ”Meddelande om utväxling av vagn/Sub” underrättar RU 2 sin IM om att den accepterat att ta över ansvaret.
Huvuduppgifter	:	— Vagnnummer. — Tågidentitet (endast om vagnen ingår i ett tåg). — Position, datum och tidpunkt för utväxling. Dessutom måste följande uppgifter lagras i databaser och finnas lätt tillgängliga: — Identifiering av transportenhet (nummer, storlek och typ). — Totalvikt (bokad/faktisk totalvikt (massa) av gods, inklusive emballage och transportutrustning). — Använd kapacitet i enheten. — Identifiering av och detaljer angående farligt gods.

4.2.9.3   Meddelandet Meddelande om utväxling av vagn/Sub.

Syfte	:	Med ”Meddelande om utväxling av vagn/Sub” underrättar RU 2 IM om att den accepterat att ta över ansvaret för en viss vagn.
Huvuduppgifter	:	— Vagnnummer. — Tågidentitet (endast om vagnen ingår i ett tåg). — Position, datum och tidpunkt för utväxling. Dessutom måste följande uppgifter lagras i databaser och finnas lätt tillgängliga: — Identifiering av och detaljer angående farligt gods.

4.2.9.4   Meddelandet Vagn mottagen vid utväxlingspunkt

Syfte	:	Med meddelandet ”Vagn mottagen vid utväxlingspunkt” underrättar RU 2 RU 1 om att den accepterar att ta över ansvaret för vagnen.
Huvuduppgifter:	:	— Vagnnummer. — Position, datum och tidpunkt för utväxling.

4.2.9.5   Meddelandet Vagn avvisad vid utväxlingspunkt

Syfte	:	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.
Huvuduppgifter	:	— Vagnnummer. — Position, datum och tidpunkt för utväxling. — Orsakskod för avvisandet. — Närmare beskrivning (frivilligt).

4.2.10   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 2001/16/EG).

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, skall 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 skall tydligt visa den uppnådda nivån i förhållande till det mål som överenskommits mellan de avtalsslutande parterna.

Utvärderingsrapporterna måste ge tillgång till tillräckligt detaljerade uppgifter för att en analys skall kunna göras som visar position och förmodad orsak till kvalitetsnedsättningar t.ex. fördröjningar. En analys av de grundläggande orsakerna måste sedan genomföras med avseende på återkommande kvalitetsbrister, så att beslut om korrigerande åtgärder kan fattas av de avtalsslutande parterna.

IM och RU är skyldiga att tillhandahålla uppgifter, delta i analyser av grundläggande orsaker, även med tredje part, samt att vidta alla korrigerande åtgärder som överenskommits.

Utvärderingsprocessen är en återkommande process.

För att mäta kvaliteten kan de redan beskrivna meddelandena användas, på det sätt som visas under de 6 rubrikerna här nedan:

1.   LRU/Kund: Transiteringstid, ETA, detaljeringsgrad i underrättelser

I avtal mellan sådana RU som agerar transportsamordnare (LRU) och kunder, kan åtaganden göras (beroende på de enskilda avtalen) beträffande transiteringstid, ETA och detaljeringsgrad i underrättelser. De mest relevanta meddelandena för denna kvalitetsmätning är

Meddelande om frisläppande,

Meddelande om avgång,

Meddelande om leverans.

2.   LRU/Tjänsteleverantörer: Transiterings- och hanteringstider, ETA, ETI, orsakskoder

I avtal mellan en LRU och andra transporttjänsteleverantörer kan enskilda tjänsteleverantörer göra åtaganden med avseende på transiteringstider (timmar) enligt följande:

Från tid för frisläppande/klar att dras till leverans vid utväxlingspunkt.

Från upphämtning till på uppställningsplats.

Från på uppställningsplats till lastning.

Från mottagning vid utväxlingspunkt till leverans vid utväxlingspunkt.

Från mottagning vid utväxlingspunkt till placering/konstruktiv placering.

Från ankomst till destination till leverans.

De mest relevanta meddelandena för denna kvalitetsmätning är

Meddelande om frisläppande,

Meddelande om avgång,

Ankomst till bangård,

Avgång från bangård,

Meddelande om ankomst,

Vagn levererad till utväxlingspunkt,

Vagn mottagen vid utväxlingspunkt,

Vagn avvisad vid utväxlingspunkt.

3.   RU/IM: Tågets resultat, tågets ETA (TETA), ETH

I avtal mellan RU och IM kan en punktlighetsnivå i förhållande till tågtidtabeller vid angivna rapporteringspunkter specificeras, liksom exakthet vad gäller ETA och ETH för tåget. De mest relevanta meddelandena för denna kvalitetsmätning är

Tågföringsprognos,

Tågföringsinformation,

Förfrågan/Svar om tågs fördröjning/resultat.

4.   RU/IM: Tillgång till tågläge/planerat

I avtal mellan RU och IM beskrivs tydligt tillgången till tåglägen för att framföra tåg i termer av tidsomfång mellan specifika punkter. Specifikationer för tågen i fråga om maxlängd, bruttovikt, lastprofil etc. ingår också i dessa avtal. Denna aspekt tas upp under rubrik 6 (IM/RU: Kvalitet avseende tågsammansättning).

Förfaranden och tidsramar för att bekräfta utnyttjandet av ett tågläge, annullera ett planerat tågläge och den utsträckning i vilken ett tågläge kan användas utanför (före eller efter) det angivna tidsomfånget kan också omfattas av dessa avtal. De mest relevanta meddelandena för denna kvalitetsmätning är

Annullerat tågläge,

Tågläge inte tillgängligt.

5.   RU/IM: Tillgång till tågläge med kort varsel

När en RU vill framföra ett tåg utanför de fastställda tidsramarna för ett bokat tågläge, måste en begäran om tågläge med kort varsel sändas till berörd(a) IM (såsom föreskrivs i direktiv 2001/14/EG).

RU skall med regelbundna mellanrum jämföra uppgifterna i begäran om tågläge med uppgifterna i svaret för att producera rapporter om

svarstid på begäran om tågläge jämfört med ramavtalet,

antal tillhandahållna tåglägen inom vissa tidsperioder, inom den tid begäran avsåg,

antal avvisade ansökningar om tåglägen.

De mest relevanta meddelandena för denna kvalitetsmätning är

Begäran om tågläge,

Specifikation av tågläge,

Avvisad specifikation av tågläge,

Annullerat tågläge,

Tågläge inte tillgängligt.

6.   IM/RU: Kvalitet avseende tågsammansättning

Då meddelanden om att tåget är klart och/eller listor över tågets sammansättning sänds av en RU till berörd(a) IM eller till andra RU, skall de överensstämma med tågspecifikationerna i tillämpligt avtal. För att kontrollera denna överensstämmelse och därmed mäta kvaliteten när det gäller tågets sammansättning är de mest relevanta meddelandena

Tågets sammansättning,

Tåget är inte lämpligt.

4.2.11   Viktigaste referensdata

4.2.11.1   Inledning

Uppgifter om infrastrukturen (järnvägsnätsbeskrivningarna och de lagrade uppgifterna i databasen över 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.11.2   Databaserna över information om infrastrukturbegränsningar

Varje IM är ansvarig för lämpligheten hos ett tågläge på den egna infrastrukturen och RU är skyldig att kontrollera tågets egenskaper mot de värden som anges i specifikationen av tågläget 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.

För detta syfte måste IM inrätta och fylla i databaser över information om infrastrukturbegränsningar. Strukturen för en sådan databas beskrivs i bilaga A index 2. Posterna i dessa databaser grundar sig på avsnitten i motsvarande järnvägsnätsbeskrivningar med tillägget information om begränsningar. Dessa databaser måste vara tillgängliga via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.14.7: Gemensamt gränssnitt).).

RU är skyldig att ta hänsyn till alla begränsningar i databasen över information om infrastrukturbegränsningar som har betydelse för RU: s framförande av tåget, fram till perioden före avgång. Om inget annat anges i avtalet mellan IM och RU, börjar perioden före avgång en timme före avgångstid enligt tidtabell.

Under perioden före avgång måste IM direkt underrätta RU om varje relevant ändring som införs i databasen över information om infrastrukturbegränsningar.

4.2.11.3   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 bilaga A index 2. De måste innehålla alla uppgifter som krävs för

—	identifiering av den rullande materielen,

—	bedömning av kompatibiliteten med infrastrukturen,

—	bedömning av relevanta lastningsegenskaper,

—	bromsegenskaper,

—	underhållsdata,

—	miljöegenskaper.

Referensdatabaserna för rullande materiel skall 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 tjänsteleverantörer (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 data 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. Följande punkter måste tas upp: — 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 skall 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.11.4   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 skall 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 avser ”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:

—	Järnvägsföretaget, 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 skall 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: et (vagnnumret).

Driftdata för den rullande materielen är en del av driftdatabasen för godsvagnar och intermodala enheter, som omfattar hela Europa. Den beskrivs i avsnitt 4.2.12.2 .

4.2.12   Olika referensfiler och databaser

4.2.12.1   Referensfiler

För driften av godståg på det europeiska järnvägsnätet skall följande referensfiler finnas tillgängliga och vara åtkomliga för alla tjänsteleverantörer (IM, RU, tillhandahållare av logistik och vagnparksförvaltare). Uppgifterna i referensfilerna skall vid varje tillfälle motsvara den faktiska statusen.

Lokalt lagrade och administrerade:

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

Centralt lagrade och administrerade:

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

—	Referensfil över koder för transportkunder.

—	Referensfil över koder för positioner (primära, sekundära och zone-track-spot).

—	Referensfil över koder för kunders positioner.

—	Referensfil över alla befintliga tågledningssystem.

—	Referensfil över farligt gods, UN- och RID-nummer.

—	Referensfil över alla olika typer av lok.

—	Referensfil över alla KN- och HS-nummer för gods.

—	Referensfil över alla underhållsverkstäder i Europa.

—	Referensfil över alla revisionsorgan i Europa.

—	Referensfil över alla operatörer med tillstånd, inklusive en förteckning över nationellt utfärdade säkerhetsintyg.

Kodningen för IM, RU, transportorganisationer och -företag och transportkunder, liksom för positioner (primära, sekundära…) inklusive kunders positioner är ännu inte klar.

4.2.12.2   Andra databaser

För att göra det möjligt att lokalisera tågs och vagnars rörelser skall 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 skall ha tillgång till relevanta data för fullgörandet av sina uppgifter, i enlighet med villkoren i avtalen.

—	Driftdatabas för godsvagnar och intermodala enheter.

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

Dessa databaser skall vara tillgängliga via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.14.7: 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 skall 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 skall 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 skall vara tillgänglig via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.14.7: 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 positioner 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 järnvägsföretag 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 infrastrukturförvaltare och övriga järnvägsföretag 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 infrastrukturförvaltare och järnvägsföretag 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åg innehåller vanligtvis vagnar från olika kunder. För varje vagn skall LRU (den RU som fungerar som samordnare för transporten) upprätta och uppdatera en färdplan som motsvarar tågläget på tågnivå. Nya tåglägen för ett tåg – 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 skall lagras av varje LRU i en databas. Dessa databaser skall vara tillgängliga via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.14.7: 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. Huvudposterna ä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: Begäran om tågläge). Dessa databaser skall vara tillgängliga via det gemensamma gränssnittet (4.2.14.1: Allmän arkitektur och 4.2.14.7: Gemensamt gränssnitt).).

4.2.12.3   Ytterligare krav på databaserna

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

Följande ytterligare krav skall 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 skall stödja principen ACID (Atomicity, Consistency, Isolation, Durability).

4.

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 skall stödjas ner till nivån för enskilda attribut till en registrerad uppgift. Databasen skall stödja konfigurerbar, rollbaserad accesskontroll för införande, uppdatering eller borttagning av registrerade data.

5.	Spårning En databas måste stödja loggning av alla åtgärder som vidtagits i databasen för att det skall 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 stödja den tillgänglighet som krävs.

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 skall 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, såsom SQL eller XQL.

13.	Importmöjligheter En databas skall 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 skall vara så utformad 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 införa, uppdatera eller ta bort registrerade data utan oacceptabla fördröjningar.

18.

Prestandaaspekter En databas skall stödja den mängd frågor som krävs för att cirka 60 000 tågfärder effektivt skall kunna genomföras per 24 timmar. Cirka 50 % av dessa tågfärder förmodas äga rum inom två timmar. Antalet och typen av frågor eller uppdateringar per tåg beror på den övergripande planeringsprocessen för framförandet av ett tåg.

19.

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

20.	Historiska data En databas skall 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 skall 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 skall finnas tillgängligt som hyllvara (COTS-produkt) eller vara fritt tillgängligt i public domain (Open Source).

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.14.1: Allmän arkitektur och 4.2.14.7: 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.13   Elektronisk överföring av dokument

I avsnitt 4.2.14 (Nätverk och kommunikation) beskrivs det kommunikationsnät som skall användas för datautväxling. Detta nät och den beskrivna säkerhetshanteringen möjliggör alla typer av överföringar, t.ex. e-post och filöverföring (ftp, http). Typen av överföring kan överenskommas mellan de parter som deltar i informationsutväxlingen, vilket betyder att man bestämmer att elektronisk överföring av t.ex. dokument skall ske via ftp.

4.2.14   Nätverk och kommunikation

4.2.14.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 skall 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,

—	säkrar redan gjorda IT-investeringar.

Arkitekturen för informationsutväxling 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 bilaga A index 5 avsnitt 1.5.

4.2.14.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 implementera en hybridartad peer-to-peer-modell över det publika Internet med en central datakatalog och ett gemensamt gränssnitt vid alla aktörers noder.

Först kontaktas den centrala datakatalogen för att få metainformation, såsom identiteten för den aktör där viss information finns lagrad, eller för att verifiera en aktörs identitet. Sedan genomförs en peer-to-peer-kommunikation mellan de berörda aktörerna.

4.2.14.3   Protokoll

Endast protokoll som hör till Internet Protocol Suite får användas.

4.2.14.4   Säkerhet

För att uppnå en hög säkerhetsnivå skall 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 att använda en metod för kryptering och signering liknande den som används för kryptering av e-post. Det gör det möjligt att använda alla typer av överföring i nätet, som e-post, filöverföring (ftp, http) etc. De parter som deltar i informationsutväxlingen kan sedan gemensamt besluta om vilken typ som skall användas.

4.2.14.5   Kryptering

Man skall 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.14.6   Den centrala datakatalogen

Den centrala datakatalogen skall kunna hantera

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

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

—	certifieringsinstans (CA),

—	adresskatalog (”adressbok”) – innehåller all information om de deltagande aktörerna som behövs för att utväxla meddelanden.

Förvaltningen av den centrala datakatalogen bör skötas av en icke-kommersiell sameuropeisk organisation.

4.2.14.7   Gemensamt gränssnitt

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

Det gemensamma gränssnittet skall 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 skall ha tillgång till de data som krävs enligt TSD inom varje RU, IM, etc., oavsett om de relevanta databaserna är centrala eller individuella (se även bilaga A index 5 avsnitt 1.6).

På grundval av resultaten av äkthetsverifieringen av inkommande meddelanden kan en miniminivå för meddelandekvittens implementeras:

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 de ovan nämnda uppgifterna.

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, med eventuella uppdateringar i databasen över 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 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 skall 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 skall 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 skall följande förfarande tillämpas:

När de specifikationer i TSD Drift och trafikledning som rör kraven i denna TSD skall 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.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, skall varje TSD-meddelandes avsändare vara ansvarig för att uppgiftsinnehållet i meddelandet är korrekt vid den tidpunkt då 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, skall 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, skall 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 aktualitet och kontinuitet när det gäller uppgifter och meddelanden.

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, som spelar en avgörande roll vid befordran av en försändelse, en vagn eller en container, 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, t.ex. med utgångspunkt från den fraktsedel som upprättas när en vagn eller försändelse överlämnas för transport, så att alla dessa data kan användas i all behandling längre fram.

Fullständighet:

Innan meddelanden sänds ut skall 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 skall 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 skall vara tydligt identifierad.

På vilket sätt dessa regler skall 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 utformat på ett bra sätt 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.

Generellt gäller att följande villkor skall vara uppfyllda:

Svarstiderna för förfrågningar får inte vara längre än 5 minuter. Alla uppdateringar och utväxlingar av data måste göras så snart som möjligt. Systemets reaktions- och överföringstid för uppdateringar skall vara mindre än 1 minut.

Mätning av uppgifternas kvalitet:

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, skall 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) skall ligga över 90 %. Det exakta värdet och kriterier skall 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.14.6 (Den centrala datakatalogen). I syfte att kvalitetssäkra uppgifterna, skall det organ som driver den centrala datakatalogen vara ansvarigt för uppdateringen av och kvaliteten på metadata och adresskatalogen, liksom för administrationen av accesskontrollen (öppna nycklar). När det gäller metadata måste en nivå på 100 % uppnås med avseende på fullständighet, samstämmighet, aktualitet och korrekthet.

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.12.3 (Ytterligare krav på databaserna), punkterna 10 och 21.

4.6   Yrkeskvalifikationer

För den personal som skall 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 skall denna inte endast bestå i att man visar personalen hur de skall 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å arbetsskicklighet upprätthålls, eftersom detta är en avgörande faktor för tillförlitligheten hos den information som skall 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 skall 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.

4.8   Registren över infrastruktur och rullande materiel

Enligt artikel 24.1 i direktiv 2001/16/EG skall medlemsstaterna ”se till att register över infrastrukturerna och rullande materiel offentliggörs och uppdateras varje år. Detta register skall, för varje delsystem eller del av delsystem som berörs, innehålla uppgifter om de viktigaste egenskaperna (till exempel grundparametrarna) och deras överensstämmelse med de egenskaper som föreskrivs i gällande TSD. I varje TSD skall därför noggrant anges vilka uppgifter som skall föras in i registren över infrastrukturerna och den rullande materielen.”

Eftersom dessa register uppdateras och offentliggörs en gång per år, är de inte användbara för delsystemet Telematikapplikationer för godstrafik. Därför skall enligt denna TSD inga uppgifter föras in i dessa register.

5.   DRIFTSKOMPATIBILITETSKOMPONENTER

5.1   Definition

Enligt artikel 2 d i direktiv 2001/16/EG

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 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”.

5.2   Förteckning över komponenter

Driftskompatibilitetskomponenterna behandlas i de tillämpliga bestämmelserna i direktiv 2001/16/EG.

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 skall grunda sig på europeiska specifikationer eller specifikationer som godkänts i enlighet med direktiv 2001/16/EG.

När det gäller komponenternas lämplighet, anges i dessa specifikationer alla de parametrar som skall 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 skall utföras av ett av tillverkaren eller dennes i gemenskapen etablerade ombud utvalt anmält organ, i enlighet med bestämmelserna i relevanta moduler i rådets beslut 93/465/EEG 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.2   Delsystemet Telematikapplikationer för godstrafik

På anmodan 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 2001/16/EG.

Enligt bilaga II till direktiv 2001/16/EG 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 adresskatalogen (adressboken) över alla deltagande aktörer i utväxlingen av meddelanden. Denna adresskatalog skall vid varje tillfälle motsvara den faktiska statusen. Felaktiga inmatningar uppdagas omedelbart. Inget bedömningsförfarande krävs.

—	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 bilaga A index 1) 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 är inriktad på tillhandahållandet av informationsstöd till affärsprocessen för godstrafik på järnväg, vilket kan leda till en betydande höjning av kvaliteten på transporttjänsterna. Tillämpningen av denna TSD i sig är oberoende av åtskillnaden mellan begreppen ny/ombyggd eller äldre infrastruktur eller rullande materiel, som annars kan vara avgörande i andra TSD som följer av direktiv 2001/16/EG.

Denna TSD är av övergripande natur och kommer att få djupgående effekter på affärs- och driftsprocesser inom hela den europeiska järnvägsindustrin. Dessutom gör den stadiga ökningen av internationella transporter att det behövs ett Europatäckande synsätt när det gäller informationshantering. Dessa faktorer tillsammans talar för att en samstämmig transeuropeisk genomförandeplan bör upprättas för denna TSD. Denna plan bör ge både en vision av vad som kommer att uppnås genom att denna TSD genomförs och en idé om hur och inom vilka tidsramar en övergång kan ske från den nuvarande situationen med ett fragmenterat nät av olika informationssystem till ett heltäckande system av informationsmotorvägar som omfattar hela Europa och som kan ge ett mervärde för alla intressenter inom järnvägstransporter – infrastrukturförvaltare, järnvägsföretag, speditörer och i slutändan även kunden.

Mot denna bakgrund har utarbetandet av en strategisk europeisk genomförandeplan (SEDP) påbjudits. I SEDP definieras det målsystem som skall uppnås för att denna TSD skall kunna genomföras, liksom en underbyggande spridningsplan för detta system, som beskrivs i följande avsnitt.

7.1.2   Strategisk europeisk genomförandeplan (SEDP)

7.1.2.1   Målen med SEDP

Syftet med den strategiska europeiska genomförandeplanen är trefaldigt:

1.	Att tillhandahålla en vision för genomförandet av TSD Telematikapplikationer för godstrafik (TSD-TAF) inom den europeiska järnvägsindustrin.

2.	Att berättiga en sådan vision ur ett tekniskt och ekonomiskt genomförbarhetsperspektiv.

3.	Att fastställa en åtgärdsplan för de åtgärder som anses nödvändiga för att realisera en sådan vision.

Förutom att föreslå en åtgärdsplan för genomförandet av TSD-TAF som synliggör hela genomförandeprocessen, bör SEDP tillhandahålla lämpliga måttstockar så att de olika intressenterna – dvs. infrastrukturförvaltare, järnvägsföretag, speditörer och i slutändan kunden – kan övervaka att processen fortskrider på ett sätt som gör att deras intressen tas tillvara på bästa sätt. Detta gäller särskilt för de nödvändiga investeringar som måste göras av infrastrukturförvaltare och järnvägsföretag för eventuell uppgradering och integrering av deras befintliga IT-system, och de TSD-TAF-baserade systemens förmåga att effektivt svara mot de ständigt ökande informationskraven från speditörernas och kundernas sida.

Mot denna bakgrund bör SEDP ytterst utgöra ett instrument som får hela den europeiska järnvägsindustrin att fokusera på ett gemensamt mål för informationssystemutvecklingen, samtidigt som det främjar synergieffekter, minskar fragmenteringen och koncentrerar de begränsade resurserna till de prioriterade åtgärder som bäst svarar mot det övergripande målet att förbättra kvaliteten på transporttjänsterna.

7.1.2.2   Krav enligt SEDP

Utarbetandet av en sådan plan kräver en systematisk analys av de relevanta tekniska, driftmässiga, ekonomiska och institutionella frågor som ligger till grund för genomförandet av TSD-TAF. Detta inbegriper särskilt följande:

1.	En inventering av de relevanta befintliga IT-applikationer som skulle kunna utgöra den grund på vilken man kan bygga upp ett Europatäckande system som uppfyller kraven i TSD-TAF (nedan kallat ”TAF-systemet”).

2.	Definition av de funktionskrav och tillhörande data- och prestandakrav som måste uppfyllas för genomförandet av TSD-TAF.

3.

Ett utkast till arkitektur för TAF-systemet. Utgångspunkten för detta skall vara en analys av de systemkonfigurationer som skulle ha potential att integrera befintliga IT-system på ett sätt som gör att kraven på funktionalitet och prestanda uppfylls – t.ex. centraliserade eller distribuerade klient-serverarkitekturer eller agentbaserade arkitekturer.

4.	Fastställande av tekniska krav och gränssnittskrav för TAF-systemet och dess potentiella under-/klientsystem.

5.

Utarbetande av en övergripande utvecklingsplan för TAF-systemet från koncept till färdigt resultat. En sådan plan bör innehålla riktlinjer för processen och planeringen av en potentiell integrering av befintliga system samt en riskbedömning med avseende på de kritiska faserna i planen. Vidare bör den ta hänsyn till pågående och planerad utveckling av befintliga system.

6.	Identifiering av lämpliga ledningsstrukturer för utvecklingen av TAF-systemet liksom för systemets drift under hela dess livstid.

7.	En bedömning av den totala livscykelkostnad (LCC) som är förenad med utvecklingen och driften av TAF-systemet och, utifrån detta, utarbetande av en investeringsplan.

Snarare än att genomföras steg för steg, bör denna analys växa fram genom en iterativ process i syfte att identifiera den optimala utvecklingsstrategin för systemet. En sådan cyklisk analys bör i slutändan leda fram till följande specifika resultat:

—	En fullständig uppsättning av funktionella, prestandarelaterade, systemrelaterade och tekniska specifikationer för upphandlingen av TAF-systemet.

—	Ett utvecklingsprogram från koncept till färdigt resultat. Detta skall inkludera detaljplanering av alla projektfaser och större enskilda åtgärder som tillsammans bidrar till att slutmålen uppnås.

—	En definition av de ledningsstrukturer, -metoder och -förfaranden (7) som skall ligga till grund för systemets utveckling, validering och drift.

—	En investeringsplan och tillhörande finansieringsstrategi för dess genomförande.

7.1.3   Metoder för genomförande

Metoderna för tillämpning av denna TSD omfattas av kraven i den strategiska europeiska genomförandeplanen (SEDP) som beskrivits ovan.

För utarbetandet av SEDP gäller följande krav:

—	Järnvägsföretag och infrastrukturförvaltare skall bidra genom att tillhandahålla funktionell och teknisk information om befintliga enskilda telematikapplikationer för godstrafik (8).

—

De organ som företräder järnvägssektorn på europeisk nivå, så som dessa definieras i artikel 3.2 i förordning (EG) nr 881/2004, skall fastställa den strategiska europeiska genomförandeplan som beskrivs i föregående avsnitt. De skall senast ett år efter att denna förordning offentliggjorts överlämna den strategiska planen till medlemsstaterna och kommissionen. Om inga avgörande framsteg gjorts efter den tiden, kommer uppgiften att tas över av Europeiska kommissionen som då får lägga fram förslag till lagstiftning för genomförandet av denna TSD.

—

När den strategiska planen har färdigställts, måste alla åtgärder som är kopplade till genomförandet av delsystemet Telematikapplikationer för godstrafik vara berättigade enligt denna genomförandeplan. Om en RU eller IM föreslår avsteg från planen, bör detta motiveras i den dokumentation om genomförandet som lämnas till medlemsstaten, Europeiska järnvägsbyrån och till EG.

7.2   Övergångsstrategi

Övergångsstrategier måste planeras för att hantera övergången från det nuvarande nätverket av olika informationssystem och uppfyllandet av denna TSD i enlighet med vad som föreskrivs i SEDP.

I detta syfte har de koncept för informationshantering som beskrivs i denna TSD utvecklats för att underlätta en sådan övergång. De tillåter en inkrementell utveckling mot målet som är det Europatäckande TSD-TAF-systemet, bland annat genom systemmöjligheter som peer-to-peer-kommunikation som grundar sig på t.ex. konceptet med gemensamma datakataloger (som inbegriper metadata för meddelanden, adresskatalog och certifieringsinstans).

Ett belysande exempel på hur en sådan informationsutväxling mellan RU och IM skulle kunna fungera i praktiken ges nedan. Exemplet visar bara de logiska beroendena för kommunikation mellan systemen enligt en stegvis struktur, utan hänsyn till eventuella utvecklingsbehov av de enskilda systemen i samband med övergången. De senare behoven bör noga beaktas i samband med utarbetandet av SEDP.

Steg 1: I den allmänna arkitekturen, som beskrivs i avsnitt 4.2.14.1 (Allmän arkitektur), ingår konceptet med en ”central datakatalog” som drivs av ett neutralt och oberoende organ. För driftskompatibilitet specificeras ett gränssnittslager, som kan innehålla en meddelandehanterare, som skall finnas på plats hos varje deltagare i kommunikationsnätet och som kan byggas upp centralt eller individuellt. Dessa delar är med avseende på ”nätverk och kommunikation” de enda driftsaspekterna som krävs för driftskompatibilitet. De utgör också de grundläggande förutsättningarna för den Europatäckande datautväxlingen. Därför måste de förverkligas och installeras innan någon annan funktion kan tas i drift.

Efter detta steg kan elektronisk överföring av dokument (avsnitt 4.2.13: Elektronisk överföring av dokument)ske, oberoende av den logiska följden av övriga steg.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Grunden för informationsutväxlingen är lagd. Fördel:   Elektronisk överföring av dokument kan göras i den slutliga miljön.   Tester av de olika kommande stegen kan utföras i verklig miljö.

Steg 2: Samtidigt eller kort efter steg 1, måste referensdatabaserna för rullande materiel och driftdatabasen för godsvagnar och intermodala enheter (avsnitt 4.2.11.3: Referensdatabaserna för rullande materiel och avsnitt 4.2.12.2: Andra databaser) göras tillgängliga. Om inte alla uppgifter redan finns i databaserna, måste det åtminstone gå att i driftdatabasen för godsvagnar och intermodala enheter – för varje vagn i ett tåg i trafik – manuellt föra in de uppgifter som krävs för järnvägstransport enligt förteckningen i bilaga A index 2).

Tillgängliga egenskaper efter detta steg, för
IM	RU
Den grundläggande informationen i driftdatabasen för godsvagnar och intermodala enheter och referensdatabaserna för rullande materiel är tillgänglig. Manuell uppdatering av relevanta uppgifter är möjlig. Fördel:   IT-stöd för begäran om tågläge och för tågets sammansättning finns.   Enkel tillgång till uppgifter om rullande materiel för tredje part, t.ex. vagnparksförvaltare, kan skapas.

Steg 3: För extern tillgång till de olika databaserna måste det gemensamma gränssnittet förverkligas och införas parallellt med eller strax efter steg 2.

Tillgängliga egenskaper efter detta steg, för
IM	RU
En databas för lagring av tågläges/tåginformation är iordningställd. Införandet av uppgifter kan göras manuellt till en början. Online-anslutning till befintliga IM-system för automatisk inmatning och uppdatering är möjlig. Fördel:   Uppgifter i inkommande meddelanden kan lagras vad beträffar den slutliga versionen.	Databasen/databaserna över vagnars och intermodala enheters rörelser och last (vikt, farligt gods) är färdigställda, tillsammans med nödvändiga referensfiler. Från och med nu kan relevanta uppgifter från lämnade fraktsedlar (vagnorder) och/eller den befintliga tågsammansättningen matas in manuellt, eller redan automatiskt via RU: s interna anslutning till befintliga system för registrering av fraktsedlar och för registrering av tågsammansättning. Kontroll av vagndata mot referensdatabasen för rullande materiel är möjlig, liksom bedömning av tågdata i förhållande till infrastrukturdata. Fördel:   Stöd för upprättande av tågets sammansättning.   Uppgifter i inkommande meddelanden kan lagras vad beträffar den slutliga versionen.

Inför de nästkommande stegen är det viktigt att nämna att den föreslagna arkitekturen gör att man på ett smidigt sätt kan ta i bruk de olika funktioner som skall uppfylla kraven för delsystemet Telematikapplikationer för godstrafik. Med utgångspunkt från den centrala datakatalogen (metadata för meddelanden, adresskatalog och certifieringsinstans) kan man möjliggöra utväxling av data mellan två parter med avseende på enskilda meddelandetyper.

Steg 4: Meddelandena för begäran om tågläge kan införas oberoende av kommande steg, men för steg 6 krävs att tågläget redan benämnts med en tåglägesidentitet.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Automatisk inmatning av uppgifter i databasen för lagring av tågläges/tåginformation. Telematikstöd för fastställande av tågläge i kombination med databaserna över information om infrastrukturbegränsningar. Fördel:   Snabbare svar på ansökningar om tågläge, bättre efterfrågestyrd användning av tåglägen, högre tillförlitlighet i uppgifterna om tåglägets egenskaper (aktuell status i databaserna över information om infrastrukturbegränsningar), förbättrad användning av infrastrukturen.	Begäran om tågläge med kort varsel är möjlig. Fördel:   Mer efterfrågestyrda ansökningar om tåglägen kan göras. Snabbare svar från IM på ansökningar om tågläge, högre tillförlitlighet i uppgifterna om tåglägets egenskaper. Snabbare vändningstider för vagnar.

Steg 5: Uppgifterna i vagnorderna ger grundläggande information för ett tågs sammansättning. Därför bör dessa meddelanden tas i drift före steg 6.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Inga tillkommande egenskaper.	Automatiskt överföring av uppgifterna på fraktsedeln till datalagringen i steg 3. Automatisk generering och sändning av vagnorder till samarbetande RU. Fördel:   Snabbare distribution av vagnorderna, kortare hanteringstider vid utväxlingspunkter.   Stöd för tillämpning av internationella handelsavtal.

Steg 6: Idrifttagandet av utväxlingen av meddelanden om iordningställande av tåg är nästa steg, varvid sändningen av meddelandet om tågets sammansättning är viktigast och bör införas först.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Uppgifter om tåget sammansättning erhålls i förväg. Högre tillförlitlighet i uppgifterna. Tydlig tidsstämpel för starttiden för användningen av tågläget. Automatisk uppdatering av databasen för lagring av tågläges/tåginformation. Fördel:   Optimerad användning av tåglägen, tydlig ansvarighet vid starttiden.	Sändning av till stora delar automatiskt genererad tågsammansättning, hög tillförlitlighet i uppgifterna, automatisk uppdatering av datalagringen i steg 3. Fördel:   Tydlig ansvarighet vid starttiden för IM: s tjänst, tillförlitlig starttid för vagnarna/försändelserna.   Stöd för minimering av utgifter och kostnader genom minskade behov av att föra in uppgifter vid korsande av nationsgränserna.   Stöd för att förkorta frakttiderna genom garantier för övertagande av tåg av RU och IM.   Stöd för minimering av risker i samband med övertagande av vagnar.

Steg 7: Senast före steg 8 bör funktionerna för vagnrörelser ”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 vagns ankomst och Meddelande om leverans av vagn/Bekräftelse av leverans av vagn” tillsammans med funktionen för färdplanering införas på RU-nivå.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Inga tillkommande egenskaper.	IT-stödd färdplanering på nivån för vagnar och intermodala enheter är möjlig. Systemet är förberett för beräkning, sändning och mottagning av meddelanden rörande vagnars och intermodala enheters rörelser. Fördel:   Första steg mot lokalisering och spårning av vagnar och försändelser på internationell nivå.

Steg 8: I nästa steg bör meddelandena Tågföringsinformation och Tågföringsprognos införas. Med meddelandet om tågföringsprognos kan den beräknade tiden för tågets ankomst (TETA respektive ETH) sändas, vilket ligger till grund för beräkningen av vagnarnas/försändelsernas ETI och ETA. I detta steg ingår också införandet av förfrågan/svar angående tågföring och tågföringsprognos.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Tågföringsinformation och Tågföringsprognos sänds i realtid till angränsande IM och till berörda RU. Fördel:   Utökade och mer tillförlitliga planeringsmöjligheter, vilket stöder effektiv användning av tåglägen.   Minskar stopp vid gränser, stöder efterfrågestyrd användning av tåglägen.	Uppgifter tillgängliga om tågs beräknade ankomsttider till angivna positioner, som grund för beräkning av vagnars/försändelsers ETI/ETA. Fördel:   Ett verktyg för att möta kundens önskemål om att bli informerad om problem uppstår under transporten.   Tillsammans med färdigställandet av steg 4 stöd för minimering av utgifter och kostnader genom efterfrågestyrd användning av tåglägen.   Utökade och mer tillförlitliga planeringsmöjligheter.   Stöd för att förkorta frakttiderna genom minskade stopp vid gränserna.   Stöd för minimering av risker i samband med övertagande av tåg.

Steg 9: Rapporteringen om utväxling (avsnitt 4.2.9: Rapportering om utväxling) och funktionerna i avsnitt 4.2.7 (ETI/ETA för en försändelse) bör införas samtidigt med eller strax efter steg 8. Detta är särskilt relevant för RU.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Möjlighet att veta position för en vagn inom IM: s infrastruktur och vilken RU som är ansvarig, även om vagnen inte ingår i ett tåg. Fördel:   Att ha kontroll över vagnars positioner och ansvariga enheter på en bangård.	Beräkning av ETI och ETA baserat på TETA-värden, automatisk uppdatering av rörelsedata i driftdatabasen för godsvagnar och intermodala enheter. Internationell hantering av tomma vagnar helt genomförd. Internationell färdplanering genomförd. Fördel:   Lokalisering och spårning av försändelser på internationell nivå.   Snabbare vändningstider för vagnar.   Stöd för internationell hantering av tomma vagnar.   Stöd för försändelser utomlands och bokning av sådana.   Stöd för förbättringar av kvaliteten på internationella transporter.   Stöd för internationell färdplanering.

Steg 10: Införandet av funktionen för ”information om trafikstörning” är en del av steg 10 tillsammans med införandet av funktionen för förfrågan/svar om tågs fördröjning, tågidentitet och tåg vid rapporteringsposition. Med utgångspunkt från informationen om trafikstörning, kan funktionen för meddelande om vagnsavvikelse på RU-nivå (avsnitt 4.2.8.6: Meddelande om vagnsavvikelse och avsnitt 4.2.8.7: Förfrågan om ny ETI/ETA till följd av Meddelande om vagnsavvikelse) tas i bruk.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Hantering av trafikstörning och rapporter till RU om utestående leveranser. Fördel:   Förbättrad kvalitet på tjänsten.	Hantering av avvikelser och utestående förfrågningar. Fördel:   Internationell lokalisering och spårning av försändelser.   Snabbare vändningstider för vagnar.

Steg 11: Efter en konsolideringsfas kan en funktion införas för utvärdering av överförda och lagrade data i syfte att åstadkomma kvalitetsförbättringar.

Tillgängliga egenskaper efter detta steg, för
IM	RU
Tillgång till en fullständig statistisk databas. Fördel:   Tillgång till ett underlag för förbättring av kvaliteten på transporttjänsterna.

7.3   Förändringshantering

7.3.1   Inledning

Löpande förändring är en inneboende aspekt i alla typer av datorbaserade system som används i verkliga miljöer. Systemförändringar drivs på av att nya krav växer fram eller att befintliga krav förändras antingen på grund av att funktionsfel rapporteras eller för att man vill förbättra prestanda eller andra icke-funktionella egenskaper.

Men förändringarna måste hanteras med hänsyn till krav på kontinuitet i tjänsterna och kompatibilitet bakåt, så att omkostnaderna i tid och pengar blir så små som möjligt för att driva redan befintliga IT-system som utvecklats för att tillhandahålla TAF-funktionalitet (dvs. ärvda system). Det är därför viktigt att definiera en tydlig strategi för hur förändringar av ärvda IT-system skall genomföras och hanteras för att undvika störningar i järnvägsdriften, utan att underminera det underliggande målen att garantera kontinuitet i tjänsterna och driftskompatibilitet. Två viktiga frågor bör ligga till grund för definitionen av en sådan strategi:

—

Fastställandet av ett ramverk för konfigurationsstyrning, som definierar standarder och förfaranden för att hantera systemutvecklingen. Detta bör inbegripa hur föreslagna systemförändringar registreras och behandlas, hur dessa förändringar relateras till systemkomponenter och hur man håller reda på systemversioner.

—	En policy för att distribuera grundstrukturer för systemen.

7.3.2   Ta fram grundstrukturer

Systemstabilitet är en mycket viktig faktor för att det skall vara realistiskt att införa och utveckla funktionerna i praktiken. Detta behov av stabilitet är detsamma för alla parter:

—	Infrastukturförvaltare och järnvägsoperatörer som kommer att behöva hantera olika versioner av system som tillhandahåller TAF-funktionalitet.

—	Industrin som behöver tid för att specificera, utveckla och testa fortsatt driftskompatibilitet.

En grundstruktur är i princip ett uttryck för en stabil grundstomme i fråga om systemfunktionalitet, prestanda och andra icke-funktionella egenskaper (t.ex. RAM) (9). Emellertid har tidigare erfarenheter med denna typ av system visat att det krävs ett antal versionsreleaser (10) för att uppnå en stabil grundstruktur som är lämplig att genomföra. Detta kan illustreras som en stegvis process enligt följande:

Med alla återkopplingar är detta i hög grad en sammanflätad process. På detta sätt undviker man att flera liknande processer genomförs parallellt, vilket skulle leda till situationer med instabilitet, förvirring och hinder för driften. Grundstrukturerna måste sedan behandlas i serie snarare än parallellt så som illustreras nedan:

7.3.3   Grundstrukturreleaser

Baserat på de erfarenheter som finns i dagsläget kan lämplig tid mellan releaser av olika grundstrukturer vara fyra till fem år.

En ny grundstruktur bör i princip höra samman med avgörande förändringar av systemets funktionalitet eller prestanda. Detta kan innefatta aspekter som

—	införlivandet av uppsättningar av i dagsläget nationella funktioner, i de fall dessa kan göras allmänna inom den driftskompatibla grundstommen,

—	andra framtida mervärdestjänster.

Varje grundstruktur bör också innefatta funktionaliteten i den föregående grundstrukturen. Avbuggningsversioner som åtgärdar systemfel eller säkerhetsbrister bör ses som versionsreleaser av en viss grundstruktur. Om detta inte hindras av säkerhetsskäl, skall sådana versionsreleaser vara kompatibla bakåt.

Den tillkommande funktionalitet som kan ingå i olika grundstrukturer medför ovillkorligen att olika grundstrukturer inte är kompatibla bakåt. Emellertid bör de olika grundstrukturerna, för att underlätta övergången och i den mån det är möjligt ur teknisk synpunkt, omfatta en gemensam kärna av funktionalitet för vilken kompatibilitet bakåt garanteras. En sådan gemensam kärna bör ge en minsta grundstomme som tillåter driftskompatibla datatjänster med acceptabla prestanda.

7.3.4   Utveckling av nya grundstrukturer

Infrastrukturförvaltare och järnvägsoperatörer kommer aldrig att kunna övergå från en grundstruktur till nästa över en natt. Därför måste varje grundstruktur utvecklas hand i hand med en lämplig övergångsstrategi. Detta är för att möta problem som samexistens av TAF-system som överensstämmer med olika versioner av TAF-specifikationerna, föredragen väg för övergången (dvs. prioritering av spåren, prioritering av den rullande materielen, eller båda samtidigt) liksom vägledande tidsramar och prioriteringar för övergången.

7.3.5   Förändringshanteringsprocessen – krav som ställs

Så som nämnts tidigare är förändring en livsbetingelse för större mjukvarubaserade system. Förfaranden för förändringshantering bör utformas för att se till att de kostnader och den nytta som är förenad med förändringarna analyseras noggrant och att förändringarna genomförs på ett kontrollerat sätt. Detta gör att den definierade förändringshanteringsprocessen och tillhörande verktyg måste garantera att förändringarna registreras och tillämpas på specifikationerna på ett kostnadseffektivt sätt. Vilka de specifika detaljerna i en sådan process än kommer att vara, bör den i stort kunna åskådliggöras på ett strukturerat sätt enligt följande:

En plan för konfigurationsstyrning som innefattar standarder och förfaranden för förändringshantering bör underbygga hela den förändringshanteringsprocess som beskrivs ovan. De allmänna kraven på en sådan plan beskrivs i avsnitt 7.3.6. Genomförandestrategin för de godkända förändringarna bör formaliseras (baserat på tillbörlig bearbetning och tillbörlig dokumentation) till en förändringshanteringsplan som bland annat innefattar

—	identifiering av de tekniska begränsningar som ligger till grund för förändringen,

—	en redogörelse för vem som tar ansvar för förfarandena för genomförande av förändringen,

—	ett förfarande för validering av de förändringar som skall genomföras,

—	en policy för förändringshantering, utgåva, övergång och spridning.

En viktig del av förändringshanteringsprocessen är definitionen av ansvar när det gäller framtagningen av specifikationerna liksom kvalitetssäkring och konfigurationsstyrning. Enligt planerna kommer utförandet av eller övervakningen av de flesta av dessa uppgifter att tillfalla Europeiska järnvägsbyrån (inrättad genom förordning (EG) nr 881/2004) när denna har inlett sitt arbete. Förändringshanteringsprocessen bör formaliseras inom ramen för den uppsättning av dokumentation som hänvisas till i bilaga A.

Slutligen är det viktigt att förändringskontrollgruppen (Change Control Board, CCB), som eventuellt kommer att fungera som övergripande systemansvarig, är sammansatt av ett representativt tvärsnitt från alla berörda parter – dvs. infrastrukturförvaltare, järnvägsföretag, järnvägsindustrin, anmälda organ och tillsynsmyndigheter. Ett sådant deltagande från parternas sida bör garantera ett systemperspektiv på de förändringar som behöver göras och en övergripande bedömning av ändringarnas effekter. CCB kommer i sista hand att stå under Europeiska järnvägsbyråns kontroll.

7.3.6   Plan för konfigurationsstyrning – krav

Planen för konfigurationsstyrning bör beskriva uppsättningen standarder och förfaranden för förändringshantering och bland annat innehålla

—	en definition av vilka enheter som skall hanteras och ett formellt system för att identifiera dessa enheter,

—	en redogörelse för vem som tar ansvar för förfarandena för konfigurationsstyrning liksom för att överlämna kontrollerade enheter till beslutsstrukturen för konfigurationsstyrningen,

—	den policy för konfigurationsstyrning som skall användas för kontroll av förändringar och hantering av versioner,

—	en beskrivning av den dokumentation av konfigurationsstyrningsprocessen som skall upprätthållas,

—	en beskrivning av de verktyg som skall användas för konfigurationsstyrning och de förfaranden som skall tillämpas när dessa verktyg används,

—	en definition av den konfigurationsdatabas som skall användas för att registrera konfigurationsinformation.

De särskilda detaljerna rörande konfigurationsstyrningsprocesserna skall formaliseras genom specifikationer som skall införlivas med listan över specifikationer i bilaga A till denna TSD.

7.4   Specialfall

7.4.1   Inledning

Följande särskilda bestämmelser gäller i nedanstående specialfall.

Specialfallen kan delas in i två kategorier: bestämmelserna tillämpas antingen permanent (”P”-fall), eller temporärt (”T”-fall). När det gäller temporära fall rekommenderas att de berörda medlemsstaterna bör uppfylla kraven för delsystemet i fråga antingen år 2010 (”T1”-fall), ett mål som fastställs i Europaparlamentets och rådets beslut nr 1692/96/EG av den 23 juli 1996 om gemenskapens riktlinjer för utbyggnad av det transeuropeiska transportnätet (11)1, eller år 2020 (”T2”-fall). ”T open” definieras som en obestämd period som kommer att fastställas i en senare omarbetning av denna TSD.

7.4.2   Förteckning över specialfall

7.4.2.1   Specialfall för EU-medlemsstater som gränsar till tredje land

För EU-medlemsstater som gränsar till tredje land gäller att på deras territorier är kraven i denna TSD inte obligatoriska för transporter som kommer direkt från eller går direkt till dessa tredjeländer (”T open”-fall).

Men om transporten utsträcks till en annan medlemsstat, skall kraven i denna TSD tillämpas fullt ut, förutsatt att det inte finns någon bilateral eller multilateral överenskommelse mellan de berörda staterna eller mellan de RU eller IM som är verksamma på dessa medlemsstaters territorier.

7.4.2.2   Specialfall för Grekland

På en transport som drivs på linjer med 1 000 mm spårvidd, skall nationella bestämmelser tillämpas.

---

(1)  EGT L 75, 15.3.2001, s. 29. Direktivet senast ändrat genom direktiv 2004/49/EG (EUT L 164, 30.4.2004, s. 44. Rättat i EUT L 220, 21.6.2004, s. 16).

(2)  EGT L 220, 30.8.1993, s. 23.

(3)  EGT L 75, 15.3.2001, s. 26.

(4)  EGT L 237, 24.8.1991, s. 25. Direktivet senast ändrat genom Europaparlamentets och rådets direktiv 2004/51/EG (EUT L 164, 30.4.2004, s. 164. Rättat i EUT L 220, 21.6.2004, s. 58).

(5)  Med utgångspunkt avses tåglägets utgångspunkt, vilket kan vara tågets avgångspunkt för färden eller en utväxlingspunkt. Överlämningspunkten är destinationen för tågläget.

(6)  Det betyder att tillgången till denna information skall vara oavhängig av vilken IM som lagrat informationen eller delar av den.

(7)  Till exempel kvalitetssäkringsstandarder, metoder för systemutveckling, testmetoder, dokumentationsplanering.

(8)  Med befintliga telematikapplikationer för godstrafik avses telematikapplikationer för godstrafik som redan är i bruk innan denna TSD träder i kraft.

(9)  En grundstruktur fungerar som en referens, som utgångspunkt för en kontrollerad hantering av systemutvecklingen.

(10)  En versionsrelease är en version av systemet som distribueras till järnvägskunder. Versioner av systemet kan ha olika funktionalitet, prestanda eller kan åtgärda systemfel eller brister i fråga om tillförlitlighet eller säkerhet.

(11)  EGT L 228, 9.9.1996, s. 1. Beslutet senast ändrat genom beslut 884/2004/EG (EUT L 167, 30.4.2004, s. 1. Rättat i EUT L 201, 7.6.2004, s. 1).