Utvecklingsspecifikation av simulatorprototyp, steg 1

Utvecklingsspecifikation av simulatorprototyp, steg 1 En rapport från TOPSim och CATD-projekten Ett forskningsprojekt i samverkan mellan MDI, inst. för informationsteknologi, Uppsala universitet Högskolan Dalarna ÅF-Industriteknik AB Banverket Rapportnamn Utvecklingsspecifikation av simulatorprototyp, steg 1 Rapportnummer T2 Revisionsdatum 2001-11-15 Status Slutrapport

T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 1

Förord Denna rapport är en delrapport inom projekten: CATD TOPSim Framtida tågtrafikstyrning. Beslutsstöd och användargränssnitt Banverkets FoU, dnr S00-3165/08 Simulering inom planering, utbildning och drift Banverkets FoU, dnr S00-3164/08 För ytterligare information om projekten hänvisas till projektplanerna samt till information på adressen http://www.hci.uu.se/projects/ Projektrapporterna tas fram med olika status: arbetsmaterial, remissversion resp. slutrapport. Denna rapport, T2. Utvecklingsspecifikation av simulatorprototyp, steg 1, beskriver specifikationen av utvecklingen av TOPSim/TTS, dvs trafiksimulatorn och dess olika delar, under denna fas av projektet. Rapporten har framställts av Joakim Storck, ÅF/Industriteknik. I CATD och TOPSim-projekten deltar följande personer MDI, Uppsala universitet Bengt Sandblad, projektledare Arne W Andersson Högskolan Dalarna Thomas Kvist ÅF-Industriteknik AB Per Lindström Joakim Storck Karl-Einar Jonsson Banverket projektering Peter Hellström Banverket Jan Byström (kontaktperson CATD) Magnus Wahlborg (kontaktperson TOPSim) T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 2

T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 En rapport från CATD och TOPSim-projekten T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 3

Innehållsförteckning FÖRUTSÄTTNINGAR... 5 KRAV EFTER KATEGORI... 6 FUNKTIONELLA KRAV... 7 ARBETSPLAN... 9 BILAGA 1 - IMPLEMENTATIONSFÖRSLAG... 10 KRAV 1. MANUELL STYRNING... 10 KRAV 2. SYNTAX... 10 KRAV 3A. ANSVAR FÖR ANSLUTNING... 10 KRAV 3B. DATADISTRIBUTION... 10 KRAV 4. STATIONSPASSAGE... 10 KRAV 5. SIMULERINGSHASTIGHET... 11 KRAV 6A. LEVERANS AV ORDER... 11 KRAV 6B. KVITTENS... 11 KRAV 6C. TILLFÄLLIG MAGASINERING... 11 KRAV 7. ÅTERTA BEGÄRD TÅGVÄG... 12 KRAV 8. BLOCKBETECKNINGAR... 12 KRAV 9. FELMEDDELANDE... 13 KRAV 10. TEKNISK PLATTFORM... 13 KRAV 11. KONTINUERLIG TÅGRÖRELSE... 13 KRAV 12. BATCHKÖRNING... 14 KRAV 13. LOGGNING... 14 KRAV 14. HJÄLPFUNKTION... 14 KRAV 15. TIDTABELLSINFORMATION... 15 KRAV 16. DELA SIMULERING... 15 KRAV 17. AUTOMATISKT STYRDA GRENAR... 16 KRAV 18A. FÖRBEREDANDE ORDER... 16 KRAV 18B. VISUALISERING AV FÖRBEREDANDE ORDER... 17 KRAV 19. ÅTERTA FÖRBEREDANDE ORDER... 18 T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 4

Förutsättningar Som ett resultat av det hittilsvarande arbetet i TOPSim- och CATD-projekten har en kravspecifikation för denna projektfas tagits fram 1. Denna är i skrivande stund ännu preliminär. Syftet med den här utvecklingsplanen är att komplettera kravspecifikationen genom att: ta fram förslag till hur de krav som ställs ska implementeras. disponera tiden för det kommande utvecklingsarbetet. Kravspecifikationen kategoriserar de ställda kraven som absolutkrav, skallkrav och börkrav. Den prioriteringen behålls här, dock omformulerat som prioritet 1 till 3 i samma ordning. Kraven har också bedömts efter komplexitetsgrad på en skala där 1 är lägst komplexitet och 5 högst komplexitet. Risken för förseningar på grund av oförutsedda svårigheter växer med ökande komplexitet. 1 Se Rapport C3 "Kravspecifikation TOPSim, steg 1" T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 5

Krav efter kategori Allmänt 10. Teknisk plattform 14. Hjälpfunktion Klient-server 3a. Ansvar för anslutning 3b. Datadistribution Kommandogivning 1. Manuell styrning 2. Syntax 6a. Leverans av order 7. Återta begärd tågväg 13. Loggning 16. Dela simulering 17. Automatiskt styrda grenar 18a. Förberedande order 19. Återta förberedande order Presentatör 6b. Kvittens 6c. Tillfällig magasinering 8. Blockbeteckningar 9. Felmeddelande 15. Tidtabellsinformation 18b. Visualisering av förberedande order Rapportering 4. Stationspassage 11. Kontinuerlig tågrörelse Simulering 5. Simuleringshastighet 12. Batchkörning T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 6

Funktionella krav Nr Namn Kategori Krav Tidsåtgång [timmar] Prio Komplx Klart 1. Manuell styrning Kommandogivning Vid interaktiv styrning ska det bara vara den mänsklige tågledaren som styr. 8 1 1 JSK TTS får inte påverka styrningen på något sätt. 2. Syntax Kommandogivning Kommandosyntaxen ska i största möjliga utsträckning baseras på vad som gäller i dagens manöversystem. - 1 - JSK 3a. Ansvar för anslutning Klient-server Klienten ansvarar för att upprätta förbindelse med serversidan och eventuella andra moduler på det egna systemet. - 1 JSK 3b. Datadistribution Klient-server Klienten förser i samband med simuleringen samtliga aktörer med data genom - 1 2 JSK att bl a distribuera indatafilen över nätverket. Överföring av filer sker automatiskt. Det är av stor vikt att användaren inte upplever detta som besvärligt. 4. Stationspassage Rapportering TTS skall så snart ett tåg ankommer till, avgår från eller i flykt passerar en 8 1 1 station förmedla information om detta till DSS-modulen Desirée. 5. Simuleringshastighet Simulering Det skall vara möjligt att låta simuleringsförloppet gå i den takt som önskas, - 1 1 JSK varvid de grafiska representationerna uppdateras vid i simuleringen aktuella tidpunkterna för de olika händelserna. 6a. Leverans av order Kommandogivning Om ett trafikledningskommando är avsett att verkställas omedelbart så sänds - 1 - JSK det direkt till TTS. TTS försöker verkställa inkommande order så snart som möjligt. 6b. Kvittens Presentatör Kvittens på om en reservation eller annullering lyckas kommer via de 30 1 3 presentatörsmeddelanden som TTS genererar. Lagda och reserverade vägar visas i grönt respektive rött i Presentatören. Presentatören ska visa ett felmeddelande om ett givet trh-kommando misslyckas. 6c. Tillfällig Presentatör En tänkbar utvidgning av detta (6b) är att en begärd tågväg (eller en del av den) 30 1 2 magasinering visas med gul färg till dess att den har reserverats, dvs så länge som den är "tillfälligt magasinerad". 7. Återta begärd tågväg Kommandogivning Tågledaren skall kunna återta en begärd tågväg. Kommandot C:> utl g1d2v00 g1c2v00 80 1 4 ska resultera i att lagda enkla tågvägarn mellan de två signalerna tas bort från de aktuella interna tågvägslistorna och avmarkeras i presentationsfönstret. 8. Blockbeteckningar Presentatör Presentatören uppgraderas så att den på bilden av spårplanen även visar 30 1 JSK T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 7

blockbeteckningarna" på ett för användarna användbart sätt. 9. Felmeddelande Presentatör I presentatören skall visas ett felmeddelande om ett givet trafikledningskommando ej accepteras. 10. Teknisk plattform Allmänt För TopSim-systemet gäller att simulatorkärnan TTS körs på en UNIX-maskin 11. Kontinuerlig tågrörelse Rapportering och övriga delar körs från en Windows-NT-maskin. TTS skall till anslutna delsystem kunna svara för en kontinuerlig uppdatering av tåginformation (position hastighet etc.). Kontinuerlig uppdatering kan åstadkommas genom att tågen beordras att rapportera var de befinner sig med ett visst tidsintervall, exempelvis varje 10:e sekund simulerad tid. Rapporteringshändelser placeras i händelsekön och skickas som meddelanden med önskat tidsintervall medan simuleringen i övrigt förflyter på normalt sätt. 10 1 1-2 - JSK 20 2 2 12. Batchkörning Simulering Man ska kunna genomföra en kombinerad "batch"- och "styr"-simulering. 20 2 2 13. Loggning Kommandogivning En lättillgänglig loggning av givna TRH-kommandon skall finnas. 8 2 1 14. Hjälpfunktion Allmänt En fungerande hjälpfunktion skall finnas tillgänglig i systemet. 80 2 2 15. Tidtabellsinformation Presentatör Det skall vara möjligt att se en lista över tågnr och stationer på skärmen. Speciellt tågens utgångsstation. 16. Dela simulering Kommandogivning Flera Klienter skall ha möjlighet att ansluta till samma simulering. I Simson är detta förberett genom att operatören kan välja vilken gren han skall övervaka. 17. Automatiskt styrda Kommandogivning Det skall vara möjligt att manuellt styra en gren, medan övriga grenar styrs av grenar Simon-trafikledaren. 18a. Förberedande order Kommandogivning Trafikledningskommandon kan också sändas som förberedande order till Presentatören. Dessa blir inte tillgängliga för simulatorn förrän de fastställs av operatören. 18b. Visualisering av förberedande order 19. Återta förberedande order Tabell 1 Funktionella krav Presentatör Kommandogivning Dessa (förberedande order) skiljer sig också visuellt i presentationsfönstret från lagda och reserverade vägar, exempelvis genom att ritas upp med gul färg. Tågledaren skall kunna återta en "förberedd" tågväg. T ex skulle kommandot afv g1d2v00 g1c2v00 resultera i att den tågväg som är planerad mellan de två blocken togs bort från listan med förberedda order och avmarkerades i presentatören. 80 3 - - 100 3 5 10 3 1 JSK 80 3 4 40 3 4 40 3 3 T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 8

Arbetsplan November-december 2001 Under perioden November-December 2001 föreslås att utvecklingsarbetet inriktas på : 1. Krav 7: Återta begärd tågväg med utl-kommandot 2. Krav 11: Kontinuerlig tågrörelse 3. Krav 4: Meddelande vid stationspassage 4. Krav 9: Felmeddelande vid ogiltiga kommandon 5. Krav 6c: Visualisering, tillfällig magasinering Beräknad tidsåtgång för arbetet är 138 timmar. T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 9

Bilaga 1 - Implementationsförslag I detta avsnitt innehåller en genomgång där kraven kommenteras punkt för punkt. Varje avsnitt innehåller en kortfattad analys av problemet och ett förslag till implementation. Krav 1. Manuell styrning Förbigå TTS trafikledning om tåget befinner sig på en manuell gren, så att bara den mänsklige tågledaren styr. Arbetsmoment: Förse grenklassen med flagga som indikerar manuell styrning av gren. Förbigå automatiska trafikledningen om tåget befinner sig på en gren som ska styras manuellt. Möjliggöra att ange manuell styrning av grenar via användargränssnittet. Komplexitet: 2 Tidsåtgång: 8 timmar Krav 2. Syntax Kommandosyntaxen ska i största möjliga utsträckning baseras på vad som gäller i dagens manöversystem. En syntax för kommandogivningen formulerades som en del av kravspecen i TOPSim fas 1, se Tabell 2. Delar av denna har implementerats under fas 1 och 2. Vidare utveckling sker nu under projektfas 3, bland annat för att för ge användaren möjlighet att lösa ut vägar. Funktion Kommando Krav Begära ny tågväg trh a b Se TOPSim fas 1-2 Förberedd begäran av tågväg trh -prep a b 19 Lösa ut tågväg utl a b 7 Aktivera förberedd begäran av tågväg trp x 19 Återta förberedd tågväg afv a b 20 Tabell 2 Kommandosyntax Bedömning av komplexitet och tidsåtgång för moment som är planerade att implementeras under fas 3 finns under respektive avsnitt. Krav 3a. Ansvar för anslutning Klienten ansvarar för att uppkopplingen mot servern sker utan besvär för användaren. Krav 3b. Datadistribution Distribution av datafiler hanteras automatiskt av systemet. Filöverföring hanteras av systemet utan att användaren behöver gripa in. Krav 4. Stationspassage Ankomst till respektive avgång från station loggas sedan tidigare i resultatfiler. Som komplement införs nya presentatörsmeddelanden som t ex kan användas av planeringsprogram. Nya meddelanden införs: Ankomst > 45 %s 1 %s 2 %ld 3 %hd 4 Avgång > 46 %s 1 %s 2 %ld 3 %hd 4 1 Tågnummer 2 Stationssignatur 3 Tid [s] 4 Riktning [framåt,bakåt] T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 10

Komplexitet: 2 Tidsåtgång: 8 timmar Krav 5. Simuleringshastighet Krav 6a. Leverans av order Moduler som körs på klientdatorn skickar meddelanden över nätverket på en port som har erhållits från servern. Meddelanden vidarebefordras till TTS, och skrivs i en kommandofil (fifo). Denna hantering sker helt i bakgrunden utan att användaren märker något. TTS_S kontrollerar om det finns några nya meddelanden med jämna mellanrum. När TTS_S upptäcker ett nytt meddelande så tas det om hand. Om ett giltigt kommando påträffas så utförs detta. Standardinställningen är att polla efter nya meddelanden var femte sekund simulerad tid. Det går att justera pollningsintervallet genom att variera ett standardvärde i infilen. Implementerat under projektfas 1 och 2. Krav 6b. Kvittens Visa meddelande i presentatören om reservation eller annullering av väg misslyckas Reserverade vägar ska visas i grönt Belagda block visas i rött Felmeddelande ska visas vid felaktigt kommando (visas redan i simulatorns kommandofönster) TTS_S: Skicka meddelande vid reservation av väg (görs redan) Skicka meddelande vid felaktigt kommando. TTS_P Avkoda meddelande. Visa felmeddelande Komplexitet: 3 Tidsåtgång: 30 timmar Krav 6c. Tillfällig magasinering En tänkbar utvidgning av detta (6b) är att en begärd tågväg (eller en del av den) visas på avvikande sätt till dess att den har reserverats, dvs så länge som den är "tillfälligt magasinerad". Markeringen för tillfällig magasinering bör vara synlig även när belagda och reserverade block visas på samma sträcka. Presentatören får ett meddelande för tillfällig magasinering på blocknivå. Ett meddelande införs för att meddela att tillfällig magasinering på ett block upphör. Observera att flera tillfälliga magasineringar kan finnas på samma block. Komplexitet: 2 Tidsåtgång: 30 timmar T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 11

Krav 7. Återta begärd tågväg Användaren ska kunna återta en redan lagd tågväg. Kommandot utl A B, där A och B är giltiga namn på block som är förbundna med varandra, ska upphäva eventuella reservationer på alla block mellan A och B. Undantag gäller om det finns ett tåg på något block mellan A och B, i vilket fall följande ska gälla: Det block där tåget befinner sig ska förbli reserverat och belagt. Block som har ett överlapp som innefattar blocket förblir reserverade. Arbetsmoment: Parsa det inkommande kommandot Anropa kommandoutföraren Bygga upp en lista med referenser till alla block mellan A och B För varje block i blocklistan: Om blocket är reserverat, försök upphäva reservationen. Flytta tillbaks vägsslut för berörda klarerare. Se vidare avsnittet "Lösa ut tågväg" i Bilaga 1, "Interaktiv trafikledning i TOPSim/TTS". Komplexitet: 4 Tidsåtgång: 80 timmar Krav 8. Blockbeteckningar Blockbeteckningar finns sedan tidigare i TTS-modellen och ska skrivas ut i TTS_P. Om signalbeteckningar ska visas så måste datamodellen kompletteras och syntax för inmatning i modellen införas. Se exempel på syntax nedan. (Obs! ingår ej i tidsuppskattningen!) Ex: Kalla signal på block 4 på grafinivå 2, körriktning höger, för "SIG122": frb sig_id 4 h 4 SIG122 slut Kalla signal på växel v1:s inben, grafinivå 4, för "SIG123": vxl v1 sig_id v 4 h SIG123 slut Meddelandetyp 20 modifieras så att information om signalbeteckningar överförs till presentatören. Signaldata > 20 %ld 1 %s 2 1 Position 2 Signal-id Visning av blockid har implementerats under projektfas 1 och 2. T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 12

Krav 9. Felmeddelande Presentatören ska visa ett felmeddelande om ett givet trafikledningskommando inte accepteras. Det går att tänka sig två olika typer av felmeddelande: [9.1] Ett meddelande i klartext skickas när ett fel uppstår. Ingen koppling till det ursprungliga kommandot ges utöver vad som skrivs i meddelandetexten. Användaren blir medveten om att ett fel har uppstått, men ges ingen möjlighet att korrigera det. [9.2] När ett fel uppstår så skickas ett meddelande som innehåller felets art och ett kommando-id, som gör att programmet som skickade det felaktiga kommandot kan identifiera precis vilket kommando som var felaktigt. Det kan vara önskvärt om det t.ex. ska vara möjligt för användaren att korrigera ett felaktigt kommando i efterhand. Ändra hanteringen av inkommande kommandon så att TTS_S kan ge returvärden [9.2]. TTS_S returnerar omedelbart kommando-id för varje mottaget kommando [9.2]. Skicka meddelande från TTS_S till presentatören när ett kommando inte accepteras [9.1]. Meddelandet består av felmeddelande i klartext [9.1] och en referens till kommandot genom kommando-id [9.2]. Visa felmeddelande i presentatören [9.1]. Komplexitet: [9.1] 1 [9.2] 3 Tidsåtgång: [9.1] 10 timmar [9.2] 10+30 timmar Tid och komplexitet i sammanställningen syftar på variant 9.1. Krav 10. Teknisk plattform Simulatorkärnan TTS körs på en UNIX-maskin och övriga delar körs från en Windows-NT-maskin Detta krav är ett förtydlignade som överensstämmer med utveckling som har bedrivits under TOPSim fas 1 och 2. Det är således redan uppfyllt. Krav 11. Kontinuerlig tågrörelse Ett tågs läge, hastighet och acceleration meddelas vid diskreta rapporteringspunkter. I meddelandet ingår tid och sträcka tills nästa meddelande skickas. Mottagaren av meddelande kan beräkna tågets ungefärliga position mellan rapporteringspunkterna. Ett nytt meddelande för förflyttning av tåg införs: Tåg flyttas > 43 %s 1 %hd 2 %d 3 %d 4 %hd 5 %ld 6 %hd 7 %hd 8 %hd 9 %ld 10 1 Tågnummer 2 Riktning 3 Hastighet 4 Acceleration 5 Gren 6 Position 7 Grafnivå 8 Sträcka (ds) 9 Tid (dt) 10 Tidpunkt När ett meddelande ankommer till presentatören så flyttas tåget till angiven position. Tågets position tills nästa meddelande kommer kan sedan interpoleras fram. T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 13

Positionsmeddelandet skickas endast vid simulering i realtidsläge. Komplexitet: 2 Tidsåtgång: 10 timmar Krav 12. Batchkörning Det ska vara möjligt att omväxlande själv styra trafiken eller låta simulatorns inbyggda trafikledning ta över. Den interaktiva styrningen är gjord så att det redan nu går att koppla in och ur den under pågående simulering. Kombinerat med av och påslagning av realtidsläge så går det redan nu att köra kombinerat "batch" och interaktivt läge. Komplexitet: - Tidsåtgång: - Krav 13. Loggning Utförda trh-kommandon ska loggas på fil. Loggning kan göras i samband med att kommandon godtas och lagras i magasinet. Loggen kan göras tillgänglig som en textfil i användarens arbetskatalog på servern. Hur ska loggfilen göras lätt åtkomlig för användaren? Behövs någon form av gränssnitt i klienten? (Obs, ingår ej i tidplanen.) Komplexitet: 1 Tidsåtgång: 8 timmar Krav 14. Hjälpfunktion En fungerande hjälpfunktion skall finnas tillgänglig i systemet. Arbetets omfattning beror på hur ingående och heltäckande hjälpen ska vara. Olika vägar kan väljas: 1. Integrera hjälpfunktionen i klienten 2. Integrera hjälpfunktionen i TTS_P Arbetsmoment: Besluta hur integrationen av hjälpen ska se ut. Hjälpen kan vara kontextberoende, så att det är möjligt att skapa hjälptexter som är direkt kopplade till dialoger o.dyl. Enklare och mindre arbetskrävande är att bygga ett fristående hjälpsystem med hypertexter. Besluta vilken typ av användare hjälpen ska rikta sig till Identifiera vilka moment som i första hand ska förses med hjälp Skriva hjälptexter Integrera hjälpapplikationen i systemet. Komplexitet: 2 Tidsåtgång: 80 timmar T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 14

Krav 15. Tidtabellsinformation Det skall vara möjligt att se en lista över tågnr och stationer på skärmen. Speciellt tågens utgångsstation. TTS_P: Presentatören har i nuvarande version bara tillgång till en förenklad version av banbeskrivningen. Tidtabellen läses inte överhuvudtaget. Information om tågens existens överförs först när tågen "föds" i TTS_S. Det går att tänka sig flera olika lösningar på kravet på information. Komplexitet: 4 Tidsåtgång: 80 timmar Förenklad version I stället för att låta TTS_P läsa hela tidtabellen kan informationen i tågmeddelandena användas för att skapa en "informationsdatabas"med information om de tåg som vid varje tidpunkt befinner sig på banan. Denna kan sedan användas för att visa tåginformation för användaren på något lämpligt sätt. Fullständig version Läs in tidtabellen i TTS_P innan simuleringen startar. Krav 16. Dela simulering Två eller flera användare ska kunna koppla upp sig mot samma simulering och styra trafiken på varsin del av banan. En användare som just har kopplat upp sig mot servern kan ges möjlighet att se en lista på simuleringar som just då körs, eller är på väg att påbörjas, på servern. Användaren anmäler via klientens gränssnitt att denne vill ansluta sig till någon av simuleringarna. När den som "äger" simuleringen, dvs den som först startade den, har gett sitt godkännande via något kommando i sitt gränssnitt, så måste den nyanslutna klienten få tillgång till modellen. Hela modellen måste överföras, dessutom aktuellt tillstånd för tågens lägen (och beläggda block), signalernas tillstånd, reserverade block, aktuell tidpunkt, Anslutande klient Visa lista på simuleringar (ID) som just nu körs hos servern Ge användaren möjlighet att ansluta sig till en pågående simulering Simuleringens ägare Ta emot begäran om anslutning Godta eller förkasta begäran Skicka svar till avsändaren TTS-Server Ge varje simulering som startas ett ID På begäran, skicka lista med ID och annan info om pågående simuleringar Ta emot begäran om att ansluta klient till en pågående simulering Skicka begäran om att validera begäran till simuleringens ägare Anslut klient till simulering med givet ID. Skica modell och dess aktuella tillstånd till nya klienten Meddela nya klienten att anslutningen är klar eller att anslutningen misslyckades TTS_S Till exempel: Ska varje operatör ha exklusivitet till sitt ansvarsområde? T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 15

Märk trafikledningskommandon med klient-id så det framgår vem som är avsändaren. Mer detaljerad spec av funktion och gränssnitt behövs. Komplexitet: 5 Tidsåtgång: 100 timmar Krav 17. Automatiskt styrda grenar Tillåt att tåg på vissa grenar trafikleds interaktivt medan andra grenar körs av simulatorns inbyggda trafikledning. Speca funktionssätt närmare: Hur ska den som ansvarar för en gren veta att ett tåg är på väg in på grenen? Ska ett tåg få reservera block i grenens ändar automatiskt? Ska en gren markeras som manuell resp. automatisk i infilen eller på något annat sätt? Ska kontrollstatusen (interaktiv/automatisk) kunna ändras under pågående simulering? Arbetsmoment: Användaren ska kunna ange vilka grenar som körs interaktivt resp. automatiskt. Vid framflyttning av vägslut: Tågklareraren kontrollerar om den gren den befinner sig på körs automatiskt eller manuellt. Komplexitet: 4 Tidsåtgång: 20 timmar Krav 18a. Förberedande order Förberedande begäran av tågväg ska registrera ordern i systemet, men inte utföra den förän operatören aktiverar kommandot. Under tiden ska presentatören indikera att en förberedd order finns på den avsedda bandelen genom att markera de block som ingår i vägen med gul färg. Den här punkten beskriver förändringar som berör simuleringskärnan TTS_S. Användaren skapar en förberedande order genom att ange kommandot trh -prep b1 b2, bär b1 och b2 är start- respektive slutblock för vägen. En order aktiveras med kommandot trp x, där x anger ordningsnumret för en förberedande order. Förberedande order numreras automatiskt. TTS_S: Ge förberedande order: a) Parsning av kommando trh prep A B, för att begära förberedande väg mellan A och B b) Parsning av kommando trp x, för att aktivera en förberedd väg c) Anropa kommandoutföraren d) Skapa blocklista Kontrollera att A och B är giltiga blockreferenser Sök i banstrukturen för att hitta väg mellan A och B Spara referens till alla block mellan A och B i listan e) Skapa väglista Dela in blocklistan i in- och utfartsvägar. Förbindelseblock behandlas som en del av föregående utfartsväg. f) Placera vägobjekt i magasin 2 för förberedda order g) Initiera vägen: För varje block, skicka meddelande till presentatören h) Möjliggör listning av förberedda order Visa väg-id, ingående block mm. Aktivering av förberedande order a) Parsa kommando för aktivering av väg förberedande order b) Anropa kommandoutföraren c) Skaffa referens till ordern d) Aktivera ordern T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 16

TTS_P Se Flytta vägobjekt till magasin 1. Krav 18b. Visualisering av förberedande order. Komplexitet: 4 Tidsåtgång: 80 timmar Krav 18b. Visualisering av förberedande order Förberedande order ska visas i presentatören i annan färg än rött eller grönt, t ex gult. e) Visa antal förberedande order i avvikande färg. En räknare måste hålla ordning på antal förberedande order Räkna upp respektive ner när tågväg begärs respektive reserveras Indikera förberedande order i spårplansbilden Vad händer om det både finns en reserverad tågväg och en eller flera förberedande order på samma sträcka? Ska då den förberedande ordern synas i spårplanet? f) Indikera start- och slutpunkt för förberedande order. Exempel på användning av förberedande order: Tåg 1 befinner sig i utgångsläget på tågspår A1 på station A. Tåg 2 står på tågspår A2. 1=> 2=> Stn A B1 B2 Stn B Vi skapar en förberedande order så att vi att snabbt ska kunna begära väg för tåg 1 till tågspår B1 på station B. >> trh -prep A1 B1 1=> 1 2=> B1 B2 Nu begär vi tågväg för tåg 2 som befinner sig på tågspår A2 på station A till tågspår B2 på station B. Tåg 2 börjar köra mot station B. >> trh A2 B2 1=> 1 A2 2=> B1 B2 Tåg två har kommit iväg, och vi aktiverar nu den förberedda ordern som begär väg för det andra tåget. Tåg 1 ger sig iväg mot station B. Indikeringen för förberedande order tas bort. >> trp 1 1=> B1 A2 2=> B2 T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 17

TTS_S Ett nytt meddelande införs för att överföra information till presentatören. FörberedandeTagvag > 35 %hd 1 %hd 2 %hd 3 %hd 4 %hd 5 1 Gren 2 Grendel 3 Länk/objekt 4 Block/växelben/tågspår 5 Riktning TTS_P: Avkoda meddelande Räkna antal förberedande order för varje block Visualisera i avvikande färg Använd speciell indikation för förberedande ordern start- och slutblock Visa ordernummer Komplexitet: 3 Tidsåtgång: 60 timmar Krav 19. Återta förberedande order Registrerade förberedda order återtas med kommandot afv a b. Kommandot tar bort alla förberedda order på sträckan och avmarkerar dem i presentationsfönstret. Komplexitet: 3 Tidsåtgång: 30 timmar T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 18

Rapportförteckning - översikt CATD C1. Kravspecifikation CATD, steg 1 C2. Kravspecifikation CATD, steg 2 C3. Kravspecifikation TOPSim, steg 1 C4. Systemdokumentation för beslutsstöd, DSS C5. Utvärdering av DSS-moduler C6. Systemdokumentation av gränssnittsmoduler C7. Utvärdering av gränssnittsmoduler C8. Kravspecifikation TOPSim, steg 2 C9. Kravbeskrivning för utbildnings- och träningssimulator C10. Seminariedokumentation C11. Sammanfattande slutrapport från CATD-projektet TOPSim T1. Testdokumentation av simulatorprototyp, steg 0 T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 T3. Systemspecifikation av simulatorprototyp, steg 1 T4. Testdokumentation av simulatorprototyp, steg 1 T5. Utvecklingsspecifikation av simulatorprototyp, steg 2 T6. Systemspecifikation av simulatorprototyp, steg 2 T7. Testdokumentation av simulatorprototyp, steg 2 T8. Seminariedokumentation (Se CATD rapport C10) T9. Simulatorsystem inom tågtrafikstyrning, en kunskapsdokumentation T10. Sammanfattande slutrapport från TOPSim-projektet T2. Utvecklingsspecifikation av simulatorprototyp, steg 1 19