Själv tror jag ju att systemet med fasta block är tillräckligt bra. En fördel är att det är ordentligt utprovat. Om 25 m korta blocksträckor kan sägas att ett tåg som kör i 90 km/h passerar det blocket på 1 sekund. Dubblar vi blocklängden till 50 m så tar det 2 sekunder. Då kan man exempelvis fråga sig om en förkortning av blocklängden från 50 m till 25 m, vilket teoretiskt skulle innebära en "förbättring" med 1 sekund, är tillräckligt stor för att det ska gå att klämma in ytterligare ett tåg, låt oss säga under maxtimmen? Nej, säger jag, det är inte tillräckligt Har vi i utgångsläget 30 tåg/h, alltså ett tåg/120 sekunder, så räcker inte 30 sekunders "förbättring" (OBS! det är en maximalsiffra för förbättringen) för att det ska gå att klämma in ett tåg till. Låt oss säga att vi förkortar blocklängden från 25 m med fasta block till 0 m med CBTC/moving block, som nämndes. Ja, då blir det bara ytterligare en sekunds förbättring.Sio skrev:Nej, jag hittar ingen sådan, de flesta artiklar om CBTC/moving block på nätet är aningen skrivna av leverantörer eller okritiskta populärvetenskapliga texter som sjunger teknikens lov.kildor skrev:Vem hävdar detta? Har du någon länk?Sio skrev:I praktiken ger inte CBTC system högre kapacitet än konventionella system med korta blocksträckor
Så du får tänka själv.
Om man gör blocksträckorna mycket korta, säg 25 meter. Då kanske vi kan komma överens om att det inte blir någon större skillnad mellan fasta och flytande block. Så frågan är snarare hur långa måste de fasta blocken vara för att CBTCska vara märkbart bättre?
Illustrationer som visa flytande block jämfört med fasta brukar visa blocksträckor som är lika långa som bromkurvan mot stopp. Det är ett pedagogiskt sätt stt visa varför flytande block är bra. I verkligheten på fastblocksystem med hög kapacitet brukar bromkurvan sträcka sig över tre-fyra blocksträckor.
På samma sätt brukar illustrationer med flutande blpck bisa att bromkurvsn kan sluta i bakänden på framförvarande tåg. I verkligheten kommer man ändå att kräva ett överlapp imellan målpunten och framförvarande tåg eftersom bromsverkan kan vara lägre än förväntat. Man behöver ett ännu längre avstånd mellan tågen när man bestämmer banans kapacitet eftersom man någon stans där linjen delarsig lär vilja ha tid nog att låsa upp tågvägen för det framförvarande tåget, lägga om växlar och låsa en ny tågväg för det bakomvarande tåget. Och sedan har vi ju den tid som stationsuppehållen tar också att ta hänsyn till när det kommer till praktisk kapacitet.
Slutsats i praktiken kan ma nå ca 30tåg per timme både med och utan CBTC. Mer än det är knepigt mest pga stationsuppehållen.
MEN, man kan ju för ett ögonblick fundera över de faktorer som behöver tas hänsyn till för att kalkylera avstånd mellan tåg, för att maximalt utnyttja möjligheterna med CBTC/moving blocks. De är exempelvis: Aktuell "kraft" (hp) som motorerna matas med (alternativt kraften bromsarna påverkar med) i varje ögonblick, massan på tåget (inkl passagerare), vad pådraget hos föraren (eller ATO) står i för läge, hastigheten på tåget, accelerationen på tåget (kan vara negativ), positionen på tåget, och sist men inte minst en angiven säkerhetsmarginal för fel (postionsfel, mer slitna hjul än beräknat, ojämn passagerarfördelning i tåget etc). Det tar sin lilla stund att beräkna detta för en dator.
Av säkerhetsskäl är det inte en enda dator som gör beräkningarna, utan man har låt oss säga tre datorer som utför dem. Då ska det också jämföras, och om två av dem är överens (eller alla tre) så godtar man beräkningen. Frågan är då om man dimensionerar datakraften så att den beräkningen ska göras under oändligt små tidsperioder? Nej, säger jag. Varför skulle det vara kontinuerligt? Tittar vi på en film så är varje sekund sönderhackad i 24 stillbilder (som sedan projiceras flera gånger för att undvika flimmer). Pratar vi i mobilen så är det datapaket som skickas och sätts ihop. En flygledare som tittar på en radarbild från markradarn ser planens position med viss fördröjning om radarmottagaren roterar. Av det skälet att det kräver väsentligt mindre resurser än "kontinuerligt" skulle kräva.
Låt oss säga att beräkningarna görs varje sekund. Då har vi ändå en osäkerhet på 25 m var tåget befinner sig (vid 90 km/h). Det kan vara 25 m framåt eller 25 m bakåt. Alltså är "osäkerhetssträckan" 50 m. Så det är en chimär att tro att principen med CBTC/moving blocks skulle förbättra kapaciteten så väldigt mycket. Så menar i alla fall jag. Synpunkter välkomna!

Nu ska jag göra ett litet djärvt påstående. Har inga länkar, utan förväntar mig att bli emotsagd om så behövs. CBTC/moving block är i praktiken fasta block, fast det marknadsförs som något annat. Av det enkla skälet att det skulle krävas så oerhört mycket mer datorkraft för att få ett "kontinuerligt system". Av precis samma skäl som exemplen med film, mobilsamtalen och det andra jag nämnde inte heller sker kontinuerligt. Det är betydligt enklare för en dator att ha ett antal "virtuella punkter" på banan och sedan beräkna tågens rörelse i förhållande till dem, än att ha ett oändligt antal punkter som datorn ska beräkna utifrån. Skulle vara intressant att läsa någon reaktion på det påståendet (jag drar till med ett påstående så blir det lättare att fatta pennan, förlåt slå på tangenterna menar jag).

Visst, korta block absolut! Helt nytt signalsystem och tro att förbättringen står i proportionen till kostnaderna? Nja, tveksamt. Trimning av uppehållstider med olika "hjälpsystem" och vad man nu kan hitta på, och förbättring i proportion till kostnaderna? Ja, det tror jag mer på!
