Arhitecturi ITS

Arhitectura ITS specific schimbul de informaii i managementul controlului pe

diferite niveluri, aa cum este prezentat n modelul multinivel din figura Model multinivel al
arhitecturii ITS (CONVERGE 1998). Exist mai multe modaliti de definire a acestor
niveluri. Managerii din domeniul transporturilor au nevoie de mai multe informaii privind
arhitectura sistemului referitoare la nivelurile superioare (nivelurile 2 i 3), care sunt orientate
spre organizarea sistemului. Nivelurile inferioare sunt orientate spre proiectarea i ingineria
detaliat a sistemului.
Reea de organizaii
(Proprieti de
interoperabilitate)

Nivelul 3

Nivelul 2

O organizaie
(Proprietile sistemului)

Nivelul 1

Structura sistemului
(Subsistemele sistemului)

Nivelul 0

Structura sistemului
(Componentele subsistemului)

Figura 1 Model multinivel al arhitecturii ITS

Nivelul 3 al arhitecturii trebuie s reflecte constrngerile din lumea real care opereaz asupra
organizaiilor

de

transport

cerinele

privind

proprietile

sistemului,

pecum

interoperabilitatea dintre organizaia implicat i mediu totodat i controlul informaiei

furnizate de organizaia respectiv. Aceasta mai poate evidenia locul i momentul cnd trebuie
modificate sau schimbate structurile organizaionale existente n scopul furnizrii de servicii
ITS. Nivelul 3 al arhitecturii stabilete cadrul de lucru pentru nivelul 2 al arhitecturii ITS.

Nivelul 2 al arhitecturii ITS prezint proprietile sistemelor care opereaz ntr-o

singur organizaie i ia n considerare caracteristicile existente i viitoare ale sistemului.
Structurile existente privind responsabilitaile n cadrul organizaiei i sistemele ITS care
funcioneaz pe baza acestora pot fi obiectul unor modificri considerabile n timp.
Nivelul 1 al arhitecturii ITS este orientat, n primul rnd, spre proiectarea sistemului. La
acest nivel, este definit structura sistemului, funciile ITS sunt grupate pentru implementare i
sistemul informaional este descompus logic n subsisteme n scopul de a fi proiectate la
nivelul 0. Sunt alese tehnologii specifice care vor fi indicate doar la nivelul 0. Nivelurile 1-3
ale arhitecturii ITS sunt independente de tehnologie fiind relativ stabile n raport cu
modificrile tehnologice.

2.1

Cerine utilizator

Primul pas n elaborarea arhitecturii ITS este selectarea i acordarea de prioriti

serviciilor utilizator. n procesul de dezvoltare a arhitecturii trebuie s fie implicai, pe baz de
consens toi utilizatorii, furnizorii de servicii, utilizatorii de servicii i alte grupuri de ageni
economici int ceea ce este foarte important pentru dezvoltarea i operarea cu succes pe
termen lung a sistemelor de tip ITS.
Consensul este orientat spre determinarea cerinelor funcionale i specificarea unui
concept de operare, care descrie cine furnizeaz i cine primete un anumit serviciu/anumite
servicii ITS, precum i relaiile sau interaciunile dintre furnizori, n scopul sprijinirii livrrii
serviciului.
Fiecare grup de interese are propriile sale obiective politice, care sunt legate de
obiectivele mai generale de mbuntire a siguranei, eficienei, calitii mediului i altele.
Urmrind principiul prezentat n figura Politica de selecare a serviciilor ITS, fiecare grup de
interese analizeaz propriile obiective politice i definete serviciul/ serviciile ITS care sprijin
obiectivele politice definite.
Operatorii unei reele de drumuri pot aborda aspecte referitoare la controlul fluxului pe
rampa de acces n scopul meninerii unui flux de trafic calm n reea. Un efect secundar poate fi
producerea de cozi lungi de vehicule pe drumurile nconjurtoare i pe ramp. Dac acest efect
se produce, se iau msuri care s asigure c reeaua de drumuri nconjurtoare nu se va bloca

avnd prioritate vehiculele destinate transportului public i cele cu un grad mare de ncrcare
care ateapt s intre pe ramp.
Scopurile politice
(Siguran, eficien, mediu etc.)

Serviciile care susin politica

Serviciile din cadrul domeniului propriu

Servicii utilizator
(furnizate total sau parial n cadrul domeniului propriu)

Servicii utilizator comune selectate

Figura 2 Politica de selectare a serviciilor ITS

Gar
Conducerile executive ale diferitelor organizaii
implicate n dezvoltarea i utilizarea
Gar

ITS trebuie s
contientizeze
activitile care vor avea loc n sistem, ce roluri
se ateapt s
Autobuze
Transbordare
ntre
Autobuze

Transbordare ntre

trenuri
trenuri trebuie s aib loc pentru ca s fie livrate serviciile ITS. O soluie de
joace i ce interaciuni
Centrudede unei arhitecturi ITS prezint grafic
operare poate prezenta aceste relaii. Figura Centru
Schia

interaciunile la nivel nalt dintre trei centre

managemen
managemen
t al
t al
de management
tranzitului
tranzitului

i poliie, pentru oferirea unui

management al transportului multimodal i a serviciilor de urgen. Figura reliefeaz

necesitatea de a se avea n vedere att sistemele organizaiilor de sine stttoare (nivelul 2), ct
i interoperabilitatea multiorganizaional (nivelul 3). Aceste tipuri de diagrame pot fi utilizate
pentru a se descrie scopul i natura fiecrei interfee indicate.
Vehicule
Vehiculededeurgen
urgen

Poliie
Poliie

Semnale
Semnale

Centru
Centrudede
managemen
managemen
t al
t al
traficului
traficului

Detectare
Detectare

CCTV
CCTV

HAR
HAR

Centru
Centrudede
managemen
managemen
t al
t al
urgenelor
urgenelor

Figura 3. Schia unei arhitecturi ITS

VMS
VMS

3
Legend

CCTV
HAR
VMS

Televiziune cu circuit nchis (Closed Circuit Television)

Informaii radio pentru autostrzi (Highway Advisory Radio)
Panou cu mesaje variabile (Variable Message Sign)

Din momentul n care au fost alese serviciile ITS, soluia de operare poate fi specificat n cel
mai mic detaliu, lund n considerare responsabilitile privind furnizarea acestor servicii.
Figura Relaii conceptuale pentru furnizarea de servicii de ctre ITS prezint
legturile dintre entitile aflate n interaciune. Sunt evideniate dou sisteme avansate de
management al traficului, unul pentru autostrzi i altul pentru zona urban. Aceast schem
specific existena unor centre de informare n transport care s transmit informaii privind
transportul multimodal ctre utilizatorii finali prin intermediul a doi furnizori de servicii de
informare (ISP 1 i ISP2). Aceti furnizori de servicii de informare aparin probabil sectorului
privat i pot furniza utilizatorilor finali informaii pentru cltori, informaii meteorologice,
rezervri de bilete i alte servicii.
ATMS

ISP 1
TIC

ATMS

ISP 2

APTS
CVO

EMS
Legend

ATMS
APTS
CVO
EMS
ISP
TIC

Sistem avansat de management al traficului (Advanced Traffic Management System)

Sistem avansat pentru transportul public (Advanced Public Transport System)
Sistem pentru operarea vehiculelor comerciale (Commercial Vehicle Operation)
Sistem de management al urgenelor (Emergecy Management System)
Furnizor de servicii de informare (Information Service Provider)
Centru de informare n transport (Transport Information Centre)

Figura 4. Relaii conceptuale pentru furnizarea de servicii de ctre ITS

2.2

Tipuri de arhitecturi ITS

Arhitectura ITS reunete elementele izolate i discrete de cunotine astfel nct s

creeze un model i s identifice relaiile i diferenele reprezentnd o baz pentru aciunile
urmtoare de realizare a ITS.1

Figura 5. Arhitectura ITS din perspectiva serviciilor i legturilor dintre componente

2.2.1 Arhitectura funcional

La cel mai nalt nivel de prezentare al unei arhitecturi funcionale aceasta este format
dintr-un numr de domenii funcionale. Fiecare domeniu este identificat printr-un nume i un
1

http://www.iteris.com/itsarch/html/menu/hypertext.htm

numr. Funcionalitatea fiecrui domeniu este prezentat prin funcii. Exist dou tipuri de
funcii i anume:

Funcii de nivel nalt

Pentru o nelegere mai uoar a funcionalitii acestor funcii, acestea sunt divizate n
funcii de nivel inferior. Unele dintre acestea pot fi la rndul lor funcii de nivel nalt avnd un
oarecare grad de complexitate sau funcii de nivel inferior propriu-zise, aa cum se prezint n
continuare. Funciile de nivel nalt rareori satisfac direct necesitile utilizatorilor prin ele
nsele, dar ntotdeauna satisfac aceste necesiti prin intermediul funciilor de nivel inferior ce
le compun.

Funcii de nivel inferior

La fel ca i domeniile funcionale, fiecare funcie are propriul nume. Acest nume este o
expresie a ceea ce face i conine un verb n denumire. Astfel, o funcie cu numele
administreaz vehiculele de urgen va oferi acea funcionalitate ce permite managementul
operrii vehiculelor de urgen.
Domeniile funcionale sau funciile de nivel nalt pot incude depozite de date (baze de
date). Ele sunt folosite pentru a pastra datele utilizate de mai multe funcii de nivel nalt dintrun domeniu sau de funciile de nivel inferior dintr-o funcie de nivel nalt.
Fiecare depozit de date va avea facilitile de management corespunztoare ca de
exemplu controlul citirii/scrierii, crearea jurnalelor, salvarea de siguran etc. Aceste faciliti
trebuie totodat s acopere toate necesitile de comunicaie, mai ales dac depozitul de date
este folosit de funcii pe care arhitectura fizic le-a plasat n alt loc. n multe cazuri, fluxurile
de date care cer ca datele s fie furnizate de depozitele de date sau care confirm c datele au
fost scrise n baza de date, nu sunt vizibile, dei se presupune c aceste fluxuri exist i sunt
folosite.
nlnuirea funciilor se face prin intermediul fluxurilor de date. Acestea permit
transmiterea datelor de la o funcie la alta, la sau de la depozitele de date, la sau de la
terminale. Terminalul reprezint interfaa dintre arhitectur i mediul exterior asigurnd fluxul
de date de la mediul exterior spre arhitectura sistemului i de la aceasta ctre mediul exterior.
Un terminal poate fi o entitate uman, un sistem sau o entitate fizic de la care pot fi obinute
date, cum ar fi starea vremii sau starea drumului. Att entitile umane ct i sistemele pot face

parte din organizaii sau autoriti publice ce contribuie, ntr-un anumit mod, la furnizarea
serviciilor ITS.

2.2.2 Arhitectura logic

Arhitectura logic face parte din domeniul nivelului 1 reprezentat n figura Model
multinivel al arhitecturii ITS. Arhitectura logic prezint procesele i fluxul informaional
dintre procese. n dezvoltarea arhitecturii logice sunt examinate aspectele comune din cerinele
funcionale ale diferitelor servicii utilizator, astfel nct cerinele comune pot fi grupate n
acelai set de procese.
n figura O arhitectur logic naional ITS, este prezentat ca exemplu o arhitectur
logic de nivel nalt. Sgeile indic direciile fluxului de date care sunt necesare pentru a
efectua serviciile selectate. Cercurile reprezint grupuri de procese care sunt prezentate mult
mai detaliat pe nivelurile inferioare ale arhitecturii logice. Pe nivelurile cele mai de jos,
cercurile descriu prelucrarea de date i algoritmul necesare pentru detectarea automat a
incidentelor.
n arhitectura logic grupurile de procese prezentate prin cercuri nu implic nici o
alocare a responsabilitilor organizaionale, dar ele indic faptul c funcia specificat
trebuie s fie efectuat i s interacioneze cu alte funcii. Rolul important al arhitecturii
logice este s descrie modul n care sistemul trateaz anomaliile. Pentru siguran
trebuie avute n vedere toate tipurile de deficiene i trebuie descrii paii logici privind
apariia unei degradri n condiiile n care apar anomalii respectnd soluia definit
pentru operarea sistemului.

Conductori
Conductoridede
vehicule
vehiculeiicltori
cltori

Cereri de plat

Plat
electronic

Cereri
informaii de
planificare

Rspuns la urgene

Asisten
pentru
conductorii
vehiculelor i
pentru cltori

Managementul
urgenelor

Anunarea urgenelor

Plat
Instituii
Instituii
financiare
financiare

Planificarea
tranzitului

Cerere de rut
Informaii de rut
Managementu
l vehiculelor
comerciale

Vehicul
Vehicul
comercial
comercial

Tranzit
Tranzit

Monitorizarea
i controlul
vehiculului

Vehicul
Vehicul

Informaii
de trafic

Starea
vehiculului

Cereri de
tranzit
Managementu
l tranzitului

Telecomunicaii
Telecomunicaiidedeurgen
urgen

Informaii
despre rut

Informaii
de urgen

Informaii de
planificare

Informaii de
planificare

Informaii
referitoare la
incidente
Cereri de
prioritate

Managementu
l traficului

Informaii de
control al
traficului

Anunarea
incidentului
Informaii
de trafic

Planificarea,
dezvoltarea i
implementarea
sistemului de
planificare

Planuri
Planuridedetransport
transport

Informaii de
planificare
Trafic
Trafic

Figura 6. O arhitectur logic naional ITS

2.2.3 Arhitectura fizic

Arhitectura fizic, orientat pe proiectarea sistemului, distribuie procesele definite de
arhitectura logic a subsitemelor fizice, pe baza specificaiilor proceselor funcionale i a
locului unde trebuie efectuate funciile. Arhitectura fizic distribuie procesele n subsisteme
fizice, lund n considerare responsabilitile instituionale. O schem de nivel nalt a unei
arhitecturi fizice naionale este prezentat n figura O arhitectur fizic naional ITS.
Interfeele dintre cele patru subsisteme ale arhitecturii fizice sunt indicate n figur.
Fluxul de date dintre subsisteme se efectueaz prin intermediul celor trei tipuri de mijloace de
comunicare.
Fiecare ar sau regiune trebuie s stabileasc propriile sale necesiti i cerine
utilizator n momentul nceperii elaborrii unei arhitecturi ITS naionale sau regionale.
Anumite cerine locale pot diferi de la o ar la alta.
O arhitectur fizic definete i descrie modul n care componentele arhitecturii
funcionale pot fi grupate, pentru a forma entiti fizice. Principalele caracteristici ale acestor
entiti sunt, n primul rnd, faptul c ele furnizeaz unul sau mai multe dintre serviciile ce sunt
cerute de ctre necesitile utilizatorilor iar, n al doilea rnd, faptul c ele pot fi create. Acest
proces de creare poate implica entiti fizice, cum ar fi structuri amplasate pe drum i diferite
forme de echipamente, entiti care nu sunt fizice, cum ar fi software-ul, sau combinaii ale
celor dou. n arhitectura fizic ITS aceste entiti fizice sunt numite sisteme etalon.
Toate sistemele etalon pot fi compuse din dou sau mai multe subsisteme. Un
subsistem execut una sau mai multe sarcini definite i poate fi oferit ca un produs comercial.
Fiecare subsistem poate fi compus din una sau mai multe pri ale arhitecturii funcionale
(funcii i depozite de date) i poate comunica cu alte subsisteme i cu unul sau mai multe
terminale. Aceste comunicaii pot fi furnizate prin folosirea fluxurilor fizice de date.

Acces la informaii
personale

Comunicaii prin Internet

Comunicaii fr fir

Vehicul

Autostrad
Colectarea taxelor

Comercial
Urgen

Subsistemele vehiculului

Comu
nicaii
fr
fir
Pe
arie
redus

Comu
nicaii
de la
vehicu
l la
vehicu
l

Tranzit

10

Managementul parcrilor
Controlul vehiculelor comerciale

Subsistemele referitoare la drum

Furnizor de servicii de informaii

Managementul emisiilor

Administrarea taxelor

Managementul urgenelor

Administrarea vehiculelor comerciale

Managementul mrfii i a flotei

Planificare

Suport pentru
informarea de la
distan a
cltorilor

Managementul tranzitului

Subsistemele centrului de management

Managementul traficului

Subsistemele cu acces de la distan

Figura 7. O arhitectur fizic naional ITS

2.2.4 Arhitectura organizaional

Responsabilitatea pentru implementarea sistemelor ITS trebuie s fie mprit ntre diferite organizaii i ntre diferite
departamente de management din cadrul acestor organizaii, n funcie de scopuri i cerine. Arhitecturile logice i fizice trebuie s fie
transpuse ntr-o arhitectur organizaional care este relevant pentru nivelul local. Arhitectura organizaional este utilizat pentru
dezvoltarea i explicarea responsabilitilor i a interaciunilor funcionale dintre organizaii publice, private sau parteneriate
public/privat. Arhitectura organizaional este dezvoltat prin asigurarea entitilor locale din arhitectura logic a unui model
organizaional.
Modelul de referin european GERDIEN (date generale referitoare la drumurile europene i reeaua de schimb a informaiilor)
este un model organizaional care subliniaz dimensiunea grafic, artnd unde este furnizat efectiv un serviciu ITS. Impactul dintre
componentele organizaionale este prezentat prin legturi.
Figura Un model geografic ierarhic, care conine modelul de referin GERDIEN, reprezint nivelurile domeniilor
geografice. Intenia este de a se indica cu claritate zona de aciune pentru fiecare funcie sau serviciu ITS, din punct de vedere al
nivelului geografic. Din momentul n care acest lucru este clar trebuie s reias limpede cum este necesar s interacioneze dou
sisteme de management. n exemplul dat n figura Un model geografic ierarhic, dou sisteme vecine de management al autostrzii
au conexiuni la nivelul superior pentru dirijarea traficului pe distane mari; la nivelul inferior urmtor, dou regiuni nvecinate
colaboreaz pentru dirijarea traficului vizitatorilor dintr-o regiune care particip la evenimente care au loc n cealalt regiune. Din
momentul n care au fost luate decizii la acest nivel, aceste decizii pot fi transformate n comenzi n interiorul fiecrei regiuni,
influennd nivelurile lor inferioare corespunztoare, ceea ce nu necesit comunicaii directe ntre ele.
Modelul organizaional prezentat n figura de mai jos poate fi extins pentru a include relaii conceptuale, sistemul de
management al traficului urban (UTMS Urban Traffic Management System) i sistemul de management al urgenelor.

11

ar / Stat

ar / Stat

Regiune

Trafic pe
distane lungi

Regiune

District

Trafic in caz de
evenimente
speciale

District

Magistral

Magistral

Legtur

Legtur

Seciune

Seciune

Punct

Punct

ATMS pentru autostrad

ATMS pentru autostrad

Stratul A
Autostrad
Figura 8. Un model geografic ierarhic
ATMS
Stratul B
Autostrad
2
n figura Un model organizaional pentru ITS , sunt reprezentate patru sisteme de management sub form de turnuri, cu
ATMS
NAIUNE

interaciunile asociate. Modelul organizaional orientat geografic prezint localizarea, mrimea impactului i interaciunile dintre
EMS
Ora
NAIUNE
REGIUNE
organizaii pe
nivelurile geografice
specifice.
UTMS
REGIUNE
REEA
NAIUNE
REGIUNE
REEA
SECIUNE
REGIUNE
REEA
SECIUNE
PUNCT
REEA
SECIUNE
Modelul de referin
PUNCT
SECIUNE
2
PUNCT Departamentul transporturilor din Olanda GERDIEN
sursa: Rijkswaterstaat
PUNCT
Legend

UTMS
ATMS
EMS

Sistem de management al traficului urban (Urban Traffic Management System)

Sistem avansat de management al traficului (Advanced Traffic Management System)
12
Sistem de management al urgenelor (Emergecy Management System)

Figura 9. Un model organizaional pentru ITS

2.2.5 Arhitectura de comunicaie

O arhitectur de comunicaie definete i descrie mijloacele care asigur schimbul de informaii dintre diferitele pri ale
sistemului. Acest schimb de informaii este realizat folosind fluxurile fizice de date descrise n arhitectura fizic. Arhitectura de
comunicaie definete i descrie mijloacele prin care sunt realizate fluxurile fizice de date pentru unele dintre sistemele etalon din
arhitectura fizic ITS.
Descrierea i definirea acestor mijloace de realizare a fluxurilor fizice de date implic dou elemente complementare. Primul
element este asigurarea mijloacelor ce permit ca datele s fie transferate de la un punct la altul i sigurana c modul n care aceste date
sunt transferate este corespunztor pentru sistem n ceea ce privete costul, alterarea informaiei i ntrzierea ei. Cu alte cuvinte,
problema este descrierea i definirea canalelor de informaii ce sunt necesare pentru transferul informaiilor. Al doilea element este
obinerea siguranei c informaia transmis de la un capt al canalului de informaii este interpretat fr erori la cellalt capt, de
recepie, al canalului.

13

Arhitectura de comunicaii trebuie s rmn, pe ct este posibil, independent de tehnologie. Pentru realizarea acestui
obiectiv, metodologia propus n cele ce urmeaz este caracterizarea i analizarea fluxurilor fizice de date ale celor mai reprezentative
sisteme etalon din arhitectura fizic ITS, pentru a fi satisfcute cele mai reprezentative necesiti de comunicaie ale diferitelor
interfee ale sistemului.
Descrierea acestor necesiti tipice de comunicaii este prima int a arhitecturii de comunicaie. Tehnologiile de comunicaie
se schimb ntr-un ritm att de rapid nct nu este posibil oferirea unei arhitecturi bazate pe tehnologie care s fie valabil pe termen
lung. Alegerea modului de comunicaie este deseori fcut prin procese complexe i dup diferite etape de analiz. De fapt, alegerea
modului de comunicaie are, de cele mai multe ori, un mare impact asupra sistemului i asupra eficienei acestuia. n proiectarea unei
arhitecturi de comunicaie trebuie avute n vedere cteva probleme importante.
Primul aspect este satisfacerea necesitilor sistemului ntr-o msur ct mai mare.
Al doilea aspect este includerea efectiv a soluiei de comunicaie considerate ntr-un sistem existent. ntrebrile ce se pun
sunt:

Cum s se integreze soluiile de comunicaie ntr-un cadru existent de comunicaie?

Cum s se obin evoluia acestui cadru existent sau cum s fie el nlocuit?

Un ultim aspect, la fel de important, l constituie problema costurilor. Costurile sunt legate de achiziia soluiei, de migrarea de
la o soluie veche la una nou, de punerea n practic a soluiei i de nlocuirea soluiei. Aceste costuri trebuie s fie avute n vedere nu
numai din punct de vedere al materialelor i serviciilor, ci i din punct de vedere al personalului implicat n toate aceste faze. Acest
aspect este, de asemenea, foarte strns legat de alegerile privind implementarea.
Standarde referitoare la comunicaie sunt folosite de sistemele de tip ITS. Recent, a avut loc o cretere exploziv n utilizarea
comunicaiilor i n alte sectoare, de exemplu n comerul electronic. Sistemele de tip ITS nu trebuie s-i mai dezvolte propriile
standarde de comunicaie, cu excepia cazurilor n care este sigur folosirea unei infrastructuri proprii (private). Dac se dorete

14

utilizarea unor reele de comunicaii deja existente (ca de exemplu, folosirea n comun a liniilor de telecomunicaii) atunci trebuie
utilizate standarde stabilite de alii.
Folosirea reelelor de comunicaii existente poate fi privit i ca o economie, deoarece scutete pe proprietarii de sisteme de
tip ITS i/sau pe operatorii ITS de sarcina de a furniza i ntreine reele proprii. Cteodat, aceste economii pot fi semnificative,
deoarece ncrcarea canalului de comunicaie (limea benzii) impus de date traficului ITS este mai mic dect cea impus de ali
utilizatori. Condiia este, aa cum a fost menionat mai sus, ca ITS s foloseasc standardele elaborate de ctre cei ce folosesc limile
cele mai mari de band.

2.2.6 Arhitectura de referin

Arhitectura de referin a sistemului de control i informare n transporturi este o arhitectur orientat pe obiect pentru
sistemele de tip ITS, dezvoltat de Organizaia Internaional de Standardizare Comitetul tehnic 204 (ISO TC 204) pentru utilizare la
nivel internaional. n momentul n care grupul de lucru a iniiat acest proiect, mai multe ri dezvoltaser deja arhitecturi ITS, ceea ce
poate conduce la standarde i implementri incompatibile.
Arhitectura de referin TICS (Transport Information and Control System Sistem de control i informare n transporturi) a
ISO se bazeaz pe intrri de la toate arhitecturile regionale, n special arhitectura naional a Statelor Unite (US National
Architecture), marele proiect japonez (Japanese Grand Design) i arhitecturi elaborate n cadrul proiectelor CEN (Comitee Europeen
de Normalisation Comitetul European de Standardizare) i DRIVE n Europa.
Obiectivul este facilitarea dezvoltrii armonioase i interoperabile, la nivel internaional, a ITS prin intermediul unei arhitecturi
de referin comune. Deoarece aceast arhitectur este o arhitectur de referin de baz ea nu poate fi utilizat la nivel de detaliu
atunci cnd se face referire la documentele de intrare, cum poate fi utilizat arhitectura naional a Statelor Unite. Ea nu intenioneaz
s nlocuiasc arhitecturile regionale, ci mai curnd s promoveze, la nivel internaional armonizarea eforturilor care se depun privind

15

arhitectura i standardizarea. Arhitectura de referin este compatibil cu arhitecturile regionale existente dezvoltate cu metodologii
alternative.
Arhitectura de referin TICS este un model al sistemului informatic i al relaiilor sale care sprijin managementul i
executarea resurselor de transport rutier ntr-un mediu integrat. Ea furnizeaz grupului de lucru, din cadrul Comitetului Tehnic 204, un
cadru de referin uniform astfel nct acesta s dezvolte standarde de tehnologie a informaiei pentru domeniul transporturilor. A fost
aleas o abordare orientat pe obiect bazat pe tendinele actuale ale tehnologiei informaiei. Arhitectura de referin TICS este
exprimat utiliznd modelarea vizual pentru sisteme orientate pe obiect i bazate pe componentele specificate n limbajul unificat de
modelare (UML Unified Modelling Language).
n cadrul contextului descrierii grafice UML, figura Caz de utilizare la nivel nalt a arhitecturii de referin TICS prezint o
diagram Caz de utilizare de nivel nalt al arhitecturii de referin TICS. Diagrama Caz de utilizare descrie graniele arhitecturii,
agenii economici externi i serviciile furnizate.

Operarea
vehiculului
Vehicul

Managementul
traficului

Siguran

Utilizator

Financiar

Plat
electronic

Operator

Organizaie
de
conformitate

Marf i
flot

Informarea
cltorilor

Transport
public

Urgene

16
Figura 10. Caz de utilizare la nivel nalt a arhitecturii de referin TICS

Infrastructura

Furnizor de
servicii

Furnizor de
informaii

Sursa datelor
de localizare

17

2.2.7 Arhitectura ITS la nivelul naional

Scopul central al realizrii cu succes a unui ITS la nivel naional este stabilirea
unei arhitecturi ITS unificate. Dac arhitectura este proiectat cu minuiozitate, ea va
asigura dezvoltarea unui sistem compatibil la nivel naional, care s conecteze toate
modurile de transport. Arhitectura ncurajeaz realizarea de standarde naionale, pentru a
promova cltoriile ntre orae i micarea mrfurilor la nivel naional, mpiedicnd n
acelai timp zonele locale sau regionale s dezvolte implementri ITS incompatibile.
Arhitectura naional ITS permite agenilor economici int s adopte elemente ITS ntr-o
manier i ntr-un cadru de timp ales de ei, permind ca aceste elemente s fie livrate de
mai muli furnizori i servind ca baz pentru standarde care pot reduce eforturile depuse
de grupurile de ageni economici int ce pot accelera procesul de introducere a
produselor i serviciilor ITS i pot reduce riscurile ntmpinate de sectorul privat n
dezvoltarea acestor produse i servicii.
Recunoscnd necesitatea unui program ITS orientat spre arhitecturi de sistem,
Departamentul Aprrii al Statelor Unite (USDOT United States Departament of
Transportation) a iniiat un program naional pentru dezvoltarea unei arhitecturi ITS
(National ITS Architecture Development Program). USDOT a selectat echipele care s
elaboreze arhitecturi alternative, pe baz de contract, pentru un orizont de planificare
ntins pe o durat de 20 de ani (1992 - 2012). Prima faz a nceput n septembrie 1993 cu
patru echipe conduse de Hughes Aircraft, IBM-Loral, Rockwell International i
Westinghouse Electric aflate n competiie pentru elaborarea celei mai bune arhitecturi.
Faza a II-a a nceput n februarie 1995 cu dou echipe selectate, Loral i Rockwell
International care au lucrat mpreun pentru a mbina i a perfeciona arhitecturile lor n
scopul elaborrii unui standard naional.
Baza arhitecturii ITS o reprezint setul de 32 servicii utilizator. Serviciile
utilizator reprezint un spectru larg de servicii, incluznd sisteme avansate pentru
vehicule, managementul transportului i servicii de plat electronic. Obiectivul
programului naional pentru dezvoltarea unei arhitecturi ITS este unificarea i
organizarea serviciilor utilizator i promovarea standardelor care asigur aceeai
funcionare a sistemului n ntreaga ar.

18

Arhitectura ITS naional furnizeaz o structur comun pentru proiectarea

sistemelor de tip ITS. Ea definete cadrul n care se pot dezvolta diferitele moduri de
abordare ale proiectrii sistemelor ITS, fiecare dintre acestea fiind realizat pentru
rezolvarea necesitilor regionale specifice, meninnd n acelai timp beneficiile unei
arhitecturi comune n cadrul sistemelor actuale ct i a celor planificate.
Arhitectura ITS naional definete funciile (de exemplu, controlul semnalelor de
trafic, managementul autostrzilor sau managementul incidentelor) ce trebuie s fie
ndeplinite de ctre componente sau subsisteme, locul n care se gsesc aceste funcii (de
exemplu, la marginea drumului, n centrul de management al traficului sau n vehicul),
interfeele i fluxurile de informaii dintre subsisteme, precum i cerinele de comunicaii
pentru fluxurile de informaii (de exemplu, comunicaii prin cablu sau radio).
Arhitectura ITS naional poate aduce beneficii pe termen scurt economisirea
de timp i bani n dezvoltarea unui proiect, de la faza de concepere pn la implementarea
acestuia, deoarece:

Furnizeaz un punct de pornire pentru dezvoltarea cerinelor funcionale i a

specificaiilor sistemului;

Realizeaz corelaia ntre necesiti i probleme pentru serviciile ce trebuie s

fie efectuate, prin aceasta asigurnd, pentru un proiect, posibilitatea de
urmrire a necesitilor generale de transport;

Furnizeaz o perspectiv pentru identificarea serviciilor i funcionalitilor

care nu au fost luate n considerare iniial, necesare n mod curent i care sunt
posibile. Astfel, se furnizeaz o list a capacitilor viitoare, ce pot fi
planificate de acum, ca o anticipare a necesitilor viitoare (de exemplu, se
poate planifica, pentru un furnizor de informaii, distribuirea informaiilor de
trafic sau de alt tip de diveri abonai);

Ilustreaz eficiena ce poate fi ctigat prin eliminarea implementrilor

redundante de funcii similare;

Ofer o list extins a organizaiilor de transport (prin realizarea corelaiei

dintre funciile pe care le execut acestea, cu numele subsistemelor
corespunztoare din arhitectura ITS naional) cu care ar trebui s discute o
organizaie, n timpul planificrii iniiale a unei implementri;
19

Definete tipul de informaii ce trebuie partajate de aceste organizaii.

Organizaia poate folosi aceste informaii ca o list de verificare n
planificarea proiectului i n discuiile cu celelalte grupuri int, pentru a arta
cum pot participa acestea la partajarea informaiilor;

Reprezint un bun punct de plecare sau model pentru dezvoltarea arhitecturii

care va direciona strategia de desfurare a unui anumit proiect. Pornind de la
arhitectura ITS naional se pot nltura funciile i fluxurile de informaii ce
nu sunt potrivite i apoi se pot include modificri sau suplimentri, pentru
satisfacerea cerinelor i consideraiilor specifice locale;

Identific interfeele i schimburile de date ce trebuie s fie incluse (de

exemplu schimburi de date ntre subsistemele de management al traficului i
cele amplasate de-a lungul drumului);

Ajut la reducerea necesitii unor schimburi costisitoare ntr-o faz trzie a

procesului de proiectare i implementare;

Furnizeaz estimri aproximative ale costurilor pentru un spectru larg de

echipamente i servicii ITS, ce pot fi folosite la calcularea costurilor iniiale
ale proiectului;

Furnizeaz o verificare a produsului de ctre contractorul proiectrii (dac

contractorului i se cere s demonstreze folosirea arhitecturii ITS i relaia
dintre aceasta i proiectarea oferit).

Utilizarea arhitecturii ITS naionale i standardelor ITS va furniza, de asemenea,

mari beneficii pe termen lung. Acestea vor aduce un ctig att la nivel naional, ct i
regional i anume:
Interoperabilitate
Arhitectura ITS naional specific standardele care sunt necesare pentru
asigurarea interoperabilitii i componentele crora li se adreseaz; de regul aceste
componente sunt de tip interfa ntre componente de tipul prelucrare, memorare date,
comunicare, mediu extern.
Soluiile inovatoare utilizate n definirea arhitecturii pot contribui la dezvoltarea
standardelor existente suport pentru asigurarea interoperabilitii ntre componentele sau
ntre sisteme.
20

Utilizarea interfeelor standard va asigura, la nivel naional i regional,

interoperabilitatea i interschimbabilitatea sistemelor i dispozitivelor utilizate n
managementul cltorilor prin intermediul sistemelor ITS.
Competiie mai bun
Prin solicitarea utilizrii de standarde deschise, se va putea rspunde cerinelor
arhitecturii de ctre mai muli vnztori/furnizori care respect standardele. Totodat, pot
fi obinute sprijin i actualizri din mai multe surse, evitndu-se problema blocrii la o
singur surs, implicnd creterea competiiei.
Posibilitatea de extindere viitoare
Prin proiectarea ntr-un cadru comun i utilizarea unor standarde deschise, se
poate crea un mediu care integreaz sistemele ITS vechi cu sistemele ITS noi i se
permite adugarea unor funcii noi, atunci cnd acest lucru este dorit sau este necesar.
Costuri mai mici
Costurile de termen lung ale dezvoltrii se vor diminua prin economiile fcute
datorit echipamentului i produselor ITS gata fabricate i a competiiei dintre mai muli
furnizori.
Integrare mai bun ntr-un sistem de transport
Natura deschis i structura arhitecturii naionale ITS i utilizarea unor
componente care s respecte standardele vor facilita integrarea componentelor complexe
ale managementului traficului cu componentele altor sisteme de tip ITS. O integrare mai
bun a sistemelor proprii diverselor organizaii va permite o partajare efectiv a
informaiei i o utilizare mai eficient a resurselor.

21