A32 delserie 3 ytterligare försenad

[Lars Ödlund]

Ett problem i sammanhanget är väl att systemet ställer stora krav på föraren när det gäller att specificera vilka fel som uppstår. Det gäller ju att han/hon uppfattar och skriver ned en massa hexadecimala felkoder samt helst också anger vid vilken hastighet, vilket ATC-besked och på ganska exakt vilken plats saker och ting inträffar, samt att detta på rätt sätt rapporteras vidare genom hela organisationen. Om detta alltid gjordes på rätt sätt så skulle nog en hel del av de där "oförklarliga" felen inte vara lika oförklarliga längre. Om trafikpersonalen å andra sidan alltid skulle hoppa över sin del av felsökningen, omaktivera/stänga av och köra vidare och sedan bara säga "blä, det fungerar inte, v.g. fixa" till pappa spårinnehavaren så skulle man kunna hålla på hur länge som helst innan man hittar felen. Nu är det ju inte precis så det går till, men det är helt klart att användarens attityd spelar roll. Man kan inte bara tycka att allt är någon annans ansvar....

Det där kan tyvärr inte uppfattas annat än som ett direkt angrepp på Tvärbanans förarpersonal. Du förefaller att ha glömt bort att förarpersonalens egentliga uppgift är att framföra tågen, och framföra dem i tid, inte att debugga ATC-systemet. I huvudsak skulle man kunna tänka sig att tågens systemloggar svarade för datainsamligen, men inte ens när Bombardier provkör med alla loggfunktioner påslagna hittar de alltid några orsaker till felen. Att vissa fel är direkt knutna till enskilda vagnindivider talar också för att det inte enbart rör sig om programvarufel.

Björn

Det tillhör väl, eller bör tillhöra arbetsuppgifterna att klart o tydligt kunna redogöra för inträffade fel, var de inträffade, vad som försigick när de inträffade och vilka eventuella indikeringar utrustningen gav.

[leifd]

Allså, det känns som om trätan i viss mån hamnat på att man måste starta om hela tågsättet i vissa lägen.
Som gammal datanörd, så känns ju inte det så märkligt. Det är ju ett kännt faktum att datorer mår bra av "kallstart" (dvs omstart från helt spänningslöst läge) ibland. Tyvärr nått som man får tillgripa även på datoriserade fordon ibland, även om det kan tyckas vara så att det inte ska behövas.
Att göra omstart i vart fall vid klargöring, känns ju inte fel, möjligen kanske man skulle ha det som rutin även vid normal vändning.

Men varför ?? undrar kanske någon ......
Jo, vid omstart från helt spänningslöst läge, läser alla datorer in sin programvara på nytt, vilket ger ett nytt rent system fritt från buggar och annat som ibland uppstår då datorer går i tomgång (t.ex. då tågsättet står uppställt). Detta brukar gå under uttrycket "Norsk reset".

[Lars Stegenius]

Men varför ?? undrar kanske någon ......
Jo, vid omstart från helt spänningslöst läge, läser alla datorer in sin programvara på nytt, vilket ger ett nytt rent system fritt från buggar och annat som ibland uppstår då datorer går i tomgång (t.ex. då tågsättet står uppställt). Detta brukar gå under uttrycket "Norsk reset".

Under ett antal år arbetade jag för ett amerikanskt oljebolag som i Norden gjort sig känt för sina automatiska bensinstationer. Under början av 2000-talet var jag ansvarig för att införa ett helt nytt PC-baserat system på de Nordiska stationerna. Systemet var inte baserat på Windows eftersom det inte, med all rätt, ansågs tillförlitligt nog för kontinuerlig drift utan var baserat på IBM OS/2, en erkänt stabil plattform för kommunikationsbaserade system. OS/2 är faktiskt en kusin till Windows NT, bägge systemen har samma ursprung i samarbetet mellan IBM och Microsoft, men IBM hade erfarenhet av driftsäkerhetskraven från stordatorer vilket Microsoft ju inte hade vilket avspeglade sig i driftsäkerheten.

I Norge talade man om att när systemet, under provdrift, sket sig skulle man trycka på "Svenskeknappen", dvs man fick en hårdvarureset och reboot av systemet. Samma uttryck spred sig till Finland, men det var helt och hållet mitt fel.....

När systemet väl var färdigutvecklat och färdigtestat behövdes inga knapptryckningar. Tills koncernen fick för sig att alla system skulle vara Windows NT-baserade.... Men då slutade jag.

//Lars S

[Björn Ehnberg]

Ett problem i sammanhanget är väl att systemet ställer stora krav på föraren när det gäller att specificera vilka fel som uppstår. Det gäller ju att han/hon uppfattar och skriver ned en massa hexadecimala felkoder samt helst också anger vid vilken hastighet, vilket ATC-besked och på ganska exakt vilken plats saker och ting inträffar, samt att detta på rätt sätt rapporteras vidare genom hela organisationen. Om detta alltid gjordes på rätt sätt så skulle nog en hel del av de där "oförklarliga" felen inte vara lika oförklarliga längre. Om trafikpersonalen å andra sidan alltid skulle hoppa över sin del av felsökningen, omaktivera/stänga av och köra vidare och sedan bara säga "blä, det fungerar inte, v.g. fixa" till pappa spårinnehavaren så skulle man kunna hålla på hur länge som helst innan man hittar felen. Nu är det ju inte precis så det går till, men det är helt klart att användarens attityd spelar roll. Man kan inte bara tycka att allt är någon annans ansvar....

Det där kan tyvärr inte uppfattas annat än som ett direkt angrepp på Tvärbanans förarpersonal. Du förefaller att ha glömt bort att förarpersonalens egentliga uppgift är att framföra tågen, och framföra dem i tid, inte att debugga ATC-systemet. I huvudsak skulle man kunna tänka sig att tågens systemloggar svarade för datainsamligen, men inte ens när Bombardier provkör med alla loggfunktioner påslagna hittar de alltid några orsaker till felen. Att vissa fel är direkt knutna till enskilda vagnindivider talar också för att det inte enbart rör sig om programvarufel.

Björn

Det tillhör väl, eller bör tillhöra arbetsuppgifterna att klart o tydligt kunna redogöra för inträffade fel, var de inträffade, vad som försigick när de inträffade och vilka eventuella indikeringar utrustningen gav.

Viss! Har jag påstått något annat? Det kanske tar någon minut, i synnerhet om det är ett stoppande fel. Ooch vid nästa hållplats (eller hållplats Globen, eller Gullmarsplan) står trafikanterna och pekar på sina armbandsur och undrar varför tåget är försenat.

[leifd]

Men varför ?? undrar kanske någon ......
Jo, vid omstart från helt spänningslöst läge, läser alla datorer in sin programvara på nytt, vilket ger ett nytt rent system fritt från buggar och annat som ibland uppstår då datorer går i tomgång (t.ex. då tågsättet står uppställt). Detta brukar gå under uttrycket "Norsk reset".

Under ett antal år arbetade jag för ett amerikanskt oljebolag som i Norden gjort sig känt för sina automatiska bensinstationer. Under början av 2000-talet var jag ansvarig för att införa ett helt nytt PC-baserat system på de Nordiska stationerna. Systemet var inte baserat på Windows eftersom det inte, med all rätt, ansågs tillförlitligt nog för kontinuerlig drift utan var baserat på IBM OS/2, en erkänt stabil plattform för kommunikationsbaserade system. OS/2 är faktiskt en kusin till Windows NT, bägge systemen har samma ursprung i samarbetet mellan IBM och Microsoft, men IBM hade erfarenhet av driftsäkerhetskraven från stordatorer vilket Microsoft ju inte hade vilket avspeglade sig i driftsäkerheten.

I Norge talade man om att när systemet, under provdrift, sket sig skulle man trycka på "Svenskeknappen", dvs man fick en hårdvarureset och reboot av systemet. Samma uttryck spred sig till Finland, men det var helt och hållet mitt fel.....

När systemet väl var färdigutvecklat och färdigtestat behövdes inga knapptryckningar. Tills koncernen fick för sig att alla system skulle vara Windows NT-baserade.... Men då slutade jag.

//Lars S

Bra Lars, vi vet båda vad vi talar om det är tydligt, att allt inte alltid blir så perfekt i alla lägen, det är nog bara att inse, tyvärr (framför allt då folk som inte har samma insikter och/eller ekonomiska krav att tänka på, ska bestämma). /Leif D

[leifd]

Det tillhör väl, eller bör tillhöra arbetsuppgifterna att klart o tydligt kunna redogöra för inträffade fel, var de inträffade, vad som försigick när de inträffade och vilka eventuella indikeringar utrustningen gav.

Viss! Har jag påstått något annat? Det kanske tar någon minut, i synnerhet om det är ett stoppande fel. Ooch vid nästa hållplats (eller hållplats Globen, eller Gullmarsplan) står trafikanterna och pekar på sina armbandsur och undrar varför tåget är försenat.

Självklart ska väl hårdvarans loggfunktioner användas så mycket det går, dock är nog en viss känsla hos den som anmäler ett fel av godo, det är inte direkt självklart att felet går att återskapa utan all tänkbar kännedom om omständigheter. Men det är ju klart, vill man inte få fel fixade, så skiter ma i att hjälpa till, så är det (påhopp eller inte, men då ska man heller inte gnälla).
Som förare så ska man, tycker jag allafall, ha så gott psyke att man inte bryr sej det minsta om att "packet" står och pekar på sina klockor, det är ju bara deras stressade magar som gör att de är sånna. De behöver alltså en stund att lugna ner sej på.....

[scotland_dan]

Tyvärr så var felsökningen på Bombardiers ombordplattform rätt så svårjobbad.
pga diversitet principerna som är använda, systemwatchdogen (distributed), den distribuerade funktionaliteten,
realtids o/s som används med olika cykelhastighet, samt vissa andra anledningar.....

Användarinput är ett måste för att hitta mycket...speciellt när det har att göra med samspelet med
konfigurationen.
snabbspårvägen har ett par syster projekt som använder mer eller mindre samma mjukvara, ett av dessa
har lyckats ha ganska bra tillgänglighet. så ganska mycket har förmodligen att göra med den ganska ovanliga
kör situationerna som man har på tvärbanan (avstånd, allt mycket "komprimerat" samt litet,mycket som händer konstant)
ta t.ex. GPS satelliterna som startar om varje 45-60 sekund för att se till att minne samt annat inte ska fragmenteras.
Unix dialekten som används i tvärbanan är bra för denna typ av applikationer men det finns alltid gränser
kompilerad med opensource kompilator btw om någon är intresserad.
tyvärr så är en del av mjukvaran(familjen) i tvärbanan också av "1:a generationen" utvecklingsmässigt...förmodligen så det har spelat in i hög grad.

-Dan

[leifd]

Tyvärr så var felsökningen på Bombardiers ombordplattform rätt så svårjobbad.
pga diversitet principerna som är använda, systemwatchdogen (distributed), den distribuerade funktionaliteten,
realtids o/s som används med olika cykelhastighet, samt vissa andra anledningar.....

Användarinput är ett måste för att hitta mycket...speciellt när det har att göra med samspelet med
konfigurationen.
snabbspårvägen har ett par syster projekt som använder mer eller mindre samma mjukvara, ett av dessa
har lyckats ha ganska bra tillgänglighet. så ganska mycket har förmodligen att göra med den ganska ovanliga
kör situationerna som man har på tvärbanan (avstånd, allt mycket "komprimerat" samt litet,mycket som händer konstant)
ta t.ex. GPS satelliterna som startar om varje 45-60 sekund för att se till att minne samt annat inte ska fragmenteras.
Unix dialekten som används i tvärbanan är bra för denna typ av applikationer men det finns alltid gränser
kompilerad med opensource kompilator btw om någon är intresserad.
tyvärr så är en del av mjukvaran(familjen) i tvärbanan också av "1:a generationen" utvecklingsmässigt...förmodligen så det har spelat in i hög grad.

-Dan

Alltså kanske vi ska se detta som ett exempel på att tankarna var goda, på papperet, en gång i tiden..... men i praktiken blev det lite annorlunda.
Känns alltså som de thär ATC-systemet blev lite väl mycket provbänk, med som det visade sig väl stora krav på användare och tekniker.
Det är nog bra att någon nu vågar ta konsekvenserna av detta och byter ut allt mot mer beprövade saker.

[ragge]

...
Nu var det ju så att Bombardier (egentligen Adtranz, som var SL:s ursprungliga avtalspart) genom 1997 års optionsavtal garanterade leverans av upp till 70 vagnar efter avrop fram till 2011 (man har senare också, i samband med beställningen av delserie 3 förklarat sig villig att förhandla om en förlängning av avtalet) mot att SL ropade av vagnar i en jämn takt. Detta har SL inte gjort. Delserie 1 (10 vagnar) slutlevererades i december 1999, delserie 2 (12 vagnar) i september 2002. Sen blev det ingenting förrän beslutet om delserie 3 i april 2006!
...

Vad menar du att de har gjort för fel? Inte ropat av vagnar i en takt jämn nog? Jämn nog för vad? Enligt vilken måttstock då?

Tycker du att man skulle köpt vagnar som man inte hade avsättning för eller råd med eller vad nu skälet är att man inte köper dem förrän nu, bara för att hålla en jämnare avropningstakt? Det låter som ett högst egendomligt resonemang och arrangemang.

/ragge s

[Björn Ehnberg]

Det tillhör väl, eller bör tillhöra arbetsuppgifterna att klart o tydligt kunna redogöra för inträffade fel, var de inträffade, vad som försigick när de inträffade och vilka eventuella indikeringar utrustningen gav.

Viss! Har jag påstått något annat? Det kanske tar någon minut, i synnerhet om det är ett stoppande fel. Ooch vid nästa hållplats (eller hållplats Globen, eller Gullmarsplan) står trafikanterna och pekar på sina armbandsur och undrar varför tåget är försenat.

Självklart ska väl hårdvarans loggfunktioner användas så mycket det går, dock är nog en viss känsla hos den som anmäler ett fel av godo, det är inte direkt självklart att felet går att återskapa utan all tänkbar kännedom om omständigheter. Men det är ju klart, vill man inte få fel fixade, så skiter ma i att hjälpa till, så är det (påhopp eller inte, men då ska man heller inte gnälla).
Som förare så ska man, tycker jag allafall, ha så gott psyke att man inte bryr sej det minsta om att "packet" står och pekar på sina klockor, det är ju bara deras stressade magar som gör att de är sånna. De behöver alltså en stund att lugna ner sej på.....

Leif, och alla andra: Jag förstår inte riktigt hur missuppfattningen att förarpersonalen skulle strunta i att rapportera felsituationer har uppkommit. Självklart görs det! Problemet var bara, särskilt i början av ATC-perioden (1/3 2007 ungefär fram till sommaren samma år) att uppgiften blev nästan övermäktig pga. den flod av felsituationer som inträffade och som gav upphov till omfattande förseningar. Tågpersonalen fick ta ganska mycket skit för detta. Självklart slår de flesta förare ifrån sig trafikanternas spontana missnöjesyttringar, annars blir man nog inte gammal i jobbet. Annars är, parentetiskt omnämnt, tidhållningen en växande anledning till de trafikantklagomål som kommer in till SLs kundtjänst och det där är nog något som en del förare har i bakhuvudet. Det är stressigt att köra på Tvärbanan - trafiken bedrivs, grovt uttryckt tunnelbanemässigt, men man kör delvis i gatutrafik bland mer eller mindre hänsynslösa bilister och med flodvågor av trafikanter korsande spåren vid vissa hållplatser. Ett bra exempel på det senare är hållplats Årstaberg, som är felkonstruerad ur nästan alla aspekter.

Personalens felrapportering har lett till förbättringar i ATC:n, inte tal om annat! Den senaste och sista programversionen har uppenbarligen en betydligt bättre bufferhantering, som kräver mycket färre omaktiveringar än tidigare. Felsituationer av den typ Bombardier klassificerar som plattformsfel eller systemfel, dvs. mer eller mindre kontrollerat generalknas i programvaran (eller ibland, fastän förstås ovanligare hårdvaran - vissa vagnindivider har visat sig ovanligt svåra att felsöka, exempelvis vagn 406), har också minskat. Bra vill jag dock inte säga att situationen är, särskilt om man jämfört med ett så pass stabilt system som Lidingöbanans Siemens-system. Nå, nu får Tvärbanan leva med detta ett antal år till, men jag tycker att frågan gott kan diskuteras utan att detta rubriceras som "gnäll". I sammanhanget vill jag påpeka att avsikten med denna tråd inte var att diskutera ATC-systemet, jag omnämnde det ursprungligen bara i en bisats vilket ledde till denna, tyvärr bitvis inflammerade debatt.

Mvh.

Björn

[Björn Ehnberg]

Tyvärr så var felsökningen på Bombardiers ombordplattform rätt så svårjobbad.
pga diversitet principerna som är använda, systemwatchdogen (distributed), den distribuerade funktionaliteten,
realtids o/s som används med olika cykelhastighet, samt vissa andra anledningar.....

Användarinput är ett måste för att hitta mycket...speciellt när det har att göra med samspelet med
konfigurationen.
snabbspårvägen har ett par syster projekt som använder mer eller mindre samma mjukvara, ett av dessa
har lyckats ha ganska bra tillgänglighet. så ganska mycket har förmodligen att göra med den ganska ovanliga
kör situationerna som man har på tvärbanan (avstånd, allt mycket "komprimerat" samt litet,mycket som händer konstant)
ta t.ex. GPS satelliterna som startar om varje 45-60 sekund för att se till att minne samt annat inte ska fragmenteras.
Unix dialekten som används i tvärbanan är bra för denna typ av applikationer men det finns alltid gränser
kompilerad med opensource kompilator btw om någon är intresserad.
tyvärr så är en del av mjukvaran(familjen) i tvärbanan också av "1:a generationen" utvecklingsmässigt...förmodligen så det har spelat in i hög grad.

-Dan

Intressanta synpunkter, Danne. Själv har jag jobbat ganska lite med utveckling av realtidsprogramvara och nästan inte alls med dito för processtyrning, men som gammal systemarkitekt har jag ändå ställt mig frågande inför Bombardiers reaktion när de ställs inför (åtminstone vissa) önskemål om förändringar i funktionaliteten: "Det går inte för då bryter man sönder arkitekturen". Jag bevistade en gång dr. Harold Lawsons föreläsningar om vilka överväganden man gjorde när man tog fram arkitekturen till ombordutrustningen i Banverkets ATC-system och det gav många intressanta infallsvinklar på problemet, som inte är direkt trivialt.

Mvh.

Björn

[Björn Ehnberg]

...
Nu var det ju så att Bombardier (egentligen Adtranz, som var SL:s ursprungliga avtalspart) genom 1997 års optionsavtal garanterade leverans av upp till 70 vagnar efter avrop fram till 2011 (man har senare också, i samband med beställningen av delserie 3 förklarat sig villig att förhandla om en förlängning av avtalet) mot att SL ropade av vagnar i en jämn takt. Detta har SL inte gjort. Delserie 1 (10 vagnar) slutlevererades i december 1999, delserie 2 (12 vagnar) i september 2002. Sen blev det ingenting förrän beslutet om delserie 3 i april 2006!
...

Vad menar du att de har gjort för fel? Inte ropat av vagnar i en takt jämn nog? Jämn nog för vad? Enligt vilken måttstock då?

Tycker du att man skulle köpt vagnar som man inte hade avsättning för eller råd med eller vad nu skälet är att man inte köper dem förrän nu, bara för att hålla en jämnare avropningstakt? Det låter som ett högst egendomligt resonemang och arrangemang.

/ragge s

Äntligen någon som vill diskutera det tråden egentligen behandlar.

Tecknar man ett optionsavtal på en så stor volym som det här är frågan om (70 vagnar fram till 2011) måste man förutsätta att avropen sker i en någorlunda jämn takt, och leverantören ska kunna upprätthålla någon form av produktionsplanering och inte drabbas av alltför stora startkostnader vid varje avrop (ex.vis för att på nytt sätta upp den produktionslinje som behövs), något som ofrånkomligen fortplantar sig till fordonspriset. Att SL och Bombardier numera inte är överens om detta framgår tydligt av det beslutsunderlag som SLs fordonsavdelning upprättade inför styrelsebeslutet om anskaffning den 25/4 2006. Därför har man inte heller kunna utnyttja optionsavtalets prisindexering, utan SL har fått acceptera ett offererat pris på ca. 23,5 Mkr. per vagn, ca. 6 Mkr. mer per vagn än delserie 2. Likaså förutsatte optionsavtalet en leveranstid på 16 månader från beställning till första leverans, det är vi långt ifrån nu.

Att behovet (eller avsättningen, som Du uttrycker det) finns är uppenbart. Nockebybanans gamla vagnmaterial har behövt utrangeras länge, likaså har önskemålen om tätare trafik på Tvärbanan funnits längre. Nu när SL måste agera med kniven på strupen sker det med minsta möjliga marginal, en vagn i reserv på Nockebybanan och fyra vagnar i reserv på Tvärbanan, efter det att delserie 3 levererats. När Tvärbanan ska förlängas norrut (planerad byggstart 2009) kommer det att behövas ytterligare något eller några tiotal vagnar till, så det verkar med hänsyn till ovanstående vara hög tid att beställa igen.

Att inte ha råd är ett relativt begrepp i den politiska sektorn, det är mest en fråga om prioriteringar. 2004 greps den politiska ledningen i SL av panik och gav t.ex. tjänstemännen i uppdrag att utreda vad man skulle kunna spara genom att lägga ned Lidingöbanan och Nockebybanan. Billigast är förstås att inte bredriva någon trafik alls.

Nockebybanan skulle enlig tidigare långtidsplanering har fått nya fordon 2006, men så blev det som bekant inte. Som jämförelse kan nämnas att när pendeltågen för några år sedan hade väldiga trafikproblem så plockade Anna Kettner fram en eller annan miljard någonstans ifrån och ropade av ytterligare ett antal X60-vagnar, utöver den då inneliggande beställningen hos Alstom. Det betydde naturligtvis ingenting för det aktuella trafikproblemen, utan var helt och hållet en politisk gest.

Björn

[ragge]

...
Tecknar man ett optionsavtal på en så stor volym som det här är frågan om (70 vagnar fram till 2011) måste man förutsätta att avropen sker i en någorlunda jämn takt, och leverantören ska kunna upprätthålla någon form av produktionsplanering och inte drabbas av alltför stora startkostnader vid varje avrop (ex.vis för att på nytt sätta upp den produktionslinje som behövs), något som ofrånkomligen fortplantar sig till fordonspriset.

Varför måste man förutsätta det? Jag tycker inte det är ett dugg självklart, utan en överenskommen tidsperiod är en överenskommen tidsperiod och ett avtal är ett avtal.
Har leverantören sådana krav så bör det ju i så fall stå i avropsavtalet? Gör det det?

Att SL och Bombardier numera inte är överens om detta framgår tydligt av det beslutsunderlag som SLs fordonsavdelning upprättade inför styrelsebeslutet om anskaffning den 25/4 2006.

Ok, vad står det i det beslutsunderlaget som gör att detta framgår?

Därför har man inte heller kunna utnyttja optionsavtalets prisindexering, utan SL har fått acceptera ett offererat pris på ca. 23,5 Mkr. per vagn, ca. 6 Mkr. mer per vagn än delserie 2. Likaså förutsatte optionsavtalet en leveranstid på 16 månader från beställning till första leverans, det är vi långt ifrån nu.

Om det inte står något om avropstakt i avtalet så kan ovanstående anses vara två kontraktsbrott från leverantören. Om det däremot står i kontraktet så kan ju naturligtvis leverantören göra som de vill.

Dessa vagnar säljs ju till ett antal ställen i världen (till fler ställen även med SL-varianten på hytten) så _så_ synd om leverantören och så stora problem med deras planering borde det inte behöva vara.

Att behovet (eller avsättningen, som Du uttrycker det) finns är uppenbart. Nockebybanans gamla vagnmaterial har behövt utrangeras länge, likaså har önskemålen om tätare trafik på Tvärbanan funnits längre. Nu när SL måste agera med kniven på strupen sker det med minsta möjliga marginal, en vagn i reserv på Nockebybanan och fyra vagnar i reserv på Tvärbanan, efter det att delserie 3 levererats. När Tvärbanan ska förlängas norrut (planerad byggstart 2009) kommer det att behövas ytterligare något eller några tiotal vagnar till, så det verkar med hänsyn till ovanstående vara hög tid att beställa igen.
...

Jag håller med dig om detta så klart, men finns det inga pengar att köpa för så kan man ju inte köpa. Politiskt rävspel eller inte, men SL kan ju inte på eget bevåg göra av med mer skattemedel.

/ragge s

[leifd]

Leif, och alla andra: Jag förstår inte riktigt hur missuppfattningen att förarpersonalen skulle strunta i att rapportera felsituationer har uppkommit. Självklart görs det! Problemet var bara, särskilt i början av ATC-perioden (1/3 2007 ungefär fram till sommaren samma år) att uppgiften blev nästan övermäktig pga. den flod av felsituationer som inträffade och som gav upphov till omfattande förseningar. Tågpersonalen fick ta ganska mycket skit för detta. Självklart slår de flesta förare ifrån sig trafikanternas spontana missnöjesyttringar, annars blir man nog inte gammal i jobbet. Annars är, parentetiskt omnämnt, tidhållningen en växande anledning till de trafikantklagomål som kommer in till SLs kundtjänst och det där är nog något som en del förare har i bakhuvudet. Det är stressigt att köra på Tvärbanan - trafiken bedrivs, grovt uttryckt tunnelbanemässigt, men man kör delvis i gatutrafik bland mer eller mindre hänsynslösa bilister och med flodvågor av trafikanter korsande spåren vid vissa hållplatser. Ett bra exempel på det senare är hållplats Årstaberg, som är felkonstruerad ur nästan alla aspekter.

Personalens felrapportering har lett till förbättringar i ATC:n, inte tal om annat! Den senaste och sista programversionen har uppenbarligen en betydligt bättre bufferhantering, som kräver mycket färre omaktiveringar än tidigare. Felsituationer av den typ Bombardier klassificerar som plattformsfel eller systemfel, dvs. mer eller mindre kontrollerat generalknas i programvaran (eller ibland, fastän förstås ovanligare hårdvaran - vissa vagnindivider har visat sig ovanligt svåra att felsöka, exempelvis vagn 406), har också minskat. Bra vill jag dock inte säga att situationen är, särskilt om man jämfört med ett så pass stabilt system som Lidingöbanans Siemens-system. Nå, nu får Tvärbanan leva med detta ett antal år till, men jag tycker att frågan gott kan diskuteras utan att detta rubriceras som "gnäll". I sammanhanget vill jag påpeka att avsikten med denna tråd inte var att diskutera ATC-systemet, jag omnämnde det ursprungligen bara i en bisats vilket ledde till denna, tyvärr bitvis inflammerade debatt.

Mvh.

Björn

Nåja, du har säker rätt i de du säger, inte tu tal om annat ! Så vi får väl vara överens om att detta ATC-utstyr på Tvärbanan, inte direkt skötts så bra, förmodligen inte från någon inblandad part.
Vi får väl ändå hoppas att det bättrar sej och att det nya man tänker sig ersätta med blir mycket enklare och bättre. Lycka Till med dert !

[2763]

Vi kan börja från slutet:
Är hastighetsbörvärdet en teknisk funktion?
/TKO

Nej. Det är en inställning.

//Tony

[TKO]

Vi kan börja från slutet:
Är hastighetsbörvärdet en teknisk funktion?
/TKO

Nej. Det är en inställning.

//Tony

Det är en funktion.
Börvärdet "ställs in" av ATC-systemet och varierar beroende på omständigheterna.
Om du läser de inlägg som varit den senaste tiden så kanske du inser att ATC-systemet inte fungerar så bra, och att det inte beror på felaktigt handhavande utan på felaktig funktionalitet. Om det sedan är ett hårdvarufel på ombordutrustningen, ett mjukvarufel på ombordutrustningen eller möjligen fel på den fasta utrustningen spelar ingen roll - det är fel på systemets (tekniska) funktion....

Men återigen - du och alla andra som vet exakt vad det är för fel borde skriva ner det och meddela SL och/eller Bombardier - jag tror dom skulle bli mycket tacksamma! Själv har jag ingen aning om vad det specifika felet är...

/TKO

[scotland_dan]

Vi kan börja från slutet:
Är hastighetsbörvärdet en teknisk funktion?
/TKO

Nej. Det är en inställning.

//Tony

Det är en funktion.
Börvärdet "ställs in" av ATC-systemet och varierar beroende på omständigheterna.
Om du läser de inlägg som varit den senaste tiden så kanske du inser att ATC-systemet inte fungerar så bra, och att det inte beror på felaktigt handhavande utan på felaktig funktionalitet. Om det sedan är ett hårdvarufel på ombordutrustningen, ett mjukvarufel på ombordutrustningen eller möjligen fel på den fasta utrustningen spelar ingen roll - det är fel på systemets (tekniska) funktion....

Men återigen - du och alla andra som vet exakt vad det är för fel borde skriva ner det och meddela SL och/eller Bombardier - jag tror dom skulle bli mycket tacksamma! Själv har jag ingen aning om vad det specifika felet är...

/TKO

Det kan var utbildning samt förståelse eventuellt också. Mycket svårt att säga vad detta speciella exempel ovan med 15km/h kan bero på
men bara för att ta ett exempel ur högen.
Om du tar för lång tid på dig att passerar en sträcka så kommer du att få 15km/h helt plötsligt.
iom att tvärbanan har en mycket enkel secheron display, så kan det nog verka underligt när detta plötsligt
händer(dvs ingen information om varför). detta ovan är inget "fel" utan medvetet gjort.


Dan

[2763]

Det är en funktion.
Börvärdet "ställs in" av ATC-systemet och varierar beroende på omständigheterna.
Om du läser de inlägg som varit den senaste tiden så kanske du inser att ATC-systemet inte fungerar så bra, och att det inte beror på felaktigt handhavande utan på felaktig funktionalitet. Om det sedan är ett hårdvarufel på ombordutrustningen, ett mjukvarufel på ombordutrustningen eller möjligen fel på den fasta utrustningen spelar ingen roll - det är fel på systemets (tekniska) funktion....

Men återigen - du och alla andra som vet exakt vad det är för fel borde skriva ner det och meddela SL och/eller Bombardier - jag tror dom skulle bli mycket tacksamma! Själv har jag ingen aning om vad det specifika felet är...

/TKO

Jag håller med dig om att det är fel på hur systemet fungerar, men jag har svårt att tänka mig att det är fel som beror på hårdvaran enär samma hårdvara finns i många andra tillämpningar. Felet ligger snarare i just tillämpningen och då är det inte per definition ett tekniskt fel. Funktionen kan till och med vara rätt!

Hastighetsbörvärdet är inte en "teknisk funktion" eftersom det är en variabel som beräknas utifrån givna data, möjligen kan det vara en matematisk funktion, vilket är något helt annat.

//Tony

[TKO]

Det är en funktion.
Börvärdet "ställs in" av ATC-systemet och varierar beroende på omständigheterna.
Om du läser de inlägg som varit den senaste tiden så kanske du inser att ATC-systemet inte fungerar så bra, och att det inte beror på felaktigt handhavande utan på felaktig funktionalitet. Om det sedan är ett hårdvarufel på ombordutrustningen, ett mjukvarufel på ombordutrustningen eller möjligen fel på den fasta utrustningen spelar ingen roll - det är fel på systemets (tekniska) funktion....

Men återigen - du och alla andra som vet exakt vad det är för fel borde skriva ner det och meddela SL och/eller Bombardier - jag tror dom skulle bli mycket tacksamma! Själv har jag ingen aning om vad det specifika felet är...

/TKO

Jag håller med dig om att det är fel på hur systemet fungerar, men jag har svårt att tänka mig att det är fel som beror på hårdvaran enär samma hårdvara finns i många andra tillämpningar. Felet ligger snarare i just tillämpningen och då är det inte per definition ett tekniskt fel. Funktionen kan till och med vara rätt!

Hastighetsbörvärdet är inte en "teknisk funktion" eftersom det är en variabel som beräknas utifrån givna data, möjligen kan det vara en matematisk funktion, vilket är något helt annat.

//Tony

OK om du definerar "teknisk funktion" som något som är oavhängigt mjukvaran så håller jag med dej... nu förmodar jag att SL köpt ETT system och därför inte behöver bry sej om vilka funktioer som realiserats i hårdvara och vilka som realiserats i mjukvaran.
För övrigt lär systemet inte ha någon funktion alls utan mjukvaran - ja det kanske lyser några kontrollampor!
/TKO

[Björn Ehnberg]

Det kan var utbildning samt förståelse eventuellt också. Mycket svårt att säga vad detta speciella exempel ovan med 15km/h kan bero på
men bara för att ta ett exempel ur högen.
Om du tar för lång tid på dig att passerar en sträcka så kommer du att få 15km/h helt plötsligt.
iom att tvärbanan har en mycket enkel secheron display, så kan det nog verka underligt när detta plötsligt
händer(dvs ingen information om varför). detta ovan är inget "fel" utan medvetet gjort.


Dan

Jag bifogade i mitt tidigare inlägg några ytterst översiktliga felbeskrivningar, och jag ser ingen anledning att vara mer detaljerad än så - tråden handlar trots allt inte om ATC-systemet. Iofs. skulle jag kunna ange felkoder och felbeskrivningar ur Bombardiers felkodsmanual för förarpersonalen, men det skulle föra alltför långt. De fel jag avser rörande nedsättning av börvärdet är ofta av typen att ATC av en eller annan orsak växlar drifttillstånd till läge "depå" (för en diskussion om ATC-systemets drifttillstånd, se denna tråd). Ett exempel på detta är t.ex felet "Cab signal is lost while train is moving" dvs. ATC vet inte längre om någon förarhytt är aktiverad.

Vet Du Danne vilket eller vilka språk programvaran är skriven i?

Det Danne beskriver ovan är väl den välkända MA timeout, vilket enkelt uttryck innebär att tåget bara har en viss tid på sig att passera en signalsträcka. Det implicita körtillstånd som erhålls när en huvudsignal i "kör" passeras är nämligen begränsat inte bara i rummet (=signalsträckan) utan också i tiden. När denna tid löpt ut antar ATC att nästa huvudsignal står i "stopp" och ansätter bromskurva ned till 15 km/tim. Men det var alltså inte denna typ av "fel" jag avsåg.

ATC-panelen ser ut såhär:




Mvh.

Björn