Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

Citat fra: steenth Dato 24/08-22, 09:15

Citat fra: Sporhund Dato 22/08-22, 18:03

Citat fra: steenth Dato 22/08-22, 13:51De 2 aftener er småting. I de næste 2 weekender er både Køge-Næstved, Ringsted-Køge-Vigerslev og samt forhåbentlig Køge-Roskilde spærret pga. test af signalsystem. Og der kommer mere i løbet af efteråret..

Forhåbentlig ikke. Det er da stærkt bekymrende, at man skal bruge så store grænseflader, så man er nød til at lukke al trafik på en hel strækning, i stedet for at opretholde trafikken til nærmeste nabostation.

De nye sikringsanlæg dækker flere stationer, hvor de gamle normalt dækker et. Det giver nogle udfordringer, når man skal tjekke nyt. Og her er overgangen imellem 2 strækninger, som skal tjekkes, hvor mig bekendt skal skiftes til en anden radioblok center (RBC) undervejes på sted med flere togveje. Jeg kan godt forestille mig at Køge Nord har nogle udfordringer, som et skift på fri bane ikke har.

Køge Nord ligger på den fri bane, i SR sammenhænge.

Hvis du er uenig, må du gerne oplyse, i hvilken km stationsgrænserne ligger, samt hvor I(/VI) signaler er placeret.

Anbefalet læsestof:
SR §2 1.1.
SR §2 1.2.
SR §2 1.3.
Du kan ikke se vedhæftede filer. Det er sandsynligvis fordi du ikke er logget ind i forummet.


Du kan ikke se vedhæftede filer. Det er sandsynligvis fordi du ikke er logget ind i forummet. 

Citat fra: esni Dato 24/08-22, 21:13

Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

Det er en urimelig grov simplificering.

En anden mulighed er gennem redundans. Hvor en server tager over, hvis en anden "går ned". Det er således muligt at genstarte/opdatere eller skifte hardware, uden (oplevet) nedetid.

Så jo, man kan godt opbygge (computer)systemer, hvor der ikke opleves nedetid, ved genstart af enkelt-komponenter/servere. Både Windows, og Un*x. Søg på "high availability" hvis du vil finde mere læsestof om emnet.

Citat fra: mikkelwf Dato 24/08-22, 20:48

Citat fra: Per Holm Dato 24/08-22, 19:30Rolig nu  :

"Tyllefyllebølleby St." kan man efter lyst læse som Tyllefyllebølleby Station eller Tyllefyllebølleby køreplansmæssigt Standsningssted.

Chacun à son goût!


Btw. tror jeg at de motiverede amatører her føler en fascination af at lære af de fagligt indvolverede og deres sprogbrug. For eks. at ikke bare hedder et tog eller togskinner men at de mere specifikke udtryk kan være eksotiske udtryk som "Litra My" eller strkn. 52.

Lige præces med at skrive strækning xx i stedet for København - Ringsted synes jeg faktisk er jævnt irriterende, det fremmer i hvert fald ikke en lægmands motivation for at deltage i debatten. Og så er det virkelig svært at forstå konteksten, når man ikke kender de forskellige strækningsnumre.. Ligeså, men ikke i samme grad, stationsforkortelser..

I en debat, handler det vel primært om, at læserne af ens indlæg forstår hvad man mener.

Og der tror jeg langt flere vil forstå hvad det handler om, hvis man benævner de stationer der afgrænser den stykke man taler om.

Selv i SR-sammenhænge er der flere steder, hvor man direkte ikke må bruge forkortelser. Altså undlade at bruge strækningsnumre og forkortelser.

Hvis man taler om strækningsnumre og kun benytter forkortelser, risikerer man at tabe mange deltagere i debatten. Måske man vil fremstå vidende ved den brug, men i virkeligheden opgiver folk at debattere, og man vil blot fremstå arrogant og bedrevidende (IMHO).

Men hvis man ved at alle dem man skriver med, er vant til at tale om strækningsnumre og kender stations-forkortelserne, kan det være fint nok. Men det er ikke tilfældet i dette forum.

Citat fra: Frank Poulsen Dato 24/08-22, 18:50

Citat fra: Svend Dato 24/08-22, 17:55

Citat fra: steenth Dato 24/08-22, 15:12

Citat fra: Svend Dato 24/08-22, 12:31Det er (åbenbart) ikke rart at blive korrigeret 😏

Svend - verden er mere end hvad SR, ORF eller ORS definere.

Og det fremmer ikke en diskussion med slags "korrektioner". Det bidrager ikke til at højne niveauet. Tænk over det Svend!

Jeg ved ikke om niveauet skal højnes fagligt. Men hvis det er tilfældet, kan man jo kalde tingene ved deres rette navn.
At man i dagligdags tale - blandt lægfolk - kalder de steder, hvor tog standser for stationer, er i orden. Det gør de fleste. 

Så kan der vist ikke koges mere suppe på den pind.

Men Svend så er spørgsmålet jo lidt hvad dette forum er... Er det fagfolk eller lægfolk... Jeg tror her er væsentlig flere lægfolk. og derfor ser jeg intet galt i at bruge lægfolks tale i dette forum... Når det ikke ligefrem er meningsforvirrende.

Det kan jeg da sagtens tilslutte mig. Men så skal vi heller ikke himle op, når vi støder på ord som skiftespor eller hvor "togfører" bliver brugt, hvor der i virkeligheden menes lokomotivfører. Osv, osv, osv ...,
 

Citat fra: Svend Dato 25/08-22, 10:31Det kan jeg da sagtens tilslutte mig. Men så skal vi heller ikke himle op, når vi støder på ord som skiftespor eller hvor "togfører" bliver brugt, hvor der i virkeligheden menes lokomotivfører. Osv, osv, osv ...,
 

..... og fortsat på DJM lade "Børnene ... kravle ind i det 15 meter lange damplokomotiv, der rummer instrumentbræt, fyrrum, ildkammer og askerum."

Citat fra: thomastog Dato 25/08-22, 07:36

Citat fra: esni Dato 24/08-22, 21:13

Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

Det er en urimelig grov simplificering.

En anden mulighed er gennem redundans. Hvor en server tager over, hvis en anden "går ned". Det er således muligt at genstarte/opdatere eller skifte hardware, uden (oplevet) nedetid.

Så jo, man kan godt opbygge (computer)systemer, hvor der ikke opleves nedetid, ved genstart af enkelt-komponenter/servere. Både Windows, og Un*x. Søg på "high availability" hvis du vil finde mere læsestof om emnet.

Jeg reagerede på 'Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres' som jeg mener er en svag undskyldning for en systemmæssig svaghed der KUNNE være undgået ved et design der tillod opgradering under drift.

Da vi oplever nedetid i forbindelse med opgradering, så må vi konstatere at opgradering uden driftsforstyrrelse ikke er en del af det realiserede design - uanset hvordan det evt vat tænkt realiseret?

Betydelig nedetid på en windowsmaskine ved opgradering er vel en kendsgerning, som man evt kan sløre med redundant maskine.

Så hvor mener du jeg oversimplificerer?

Citat fra: esni Dato 25/08-22, 13:49

Citat fra: thomastog Dato 25/08-22, 07:36

Citat fra: esni Dato 24/08-22, 21:13

Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

Det er en urimelig grov simplificering.

En anden mulighed er gennem redundans. Hvor en server tager over, hvis en anden "går ned". Det er således muligt at genstarte/opdatere eller skifte hardware, uden (oplevet) nedetid.

Så jo, man kan godt opbygge (computer)systemer, hvor der ikke opleves nedetid, ved genstart af enkelt-komponenter/servere. Både Windows, og Un*x. Søg på "high availability" hvis du vil finde mere læsestof om emnet.

Jeg reagerede på 'Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres' som jeg mener er en svag undskyldning for en systemmæssig svaghed der KUNNE være undgået ved et design der tillod opgradering under drift.

Da vi oplever nedetid i forbindelse med opgradering, så må vi konstatere at opgradering uden driftsforstyrrelse ikke er en del af det realiserede design - uanset hvordan det evt vat tænkt realiseret?

Betydelig nedetid på en windowsmaskine ved opgradering er vel en kendsgerning, som man evt kan sløre med redundant maskine.

Så hvor mener du jeg oversimplificerer?

I din antagelse af, at windows giver mere/oftere nedetid ved opdatering.

Med kompetente sysadm's, kan du få lige så god ydelse/oppetid, med windows.

Citat fra: thomastog Dato 25/08-22, 14:00

Citat fra: esni Dato 25/08-22, 13:49

Citat fra: thomastog Dato 25/08-22, 07:36

Citat fra: esni Dato 24/08-22, 21:13

Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

Det er en urimelig grov simplificering.

En anden mulighed er gennem redundans. Hvor en server tager over, hvis en anden "går ned". Det er således muligt at genstarte/opdatere eller skifte hardware, uden (oplevet) nedetid.

Så jo, man kan godt opbygge (computer)systemer, hvor der ikke opleves nedetid, ved genstart af enkelt-komponenter/servere. Både Windows, og Un*x. Søg på "high availability" hvis du vil finde mere læsestof om emnet.

Jeg reagerede på 'Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres' som jeg mener er en svag undskyldning for en systemmæssig svaghed der KUNNE være undgået ved et design der tillod opgradering under drift.

Da vi oplever nedetid i forbindelse med opgradering, så må vi konstatere at opgradering uden driftsforstyrrelse ikke er en del af det realiserede design - uanset hvordan det evt vat tænkt realiseret?

Betydelig nedetid på en windowsmaskine ved opgradering er vel en kendsgerning, som man evt kan sløre med redundant maskine.

Så hvor mener du jeg oversimplificerer?

I din antagelse af, at windows giver mere/oftere nedetid ved opdatering.

Med kompetente sysadm's, kan du få lige så god ydelse/oppetid, med windows.

Det underliggende OS er næppe årsagen til en eventuel nedetid ved systemopdateringer. Selv på Linux skal services genstartes ved opdateringer.
Man opdaterer kontrolsystemer i planlagte servicevinduer, for at forblive i kontrol. Om det er hele systemet eller kun nogle units, afhænger af den opdatering der skal laves.

Citat fra: thomastog Dato 25/08-22, 07:28

Citat fra: steenth Dato 24/08-22, 09:15

Citat fra: Sporhund Dato 22/08-22, 18:03

Citat fra: steenth Dato 22/08-22, 13:51De 2 aftener er småting. I de næste 2 weekender er både Køge-Næstved, Ringsted-Køge-Vigerslev og samt forhåbentlig Køge-Roskilde spærret pga. test af signalsystem. Og der kommer mere i løbet af efteråret..

Forhåbentlig ikke. Det er da stærkt bekymrende, at man skal bruge så store grænseflader, så man er nød til at lukke al trafik på en hel strækning, i stedet for at opretholde trafikken til nærmeste nabostation.

De nye sikringsanlæg dækker flere stationer, hvor de gamle normalt dækker et. Det giver nogle udfordringer, når man skal tjekke nyt. Og her er overgangen imellem 2 strækninger, som skal tjekkes, hvor mig bekendt skal skiftes til en anden radioblok center (RBC) undervejes på sted med flere togveje. Jeg kan godt forestille mig at Køge Nord har nogle udfordringer, som et skift på fri bane ikke har.

Køge Nord ligger på den fri bane, i SR sammenhænge.

Hvis du er uenig, må du gerne oplyse, i hvilken km stationsgrænserne ligger, samt hvor I(/VI) signaler er placeret.

Du mistro sammenhængen. Hovedemnet er test af det nye signalsystem, hvor Køge Nord og Lille Syd skal forbindes og hvor der kun skal bruges ETCS. Dvs. SR er ikke relevant her.

Problemet er er forklaringsmæssigt, hvor ORF ikke indeholder de samme begreber som SR. Eller de bruger begreber som man ikke vil bruges af alle i det daglige...

Hvis kigger i strækningsoversigten, så er sporstiftet, hvor Lille Syd deler sig imod Køge Nord og Roskilde dækker af ETCS stopmærker Lw-211 og Kjn-063 (i km 36,4) fra hhv Lille Skensved og Køge Nord og Kj-404 fra Køge - efter sporskiftet er Kj-402 i km 36,6. Så der må være en skillepunkt ved km 36,4 og 36,6, hvor der skiftes Radio Blokcenter  og sikringsanlæg

Spørgsmålet hvad skal kalde det. SR har en god definition på "Station" og "Fri bane". Men området omkring Køge Nord, Køge og Lille Skensved dækker med nyt signalsystem mere end de gamle stationer, hvor grænsen er ved I-signalet, mens med den nye er vel området huset med teknisk dækker. Men kan kalde steder som Køge og Lille Skensved som en station, når man diskuttere området, som en samling af spor, sporskiftere og perroner? For strækningsoversigten kalder det "område med sporskifter"... vil det i praksis ikke være det vil stadig vil kalde en station... DSB vil jo kalde "planmæssigt standsningssted" som en station over for publikum... Og Køge Nord - vil det også i praksis dække området  ved sporskiftet på Lille Syd?

Samme med "Fri bane". Det kaldes "spor udenfor område med sporskifter"... Det skillepunkt imellem Lille Syd og Køge Nord, hvor der skal skiftes RBC, ligger i et område, hvor det ikke er simpel i forhold til fx "spor udenfor område med sporskifter" - det som man i SR simpel kalder "Fri bane"...

Citat fra: Mads Dato 25/08-22, 14:26Det underliggende OS er næppe årsagen til en eventuel nedetid ved systemopdateringer. Selv på Linux skal services genstartes ved opdateringer.
Man opdaterer kontrolsystemer i planlagte servicevinduer, for at forblive i kontrol. Om det er hele systemet eller kun nogle units, afhænger af den opdatering der skal laves.

Men det er muligt at skrive tjenester/services, så at de kan opdateres uden at skulle stoppes. Det blev bl.a. brugt i telefoncentraler fra LME.

Så hvis det havde været et designkriterie, at opgradering ikke måtte forstyrre driften, så er det ikke lykkedes

Citat fra: esni Dato 24/08-22, 21:13

Citat fra: frederikhk Dato 24/08-22, 10:50Der er heller ikke meget IT-udstyr eller software der kan køre mens det opdateres.

Man skal også huske at ETCS er en del af ERTMS, bl.a. trafikstyringen, så det er ofte ERTMS der opdateres og ikke kun ETCS.

Jeg tænker også at man opretholder trafikken, i det omfang det er muligt.

Men noget udstyr og SW er designet til at minimere nedetiden ved en opgradering.

Programmeringssproget Erlang, som bl.a. bruges til telefoncentraler er designet så at applikationer kan opdateres udenat de skal stoppes og genstartes.

Linux og Unix skal sjældent genstartes efter opdateringer, men jeg må desværre indrømme at det trods alt KAN forekomme.

Er ERTMS udstyret baseret på windows?

ERTMS er et sæt af andre funktioner, som ETCS og GSM-R. Og ETCS er "kun" et delsystem, som er et togkontrolsystem på linje med ATC, som forbindelser sikringsanlæg med tog.

Til sikkerhedskritisk ting, så bruger man et operativsystem, som er mere simpel end Windows Server eller ligne. Alt skal kunne valideres i dybben..

Jeg har set at til EBILOCK bruger man et domænespecifik sprog til opsætning. Og EBILOCK har også rod i Ericsson, hvis man går lang tilbage. Og de bruger ikke Erlang... Og efter hvad jeg har set, så det UNIX som bruges som OS i den.