Sisteme de Semnalizare Rutiera

8/9/2019 Sisteme de Semnalizare Rutiera

http://slidepdf.com/reader/full/sisteme-de-semnalizare-rutiera 1/35

1

ARHITECTURA UNUI SISTEM ITS

DE DIRIJARE SI SUPRAVEGHERE

A TRAFICULUI PENTRU

PODUL EUROAFRICAN

PESTE STRÂMTOAREA GIBRALTAR

- Proiect Sisteme de Semnalizare Rutiera -

Masteranzi: ing. Drăgan Andrei ing. Sandu Nicolae

ing. Virag Codrin

Profesor: S.l.dr.ing. Timnea Radu

Master Sisteme Inteligente pentru Transporturi

Universitatea Politehnica București

2014 - 2015



2

Cuprins

1. TEMA PROIECTULUI ................................................................................................................................... 3

2. SISTEME ITS. DESCRIERE ȘI GENERALITĂȚI ................................................................................................ 4

3. ARHITECTURA-CADRU EUROPEANĂ FRAME ............................................................................................. 6

4. CADRU GEOGRAFIC AL PROIECTULUI ........................................................................................................ 8

5. UTILIZATORI ............................................................................................................................................. 10

5.1 Categorii de utilizatori ........................................................................................................................... 10

5.2. Cerinte ale utilizatorilor ........................................................................................................................ 15

6. ARHITECTURA FUNCȚIONALĂ .................................................................................................................. 21

7. ARHITECTURA FIZICĂ ............................................................................................................................... 26

8. ARHITECTURA DE COMUNICAȚII ............................................................................................................. 29

8.1. Definitii ........................................................................................................................................ 29

8.2. Lista de tehnologii folosite in ITS ................................................................................................. 31

9. SUGESTII PENTRU PROIECTARE ............................................................................................................... 33

10. CONCLUZII ............................................................................................................................................. 35



3

1. TEMA PROIECTULUI

Proiectul curent vizează proiectarea unui arhitecturi de comunicații a unui sistem ITS

pornind de la modelul oferit de Arhitectura Europeană Cadru pentru ITS, numit și FRAME. Sistemul a cărui arhitectură va fi proiectată în prezenta lucrare se numește Sistem de

dirijare și supraveghere a traficului pentru podul EuroAfrican peste Strâmtoarea Gibraltar. Înmomentul de față, nu există un astfel de pod care să lege continentele Europa și Africa, în mare parte datorită dificultăților geografice de construcție a unui astfel de pod. Adâncimile mari alestrâmtorii (300-900m), lățimea relativ mare (14 km) și duritatea rocilor de pe fundul mării aufăcut până acum imposibilă construcția unui pod sau a unui tunel.

Dar o dată cu progresul stiinței și a tehnicii se poate prognoza o viitoare realizare a uneiastfel de legături. O dată cu construcția unui viitor pod, va fi necesară și implementarea unuisistem modern ITS pentru desfășurarea în condiții de siguranță a traficului pe pod. Din acestmotiv, proiectul nostru va urmări să ofere o soluție de proiectare a unui asemenea sistem ITS.

Proiectul se va baza pe arhitectura cadru europeana FRAME, pentru a asigura o bunăfuncționare și o posibilitate de viitoare interconectare cu alte sisteme sau de dezvoltare ulterioarăa sistemului.

Pentru o economie modernă de success, abilitatea garantării unui transport fluent şiefficient de mărfuri şi personae este o cerinţă fundamentală. Nereuşita îndeplinirii acestei cerinţereprezintă o ameninţare pentru competitivitate şi reflectă, deasemenea, o utilizare ne-durabilă a

infrastructurii de transport.

Aplicaţiile ITS au demonstrate că sunt o modalitate validă şi eficientă de sprijin pentrumanagementul şi operar e serviciilor de transport. Acestea pot ajuta la:

- Reducerea majoră a accidentelor rutiere; - Creşterea capacităţii efective a drumurilor fără noi construcţii (demonstrat, până la 20%); - Reducerea timpului călătoriei (cu o estimare de 1 an la nivelul unei vieţi umane); - Reducerea semnificativă a poluării vehiculelor, ex. emisiile de CO2;

Un număr crescut de aplicaţii ITS sunt acum valabile pentru diferite moduri de. Seestimează ca în 2010 piaţa europeană a acestor aplicaţii să se ridice la 20 miliarde de euro. Pentru

a furniza beneficii maxime, aceste aplicaţii trebuie să fie compatibile, aceasta înseamnă căimplementarea lor ar trebui să se bazeze pe un cadru strategic. Rolul unei Arhitecturi de Sistem pentru ITS, sau Arhitectura ITS este de a furniza un astfel de cadru.

Ca şi alte sisteme de complexitate ridicată, integrarea aplicaţiilor ITS necesită un cadrustrategic ca bază pentru alegerile privind proiectarea şi utilizarea efectivă a acestora, cât şi pentrudeciziile de investiţii. Un astfel de cadru este numit în general Arhitectura Sistemului.



4

O Arhitectură pentru un Sistem Inteligent de Transport va necesita acoperirea aspectelortehnice, şi în plus a elementelor organizaţionale, legale şi comerciale. Arhitecturile ITS pot fi create la nivel naţional, regional sau la nivelul unui oraş precum şi legatede sectoare sau servicii specifice. Acestea ajută la utilizarea efectivă a ITS, în sensul că: - Pot fi planificate într -un mod logic;

- Se integrează cu succes cu alte sisteme; - Ating nivelurilor de performanţă dorite; - Au comportamentul dorit;

- Sunt simplu de condus;

- Sunt simplu de intreţinut; - Sunt simplu de extins;

- Satisfac aşteptările utilizatorilor. Abilitatea de integrare a sistemelor creşte mult potenţialul acestora. În conformitate cu

Arhitectura Cadru Europeană ITS nu numai că aplicaţiile vor lucra împreună, dar acestea vor

putea fi făcute interoperabile la nivel european, un element cu o importanţă ridicată. Interoperabilitatea include aspecte tehnice, operaţionale şi organizaţionale şi implică funcţionareaarmonioasă şi complementară a întregului sistem.

O Arhitectură ITS furnizează un mecanism sistematic pentru determinarea obiectivelor şicerinţelor tuturor celor implicaţi – autorităţi publice, operatori de transport, producători ITS sau

utilizatori finali. Din acest motive facilitează dicuţiile clare dintre aceştia şi asigură un sprijinvaloros decidenţilor.

Podul peste strâmtoarea Gibraltar este de o importanță mai mult decât regională saunațională. Este un obiectiv de importanță continentală. Sistemul ITS proiectat pentru acesta vatrebui să interconecteze zone diferite, iar din acest motiv trebuie să fie foarte adaptabil la

schimbări, adaptări sau upgrade-uri.Podul descris în proiect se presupune a avea atât cale ferată cât și cale rutieră. El este

destinat deplasării de călatori cu mașina personală, cu autocarul sau cu trenul, și pentrutransportul de marfă pe cale ferată și de soșea.

În cursul proiectului vor fi detaliate categoriile de utilizatori și de actori care vor utiliza

sistemul ITS proiectat pentru supravegherea podului, iar apoi se va propune o soluție de creare aunei arhitecturi functionale, fizice, de comunicații, de organizare și de securitate.

2. SISTEME ITS. DESCRIERE ȘI GENERALITĂȚI

Sistemele ITS sunt sisteme de transport care utilizează informaţia, comunicaţiile şitehnologiile de control pentru a îmbunătăţi operarea reţelelor de transport. Instrumentele oferitede sistemele ITS, denumite şi „Telematici în Transport”, se bazează pe trei caracteristici de bază – tehnologia informaţiei, comunicaţiile şi automatizarile – care ajută operatorii şi călătorii să ia



5

decizii mai bune şi mai coordonate. Aceste instrumente sunt utilizate pentru a economisi timp, bani şi vieţiomeneşti, pentru îmbunătăţirea calităţii vieţii şi mediului şi pentru a creşte productivitatea activităţilor comerciale.

Referitor la sistemele ITS se poate spune că un sistem ITS, considerat în totalitatea sa,esteaproape întotdeauna mai eficient decât suma părţilor sale individuale.-Strategia de dezvoltare a

sistemelor ITS impune acţiuni de coordonare între diferiteorganizaţii şi autorităţi care lucrează îndomeniul transporturilor. Primul pas esteconsultarea unei game largi de interese şi construireaunui parteneriat local pentrudezvoltarea / construirea de sisteme ITS.

Conceptele referitoare la funcţionalitatea sistemelor ITS au fost împărţite în următoarele 3categorii:

- Coordonare - din această categorie fac parte acele concepte propuse sau implementate deoperatori sau acelea care sunt în primul rând funcţii ale unei organizaţii de trafic sau ale alteiorganizaţii; - Implementare - această categorie conţine acele concepte recomandate pentruimplementare cu

cel mai mare potenţial în ceea ce priveşte beneficiile; - Monitorizare - această categorie reuneşte acele concepte care pot fi implementate după o perioada de timp sau pot fi implementate mai devreme în condiţiile în care tehnologia se modificărapid de la o tehnologie mai puţin matură la una matură.

Subsisteme ITS

Tipuri de sisteme ITS Servicii

Managementultraficului (ATMS)

1 Tehnici suport pentru planificarea transporturilor

2 Controlul traficului

3 Managementul incidentelor

4 Managementul cererii de transport

5 Reglementări care definesc politica şi cadrul legal privindtraficul

6 Managementul întreţinerii infrastructurii Informaţii pentrucălători (ATIS)

7 Informarea înainte de călătorie

8 Informarea conducătorilor de vehicule în timpul călătoriei 9 Informarea călătorilor în timpul călătoriei 10 Servicii de informare personală

11 Navigarea şi ghidarea de-a lungul rutei

Vehicul (AVCS) 12 Imbunătăţirea vizibilităţii

13 Operarea automată a vehiculelor 14 Evitarea coliziunii longitudinale

15 Evitarea coliziunii laterale

16 Promptitudinea securităţii 17 Acţiuni preventive înaintea impactului

Vehicule comerciale

(CVO)

18 Verificarea vehiculelor comerciale

19 Procese de administrare a vehiculelor comerciale



6

20 Verificarea automată a securităţii rutiere

21 Monitorizarea securităţii la bordul vehiculelor comerciale

22 Managementul parcului de vehicule comerciale

Transport public

(APTS)

23 Managementul transportului public

24 Managementul transportului care răspunde cererii

25 Managementul transportului partajatTratarea urgenţelor

(EM)

26 Notificarea urgenţei şi securitatea personală

27 Managementul vehiculelor de intervenţie

28 Notificarea incidentelor şi a mărfurilor periculoase

Plata electronică(EP) 29 Tranzacţii financiare electronice

Siguranţa 30 Siguranţa călătoriei publice

31 Îmbunătăţirea siguranţei pentru utilizatorii rutierivulnerabili

32 Intersecţii multimodale inteligente

3. ARHITECTURA-CADRU EUROPEANĂ FRAME

Arhitectura FRAME (denumita inițial arhitectura-cadru Europeana) a fost dezvoltata ca

urmare a recomandărilor Grupului la nivel înalt privind sistemele telematice de transport, care aufost susținute de o rezoluție a Consiliului de Miniștri. Acesta a fost creată și publicată pentru prima dată în cadrul proiectului finanțat de CE KAREN în octombrie 2000. Scopul care stă la baza acestei inițiative a fost acela de a promova implementarea (pe baza de drum principal), ITSîn Europa, prin producerea unui cadru care ar putea oferi o bază sistematică de planificare a

implementării ITS, pentru a facilita integrarea lor, atunci când mai multe sisteme urmau să fiedislocate, și de a ajuta la asigurarea interoperabilitatatii, inclusiv dincolo de granițele europene.

O trăsătură distinctivă a arhitecturii FRAME este că acesta este proiectata să aibă sub-

seturi create din acesta, fiind deci improbabil să fie utilizata în întregime. Într -adevăr, la ocazii,conține mai mult de un mod de a efectua un serviciu, iar utilizatorul poate selecta setul defuncționalitati mai adecvat pentru a le livra în acel mediu. Astfel, arhitectura FRAME nu este atâtde mult un model integrat ITS, ca un cadru de la care anumite modele de integrate ITS pot fi

create într -o manieră sistematică și comune. Arhitectura FRAME acoperă acum următoarele domenii ale ITS:

• taxare rutieră electronică

• Notificarea de urgență și răspuns – Notificare pe drum și in Vehicul • Managementul Traficului - Urban, interurban, parcare, tuneluri și poduri, întreținere și simulare,împreună cu gestionarea incidentelor

• Managementul Transportului Public - orarele, tarifele, Cererea de servicii, Managementul Flotei

si al soferului

• Sisteme de tip In-Vehicul - include câteva sisteme de cooperare

• Asistență Calator - Pre-Calatorie și planificare traseu, Informații de călătorie



7

• Suport pentru aplicarea legii • Managementul marfurilor și al flotei • Furnizarea de suport pentru sistemele de cooperare - servicii specifice care nu sunt incluse înaltă parte, de exemplu, benzi pentru autobuze, parcarea autovehiculelor de transport de marfă

• interfețe multi-modale - link-uri către alte moduri de transport atunci când este necesar, de

exemplu, informații de călătorie, managementul punctelor de trecere multi-modal

Deoarece arhitectura FRAME este destinata utilizării în cadrul Uniunii Europene este înconformitate cu preceptele subsidiarității, și, prin urmare, nu prevede nici o structură fizică sau deorganizare intr-un stat membru. Acesta cuprinde doar un set de nevoi ale utilizatorilor care

descriu ceea ce ITS poate oferi, și din punct de vedere funcțional care arată modul în care se poate face. Metodologia, care este susținută de instrumente bazate pe calculator, ajută la creareade sub-seturi logice.

Ca și alte sisteme extrem de complexe, aplicațiile integrate ITS au nevoie de un cadru

strategic ca bază pentru alegerile privind proiectarea și implementarea lor, precum și pentrudeciziile de investiții. Un astfel de cadru este numit în general o arhitectură de sistem. O arhitectura de sistem inteligent de transport va trebui să acopere aspectele tehnice, plus

problemele organizatorice, juridice și de afaceri conexe. • pot fi planificate într -o maniera logica;

• integrează cu succes cu alte sisteme;• îndeplinește nivelurile de performanță dorite;• are comportamentul dorit;

• este ușor de gestionat;• este usor de intretinut;

• este ușor de extins;• satisface așteptările utilizatorilor.

Capacitatea de a integra sistemele creste foarte mult potențialul lor. Cu respectareaarhitecturii-cadru Europeană, nu numai că va lucra împreună cu alte aplicații, dar ele pot fi inter -operabile la nivel european, o caracteristică de importanță tot mai mare. Inter-operabilitatea cuprinde aspectele tehnice, operaționale și organizaționale, și implicăfuncționarea armonioasă și complementară a sistemului în ansamblu.



8

4. CADRU GEOGRAFIC AL PROIECTULUI

Sistemul ITS proiectat în această lucrare este vizat a se va implementa pe un pod ipotetic

peste strâmtoarea Gibraltar, care va lega continentele Europa și Africa. Podul este de oimportanță majoră pentru dezvoltarea comerțului internațional cu bunuri provenite din Africa.

Lagătura internațională dintre Europa și Africa va favoriza deopotrivă și dezvoltareațărilor continentului african, țări care momentan fac partea, marea majoritate, din categoria țărilorsub-dezvoltate.

Podul peste strâmtoarea Gibraltar este încă în stadiul de proiect, datorită condițiilorgeografice care fac foarte dificilă construcția unui asemenea obiectiv.

Strâmtoarea Gibraltar

Geografia strâmtorii:

Europa și Africa sunt separate de 7.7 mile nautice (14.3 km) de ocean în cea mai îngustă porțiune. Adâncimea strâmtorii variază între 300 și 900 metri, adâncime mai mare decât era întimpul ultimei glaciațiuni acum 20000ani, când se crede că nivelul apei era mai mic de 110-

120m. Strâmtoarea este traversată zilnic de către feriboturi, cu o durată a cursei de aproximativ35 min. Pe partea spaniolă a strâmtorii se găsește Parcul National El Estrecho.

Pe partea nordică a strâmtorii se află Spania și Gibraltar (teritoriu Britanic), iar în sud suntMarocul și Ceuta, o exclavă spaniolă pe coasta nord-africană. Era cunoscută în antichitate sub

numele de Coloanele lui Hercule. Aici se află mai multe insule, precum Isla Perejil, care sunt

cerute atât de Spania cât și de Maroc. Strâmtoarea Gibraltar are o poziționare strategică. Navele care trec din Atlantic în Marea

Mediterană trebuie să treacă pe aici. Traversarea între Europa și Africa se face tot prin acest punct. În timpul celui de-al doilea război mondial, britanicii dețineau controlul asupra strâmtoriide la o bază în apropiere. Submarinele germane care voiau să intre în Marea Mediterană erauefectiv prinse în capcană, deoarece nu puteau să plece pe la suprafață, iar curenții submarini erau prea puternici pentru a permite deplasarea pe sub apă.



9

Istoria strâmtorii:

Urmașii lui Mohammed au început să cotropeasca lumea dupa moatea acestuia, încă dinanul 632, până la sfârșitul secolului VII reușind să cucerească toata Africa de Nord. Prima

incursiune musulmana în Iberia a avut loc in anul 710. Anul imediat urmator, un barbar pe nume

Tariq ibn-Ziyad conducea o armata de aproximativ 7000 de oameni către țărmul pe care se afla

imensa stâncă ce domina intrarea catre Mediterana. Acestia au fost cei care au dat numele stâncii,

botezând-o Jabal Tariq, sau muntele lui Tariq. Ulterior creștinii au schimbat numele acesteia înGibraltar.

O altă legendă spune că înaintea invaziei barbare în peninsula Iberica au avut loc si alte

astfel de incursiuni conduse de Tarif ibn Malik Nakli ce urmarea atacarea Spaniei. Conform

spuselor lui Tito Vallejo (în cronica Gibraltar Chronicle ) cand Tariq a invadat pentru prima data

stramtoarea Gibraltar in anul 711, stanca purta numele de Jabal Al Fath - Muntele Victoriei.

Cuvantul arab “Tariq” inseamna de fapt “cale”. Astfel stanca din stramtoarea Gibraltaravea o alta semnificatie, reprezentand de fapt calea parcursa de musulmani catre peninsula

Iberica. Teoria dupa care s-a creat aceasta noua semnificatie, este aceea ca musulmanii,extremisti in religia lor, nu au indraznit sa boteze stanca dupa numele unei persoane, preferand sa

o boteze in onoarea religiei lor.

Inainte desoperirii Americii de catre Columb, stramtoarea Gibraltar era cunoscuta drept

capatul pamantului. Orasul spaniol Tarifa a fost denumit dupa numele arabului Taraf, nume ce

inseamna sfarsit. Daca treceai de orasul Tarifa aveai să cazi de pe marginea pamantului.

Planuri de traversare a strâmtorii:

Au fost destule planuri și proiecte pentru un pod peste strâmtoare, în diferite configurații.Profesorul T.Y.Lin a propus un pod între point Oliveros și Point Cires ce cuprindea turnuri de

susținere adânci, turnuri de 910m înălțime, pe o lungime de 14 km. Între doi stâlpi spațiul ar fi de5000m, de două ori mai mare decât cea mai întindere a unui pod din prezent.

În 2004, architectul Eugene Tsui a publicat un concept pentru un pod plutitor scufundat,

ancorat de o insulă de 3 mile lățime plasată în mijlocul mării Mediterane. Tot în 2004, Science Museum a publicat o imagine a unui proiect propus pentru Podul

Gibraltar.

În afară de poduri, pentru traversarea strâmtorii Gibraltar au fost propuse mai multe

proiecte pentru tunele. Primul proiect datează încă din 1930. A problemă majoră a apărut atuncicând inginerii angajați de guvernul spaniol au descoperit că materialul de sub strâmtoareaGibraltar este extrem de dur, rocă solidă, ceea ce a făcut imposibilă săparea tunelului cutehnologia existentă la vremea respectivă. O altă propunere era construirea unui tunel cu



10

prefabricate de beton, care să fie ancorat pe fundul apei. Tunelul ar fi fost destinat să preia atîttraficul rutier cât și cel feroviar, dar soluția a fost abandonată.

În 2008 un studiu geologic a aruncat din nou dubii asupra fezabilității proiectului. Înmartie 2009 fost pornit un studiu comandat de compania marocană Société Nationale d'Etudes du Détroit de Gibraltar (SNED) și cea spaniolă omoloagă, Sociedad española de estudios para la

comunicación fija a través del Estrecho de Gibraltar S.A (SECEGSA). Cele două companii auefectuat câteva cercetări asupra fundului mării. În prezent este propus un tunel de 40 km lungime, situat la 300m adâncime (cea mai mică

adâncime a strâmtorii), cu o construcție planificată să dureze 15 ani. Un plan mai vechi eralegarea continentelor prin cel mai îngust loc al strâmtorii, dar ideea a fost refuzată pe motiv cădificultatea construirii unui tunel la 900m adâncime ar fi fost prea mare. Cel mai adânc tunelsubmarin din lume este Eiksund Tunnel, la 287m sub nivelul mării.

Un proiect futuristic a circulat în anii 1920-1930, Atlantropa, ce propunea construirea

unui baraj în strâmtoare. El ar fi generat cantități imense de energie, și ar fi putut coborî nivelulmării Mediterane cu câțiva zeci de metri, pentru a crea noi imense porțiuni de teren pentru noiașezări umane.

5. UTILIZATORI

5.1 Categorii de utilizatori

Un utilizator (numit în programul FRAME și ”terminator”) este o entitate care reprezintă

o parte din lumea exterioară sistemului, cu care Arhitectura Cadru ITS interacționează prinintermediul unei interfețe. Entitatea poate fi o persoană, un sistem cu care se face schimb de date,or o entitate fizică de la care pot fi obținute date, cum ar fi atmosfera, sau suprafața carosabilă.Terminatorii dispun de definiții care descris ce așteaptă Arhitectura ca aceștia să facă cu scopulde a permite schimbul de informații. Persoanele pot fi utilizatori finali de genul călătorilor, sau pot fi parte dintr-o organizație sau autoritate publică.

O categorie importantă care contribuie la dezvoltarea si implementarea sistemului ITS oconstituie Actorii (Stake-holders). Acestia sunt persoane sau organizatii implicate, ce pot fi:

- Afectate de implementarea ITS.

- Implicate în implementarea ITS.

Există 4 tipuri de actori, în funcție de rolul lor: - cei care vor ITS: autorități locale, operatori rutieri - cei care construiesc ITS: furnizori/producători de componente ITS

- cei care utilizează ITS: călători, transportatori de marfă

- cei care reglementează ITS: Guverne naționale, Uniunea Europeană, Organisme destandardizare.



11

Cerintele si aspiratiile actorilor se divizeaza pentru o mai buna gestiune in diverse cerinte

ale utilizatorilor, specifice pentru fiecare terminator.

Utilizatorii sistemului ITS (terminatorii) pot fi aleși pe baza listei furnizate de arhitectura

europeană FRAME, folosind Browsing Tool. Categoriile de utilizatori care sunt descrise de

Arhitectura Europeana Frame sunt explicati pe schema generală a sistemului:

Dintre aceștia, actorii importanți care vor utiliza sistemul ITS al Podului EuroAfricansunt:

1. Călătorii (Traveller) 2. Condițiile meteo (Weather systems) 3. Traficul (Traffic)

4. Operator de transport (Transport Planner)

5. Sisteme de urgență (Emergency Systems) 6. Echipamente auxiliare pe soșea (Roadside equipment) 7. Autorități publice (Law Enforcement Agency) 8. Vehicule (Vehicle)

9. Furnizori de servicii externe (External Service Provider)

10. Infrastructura pod/tunel (Bridge/Tunnel Infrastructure)

11. Soferi (Driver)



12

Descrierea fiecărei categorii de utilizatori: 1. Călătorii Aceast serviciu va reprezenta o entitate umană ce foloseşte( sau e pe cale sa folosească)

serviciile de transport furnizate de Sistem.Aceste servicii vor cuprinde dar nu vor fi limitate la

informaţiile de călătorie şi planul călătoriei, fie inainte de începerea călătoriei sau ca o posibilitatede re- plănuire în timpul unei călătorii anterior pregătită şi care este in desfăşurare.

Această categorie are în componenţă următorii actori: a. Parcul de maşini b. Bicicliştii c. Serviciile de pasageri la cerere

d. Pietoni

e. Călătorii cu treceri planificate

f. Utilizatorii de transport public

g. Călătorii“statici”

h.

Conducătorilor auto. Va fi posibil ca aceste servicii să fie disponibile acestor “actori” prin servicii de transport public, maşină personală, bicicletă si mers pe jos. Călătorii vor fi de asemenea capabili săfolosească alte mijloace de transport bazate pe non-drumuri prin interfaţa oferită de ceilalţifurnizori. Înaintea planificării unei excursii, serviciul de actorul călătorii cu treceri planificateeste utilizat. Odată ce călătorii sunt îmbarcaţi într -o traversare(trecere), acesta poate deveni un

bicilcist, şofer, pasager sau pieton depinde de modul utilizat între punctul de origine şi dedestinaţia călătoriei. La aşteptarea în staţia sistemului de transport public, actorul calătorii“statici” este folosit.

2. Sistemul de prognoză meteo:Acest serviciu va oferi informaţii meteo generale despre zona respectivă şi prognoze meteo

sistemului. Informaţiile vor cuprinde factori ca temperatura, ceaţa, ploaia şi vântul( direcţie şiintensitate), pe când prognoza meteo va prezice schimbări ale condiţiilor meteo. Va fi posibil caambele tipuri de informaţii să fie furnizate în mod regulat sau la cererea sistemului.

3. Traficul

Acest serviciu va reprezenta mişcarea vehiculelor pe parcursul rutei. Traficul va descrienumărul de vehicule din care informaţiile de monitorizare ale traficului vor fi colectate şi asupracărora se aplică măsurile de management ale traficului. Va fi posibil ca mişcările autovehiculelordescrise de acest serviciu să fie afişate de acest serviciu în multiple forme. Acestea vor include

dar nu vor fi limitate la mijloace ca imagini video, imagini laser sau infra-roşu, semnăturimagnetice sau oricare alt mijloc în care prezenţa unui vehicul poate fi determinată.

4. Operatorul de transport

Acest furnizor va reprezenta entităţile umane şi/sau sisteme care vor fi responsabile pentruschimbări ale planului de structură al drumului reţelei de transport manageriată de sistem. Va fi



13

posibil ca prin intermediul acestui serviciu ca informaţii adunate de sistem să fie folosite şi să seobţină date de intrare şi posibilitatea de a activa sistemul pentru a se obţine strategii deoptimizarea reţelei de transport. Această optimizare poate fi impusă în cazul managementuluiincidentelor sau pentru a influenţa moduri particulare ale transportului rutier pentru ca politici

speciale ale reţelei de transport să fie implementate.

5. Sisteme de urgenţă

Acest furnizor va reprezenta sisteme destinate şi utilizate de Serviciile de urgenţă ca parte aoperaţiunilor lor.În acest context termenul de “Servicii de urgenţă” vor include organizaţii caresunt responsabile de serviciile de pompieri, poliţie, ambulaţă şi descarcerare. Sistemele deurgenţă vor fi capabile să coordoneze activităţile serviciilor individuale. Acestea vor rezolva şicontrola activităţile vehiculelor şi personalului unui anumit serviciu când întâmpină incidente.Sistemele de urgenţă vor primi informaţii de la sistem despre situaţiile apărute, determinate defuncţionalitatea acestuia. Ca răspuns sistemele de urgenţă vor furniza rapoarte cu privire la

progresul rezolvării unei situaţii pentru a restabili traficul şi pentru ca strategiile de managementale traficului să fie updatate. Sistemele vor furniza de asemenea detalii cu privire la situaţiile deurgenţă care afectează transportul rutier şi care sunt raportate direct cum ar fi un S.O.S din parteaunui autovehicul.

6. Echipamente auxiliare pe sosea

Acest furnizor va reprezenta entităţi care sunt în afara vehiculelor şi care sunt capabile safurnizeze informaţii direct şoferilor. Va fi posibil ca informaţiile să cuprindă reguli de circulaţie,comenzi pentru toate sau pentru categorii speciale de autovehicule pentru a folosi/a nu folosi

benzi de circulaţie specifice pe segmente specifice de circulaţie, comenzi despre viteza maximă,

avertizări despre orice ar putea afecta fluxul de trafic şi informaţii generale.

7. Autorităţi publice

Acest furnizor va reprezenta o autoritate care va lua măsurile necesare sau acţiunile pentruobţinerea acordurilor cu legile, regulile şi regulamentele managementului traficului rutier. Dacăsunt detectate de către sistem încălcări ale legilor , furnizorii vor furniza toate datele necesare pentru autorităţi pentru a identifica si trimite în instanţă infractorii. Aceste informaţii care suntfurnizate de către sistem vor cuprinde minim imagini, numărul de înmatriculare, locaţie, timp,dată, natura infracţiunii.

8. Vehicule

Acest furnizor va reprezenta vehiculele în termeni de funcţionalitate care ar putea să conţină principalul motiv pentru care serciciile ITS sa fie asigurate. Este format din următorii actori carereprezintă diferitele tipuri de vehicule care pot folosi reţeaua de drumuri furnizată de sistem:

Vehicule de urgenţă

Vehicule de transport marfă

Vehicule speciale de transport substanţe periculoase



14

Vehicule pentru servicii la comandă

Alte vehicule

Vehicule private

Vehicule de transport public pentru turism

Vehicule de transport public

Vehicule de mantenanţă

Fiecare din aceşti actori va avea o interfaţă asociată cu funcţionaliatea ITS în alte sfere de

acţiune şi vor primi şi/sau crea informaţii legate de sistemele ITS. Informaţiile şi datele vor ficolectate de senzori din interiorul sistemului şi vor fi limitate la cei care furnizează informaţiidespre reţeaua de drumuri în care vehiculele operează şi cele care monitorizează starea şoferilor.Actorul sisteme de vehicule va avea doar acces de citire a datelor furnizate de sistemul de

vehicule. Acesta şi ceilalţi actori nu vor fi capabili să controleze vehiculele.

9. Furnizori de servicii externe

Acest furnizor va reprezenta entităţi ce vor interfera cu sistemul în diferite moduri. Vacuprinde următorii actori: Furnizor de rezervări Serviciu de transmisie

Furnizor de comunicaţii mobile

Furnizor de informaţii despre vehicule şi şoferi Agenţie de închiriat spaţii de depozitare a mărfii Furnizor de informaţii generale

Furnizor de informaţii geografice

Furnizor de informaţii despre transportul multi-modal

Manager de evenimente planificate Furnizor de informaţii de trafic si despre călătorie

Agenţie de închirieri auto.

Câţiva din aceşti actori vor furniza pur şi simplu informaţii sistemului, ex: hărţi, informaţiidespre puncte de interes. Alţi actori vor interacţiona cu sistemul pentru furnizarea de servicii,ex:date despre situaţia traficului şi informaţii despre călătorie transmise radio, închiriereaspaţiilor de depozitare a mărfurilor.

10. Infrastructura pod/tunel

Acest furnizor va reprezenta entităţile care pot detecta condiţia fizică a podurilor şi tunelelor.Va cuprinde următorii actori:

Strucura podului

Sistemul de management al tunelelor

Conditţiile pe care acesşti actori le pot detecta vor cuprinde elemente ca starea infrastructurii podurilor sau tunelelor, nivelele de poluare atmosferică pe poduri sau în tunele, fum(doar întunele) şi condiţii meteo(doar pentru poduri) şi vor fi furnizate ca date de intrare sistemului.



15

11. Şoferi Acest furnizor va reprezenta entitatea umană care operează un vehicul licenţiat oriunde de-

alungul reţelei de drumuri. Va cuprinde următorii actori, fiecare dintre ei reprezentând entitateaumană care conduce un anumit tip de vehicul:

Şofer de vehicul de urgenţă

Şofer de vehicul de marfă

Şofer de vehicul special de transport pentru mărfuri periculoase

Şofer de vehicul de servicii la comandă

Şofer privat Şofer de transport public

Şofer de transport public pentru turism

Şofer de vehicul de mentenanţă

Fiecare actor va fi autor de cerinţe ale şoferilor către sistem şi vor fi capabili să primeascăde la sistem informaţii şi instrucţiuni pentru şoferi.

5.2. Cerinte ale utilizatorilor

Luată ca un întreg, lista Cerințelor Utilizatorilor prezintă un set de specificatii de nivelînalt pentru Arhitectura FRAME. Majoritatea cerințelor utilizatorilor sunt definite ca parte aaplicațiilor ITS sau ca servicii a obiectivelor funcționale. Altă parte dintre ele sunt legate dearhitectura fizică sau cea de comunicații. Cu scopul de a păstra numărul și mărimea

nevoilor utilizatorilor la proportii corespunzătoare, mai multe detalii au fost omise. Unele dintre

acestea vor fi găsite în descrierile funcțiilor corespunzătoare, în timp ce altele sunt cerințeoriginale, care vor fi definite de către cumpărătorul sistemului sau de către furnizor.

Nu există o corespondență unu-la-unu între nevoile utilizatorilor și funcțiile

Arhitectura FRAME. Arhitectura FRAME este definită de Functional Viewpoint (cu funcții low-

level), care complexă, iar cerințele utilizatorilor furnizează un punct structurat de acces înarhitectura funcțională.

Setul original de Cerințe ale Utilizatorilor este de 540 de cerințe, și a fost creat în timpul proiectului KAREN. Cerințele au fost împărțite în 9 grupuri de nivel înalt, și un grup de cerințe pentru Arhitectura FRAME. Grupurile sunt următoarele:

1. General

- Generic to the Framework Architecture

- Generic to (a subset of) ITS

2. Management Activities

3. Policing/Enforcing

4. Financial Transactions

5. Emergency Services

6. Travel Information



16

7. Traffic Management

8. In-Vehicle Systems

9. Freight and Fleet Operations

10. Public Transport

În continuare sunt prezentate cerințele utilizatorilor alese specific pentru sistemul ITS alPodului EuroAfrican, și funcțiile din arhitectura funcțională asociate:

Cerinta a utilizatorilor Functii asociate2. Grupul Management Activities

2.1.1.1 The system shall be able to produce information

for travellers on the traffic and travel conditions of allrelevant transport modes.

3.1.1.14 Manage Urban Traffic Data

3.1.2.9 Output Inter-urban Traffic Data

2.1.2.3 The system shall be able to assist in the planning of (inter-modal) routes.

3.1.1.14 Manage Urban Traffic Data3.1.2.16 Manage Inter-urban Traffic Data3.1.6.3 Create Traffic Predictions withSimulation Methods3.1.6.4 Manage Traffic Prediction Data Store

3.1.6.5 Provide Traffic Predictions OperatorInterface

2.1.2.5 The system shall be able to simulate potentialcapacity reduction, e.g. due to road works.

3.3.11 Simulate Demand Management Strategy3.3.8 Produce Demand Management Strategy

2.1.4.2. The system shall be able to archive (a summaryof) historical data on transport demand and transport

supply for all transport modes.

3.1.1.14 Manage Urban Traffic Data3.1.2.16 Manage Inter-urban Traffic Data

3.3.9 Manage Demand Management DataStore

2.2.0.1 The system shall provide support for roadmaintenance and infrastructure management.

3.5.9 Evaluate Needs for Short TermMaintenance4.3.2 Provide PT Maintenance Co-ordination

2.2.0.4 The system shall be able to support a databaseof maintenance operations.

3.5.8 Provide Maintenance Data StoreManagement

2.2.2.1 The system shall be able to receiveinfrastructure equipment status data remotely.

3.5.12 Evaluate Need for EquipmentMaintenance

4.3.6 Monitor PT Infrastructure

2.2.2.2 The system shall be able to monitor the

structural integrity of roads, bridges, tunnels, gantries,etc.

3.1.8.1 Assess Bridge Status and Take Action

3. Policing/Enforcing

3.1.0.1 The system shall enforce the traffic laws andregulations of the region automatically (where possible). 7.1.2 Check Compliance7.1.3 Get Vehicle Information7.2.1 Analyse Image7.2.2 Determine Violator ID

7.5.1 Manage Rules

3.1.0.2 The system shall be able to collect the evidenceof a violation of the traffic laws and regulations in a

manner suitable to justify the application of a legal punishment

7.1.2 Check Compliance7.1.3 Get Vehicle Information

7.2.1 Analyse Image7.2.2 Determine Violator ID



17

7.6 Store Violations Data

3.1.1.3 The system shall be able to measure the

characteristics, e.g. length, weight etc., of a vehicleautomatically, whilst the vehicle is in motion ("Weighin Motion").

7.1.3 Get Vehicle Information

4. Financial Transactions4.1.0.1 The system shall be able to use a variety of

relevant payment methods either electronic or not,including central account and post payment, centralaccount and prepayment, on-board account etc.

1.1.1 Create EP Contract

1.1.2 Establish Contract Statistics1.2.1 Load User's Account1.2.2 Debit User's Account

1.3.3 Check User's Contract1.3.4 Inform and Guide User1.3.5 Compute Service Fee1.3.7 Recover Fee1.4.1 Distribute Fees Revenue

1.4.3 Inform Operators on Transactions

4.1.0.5 The system shall be able to use a variety of

payment or receipt means, including contactless "smartcards".

1.2.2 Debit User's Account

1.3.7 Recover Fee

4.1.1.1 The system shall have a minimum impact on thetraffic flow, e.g. a short transaction duration.

1.3.1 Detect User1.3.2 Identify User

1.3.3 Check User's Contract1.3.4 Inform and Guide User1.3.7 Recover Fee1.5.1 Check User's rights1.5.5 Block Access to Service

3.1.4.6 Collect Payment for Car Park space use

4.1.3.1 The system shall be able to exchange financial

information between roadside equipment (e.g. toll

collection unit) and a moving traveller (e.g. a vehicle).


1.3.1 Detect User

1.3.2 Identify User1.3.7 Recover Fee1.5.5 Block Access to Service

4.1.3.4 The system shall have a low number of

incorrect transactions (e.g., non-effective transactions <1 in 10E-6; erroneous transactions < 1 in 10E-8)


1.1.2 Establish Contract Statistics1.2.1 Load User's Account

1.2.2 Debit User's Account1.3.2 Identify User1.3.6 Check Advanced Payment

1.3.7 Recover Fee1.4.1 Distribute Fees Revenue1.4.2 Credit Operator's

4.1.3.5 The system shall provide information in thenative language at the output location, and/or from auser selected choice of other appropriate foreignlanguages.

1.1.1 Create EP Contract1.2.1 Load User's Account1.2.2 Debit User's Account1.2.3 Inform Users on Transactions

1.3.2 Identify User1.3.4 Inform and Guide User

1.3.7 Recover Fee

4.1.4.1 The system shall be able to be able to collect 1.2.2 Debit User's Account



18

evidence on the non-payment of tolls, and other illegalfinancial transactions.

1.3.7 Recover Fee1.5.2 Detect Payment Violations1.5.5 Block Access to Service

5. Emergency Services

5.1.0.2 The system shall be able to detect that the

vehicle has been involved in an accident, identify itslocation, and initiate an 'eCall' automatically.

2.1.2.1 Identify and Classify Emergencies

2.1.2.3 Plan Emergency Intervention2.1.2.5 Manage Incident and Emergency Data

5.1.1.1 The system shall be able to detect when avehicle is (about to) be driven by an unauthorised

person (i.e. stolen)

5.12.6 Detect Illegal Use

5.3.0.2 The system shall be able to provide the location

of hazardous goods.


2.1.2.3 Plan Emergency Intervention2.1.2.5 Manage Incident and Emergency Data

5.11.7 Provide In-vehicle eCall Facilities8.2.2.2.1 Prepare/Process information to/from

board

8.2.2.2.2 Manage Incident

6. Travel Information

6.1.0.1 The system shall provide emergency, or urgent,

information to all road users free of charge.

6.5.10 Provide Traveller Trip Planning

Interface

6.1.0.3 The system shall be able to provide accurate,

credible, timely, and easy to comprehend traffic andtravel information where it may be of benefit to the user.

6.3.13 Provide Traveller Trip Interface

6.6.1 Provide Traveller Information Interface

6.1.1.2 The system shall be able to provide tripinformation on other modes of transport, e.g. for

demand-spreading when major events occur, or whenweather conditions, strikes, cultural or sports events etc

cause problems for one mode.

3.3.13 Output Demand ManagementInformation

6.5.10 Provide Traveller Trip PlanningInterface

6.5.3.9 Plan Trip Details

6.1.2.6 The system shall be able to provide road andtraffic information adapted to different classes of users,e.g. travellers, radio broadcasters, service operators.

3.1.1.14 Manage Urban Traffic Data3.1.2.9 Output Inter-urban Traffic Data6.6.1 Provide Traveller Information Interface

6.2.2.1 The system shall be able to inform travellers on

the current average travel time between fixed points.


6.2.2.4 The system shall provide road and traffic safety

advice based on current weather and traffic conditions.


6.5.10 Provide Traveller Trip PlanningInterface

6.2.3.3 The system shall provide information in thenative language at the output location, and/or from a

user selected choice of other appropriate foreignlanguages, when applicable.

6.3.13 Provide Traveller Trip Interface6.5.10 Provide Traveller Trip Planning

Interface6.5.3.11 Provide Green Wave Routes6.5.3.13 Provide Data & Routes to Fleet

Operators & Drivers6.5.3.3 Collect PT Data

6.5.3.8 Collect Data About Road Traffic6.5.3.9 Plan Trip Details6.5.9 Make Trip Bookings and Payments

6.7.1 Define Traveller's General Trip



19

Preferences

7. Traffic Management

7.1.1.1 The system shall be able to monitor sections ofthe road network to provide the current trafficconditions (e.g. flows, occupancies, speed and travel

times etc.) as real time data.

3.1.1.10 Collect Urban Traffic Data3.1.2.10 Collect Inter-urban Traffic Data

7.1.1.6 The system shall be able to monitor and record

weather conditions (wind, fog, rain level, ice, etc.).

3.4.1 Monitor Weather Conditions

7.1.2.1 The system shall be able to use consistenthistorical data to complement real-time data, when

necessary.

3.1.1.14 Manage Urban Traffic Data3.1.2.16 Manage Inter-urban Traffic Data

7.1.4.6 The system shall be able to provide control

measures for bridges so that warnings of weatherconditions, vehicle restrictions and closure can be

provided.


3.1.8.3 Provide Bridge Operator Interface3.1.8.4 Bridge Information Output to Drivers

7.1.5.6 The system shall be able to command drivers of

certain classes of vehicle (e.g. heavy vehicles or touristtraffic) to take an alternative route for a period of time.

3.1.1.5.24 Implement Urban Traffic Strategies

3.1.2.14.2 Output c&i to Drivers using Inter-urban Roads

3.1.2.14.4 Output Inter-urban TrafficCommands & Messages

7.4.1.25 Hazard Detection - The system shall be able todetect the presence of stationary objects (seen or

deduced) in the carriageway ahead of the host vehicle,and to warn the driver via an in-vehicle device.

5.15.1.7 Detect Stationary Objects in HostVehicle vicinity

5.15.5 Collect & forward local Host Vehicleconditions

7.4.4.1 The system shall be able to recommend a safespeed limit according to the prevailing traffic, weatherand road conditions based on the current legal speed

limit.

3.1.1.5.18 Manage Urban Traffic Speeds andHeadways3.1.2.13.4 Manage Inter-urban Road Network

Speeds & Headways5.13.10 Display Current Road Information toDriver5.13.8 Provide Suggested Speeds andHeadways for ISA

8. In-Vehicle Systems

8.2.2.1 The system shall provide support to control thelateral dynamic behaviour of the vehicle automatically,and keep the vehicle within its current lane of the

carriageway.

5.12.12 Collect Road Network Information5.12.7 Communicate with In-vehicle Systems

8.2.5.1 The system shall provide support to limit the

speed of a vehicle automatically to the a given, butvariable, maximum (intelligent speed adaptation)

5.12.7 Communicate with In-vehicle Systems

5.13.8 Provide Suggested Speeds andHeadways for ISA

9. Freight and Fleet Operations

9.1.0.2 The system shall enable all information storedon-board the vehicle to be interrogated wheneverrequired.

8.2.2.2.1 Prepare/Process information to/from board

9.4.0.5 The system shall be able to report to the home 8.3.2.1 Monitor Driver



20

base when incorrect driver behaviour persists (e.g.driver is ill, or an unskilled driver is in control).

10. Public Transport

10.1.4.2 The system shall be able to provideinformation about a PT service to the travellers before

and during the journey.

4.1.11 Manage PT Vehicle Stop4.1.12 Output Service Information to

Travellers4.1.6 Predict Vehicle Timings4.1.9 Output Arrival Information to Passengers

10.1.5.1 The system shall be able to provide two-waydata and voice communication between PT vehicles and

a central location.

4.1.15 Provide PT Vehicle Driver Interface

Rezumând tabelul anterior, am putea spune că cerințele importante pentru sistem sunt: - sistemul trebuie sa produca informatii legate de trafic pentru călători - sistemul trebuie sa monitorizeze integritatea podului, si sa primeasca date de la distanta de la

senzori. Cerinta este necesara pentru a se putea executa in functie de date diferite procese de

intretinere

- sistemul trebuie sa fie in stare sa masoare lungimea si greutatea vehiculelor . Aceasta este o cerinta de o

importanta majora, pentru a se evita supraincarcarea podului.

- sistemul trebuie sa permita o plata rapida si prin diverse mijloace a taxei de utilizare a podului

- sistemul trebuie sa determine daca un vehicul a fost implicat intr-un accident si sa apeleze automat

serviciile de urgenta prin eCall

- informatiile de urgenta trebuie afisate utilizatorilor (prin diverse mijloace, VMS, radio, etc.)

- sistemul trebuie sa furnizeze informatii in diverse limbi. O cerinta foarte importanta la un pod

international, care va face legatura intre continente. Sistemul va furniza indicatii in engleza, spaniola si

araba.

- sistemul va monitoriza conditiile de trafic si cele meteo. Cerinta este importanta pentru a se evitasupraaglomerarea podului si situatia de vehicule ramase blocate pe pod.

- sistemul va trebui sa ofere un mod de mentinere a benzii pentru masinile inteligente. Acest lucru se va

putea face integrand in structura partii carosabile a unei vopsele metalice pentru marcajele rutiere.

- sistemul va trebui sa monitorizele starea sanatatii soferilor profesionisti si a conducatorilor de vehicule

de mare tonaj

- sistemul va trebui sa ofere informatii calatorilor despre mijloacele de transport in comun si orarul de

circulatie.



21

6. ARHITECTURA FUNCȚIONALĂ

Punctul de vedere funcțional definește și descrie ce funcționalitati trebuie să fie incluseîntr -un Sistem care poate îndeplini cerințele Nevoilor Utilizatorilor din Arhitectura cadru

europeana. Acestea sunt prevăzute într -un document separat întreținut de proiectul FRAME.Prin urmare, punctul de vedere funcțional ex plica sistemului din punct de vedere

funcțional. Acesta arată, de asemenea, cum sunt facute legăturile de functionalitate cu lumea

exterioară și, în special cu utilizatorii sistemului și datele care sunt utilizate în cadrul sistemului.

Descrierea datelor este uneori inclusă într -un Punct de vedere a Informatiilor separat, dar pentru

Arhitectura Europeana ITS aceasta au fost subsumate în punctul de vedere funcțional. Abordarea orientată pe proces a fost implementata în dezvoltarea, actualizarea și

întreținerea arhitecturii-cadru europene ITS. Acesta împarte Punct de vedere functional într -oserie de domenii funcționale. Fiecare dintre ele conține funcții care conțin caracteristicile

necesare pentru a îndeplini nevoile utilizatorilor. Acestea pot include, de asemenea, colectii de

date care dețin informatii în vederea utilizării lor de către alte funcții. Functiile și colectiile de

date sunt legate între ele și la Terminatori ce reprezenta lumea exterioară, cu fluxuri de datefuncționale. Următoarele subcapitole vor furniza descrieri mai detaliate pentru fiecare dintre

aceste entități. Funcționalitatea în toate arhitecturile de sistem trebuie să fie legate de un set de nevoi ale

utilizatorilor. Nevoile defininesc serviciile pe care sistemul trebuie sa le indeplineasca pentru

satisfacerea nevoilor utilizatorilor. Nevoile utilizatorilor formează temelia pe care este construita

arhitectura sistemului.

Există două tipuri de arii funcționale:

Functii de Nivel InaltFuncțiile de nivel înalt sunt funcții foarte complexe. Pentru a face descrierea lor mai ușorde înțeles, acestea au fost împărțite în funcții de nivel inferior. Descrierea fiecărui funcții de nivel

inalt este împărțită în două părți, una care cuprinde o "Prezentare" cu scopul

funcției, si a doua o listă a funcțiilor de componente, așa cum este arătat de exemplu în figura demai jos.

Functii de Nivel Inferior

Funcțiile de nivel inferior sunt funcții ale căror funcționalitate poate fi descris fără a finecesară o subdiviziune în alete elemente constitutive (de nivel inferior). Prin urmare, acestea

reprezintă cel mai scăzut nivel de funcționalitate în fiecare zonă. Descrierea fiecarei functii de

nivel inferior este împărțita în patru părți, care cuprinde o privire de ansamblu, liste de intrareși de ieșire a Fluxurile de date, Cerinte de functionare detaliate (ceea ce face de fapt funcția) și o listă a părților interesate care sunt servite. Un exemplu tipic este prezentată în

figura următoare.



22

Identificate din cerințele utilizatorilor, funcțiile de nivel inferior sunt: 1.1.1 Create EP Contract

1.1.2 Establish Contract Statistics

1.2.1 Load User's Account

1.2.2 Debit User's Account

1.2.3 Inform Users on Transactions1.3.1 Detect User

1.3.2 Identify User

1.3.3 Check User's Contract

1.3.4 Inform and Guide User

1.3.5 Compute Service Fee

1.3.6 Check Advanced Payment

1.3.7 Recover Fee

1.4.1 Distribute Fees Revenue

1.4.2 Credit Operator's

1.4.3 Inform Operators on Transactions

1.5.1 Check User's rights

1.5.2 Detect Payment Violations

1.5.5 Block Access to Service


2.1.2.3 Plan Emergency Intervention

2.1.2.5 Manage Incident and Emergency Data

3.1.1.10 Collect Urban Traffic Data

3.1.1.14 Manage Urban Traffic Data

3.1.1.5.18 Manage Urban Traffic Speeds and Headways

3.1.1.5.24 Implement Urban Traffic Strategies

3.1.2.10 Collect Inter-urban Traffic Data3.1.2.13.4 Manage Inter-urban Road Network Speeds & Headways

3.1.2.14.2 Output c&i to Drivers using Inter-urban Roads

3.1.2.14.4 Output Inter-urban Traffic Commands & Messages

3.1.2.16 Manage Inter-urban Traffic Data

3.1.2.9 Output Inter-urban Traffic Data

3.1.4.6 Collect Payment for Car Park space use

3.1.6.3 Create Traffic Predictions with Simulation Methods

3.1.6.4 Manage Traffic Prediction Data Store

3.1.6.5 Provide Traffic Predictions Operator Interface



3.1.8.3 Provide Bridge Operator Interface

3.1.8.4 Bridge Information Output to Drivers

3.3.11 Simulate Demand Management Strategy

3.3.13 Output Demand Management Information

3.3.8 Produce Demand Management Strategy

3.3.9 Manage Demand Management Data Store



23

3.4.1 Monitor Weather Conditions

3.5.12 Evaluate Need for Equipment Maintenance

3.5.8 Provide Maintenance Data Store Management

3.5.9 Evaluate Needs for Short Term Maintenance

4.1.11 Manage PT Vehicle Stop

4.1.12 Output Service Information to Travellers4.1.15 Provide PT Vehicle Driver Interface

4.1.6 Predict Vehicle Timings

4.1.9 Output Arrival Information to Passengers

4.3.2 Provide PT Maintenance Co-ordination

4.3.6 Monitor PT Infrastructure

5.11.7 Provide In-vehicle eCall Facilities

5.12.12 Collect Road Network Information

5.12.6 Detect Illegal Use

5.12.7 Communicate with In-vehicle Systems

5.13.10 Display Current Road Information to Driver

5.13.8 Provide Suggested Speeds and Headways for ISA

5.15.1.7 Detect Stationary Objects in Host Vehicle vicinity

5.15.5 Collect & forward local Host Vehicle conditions


6.5.10 Provide Traveller Trip Planning Interface

6.5.3.11 Provide Green Wave Routes

6.5.3.13 Provide Data & Routes to Fleet Operators & Drivers

6.5.3.3 Collect PT Data

6.5.3.8 Collect Data About Road Traffic

6.5.3.9 Plan Trip Details

6.5.9 Make Trip Bookings and Payments6.6.1 Provide Traveller Information Interface

6.7.1 Define Traveller's General Trip Preferences

7.1.2 Check Compliance

7.1.3 Get Vehicle Information

7.2.1 Analyse Image

7.2.2 Determine Violator ID

7.5.1 Manage Rules

7.6 Store Violations Data

8.2.2.2.1 Prepare/Process information to/from board

8.2.2.2.2 Manage Incident

8.3.2.1 Monitor Driver

Prin introducerea datelor in Selection Tool, câteva din fluxurile de date logice generate

sunt:

flds-vehicle_position_for_eCall - It contains data from one or more sources from which the current

Vehicle position can be derived for use in an ""eCall"" message



24

fmms.mmc-inter-urban_crossing_request - It contains requests for the opening of a multi-modalcrossing that will stop or restrict the normal flow of road traffic through out the inter-urban road

network.

ftp-process_traffic_prediction_results - It contains an instruction from the Transport Planner to send

the results of a simulation for processing. This will convert the results into data that can be used by

other functionality in the System.

ftp-request_road_network_data - It contains a request from the Transport Planner for output of thecurrent road network (model) data

ftp-request_traffic_prediction_results - It contains a request from the Transport Planner for output of a particular set of simulation results. The identity of the set will be specified in the request.

ftp-run_traffic_prediction_creation - It contains an instruction from the Transport Planner for a trafficsimulation to be run.

ftp-updates_to_road_network_data - It contains updates to the road network (model) data from theTransport Planner

ft-traveller_information_request - It contains a request from the Traveller for the output of some

specified travel information

ft-trip_plan_change_approval - It contains confirmation from the Traveller that the previously

described changes can be made to the trip plan that is currently being implemented. These changeswill occur whilst the trip is in progress and be caused by either changes in the conditions within the

travel network of a request from the Traveller

fv.hmi-initiate_eCall - It is a signal, made by a Vehicle Driver or Passenger, to initiate an ""eCall"" to

the Emergency Services that the Vehicle has been involved in some kind of accident or emergency.

mt_operator_traffic_prediction_commands - It contains commands from the Transport Planner for therunning of particular simulations

mt_operator_traffic_prediction_responses - It contains the responses to previous simulation commandsfrom the Transport Planner

mt_read_prediction_data - It contains a copy of the data that is currently held in the Road TrafficSimulation Data Store

mt_request_road_data_for_predictions - It contains a request for road network (model) and associated

traffic data. This data will be used in the simulation run requested by the Transport Planner. mt_request_traffic_prediction_results - It contains a request for a copy of the results from a particular

simulation to be sent for output to the Transport Planner

mt_send_traffic_prediction_results_for_output - It contains a processed request from the Transport

Planner for the results from a particular simulation to be sent for processing so that they can be outputto other functionality

mt_traffic_prediction_results - It contains the results of a simulation that are for loading into the Road

Traffic Simulation Data Store

mt_updated_road_nework_data - It contains updates (changes) to the road network (model) data thatare to be loaded into the Road Traffic Simulation Data Store

td-current_road_and_traffic_conditions - It contains information that is being output to the Driver ofthe Host Vehicle about road and traffic conditions in the immediate surroundings of the Vehicle

td-current_road_information - It contains static information that is being output to the Driver of theHost Vehicle about the road segment in which the Vehicle is currently travelling.

td-recommended_speed_or_legal_speed_limit_exceeded - It contains a warning for the Driver of the

Host Vehicle that the Vehicle is being driven in a way that the recommended speed and/or legal speedlimit is currently being exceeded.

td-safety_behaviour_warning - It contains a warning to the Driver of the Host Vehicle that the Vehicle

is being driven in an unsafe manner, i.e. poor safety behaviour that may endanger other road users.



25

tesp.gip-request_poi_information - It contains a request for information, such as location, openingtimes, price of service, nearest transport service points about "" Points of Interest"", e.g. monuments,

museums, parks, gardens. etc. in a specific locality

tesp.gip-request_ps_information - It contains a request for information, such as location, opening

times, services available, prices, etc., about ""Points of Interest"", e.g. doctors, chemists, etc. in a

specific locality

tt-implemented_trip_plan_changes - It contains proposed revisions to the currently operating trip planthat are being proposed as a result of changes that have been detected in the travel network, or becausethe Traveller has requested a change.

ttp-requested_traffic_prediction_results - It contains the traffic simulation results that are being sent to

similar functionality in other Systems.

tt-requested_travel_information - It contains the requested travel information that is being output to the

Traveller.

tv.hmi-eCall_response - This data is used to show the response of the emergency services to a“Mayday Call”.

Actorii identificați cu Selection Tool sunt: Actor ID Nume

esp.b Broadcasteresp.ccp Cellular Communications Provider

esp.g Geographic Information Provider

esp.gip General Information Provider

esp.mmtip Multi-Modal Travel Information Provider

esp.ttip Traffic and Travel Information Provider

mms.mmc Multi-Modal Crossing

mo.rmo Road Maintenance Organisation

o.tio Traveller Information Operator

ors.iutms Inter-urban Traffic Management System

ors.ond Other Navigation Device

ors.tss Traffic Simulation Systemors.utms Urban Traffic Management System

v.hmi Human Machine Interface

Terminatorii identificați de Selection Tool sunt: Terminator

IDNume

d Driver

lds Location Data Source

re Roadside Equipment

rp Road Pavement

t Traveller

tp Transport Planner

ws Weather Systems



26

7. ARHITECTURA FIZICĂ

O arhitectură fizică definește și descrie modul în care elementele constitutive ale

Arhitecturii funcțională pot fi reunite în grupuri pentru a forma entități fizice. Caracteristicile

principale ale acestor entități sunt în primul rând, ca ofera unul sau mai multe serviciicerute de nevoile utilizatorilor, iar pe de altă parte că pot fi create. Acest proces de creare poate

implica lucruri fizice, cum ar fi structurile de pe marginea drumului și diverse f orme de

echipamente, non-fizice, cum ar fi software-ul, sau o combinație a celor două.

Elemente fizice ale unei arhitecturi sunt:

Sisteme

Sub-sisteme

Module

Fluxuri de date fizice

Numărul de sub-sisteme într -un anumit "Exemplu de sistem" va depinde de numărul de

locații care le acoperă.

Central - locul care este utilizat de către părți ale sistemului pentru colectarea, alaturarea,

gestionarea si stocarea datelor de trafic, a platii taxelor de drum, a comenzilor de transport de

marfă, și / sau generarea de măsurile de gestionare a traficului, sau instrucțiuni de gestionare a

flotei, cu sau fără intervenție umana.

Ș osea - locul care este utilizat de către părți ale unui sistem pentru detectarea traficului,

fie ca e vorba de vehicule sau pietoni, sau pentru colectarea de taxe, și / sau pentru generarea de

masuri de gestionare a traficului, și / sau furnizarea de informații și comenzi pentru conducătorii

auto și /sau pietoni.

Vehicul - un dispozitiv care este capabil să se deplaseze prin intermediul rețelei dedrumuri și care transportă unul sau mai multe persoane ( biciclete, motociclete, autoturisme,

vehicule de transport public) și / sau de mărfuri, în care părți din sistem pot fi

instalate în timpul fabricației sau adăugate ulterior.

Dispozitiv personal - un dispozitiv în care poate fi instalata o parte a sistemului astfel

încât să poată fi ușor de utilizat de către călători si considerat ca fiind unul dintre bunurile lor

personale

Dispozitiv de transport de marfă - un dispozitiv în care o parte a sistemului poate fi

instalata astfel încât să fie o parte integrantă dintr -o unitate de transport de marfă, de exemplu,container de marfă, remorcă, sau caroseria vehiculului

Kiosk - un dispozitiv, situat de obicei într -un loc public, în care o parte a sistemului poatefi instalata pentru a permite călătorilor să aibă acces limitat și controlat la unele dintre instalațiilesale.



27

Module:

Un sub-sistem poate fi împărțită în două sau mai multe module. Fiecare modul va avea

exact aceleași proprietăți ca un sub-sistem (vis-à-vis de funcționalitatea și capacitatea de a fi un produs comercial) și va avea propria identitate separată fizic. Principala diferență dintre

module și sub-sisteme (și unul dintre motivele pentru folosirea lor), este că fiecare modul este

mult mai probabil să conțina o funcționalitate de la o singură zonă a arhitecturii funcționale. Unalt motiv pentru folosirea modulelor este de a crea componente fizice care conțin o gru pare de

funcționalitati logice pentru fabricați. Modulele vor comunica unul cu altul (fie în cadrul aceluiașisub-sistem, sau cu module în alte subsisteme), utilizând fluxurile de date fizice.

Fluxuri de date fizice:

Fluxurile de date fizice fluxurilor asigura legătur ile de comunicare din fiecare "Exemplu

de sistem". Ele permite ca datele să fie transmise între sub-sisteme, între module, între sub-

sisteme și module, precum și la/de la Terminatori. Acestea pot consta în unu sau mai multe

Fluxuri de date functionale. Fiecare nume a unui flux de date este dat folosind următorul format : abcd free form text

În acest format " abcd " sunt inițialele numelui dat la " Exemplu de sistem ", la care

aparține fluxul de date fizic. "Free form text" va fi unic în cadrul fiecărui "exemplu de sistem" șiva oferi o indicație a ceea ce conține date privind fluxurile fizice. Rețineți că, atunci când un sub-

sistem conține module, poate fi necesar să împartă fluxurile de date fizice de la/la fiecare sub -

sistem în două sau mai multe componente de la/la module. În această situație fluxurile de datefizice sunt definite ca entități separate cu descrieri care conțin identitatea fluxurilor de date

funcționale pe care le includ.

Sub-sistemele fizice ale Podului EuroAfrican sunt:



28

Principalele fluxuri de date fizice:

Broadcaster - Centru de monitorizare: fesp.b-inter-urban_traffic_information_request

It contains a request from the Broadcaster for the output of traffic data for the inter-urban road network

that is currently stored by the System.

Cellular Communications Provider - Centru de monitorizare : fesp.ccp-inter-

urban_network_journey_time_data

It contains journey time data (journey times between defined locations) that has been collected by a

cellular communications provider from its mobile communication units.

Geographic Information Provider - VMS: fesp.g-ISA_information

It contains speed limit data for each part of the urban and inter-urban road networks.

General Information Provider - Panou orar autobuze: fesp.gip-ps_information

It contains information such as location, opening times, services that are provided, prices, etc. about

Personal Services (e.g. doctor, chemist, etc.,) in a specific locality. The arrival of the Data Flow may

be as a result of a previous request, or it may be unsolicited.

Location Data Source - Personal device: flds-ptja_traveller_location

It contains analogue or digital data from which functionality can determine the current location of aTraveller for implementing a trip plan.

Multi-Modal Crossing - VMS: fmms.mmc-inter-urban_crossing_request

It contains requests for the opening of a multi-modal crossing that will stop or restrict the normal flow

of road traffic through out the inter-urban road network.

Road Maintenance Organisation - Senzori trafic: fmo.rmo-infrastructure_diagnostics

It contains data that will provide guidance about the level of integrity that can be attached to the

information that is available from the infrastructure to support for Vehicle guidance.

Other Navigation Device - Senzori trafic: fors.ond-traffic_data , ors.ond

It contains current and predicted travel times for each segment in the road network that have been

received from another navigation device.

Roadside Equipment-VMS: fre-roadside_speed_indication_details

It contains a representation of the dynamic speed commands that are being displayed to Drivers from

outside of the Vehicle, i.e. from devices that are not in any way connected to the Vehicle.

Road Pavement - Senzori trafic: frp-guidance_data

It contains information from the road infrastructure for use in any automatic guidance applications.

Centru de monitorizare - VM: mt_current_inter-urban_traffic_conditions

It contains data that shows the current traffic conditions for the inter-urban road network.

Centru de monitorizare - Tahometru: mt_operator_traffic_prediction_responses

It contains the responses to previous simulation commands from the Transport Planner.

Senzori trafic - Other Navigation Device: tors.ond-traffic_data

It contains current and predicted travel times for each segment in the road network that are being sent

to another navigation device.

GPS - Driver: td-possible_speed_indication_error

It contains in indication that is being output to the Driver in the Host Vehicle that there is a difference

between the legal or dynamic speed limit, or road information that is being output to the Driver in the

Host Vehicle and that being provided to the Driver from the roadside.

Panou orar autobuze - General Information Provider: tesp.gip-request_ps_information



29

It contains a request for information, such as location, opening times, services available, prices, etc.,

about Points of Interest , e.g. doctors, chemists, etc. in a specific locality.

Panou orar autobuze - Traveller: tt-requested_travel_information

It contains the requested travel information that is being output to the Traveller.

Transport Planner - Tahometru: ftp-run_traffic_prediction_creation

It contains an instruction from the Transport Planner for a traffic simulation to be run. Weather Systems - VMS: fws-weather_conditions_for_ISA

It contains the current weather conditions for the geographic area served by the System for use in

determining the recommended speed for ISA.

8. ARHITECTURA DE COMUNICAȚII

8.1.

DefinitiiArhitectura de comunicaţii defineşte şi descrie mijloacele prin care se realizează schimbul

de informaţii între diverse părţi ale sistemului. Schimbul de informaţii este realizat prin transferulfluxurilor de date fizice descrise în arhitectura fizică. Problemele care trebuie rezolvate pentru definirea unei arhitecturi de comunicaţii funcţionalesunt, în principiu, următoarele: • Asigurarea unor canale de transmisie care să poată transmite cantitatea de date necesare, pe distanţa necesară. • Certitudinea că informaţia transmisă este descifrată corect la capătul de recepţie.

Prima problemă necesită o analiză care să conducă la definirea şi descrierea legăturilor de

comunicaţii între principalele interfeţe ale sistemului. A doua problemă implică necesitateautilizării unor protocoale standard de transmisie.

În cazul sistemului integrat de management al traficului interurban, trebuie asigurate

legăturile de date între subsisteme, precum şi între acestea şi terminalele sistemului. Problematransferului de date între modulele unui subsistem nu va fi tratată explicit, întrucât este vorba deentităţi aflate în aceeaşi locaţie, între care comunicaţiile se realizează intern sau clasic, pe fir. În consecinţă, o legătură de comunicaţii din cadrul arhitecturii de comunicaţii a sistemului estedefinită ca fiind mijlocul de transport al fluxurilor fizice de date dintre două subsisteme sau dintreun su bsistem şi un terminal.

La capetele fiecărei legături de comunicaţii se află transmiţătorul (expeditorul), respectivreceptorul (destinatarul) fluxului de date fizice respectiv. O legătură de comunicaţii poatetransfera date între unul sau mai multe emiţătoare şi unul sau mai multe receptoare. Pentru stabilirea tipurilor de comunicaţii ce vor fi utilizate pentru sistemul integrat demanagement al traficului interurban se va ţine cont de cerinţele de comunicaţii pentru transmisiilede date necesare, care vor fi analizate în subcapitolul următor. Prin definirea acestora şi



30

cunoaşterea fluxurilor de date fizice ce trebuie transferate între entităţile sistemului, se defineşte,de fapt, arhitectura de comunicaţii a sistemului.

Cerinţe de comunicaţii pentru sistemul de management al traficului interurban

În cazul sistemului integrat de management al traficului interurban studiat se vor analiza două

tipuri de comunicaţii: • Comunicaţii interne: fluxurile de comunicaţii între subsisteme

• Comunicaţii externe: fluxurile de comunicaţii între subsisteme şi terminale. Fiecare dintre cele două categorii trebuie analizate în funcţie de locaţiile emiţătorului şireceptorului, de distanţa între acestea, de tipul de date ce trebuie transmise, intervalul la caretrebuie transmise etc.

Comunicaţii interne

Sistemul de management al traficului interurban este un sistem ierarhic, cu trei nivele:

• Un subsistem central de management al traficului interurban, care colectează informaţiilegate de trafic, de starea sistemului, incidente, urgenţe etc., asigurând legătura cu subsistemele procesare locală din teren. • Mai multe subsisteme de procesare locală, amplasate în teren, care pot să aibă o legăturăde comunicaţii directă cu subsistemul central sau pot fi conectate între ele, creând o reţea.Subsistemele procesare locală colectează informaţiile la nivel zonal. Informaţiile respective pot fifolosite pentru stabilirea planurilor de semaforizare locală, în cazul recepţionării unei cereri de prioritate locală, sau transmise către subsistemul central. De la acest subsistem primesc

comenzile pe care trebuie să le transmită echipamentelor din teren. • Mai multe subsisteme infrastructură locală, amplasate în teren, fiecare dintre ele fiind

conectate la câte un subsistem de procesare locală, şi care asigură transmiterea informaţiei şiindicaţiilor de circulaţie către conducătorii de vehicule.

Telecomunicațiile sunt unele dintre tehnologiile cu cele mai rapidă dezvoltari in ziua deastăzi. Principalul imbold pentru dezvoltarea tehnologiilor este cererea tot mai mare pentru

servicii mai multe și mai calitative de către clienți. Autoritatile statului cu dereglementarea șideschiderea național a piețele de telecomunicații cunosc acest lucru. Aceasta a dus la o

concurență cu rezultatul că noile evoluții au avut loc atât în utilizarea de noi produse hardware cat

și tehnologii.

Ca urmare a acestor schimbări , implementări ITS se confruntă cu noi echipamente de

telecomunicații și noi standarde de telecomunicații cu o viteză tot mai mare . Cel mai bun

exemplu pentru această situație poate fi vazut in piata de telefoanie mobila . Starea de azi a

echipamentelor de telefoane mobile va fi depășita într -un timp scurt . Și fiecare nouă familie detelefoane mobile arată schimbări în interfețele , atât electrice și mecanice . Astfel, modificări ale

aplicatiilor ITS (care folosesc de exemplu GSM), trebuie să se facă in functie de îmbunătățirea

produsului de catre producatorii de telefoane mobile .



31

Acest document oferă o scurtă prezentare a standardelor de telecomunicații utilizate în prezent și menționează prezenta unor standarde viitoare , eventual, în curs de dezvoltare .

8.2. Lista de tehnologii folosite in ITS

1) Tehnologii WIRELESS

a) Comunicatii pe raza scurta

Pentru utilizarea în ITS există mai multe tehnologii de comunicare rază scurtă de acțiunedisponibile. Ele pot fi utilizate pentru comunicatia vehicul-vehicul (de exemplu Bluetooth), sau

pentru transmiterea de informații de la echipamente la marginea drumului la mașinile care trec pe

langa balize, așa cum este folosit în transportul public sau in sistemele de taxare.

1. Microunde

2. Infrarosu (IR)

3. Wireless LAN

4. Bluetooth

5. Dedicated Short Range Communication (DSRC)

6. Digital Enhanced Cordless Telecommunication (DECT)

b) Comunicatii de raza lunga

Pentru multe aplicații telematice, comunicarea pe distanțe lungi este esențială. Acesteaplicații au cerințe diferite, de exemplu, în ceea ce privește rata de transfer de date, securitatea

datelor, capacitatea de a percepe conținutul sau disponibilitatile speciale și temporale aleserviciului. O altă cerință ar putea fi capacitatea de a aborda grupurile speciale de utilizatori.

GSM de exemplu permite abordarea utilizatorilor individuali, dar de asemenea si un grup deutilizatori, de exemplu, toți utilizatorii într -o anumită celulă a rețelei. Transmisiunile radio FM

permite să se abordeze o gamă largă de utilizatori, dar nu a trimite un mesaj la un singur terminal

sau un anumit grup de terminale. Prin urmare tehnologia de comunicatie trebuie să fie atentselectata prin intermediul cerințelor aplicației telematice.

Comunicatii de raza lunga:

1. Sistemul global pentru comunicatii mobile (GSM)

2. 3G

3. TETRA/TETRAPOL

4. Comunicatii prin satelit

c) Difuziune1. Radio

2. Televiziune

d) Pozitionare

1. GPS - Global Positioning System

2. Sistemul European



34

Legătura de date cu restul structurii podului și stocarea acestora se va face in data-center,

în care servere de capacitate foarte mare vor colecta informațiile.

o Centru local de colectare a taxei

Pentru colectarea taxei de pod vor exista bariere unde conducătorul vehicului va achitataxa în numerar. De asemenea vor exista și kiosk -ul pentru plata automată a taxei. Dacă se achită plata prin kiosk automat, călătorul va primi un card de acces pe pod. Comunicarea se va facecontactless cu o stație de barieră automată plasată pe o bandă specială, conducătorul putând sa-șicontinue călătoria imediat după verificarea plății, fără a mai aștepta în rând cu celelalte vehicule pentru plata la fața locului.

o

Stație pentru cântărire în miscarePentru cântărirea vehiculelor aflate în miscare se vor folosi benzi piezoelectrice. O soluție

este propusă de firma Benui Electric Company. Banda asigură o precizie de cântărire de 1% pentru viteze de sub 10 km/h, de aceea banda se va plasa la intrarea pe pod.



10. CONCLUZII

Dacă se va realiza în viitor, podul ce va lega continentele Europa și Africa va avea nevoiede un sistem ITS de dirijare și supraveghere a traficului, deoarece situația politică, geografică șitehnologică fac din pod un obiectiv strategic de importanță majoră. Este necesar deci să se eviteaccidentele și incidentele de orice fel care pot apărea, să se realizeze un trafic în siguranță șirapid. În viitor va fi posibil ca mașinile să se conducă singure la viteze mari, iar sistemul ITS proiectat va oferi suport pentru desfășurarea acestei activități, utilizând tehnologii specifice.

Arhitectura cadru europeană FRAME asigură ghidarea necesară pentru realizarea uneiarhitecturi ITS care poate fi apoi integrată ușor cu sistemele în continuă dezvoltare din spațiuleuropean.

Sisteme de Semnalizare Rutiera

Documents

Transcript of Sisteme de Semnalizare Rutiera