C-7-8.Arhitectura Sistemelor In Format Ice Specifice Organizatiilor Ce a Activitati

8/9/2019 C-7-8.Arhitectura Sistemelor In Format Ice Specifice Organizatiilor Ce a Activitati

1/47

Arhitectura sistemelor informatice specifice

organizaiilor ce desf

oar

activit

i n domeniul

transporturilor.

Arhitectura ITS la nivel naional

1. Cerine utilizator2. Tipuri de arhitecturi ITS

2.1. Arhitectura funcional

2.2. Arhitectura logic2.3. Arhitectura fizic

2.4. Arhitectura organizaional

2.5. Arhitectura de comunicaie2.6. Arhitectura de referin

3. Arhitectura ITS la nivel naional


2/47

1. Cerine utilizator Primul pas n elaborarea arhitecturii sistemelor informatice

este selectarea i acordarea de prioriti serviciilor utilizator.

n procesul de dezvoltare a arhitecturii specifice organizaiilor

ce desfoar activiti n domeniul transporturilor (ITS) trebuies fie implicai, pe baz de consens, toi utilizatorii, furnizorii deservicii, utilizatorii de servicii i alte grupuri de ageni economiciint ceea ce este foarte important pentru dezvoltarea ioperarea cu succes pe termen lung a sistemelor de tip ITS.

Consensul este orientat spre determinarea cerinelorfuncionale i specificarea unui concept de operare, care

descrie cine furnizeazi cine primete un anumitserviciu/anumite servicii ITS, precum i relaiile sauinteraciunile dintre furnizori, n scopul sprijinirii livrriiserviciului.


3/47

Este probabil ca, la nivel de ar sau regiune, s existe

diferenentre modurile de stabilire ale serviciilorITS. Existgrupri de ageni economici int n jurul unui anumit domeniusau pe zone de competene i responsabiliti.

Fiecare grup de interese are propriile sale obiective politice,care sunt legate de obiectivele mai generale de mbuntire asiguranei, eficienei, calitii mediului i altele.

Urmrind principiul prezentat n figura 1: Politica de selectare aserviciilorITS", fiecare grup de interese analizeaz propriileobiective politice i definete serviciul/serviciile ITS care sprijin

obiectivele politice definite.


4/47

Fig. 1. Politica de selectare a serviciilorITS


5/47

Operatorii unei reele de drumuri pot aborda aspecte referitoarela controlul fluxului pe rampa de acces n scopul meninerii

unui flux de trafic calm n reea. Un efect secundar poate fiproducerea de cozi lungi de vehicule pe drumurilenconjurtoare i pe ramp.

Dac acest efect se produce, se iau msuri care s asigure creeaua de drumuri nconjurtoare nu se va bloca avndprioritate vehiculele destinate transportului public i cele cu ungrad mare de ncrcare care ateapt s intre pe ramp.

Prin negocieri i ajungere la un consens, pot fi dezvoltate ncomun un set de servicii ITS bazate pe cerinele funcionalecorespunztoare, n cadrul unui proces de grup. Deoarececonducerile i reprezentanii grupurilor de ageni economiciint urmresc obiective politice cnd selecteaz serviciiutilizator oferite de ITS, ca un prim pasn dezvoltareaarhitecturii de sistem, arhitectura reprezint o expresie tehnic

a politicilor de transport.


6/47

Figura 2 - Schia unei arhitecturi ITS" prezint graficinteraciunile la nivel nalt dintre trei centre de management i

poliie, pentru oferirea unui management al transportuluimultimodal i a serviciilorde urgen. Figura reliefeaz necesitatea de a se avea n vedere att

sistemele organizaiilor de sine stttoare, ct i interopera-

bilitatea multiorganizaional. Aceste tipuri de diagrame pot fiutilizate pentru a se descrie scopul i natura fiecrei interfeeindicate.

Soluia de operare este clar din punct de vedere intuitiv, dar

nu ofer detalii privind serviciile ITS specifice care trebuiefurnizate, responsabilitile, organizaiilor implicate iinformaiile care trebuie furnizate utilizatorilor finali precum intre organizaii.

Din momentul n care au fost alese serviciile ITS, soluia deoperare poate fi specificat n cel mai mic detaliu, lund nconsiderare responsabilitile privind furnizarea acestor servicii.


7/47

Fig. 2. Schia unei arhitecturi ITS


8/47

2. Tipuri de arhitecturi ITS

Arhitectura ITS reunete elemente izolate i discrete de

cunotine astfel nct s creeze un model i s identificerelaiile i diferenele reprezentnd o baz pentru aciunileurmtoare de realizare a ITS.

Arhitectura ITS exprim un sistem n mai multe moduri datoritdiferitelorviziuni asupra acestuia.

Tipurile de arhitecturi prin care sunt exprimate aceste viziunidiferite sunt prezentate n continuare.


9/47

2.1. Arhitectura funcional

O arhitectur funcional definete i descriefuncionalitile ce trebuie incluse ntr-un sistem astfel nct sfie satisfcute cerinele utilizatorilor.

La cel mai nalt nivel de prezentare al unei arhitecturifuncionale aceasta este format dintr-un numr de domeniifuncionale.

Fiecare domeniu este identificat printr-un nume i un numr.

Funcionalitatea fiecrui domeniu este prezentatprin funcii.

Exist dou tipuri de funcii i anume:

- Funcii de nivel nalt;

- Funcii de nivel inferior


10/47

- Funcii de nivel nalt Funciile de nivel nalt sunt funcii foarte complexe. Pentru ca

funcionalitatea lor s fie neleas mai uor, aceste funcii suntdivizate n funcii de nivel inferior.

Unele dintre acestea pot fi la rndul lor funcii de nivel naltavnd un oarecare grad de complexitate sau funcii de nivelinferior, aa cum se prezint n continuare.

Descrierea funciei de nivel nalt const dintr-o descrieregeneral i o list cu funciile componente.

Funciile de nivel nalt rareori satisfac direct necesitileutilizatorilor prin ele nsele, dar ntotdeauna satisfac acestenecesiti prin intermediul funciilor de nivel inferior ce le

compun.


11/47

- Funcii de nivel inferior

Funciile de nivel inferiorsunt funcii a cror funcionalitate

poate fi descris fr a fi necesar o subdivizare n funcii denivel inferior.

In consecin, ele reprezint, n fiecare domeniu, nivelul inferioral funcionalitii.

Descrierea funciei conine o descriere general, fluxul

informaional i cerinele funcionale detaliate. Acestea dinurm furnizeaz detalii referitoare la ce fac efectiv acestefuncii.

La fel ca i domeniile funcionale, fiecare funcie are propriulnume. Acest nume este o expresie a ceea ce face i conine unverb"n denumire. Astfel, o funcie cu numele administreazvehiculele de urgen" va oferi acea funcionalitate ce permite

managementul operrii vehiculelor de urgen.


12/47

Domeniile funcionale sau funciile de nivel nalt pot include

depozite de date (baze de date). Ele sunt folosite pentru apstra datele utilizate de mai multe funcii de nivel nalt dintr-undomeniu sau de funciile de nivel inferior dintr-o funcie de nivelnalt. Depozitele de dateau un nume i sunt numerotate.

Fiecare depozit de dateva avea facilitile de managementcorespunztoare ca de exemplu controlul citirii/scrierii, creareajurnalelor, salvarea de siguran (back-up) etc. Aceste faciliti

trebuie totodat s acopere toate necesitile de comunicaie,mai ales dac depozitul de date este folosit de funcii pe carearhitectura fizic le-a plasat n alt loc.

In multe cazuri, fluxurile de date care cer ca datele s fiefurnizate de depozitele de date (bazele de date) sau careconfirm c datele au fost scrise n depozitul de date, nu suntvizibile, dei se presupune c aceste fluxuri existi suntfolosite.


13/47

nlnuirea funciilor se face prin intermediul fluxurilor de date.Acestea permit transmiterea datelor de la o funcie la alta.

Terminalul reprezint interfaa dintre arhitectura i mediulexterior asigurnd fluxul de date de la mediu exterior spre

arhitectura sistemului i de la aceasta ctre mediu exterior.

Un terminal poate fi o entitate uman, un sistem sau oentitate fizic de la care pot fi obinute date, cum ar fi stareavremii sau starea drumului. Att entitile umane ct isistemele pot face parte din organizaii sau autoriti publice cecontribuie, ntr-un anumit mod, la furnizarea serviciilorITS.


14/47

Pentru simplificarea unordiagrame de fluxuri de date (DFD -Data Flow Diagrams), relaia ntre dou funcii poate fi

reprezentat printr-un singur flux de date.

Diagramele de fluxuri de date prezint modul n carefuncionalitatea fiecrui domeniu este divizat n funcii de nivel

nalt i funcii de nivel inferior.

Totodat, ele arat cum sunt legate, prin intermediul fluxurilorde date, aceste funcii unele cu altele i la terminale.

Cnd sunt folosite de mai multe funcii, depozitele de date sunti ele prezentate mpreun cu fluxurile de date care le leag la

funcii.


15/47

2.2. Arhitectura logic

Arhitectura logic prezint procesele i fluxul informaional

dintre procese. In dezvoltarea arhitecturii logice sunt examinateaspectele comune din cerinele funcionale ale diferitelorservicii utilizator, astfel nct cerinele comune pot fi grupate nacelai set de procese.

In figura 3: O arhitectur logic naional ITS", este prezentatca exemplu o arhitectur logic de nivel nalt.

Sgeile indicdireciile fluxuluide date care sunt necesarepentru a efectua serviciile selectate.

Cercurile reprezintgrupuri de procese care sunt prezentatemult mai detaliat pe nivelurile inferioare ale arhitecturii logice.Pe nivelurile cele mai de jos, cercurile descriu prelucrarea dedate i algoritmul necesare pentru detectarea automat a

incidentelor.


16/47

Fig. 3. O arhitectur logic naional ITS


17/47

In arhitectura logic grupurile de procese prezentate princercuri nu implic nici o alocare a responsabilitilor

organizaionale, dar ele indic faptul c funcia specificattrebuie s fie efectuati s interacioneze cu alte funcii.

Rolul important al arhitecturii logice este s descrie modul ncare sistemul trateaz anomaliile.

Pentru sigurantrebuie avute n vedere toate tipurile dedeficiene i trebuie descrii paii logici privind apariia uneidegradri n condiiile n care apar anomalii respectnd soluiadefinit pentru operarea sistemului.


18/47

2.3. Arhitectura fizic Arhitectura fizic, orientat pe proiectarea sistemului,

distribuie procesele definite de arhitectura logic n subsistemefizice, pe baza specificaiilor proceselor funcionale i a loculuiunde trebuie efectuate funciile.

Arhitectura fizic distribuie procesele n subsisteme fizice,lund n considerare responsabilitile instituionale. O schemde nivel nalt a unei arhitecturi fizice naionale este prezentat

n figura 4: O arhitectur fizic naional ITS".

Fiecare ar sau regiune trebuie s stabileasc propriile sale

necesiti i cerine utilizator n momentul nceperii elaborriiunei arhitecturi ITS naionale sau regionale. Anumite cerinelocale pot diferi de la o ar sau regiune la alta.


19/47

Fig. 4. O arhitectura fizic naional ITS


20/47

O arhitectur fizic definete i descrie modul n carecomponentele arhitecturii funcionale pot fi grupate, pentru aforma entiti fizice. Principalele caracteristici ale acestorentiti sunt, n primul rnd, faptul c ele furnizeaz unul saumai multe dintre serviciile ce sunt cerute de ctre necesitileutilizatorilor iar, n al doilea rnd, faptul c ele pot fi create.

Acest proces de creare poate implica entiti fizice, cum ar fistructuri amplasate pe drum i diferite forme de echipamente,entiti care nu sunt fizice, cum ar fi software, sau combinaiiale celor dou. In arhitectura fizicITS 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 sarcinidefinite i poate fi oferit ca un produs comercial. Fiecaresubsistem poate fi compus din una sau mai multe pri alearhitecturii funcionale (funcii i depozite de date) i poatecomunica cu alte subsisteme i cu unul sau mai multeterminale. Aceste comunicaii pot fi furnizate prin folosirea

fluxurilor fizice de date.


21/47

Numrul de subsisteme dintr-un anumit sistemetalon" depinde de aria geografic ce trebuie

acoperit.

Posibilele localizri ale subsistemelor sunt

urmtoarele:

- Postul central

- Drumul- Vehiculul

- Dispozitivul personal

- Dispozitivul pentru marf- Chiocul de informare


22/47

- Postul central

Postul central reprezintpunctul (nodul) folosit pentru

localizarea unor pri ale sistemului pentru colectarea,asamblarea i administrarea stocrii datelor de trafic, pliitaxelor, comenzilor pentru transportul de marfa i/sau pentrugenerarea msurilor pentru managementul traficului sau a

instruciunilor de management al parcului de vehicule, cu saufr intervenia omului; exemple: TCC (Traffic Control Centre -Centrul de control al traficului), TIC (Traffic Information Centre -Centrul de informare privind traficul) sau centrul de

management al parcului de maini i al transportului de mrfuri.

- Drumul

Drumul reprezint locul folosit pentru localizarea unorcomponente ale sistemului pentru detectarea traficului,vehiculelor sau pietonilor sau pentru colectarea taxelori/saugenerarea msurilor de management al traficului i/saufurnizarea de informaii i comenzi ctre conductori i/sau

pietoni.


23/47

- Vehiculul

Vehiculul reprezintmijlocul de transport care este capabil

s se deplaseze pe reeaua de transport i s transporte unasau mai multe persoane (de exemplu: biciclete, motociclete,automobile, vehicule pentru transport public) i/sau mrfuri(de exemplu: camionete, camioane i alte forme de vehicule ce

pot transporta mrfuri pe drum).- Dispozitivul personal

Dispozitivul personal este un dispozitiv n care poate fiinstalat o component a sistemului, astfel nct s poat fi

uor de folosit (i posibil de crat) de ctre cltori, ca unobiect personal.

- Dispozitivul pentru marf

Dispozitivul pentru marfa reprezint un dispozitiv n carepoate fi instalat o component a sistemului i care este parteintegrant a unitii de transport marfa, de exemplu: containerulde marfa, trailerul sau corpul vehiculului.


24/47

- Chiocul de informare

Chiocul de informare reprezint un echipament amplasat, nmod uzual, n locuri publice, n care poate fi instalat o parte asistemului, pentru a permite cltorilor un acces limitat icontrolat la facilitile sistemului.

Aceste localizri trebuie privite generic. Ele au fost alesedeoarece sunt relevante pentru utilizarea efectiv a ITS.Aceasta nseamn c n aceeai localizare se pot afla mai

multe subsisteme.

De exemplu, pot fi mai multe subsisteme ntr-o localizare

central", deoarece subsistemele pot fi n locuri fizice diferite,iar caracteristicile fluxurilor de date dintre ele trebuieevideniate. Oricum un subsistem nu poate s acopere dousau mai multe localizri generice diferite.


25/47

Un subsistem poate fi mpritn dou sau mai multe module.Fiecare modul va avea exact aceleai proprieti ca unsubsistem i va avea propria sa identitate fizic.

Principala diferen dintre module i subsisteme o constituiefaptul c fiecare modul este proiectat s conin ofuncionalitate de la o singur arie a arhitecturii funcionale.

Un alt motiv pentru utilizarea moduleloreste creareacomponentelor fizice ce conin o grupare de funcionaliticorelate logic.

Modulele comunic unele cu altele (fie n cadrul aceluiaisubsistem, fie cu module din subsisteme diferite) folosind fluxurifizice de date.


26/47

Fluxurile fizice de date furnizeaz legturile de comunicaii ninteriorul fiecrui sistem etalon". Ele permit ca datele s fietransmise ntre subsisteme, ntre module, ntre subsisteme imodule, precum i la/de la terminale.

Ele pot avea n componen unul sau mai multe fluxurifuncionale de date. Fluxurile de date referitoare la terminal

asigur legturile subsistemelor respectiv modulelor cu lumeaexterioar care este reprezentat de ctre terminale.

Tipurile de entiti care compun o arhitectur fizic sunt

mprite n dou grupe i anume: componentele arhitecturiifuncionale i terminalele. Componentele arhitecturii funcionalesunt funciile, depozitele de date i fluxurile de date.

Terminalele arhitecturii fizice pot fi aceleai ca cele alearhitecturii funcionale. Deoarece arhitectura fizic este derivatdin arhitectura funcional, ea trebuie s conin, de asemenea,interfeele cu respectivele terminale. Ca urmare terminalelearhitecturii fizice trebuie s aib aceleai funcionaliti" i, prin

urmare, aceleai definiii cu cele ale arhitecturii funcionale.


27/47

2.4. Arhitectura organizaional

Responsabilitatea pentru implementarea sistemelorITS trebuies fie mprit ntre diferite organizaii i ntre diferitedepartamente de management din cadrul acestor organizaii, nfuncie de scopuri i cerine.

Arhitecturile logice i fizice trebuie s fie transpuse ntr-oarhitectur organizational care este relevant pentru nivelullocal. Arhitectura organizational este utilizat pentrudezvoltarea i explicarea responsabilitilori a

interaciunilor funcionale dintre organizaii publice, privatesau parteneriate public/privat.

Arhitectura organizational este dezvoltat prin asignarea

entitilor locale din arhitectura logic unui modelorganizaional.

Un model organizaional poate evidenia dimensiunile

geografice, financiare sau alte dimensiuni.


28/47

2.5. Arhitectura de comunicaie O arhitectur de comunicaie definete i descrie mijloacele

care asigur schimbul de informaii dintre diferitele pri alesistemului.

Acest schimb de informaii este realizat folosind fluxurile fizicede date descrise n arhitectura fizic.

Arhitectura de comunicaie definete i descrie mijloaceleprin care sunt realizate fluxurile fizice de date pentru uneledintre sistemele etalon" din arhitectura fizicITS.

Descrierea i definirea acestor mijloace de realizare a fluxurilorfizice de date implicdou elemente complementare.

Primul element este asigurarea mijloacelorce permit cadatele s fie transferate de la un punct la altul i sigurana cmodul n care aceste date sunt transferate este corespunztorpentru sistem n ceea ce privete costul, alterarea informaiei i

ntrzierea ei.


29/47


30/47

Descrierea acestor necesiti tipice de comunicaii este primaint a arhitecturii de comunicaie.

Tehnologiile de comunicaie se schimb ntr-un ritm att derapid nct nu este posibil oferirea unei arhitecturi bazate pe

tehnologie care s fie valabil pe termen lung. Totui,descrierea generic a fluxurilor fizice de date tipice rmnevalabil atta timp ct imaginea celor mai reprezentativesisteme etalon" nu se schimb prea mult.

Din acest motiv, aceasta va furniza o baz solid pentruanalizarea elementelor legate de telecomunicaii n sistemeleITSn general.

Al d l i d i i t d i f t i


31/47

Alegerea modului de comunicaie este deseori fcut prinprocese complexe i dup diferite etape de analiz. De fapt,

alegerea modului de comunicaie are, de cele mai multe ori, unmare impact asupra sistemului i asupra eficienei acestuia.

In proiectarea unei arhitecturi de comunicaie trebuie avute n

vedere cteva probleme importante:

Primul aspect este satisfacerea necesitilor sistemului ntromsur ct mai mare.

Al doilea aspect este includerea efectiv a soluiei decomunicaie considerate ntr-un sistem existent. Intrebrilece se pun sunt:

cum s se integreze soluiile de comunicaie ntr-un cadru existent decomunicaie;

cum s se obin evoluia acestui cadru existent sau cum s fie elnlocuit.

I l i ti t i t t fi l l l t


32/47

In acelai timp, este important s fie alese acele elemente cermn viabile timp ndelungat. Aceasta nseamn s existe

sigurana c soluia aleas poate fi capabil s se dezvolteodat cu evoluia sistemului, c va putea sprijini schimbrilecare apari c poate fi schimbat cu uurin cu o alt soluie,atunci cnd va deveni depit.

- Al treilea aspect, la fel de important, l constituieproblema costurilor. Costurile sunt legate n principal deachiziia 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 dinpunct de vedere al materialelori serviciilor, ci i din punct de

vedere al personalului implicat n toate aceste faze. Acestaspect este, de asemenea, foarte strns legat de alegerileprivind implementarea.

Standarde referitoare la comunicaie sunt folosite de sistemele


33/47

Standarde referitoare la comunicaie sunt folosite de sistemelede tip ITS. Recent, a avut loc o cretere explozivn utilizareacomunicaiilori 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 estesigur folosirea unei infrastructuri proprii (private).

Dac se dorete utilizarea unorreele de comunicaii dejaexistente (ca de exemplu, folosirea n comun a liniilor detelecomunicaii) atunci trebuie utilizate standarde stabilite dealii.

Folosirea reelelor de comunicaii existente poate fi priviti cao economie, deoarece i scutete pe proprietarii de sisteme detip ITS i/sau pe operatorii ITS de sarcina de a furniza intreine reele proprii.

Cteodat, aceste economii pot fi semnificative, deoarece

ncrcarea canalului de comunicaie (limea benzii) impus detraficul de date ITS este mai mic dect cea impus de aliutilizatori. Condiia este, aa cum a fost menionat mai sus, caITS s foloseascstandardele elaborate de ctre cei ce

folosesc limile cele mai mari de band.

2 6 A hi d f i


34/47

2.6. Arhitectura de referin

Arhitectura de referin a sistemului de control i informare ntransporturi este o arhitectur orientat pe obiect pentrusistemele de tip ITS, dezvoltat de Organizaia Internaional

de Standardizare - Comitetul tehnic 204 (ISO TC 204) pentruutilizare la nivel internaional.

Arhitectura de referinTICS (Transport Information andControl 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 (ComiteeEuropeen de Normalisation - Comitetul European deStandardizare) i DRIVE n Europa.

Obiectivul este facilitarea dezvoltrii armonioase i


35/47

Obiectivul este facilitarea dezvoltrii armonioase iinteroperabile, la nivel internaional, a ITS prin intermediul uneiarhitecturi de referin comune. Deoarece aceast arhitectur

este o arhitectur de referin de baz ea nu poate fi utilizat lanivel de detaliu atunci cnd se face referire la documentele deintrare.

Ea nu intenioneaz s nlocuiasc arhitecturile regionale, cimai curnd s promoveze, la nivel internaional, armonizareaeforturilor care se depun privind arhitectura i standardizarea.

Arhitectura de referin este compatibil cu arhitecturileregionale existente dezvoltate cu metodologii alternative.

Arhitectura de referinTICS este un model al sistemului

informatic i al relaiilor sale care sprijin managementul iexecutarea resurselor de transport rutier ntr-un mediu integrat.Ea furnizeaz grupului de lucru, din cadrul comitetului tehnic204, un cadru de referin uniform astfel nct acesta sdezvolte standarde de tehnologie a informaiei pentru domeniul

transporturilor.

A fost aleas o abordare orientat pe obiect bazat pe


36/47

A fost aleas o abordare orientat pe obiectbazat petendinele actuale ale tehnologiei informaiei.

Arhitectura de referinTICS este exprimat utilizndmodelarea vizual pentru sisteme orientate pe obiect i bazatepe componente specificate n limbajul unificat de modelare(UML - Unified Modelling Language).

In cadrul contextului descrierii grafice UML, figura 5: Caz deutilizare la nivel nalt a arhitecturii de referinTICS" prezint odiagram Caz de utilizare" de nivel nalt a arhitecturii de

referinTICS.

Diagrama Caz de utilizare" descrie graniele arhitecturii, ageniieconomici externi i serviciile furnizate.


37/47

Fig. 5. Caz de utilizare la nivel nalt a arhitecturii de referin TICS

3 Arhitectura ITS la nivel naional


38/47

3. Arhitectura ITS la nivel naional

Scopul central al realizrii cu succes a unui ITS la nivelnaional este stabilirea unei arhitecturi ITS unificate. Dacarhitectura este proiectat cu minuiozitate, ea va asiguradezvoltarea unui sistem compatibil la nivel naional, care sconecteze toate modurile de transport.

Arhitecturancurajeaz realizarea de standarde naionale,pentru a promova cltoriile ntre orae i micarea mrfurilorla nivel naional, mpiedicnd n acelai timp zonele locale sau

regionale s dezvolte implementri ITS incompatibile.

Arhitectura naionalITS permite agenilor economici int sadopte elemente ITSntr-o manieri ntr-un cadru de timp

ales de ei, permind ca aceste elemente s fie livrate de maimuli furnizori i servind ca baz pentru standarde care potreduce eforturile depuse de grupurile de ageni economici int,pot accelera procesul de introducere a produselori serviciilorITS i pot reduce riscurile ntmpinate de sectorul privat ndezvoltarea acestor produse i servicii.

Recunoscnd necesitatea unui program ITS orientat spre


39/47

Recunoscnd necesitatea unui program ITS orientat sprearhitecturi de sistem", Departamentul Aprrii al Statelor Unite(USDOT - United States Department of Transportation) a ini

iat

un program naional pentru dezvoltarea unei arhitecturi ITS(National ITS Architecture Development Program).

USDOT a selectat echipele care s elaboreze arhitecturialternative, pe baz de contract, pentru un orizont de planificarentins pe o durat de 20 de ani (1992 - 2012).

Prima faz a nceput n septembrie 1993 cu patru echipeconduse de Hughes Aircraft, IBM-Loral, Rockwell Internationali Westinghouse Electric aflate n competiie pentru elaborareacelei mai bune arhitecturi.

Faza a Il-a a nceput n februarie 1995 cu dou echipeselectate, Loral i Rockwell International care au lucratmpreun pentru a mbina i a perfeciona arhitecturile lor n

scopul elaborrii unui standard naional.

Arhitectura ITS naional furnizeaz o structur comun


40/47

Arhitectura ITS naional furnizeaz o structur comunpentru proiectarea sistemelor de tip ITS.

Ea definete cadruln care se pot dezvolta diferitele moduri deabordare ale proiectrii sistemelor ITS, fiecare dintre acesteafiind croit pentru rezolvarea necesitilor regionale specifice,

meninnd n acelai timp beneficiile unei arhitecturi comune ncadrul sistemelor actuale i cele planificate.

Arhitectura ITS naionaldefinete funciile (de exemplu,

controlul semnalelorde trafic, managementul autostrzilorsau managementul incidentelor) ce trebuie s fie ndeplinitede ctre componente sau subsisteme, locul n care se gsescaceste funcii (de exemplu, la marginea drumului, n centrul de

management al traficului sau n vehicul), interfeele i fluxurilede informaii dintre subsisteme, precum i cerinele decomunicaii pentru fluxurile de informaii (de exemplu,comunicaii prin cablu sau radio).

Exist beneficii specifice ce pot fi obinute, n comunitatea


41/47

p p ,transporturilor, printr-o aplicare informat a metodologieiarhitecturii ITS naionale, a bazei de cunotine i a

instrumentelor, astfel:

1) Arhitectura ITS naional poate aduce beneficii petermen scurt - economisirea de timp i bani n dezvoltarea

unui proiect, de la faza de concepere pn la implementareaacestuia, deoarece:

- furnizeaz un punct de pornire pentru dezvoltarea

cerinelor funcionale i a specificaiilor sistemului;

- realizeaz corelaia ntre necesiti i probleme pentruserviciile ce trebuie s fie efectuate, prin aceasta asigurnd,

pentru un proiect, posibilitatea de urmrire a necesitilorgenerale de transport;

- furnizeaz o perspectiv pentru identificarea serviciilori


42/47

p p p 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 deacum, ca o anticipare a necesitilor viitoare (de exemplu, sepoate planifica, pentru un furnizor de informaii, distribuireainformaiilor de trafic sau de alt tip la diveri abonai);

- ilustreaz eficiena ce poate fi ctigat prin eliminareaimplementrilor redundante de funcii similare;

- ofer o list extins a organizaiilor de transport (prinrealizarea 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 timpulplanificrii iniiale a unei implementri;

- definete tipul de informaii ce trebuie partajate de aceste


43/47

p p jorganizaii. Organizaia poate folosi aceste informaii ca o listde verificare n planificarea proiectului i n discuiile cucelelalte grupuri int, pentru a arta cum pot participa acesteala partajarea informaiilor;

- reprezint un bun punct de plecare sau model pentrudezvoltarea arhitecturii care va direciona proiectarea unuianumit proiect. Pornind de la arhitectura ITS naional se potnltura funciile i fluxurile de informaii ce nu sunt potrivite i

apoi se pot include modificri sau suplimentri, pentrusatisfacerea cerinelori consideraiilor specifice locale;

- identific interfeele i schimburile de date ce trebuie s

fie incluse (de exemplu schimburi de date ntre subsistemele demanagement al traficului i cele amplasate de-a lunguldrumului);


44/47

- ajut la reducerea necesitii unor schimbri 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 lacalcularea costurilor iniiale ale proiectului;

- furnizeaz o verificare a produsului de ctre contractorulproiectrii (dac contractorului i se cere s demonstrezefolosirea arhitecturii naionale ITS i relaia dintre aceasta i

proiectarea oferit).

2) Utilizarea arhitecturii ITS naionale i standardelorITS


45/47

va furniza, de asemenea, mari beneficii pe termen lung.Acestea vor aduce un ctig att la nivel naional, ct iregional i anume:

a) Interoperabilitate

Arhitectura ITS naionalspecific standardele care suntnecesare pentru asigurarea interoperabilitii i componentelecrora li se adreseaz; de regul aceste componente sunt detip interfantre componente de tipul prelucrare, memorare

date, comunicare, mediu extern. Soluiile inovatoare utilizate n definirea arhitecturii pot contribuila dezvoltarea standardelor existente suport pentru asigurareainteroperabilitii ntre componente sau ntre sisteme.

Utilizarea interfeelor standard va asigura, la nivel naional iregional, interoperabilitatea i interschimbabilitatea sistemelori dispozitivelor utilizate n managementul cltoriilor prinintermediul sistemelorITS.

b) Competiie mai bun


46/47

b) Competiie mai bun

Prin solicitarea utilizrii de standarde deschise, se va putea

rspunde cerinelor arhitecturii de ctre mai mulivnztori/furnizori care respect standardele.

Totodat, pot fi obinute sprijin i actualizri din mai multesurse, evitndu-se problema blocrii la o singur surs,implicnd creterea competiiei.

c) Posibilitatea de extindere viitoare

Prin proiectarea ntr-un cadru comun i utilizarea unorstandarde deschise, se poate crea un mediu care integreaz

sistemele ITS vechi cu sistemele ITS noi i se permiteadugarea unor funcii noi, atunci cnd acest lucru este doritsau este necesar.

d) Costuri mai mici


47/47

Costurile pe termen lung ale dezvoltrii se vor diminua prineconomiile tcute datorit echipamentului i produselorITSgata fabricate i a competiiei dintre mai muli furnizori.

e) Integrare mai bun ntr-un sistem de transport

Natura deschis i structura arhitecturii naionale ITS i

utilizarea unor componente care s respecte standardele vorfacilita integrarea componentelor complexe alemanagementului traficului cu componentele altor sisteme de tipITS.

O integrare mai bun a sistemelor proprii diverselororganizaii va permite o partajare efectiv a informaiei i outilizare mai eficient a resurselor.

C-7-8.Arhitectura Sistemelor In Format Ice Specifice Organizatiilor Ce a Activitati

Documents

Transcript of C-7-8.Arhitectura Sistemelor In Format Ice Specifice Organizatiilor Ce a Activitati