Centralizare si Semnalizare

[cristi5]

@frunzaverde cum ce facem pe restul retelei? PZB, mai inlocuim centralizari CED cu CE (sunt cateva in PNRR). Pana la urma e descentralizat sistemul ala (spre deosebire de RBCul care vede 70+ km si N statii, BLA integrat etc) si avantajul e ca nu-i nevoie de proiecte mamut pt modernizarea graduala a centralizarii si semnalizarii PZB. Faptul ca vom avea ETCS pe magistralele principale nu inseamna ca nu putem pune CE si PZB (nou sau upgrade) pe alte linii.

De exemplu (parca asta include Mogosoaia, CEDul ala care nu putea pune semnalul de iesire pe liber)

Serviciului de elaborare a Documentației de Avizare a Lucrărilor de Intervenție (DALI): sporirea eficienței economice și a siguranței feroviare prin creşterea nivelului de centralizare al instalaţiilor de semnalizare feroviară PNRR și Buget de Stat 28,75 milioane RON, 9 luni
1. Anunt de participare: CN1047480/24.09.2022
2. Data deschidere oferte: 07.11.2022
Procedura in evaluare. Pentru Loturile 1 si 3 s-au desemnat ofertele castigatoare

N-am nicio remuscare pt ce am comunicat public despre ETCS. Mesajul principal este ca CFR nu il pune in valoare. Si da, sunt foarte convins ca cu ETCS bine configurat capacitatea la Cluj-Apahida poate fi mult mai buna decat performanta CFR pe BLA. Plus ca acolo un cuvant cheie e "management de trafic", nu doar ETCS, etc.

In ce conditii, cu ce configuratii de bloc, si alti parametri capacitatea ETCS bate PZB cu 40% e o discutie de forum, nu a fost in public si probabil nici nu va fi.

Si da, trebuie sa zicem mai des si mai apasat ca cu ETCS siguranta e mult mai buna decat PZB. Si-asa unii fug de rutier pe feroviar pt siguranta.

Calculele si strategiile pe termen lung le las pentru cei mai tineri. Am observat ca nu putem avea nicio influenta asupra lor. Mai incercam.

PS: Polonia sare direct la ETCS. 350 km de L2 in 2021.
https://www.railwaypro.com/wp/major-signalling-project-completed-in-poland/

[cristi5]

@nitz, totusi RBCurile si alte sisteme care ajung la noi acum ruleaza software conceput pt alte proiecte (as ghici HSR Bologna-Firenze in cazul Alstom, ca la Bologna au sunat cand a cazut gara Arad). Sigur, trebuie configurate cu pozitiile kilometrice, declivitatile, vitezele maxime si alti parametri de pe linia respectiva. Dar softul in sine nu cred ca e nou, "doar" datele.

Din pacate ne spune @motorzbh ca schimbarea RBC (cel putin o schimbare majora 160->200) e foarte scumpa, deci e mai complicat de atat.

Apropo, inteleg ca RBC/ETCS lucreaza cu / afiseaza kilometrul geografic, nu kilometrul CFR...

[carutasul]

...și în final codul e scris de același programator din Mumbai
Nu asta e discuția, ci care sunt exact cerințele actuale (se autorizează la nivel național sau european?)
Bun , ERTMS-ul e un set de protocoale, în el se specifică "MUST" și echipamentul trebuie să facă ce scrie acolo.
Dar știm care sunt cerințele concrete pentru omologarea unui asemenea echipament? Trebuie să treacă anumite teste și dacă da cine le face?
 Nea Gheorghe de la sculărie poate scrie în caietul de sarcini "algoritmii vor fi testați extensiv" dar dacă nu există o specificație concretă Alstom o să scrie și el în documentație "algoritmii au fost testați extensiv" și cum nea Gheorghe nu poate verifica... Din moment ce vorbim de echipamente existente înseamnă că ar trebui să putem afla care sunt cerințele astea, nu?
 

[frunzaverde]

Cerintele sunt date de un tom imens de legislatie europeana numit STI (sau TSI) - Specificatiile Tehnice de Interoperabilitate: https://www.era.europa.eu/domains/technical-specifications-interoperability_en. Sunt multe zeci de mii de pagini... STI se aplica la aproape orice componenta feroviara, de la ERTMS la roti, si de la numerele de inmatriculare pentru vehicule feroviare la calitatea pantografelor.

Si da, cerintele includ toate informatiile legate de specificatia tehnica minima pentru ca componenta individuala si produsul final sa fie compatibil cu STI. "Omologarea" se face prin acordarea certificarii CE, si se face prin intermediul unui Organism Notificat (NoBo) independent; cum vorbim de un produs european, orice NoBo cu capacitate tehnica necesara poate fi folosit. Lista lor aici:

https://ec.europa.eu/growth/tools-databases/nando/index.cfm?fuseaction=directive.pdf&refe_cd=2008%2F57%2FEC&requesttimeout=900.

Peste STI, desigur, mai vin si cerintele clientului, ca daca clientul vrea de exemplu un vagon cu scaune de plus rosu, in configuratie 2+3, asta trebuie livrat, dar asta nu e parte din STI.

[carutasul]

Cerințele de fiabilitate sunt distincte de cele de conformitate  de aceea mă aștept să aibă un capitol separat pentru că se testează diferit. Adică evident că și o chinezărie ar trebui să implementeze protocolul , asta e clar, și e relativ simplu să le conectezi într-un mediu simulat și să vezi că răspund la stimuli conform cerințelor. Partea asta de redundanță și fiabilitate e mai greu de verificat ( eu personal nu am făcut decât teste de temperatură și vibrații pentru niște mici proiecte de la începutul carierei. Din fericire tocmai ieșiserăm din Pactul de la Varșovia, deci nu au fost decât -35 grade, nu -55    
Ca să fiu sincer, deși nu am fost niciodată într-o locomotivă, mă aștept să văd două echipamente conectate într-o arhitectură gen master/slave și un mecanism de arbitrare care să comute pe al doilea când primul nu funcționează. Nu mă aștept să găsesc mai mult de atât, nici măcar un sistem cu vot majoritar, pentru că nu îi văd rostul.

[oc7avian]

La sistemele critice testarea nu mai e doar despre date de intrare/date de ieșire, ci și despre garanția că se comportă cum le-ai definit. La chestii "simple" poți face cu invarianți, oarecum matematic.

Vrei să demonstrezi că nu ai deadlock/livelock, ori să descoperi cazuri unde poate apărea? O formalizare de tipul Communicating sequential processes e una dintre soluții. Mai mult matematică, unde chiar îți bați capul. Și poți găsi cazuri aproape imposibil de găsit la testare.

La o aplicație oarecare de mobil pur și simplu nu mă interesează teste d-astea. Dai restart rapid, aia e. Dar deja de la anumite electronice de pe mașini normale în sus începe să cam ardă.

[carutasul]

 Eu nu discut acum de aspectele teoretice ale disponibilității; deși nu am avut ocazia să lucrez cu ele am idee de o parte din abordări (măcar alea de "pe vremea mea") De testare de software nu m-am ocupat dar știu cu ce se mănâncă
  Ceea ce vreau să subliniez e că și în momentul de față ele se testează prin "declarația de conformitate". Cu alte cuvinte producătorul se jură că a testat codul, algoritmii, echipamentele în multiple feluri și consideră că sunt ok. Deci vrând-nevrând ne bazăm pe probitatea și profesionalismul producătorului, în lipsa unui instrument extern de control.
  Evident că producătorul are sistemul lui intern de control și nu vreau să spun apriori că el nu ar fi bun dar are și el limitele lui; dar dacă vrei să deschizi domeniul către un număr mai mare de producători e necesar să definești mult mai precis cerințele în așa fel încât să le faci auditabile extern. Știu că definirea judicioasă a cerințelor e o sarcină aproape imposibilă, dar în final vei obține sisteme care sunt mai sigure decât cele pe care ți le oferă acum Thales sau Boeing tocmai pentru că cerințele sunt definite în altă parte. Stabilitatea lui Boeing MAX depindea de un software testat prin ce metodă vrei tu dar care depindea de un singur senzor Dau un exemplu absurd: dacă se arde un bec de semnalizare, e o situație critică sau nu? Eu zic că depinde ce semnalizează.  Și apropo de aplicațiile de mobil: datele de la ele sunt fiabile tocmai datorită redundanței. Nu e nevoie ca aplicația să fie extrem de fiabilă ci să ai suficiente mobile ca să nu conteze că s-au restartat vreo două-trei    

[carutasul]

mie mi se pare că vorbim despre tehnologii potrivite cu aparatura care merge pe Marte și presupunem că ar fi aplicate deja la echipamentele existente. Pe "cealaltă linie" înțeleg că nici implementarea propriu-zisă a protocoalelor nu e finalizată, așa că vorbim discuții.

[cristi5]

@oc7avian

Daca am un RBC sau un IXL (interlocking= centralizare) scris pt alt loc din Europa (cu toti invariantii si dovezile matematice necesare) si-l configurez cu datele Sig-Sim, trebuie sa refac niste teste banuiesc. Toate?

Altfel spus: se testeaza softul si configuratia la pachet, sau se pot testa oarecum separat?

Seamana cu sistemele de votare. Alea trebuie sa fie verificabile in timp ce ruleaza.

[carutasul]

eu întreb altceva: CINE testează? Pentru că amestecăm niște lucruri sau așa văd eu. Că eu îmi testez (sau nu) softul la mine în laborator ca să fiu sigur că nu am bug-uri, interlock-uri și ce mai vreau eu să evit e una câtă vreme informația asta nu e disponibilă decât intern, iar eu scriu în declarația de conformitate doar că e conform și că vine autoritatea și îmi testează (cum? că nu are acces la cod?) aplicația e alta. Până și când scrii o aplicație pentru mobil ai o suită de teste la care o supui, dar cine îți certifică de fapt că acele teste sunt complete (și ce înseamnă complete?) și potrivite?
Vaga mea senzație e că în lumea reală lucrurile nu se petrec deloc așa și avem doar niște teste de funcționalitate și de fiabilitate iar restul sunt doar asumate de producător prin proceduri interne . Greșesc?

[oc7avian]

@cristi5 Din punctul meu de vedere trebuie testat tot, din alt motiv: noi venim cu BLAI în paralel, care e noutate. E soluție software deocamdată custom nouă. Iar pe aceiași linie o să ai și trenuri cu ETCS îmbarcat, și cu I60/PZB. Nu am căutat specificații (poate chiar e acoperit, habar n-am), dar sunt convins că există la noi o întrebare de tipul Dacă handover-ul către ETCS L2 eșuează și locomotiva are inclusiv PZB, o frânez de urgență sau o las pe PZB că am BLAI?. Astfel de zone de handover o să avem în preajma stațiilor Brașov și Predeal, de exemplu, până e gata tunelul.

Intuiesc că poate exista o separare între configurare și soft, chiar există și o suprapunere de scenarii. Important e să prinzi la nivel formal posibile "aberații", să nu ajungem la scenariul CAF-ului încă înfipt în depou pe M2.

@carutasul răspunsul e da. ERTMS e plin de specificații care trebuie satisfăcute. Există inclusiv un Hazard Log cu diverse scenarii problematice care trebuie avute în vedere. Beneficiarul trebuie să aibă și el suita de teste fizice să se asigure că specificațiile sunt satisfăcute. Nu aștepți să se întâmple tren contra tren pentru a vedea că funcționează 100% corect ceva, ci pui în practică scenariul. Până la urmă poți găsi și un text tradus greșit, ceea ce tot periculos e.

[carutasul]

Nu am înțeles nimic din răspuns. Orice protocol are specificații care trebuie satisfăcute. Astea sunt specificațiile funcționale. Evident că beneficiarul le testează. Ultima chinezărie de pe piață implementează protocolul GSM, că altfel nu ar suna.
Pe lângă specificațiile funcționale există specificații legate de fiabilitate, de răspuns în stări anormale de funcționare etc. Mai devreme despre astea s-a discutat. Dacă aș avea îndoieli că funcționalitatea se testează în cele mai diverse scenarii nu m-aș mai urca în tren deloc
Dar că face cineva analize din astea cu situațiile posibile de deadlock pe cod... tot mă îndoiesc. Nici măcar nu mi se pare rațional să faci asta; sunt metode mai simple ca să determini dacă un sistem e într-o stare nepermisă și să îl resetezi sau să treci pe backup. Ca să rezum: pot să cred orice scenariu care se referă la verificări funcționale (aplici intrări și verifici ieșiri sau log-uri) nu cred nici un scenariu în care vine beneficiarul și rulează teste pe codul producătorului. Poate e scris prin vreun document, dar nu e realist

[carutasul]

dar dacă aveți la CFR pe cineva care poate asta, vreau să îl cunosc

[cristi5]

De exemplu

O precizare: este vorba de centralizari electronice cu IDM  central. Vor inlocui in principal centralizari mecanice. Prin urmare toate cheltuielile de personal cu acari, revizori de ace, paznici de bariere, IDM pentru N statii sunt locuite cu 1-2 IDM in 4 schimburi gen, asa cum exista deja la Faget, pe linia Ilia-Lugoj. Asta explica de ce proiectul e intitulat "sporirea eficientiei economice si a sigurantei feroviare..."

Un alt amanunt important e ca se pregateste doar DALI, lucrarile nu necesita AC sau AM.

București, 31 ianuarie 2023
📢 CFR SA investește 26 de milioane de lei din PNRR pentru modernizarea instalațiilor de siguranță feroviară - etapa DALI

‼ ‼ ‼ Au fost desemnate ofertele câștigătoare pentru ultimele 3 LOTURI la licitaţia publică pentru elaborarea Documentației de Avizare a Lucrărilor de Intervenție (DALI) privind ,,Sporirea eficienței economice și a siguranței feroviare prin creşterea nivelului de centralizare al instalaţiilor de semnalizare feroviară, aferente sectoarelor de cale ferată de pe raza Regionalelor Timișoara, Cluj, Iași și Galați.
👷 Asocierea I.S.P.C.F. SA (lider de asociere) - SC BAICONS IMPEX SRL a fost desemnată câștigătoare pentru toate cele 3 loturi, valoarea totală a ofertelor depuse fiind de 15.226.284,41 lei, pentru următoarele sectoare CF:
✅Lot 2 - Sucursalele Regionale CF Timișoara și Cluj (Sectoare CF) - 6.913.434,71 LEI fără TVA
✔️Timișoara Sud – Voiteni - Stamora Moravița (Timișoara CET, Timișeni , Jebel, Voiteni, Deta, Stamora Moravița)
✔️Reșița Sud – Caransebeș (Cornuțel Banat, Brebu, Reșița Nord, Reșița Sud)
✔️Sântana – Ciumeghiu (Sântana, Șimand, Nădab, Chișineu Criș, Zerind)
✔️Sărățel – Dej (Măghieruș Șieu, Șintereag)
✔️Deda – Sărățel (Deda, Râpa de Jos, Monor Gledin, Șieu, Marișelu, Sărățel)
✔️Săcuieni Bihor – Carei (Săcuieni Bihor, Șilindru, Valea lui Mihai, Sanislău, Carei)
✔️Gen. Avramescu – Satu Mare – Porumbești (General Avramescu, Satu Mare Sud, Satu Mare, Botiz, Micula, Porumbești)
✅Lot 4 - Sucursalele Regionale CF Iași și Galați (Sectoare CF) - 6.233.122,20 LEI fără TVA
✔️Vaslui – Iași (Bălteni, Buhăiești, Rebricea, Scânteia, Grajduri, Bârnova, Ciurea)
✔️Bârlad – Vaslui (Zorleni, Banca, Crasna, Munteni, Vaslui)
✔️Tecuci – Bârlad (Frunzeasca, Berheci, Nichișeni, Tutova, Bârlad, Tecuci)
✔️Verești – Botoșani (Bucecea, Leorda, Botoșani)
✔️Bacău - Piatra Neamț (Gârleni, Buhuși, Podoleni, Roznov, Piatra Neamț)
✅Lot 5 - Sucursala Regională Galați (Sectoare CF) - 2.079.727,50 LEI fără TVA
✔️Făurei – Galați (Dedulești, Plopu, Urleasca, Traian Sat, Lacul Sărat, Brăila, Baldovinești, Vădeni, Barboși, Filești, Galați)
✔️Urziceni – Făurei (Gârbovi, Cotorca, Pogoanele, Rușetu, Făurei)

ℹ Prin implementarea programului de centralizare a instalațiilor și integrarea acestora în centre de management ale traficului, contribuim esențial la creșterea gradului de siguranță feroviară, optimizarea capacității de exploatare a sectoarelor feroviare și la reducerea cheltuielilor aferente întreținerii.

ℹ Reamintim faptul că, ofertele depuse de aceeași asociere de firme românești au fost desemnate câștigătoare și pentru celelalte 5 LOTURI, cu o valoare totală financiară de 10.748.393,79 lei, pentru elaborarea DALI aferente centralizării instalațiilor din următoarelor stații, respectiv sectoare CF:
✅Lot 1 – Sucursalele Regionale CF Craiova/București – Sectoare CF București - Pitești și București – Urziceni
✅Lot 3 – Sucursala Regională CF Brașov - Sectoare CF Războieni - Tg. Mureș și Sibiu – Vințu de Jos
✅Lot 6 – Sucursala Regională CF București - Stațiile CF Târgoviște și Nucet
✅Lot 7 – Sucursala Regională CF Craiova - Stațiile CF Amaradia și Bascov
✅Lot 8 – Sucursala Regională CF Cluj - Stațiile CF Bușag, Acâș, Vișeul de Jos, Diosig, Biharia și Halmeu

ℹ Sursa de finanțare este asigurată din fonduri nerambursabile prevăzute în Planul Naţional de Relansare şi Rezilienţă (PNRR), iar durata contractelor va fi de 9 luni, de la emiterea ordinului de începere a prestării serviciilor.

[cristi5]

@oc7avian BLAI nu e asa inventie mioritica cum am crezut.
https://forum.peundemerg.ro/index.php?topic=69.msg352129#msg352129

BLAI e un pic mai avansat decat BLA, in sensul ca vezi fiecare bloc in centralizare, nu doar "Linie Curenta Ocupata" (adica nu vezi doar un black box care reprezinta blocurile dintre 2 statii). Practic cu BLA nu stii in ce bloc e trenul intre 2 statii, il vezi doar cand se apropie in ultimele 2 blocuri:  1AD= blocul din fata semnalului de intrare, si 2AD. Restul face BLA "automat" fara ajutorul centralizarii.

E nevoie de BLAI la ERTMS de exemplu ca sa poata calcula RBC autoritatea de miscare (MA) pe N blocuri, practic are nevoie sa stie ca fiecare din ele e liber. BLA obisnuit nu i-ar putea spune asta, pt ca nu are fir de la fiecare circuit de cale pana la centralizare/RBC, ci doar un fir de la bloc la urmatoarele 2 (sa poti pune rosu pe cel dinainte si galben pe urmatorul) sau urmatoarele 3 (la BLA 4I)

Oricine a implementat ERTMS peste PZB sau alt sistem punctual a avut problema asta deci softul nu e chiar asa diferit. Chiar daca a implementat ERTMS fara semnale luminoase, nu cred ca este diferit RBCul, pt ca semnalele laterale sunt doar o vizualizare simplificata a ceea ce "stie" RBC si vede mecanicul pe HMI. Adica daca in loco vezi MA pana la semnalul X, pe stalpul semnalului X vei vedea rosu. Daca vezi MA dincolo de semnalul X, pe stalp va fi galben, verde sau verde clipitor functie de curba de franare. Pe HMI sunt mult mai multe informatii decat atat si posibilitatile RBC de a controla franarea vehiculului ETCS sunt mult mai variate si mai precise ca viteza si pozitie decat PZBul de 2000Hz sau 1000Hz. Dar cele doua reprezentari sunt concordante (engl. "consistent") intre ele.