INGINERIA SISTEMELOR APLICATA SISTEMELOR INTELIGENTE DE

TRANSPORT
4.1. Introducere n ingineria sistemelor.................................................................115

4.1.1. Sistem si ingineria sistemelor................................................................115

4.1.1.1. Conceptele introductive ale ingineriei sistemelor..........................116
4.1.1.2. Ingineria sistemelor ca notiune complexa.....................................117
4.1.1.3. Dimensiunile multiple ale ingineriei sistemelor..............................118
4.1.2. Modele de proces din ingineria sistemelor............................................118
4.1.2.1. Modelul tip V a ciclului de viata al unui sistem............................119
4.1.2.2. Modelul tip CASCADA ...................................................................121
4.1.2.3. Modelul tip SPIRALA .....................................................................121
4.1.2.4. Modelul EVOLUTIV ca model de dezvoltare tip V.........................122
4.1.2.5. Compararea modelelor de proces.................................................123
4.2. Procesul de planificare...................................................................................123
4.2.1. Procesul de exprimare a viziunii............................................................125
4.2.2. Definirea cerintelor sistemului...............................................................127
4.2.3. Trasabilitatea........................................................................................127
4.3. Procesul de proiectare...................................................................................129
4.3.1. Transpunerea cerintelor n functii..........................................................129
4.3.2. Arhitectura ITS.......................................................................................130
4.3.2.1. Subsistemul calatorilor..................................................................132
4.3.2.2. Subsistemul centrelor...................................................................132
4.3.2.3. Subsistemul vehiculelor................................................................132

114

3. INGINERIA SISTEMELOR APLICATA SISTEMELOR AVANSATE DE

TRANSPORT
3.1. INTRODUCERE N INGINERIA SISTEMELOR
3.1.1. SISTEM S I INGINERIA SISTEMELOR
Un sistem este un ansamblu de elemente aflate n corelatie sau n interactiune.
(conform ISO/DIS 9000: 2000)
Un sistem este un ansamblu integrat, format din unul sau mai multe procese,
hardware, software, facilitati si oameni, care furnizeaza o capabilitate de a satisface o
necesitate specificata sau un obiectiv specificat. (conform ISO/CEI 12207:1995)
Ingineria sistemelor este o abordare interdisciplinara si un mijloc, care permite
realizarea cu succes a sistemelor.
Ingineria sistemelor integreaza toate disciplinele si grupurile de specialisti n efortul de
echipa formnd un proces dezvoltat structural, care porneste de la concept pentru a
ajunge la executie si operare.
Ingineria sistemelor ia n considerare att nevoile de afaceri ct si cele tehnice ale
tuturor participantilor, cu scopul de a furniza calitatea produselor care satisfac nevoile
consumatorilor (utilizatorilor).
Importanta ingineriei sistemelor nu poate fi subliniata suficient. Procentul neobisnuit de
mare al defectiunilor sistemelor bazate pe programe n domeniul tehnologiei informatiei
(IT) se schimba esential cnd proiectele sunt conduse de participanti experimentati.
Nu sunt disponibile nca statistici specifice proiectelor ITS, cunoscut fiind faptul ca
modul de nregistrare a datelor pentru aceste proiecte este mai deficitar dect pentru
oricare alt sistem. Comunitatea ITS ntmpina dificultati similare ceea ce nu ar trebui sa
surprinda, deoarece proiectele ITS:
trebuie sa opereze n timp real, 24 de ore pe zi, sapte zile pe sapta mna ;
implica interfata cu echipamentul provenind de la multi furnizori fa ra beneficiul unor

interfete standardizate;

se bazeaza, n mare parte, pe programe care sunt ele nsele mai putin fiabile;
implica clienti (de obicei agentii publice) cu putina experienta n achizitia tehnologiei

informatiei pe care se bazeaza proiectele.

Cum se poate constata din tabelul 3.1, probabilitatea de succes a proiectelor majore de
transport rutier se mbuna tateste considerabil prin cunostintele individuale experimentate
ale celor care conduc proiectul si participa la implementarea lui.
Tabelul 3.1: Probabilitatea de succes a unui proiect ITS.
Rezultate Clienti
Anulari 40% 35% 1%
ntrzieri 39% 37% 2%
Activitati corecte 21% 28% 97%

experimentati

Tot i participantii
Management cu
au experienta
experienta
(profesionalism)

Fiecare
ntre
aceste
calculator
doua notiuni.
colecteaza
Integrarea
date de trafic
sistemelor
referitoare
se refera
la drumuri
la interconectarea
n sfera autoritatii
sistemelor,
sale.
Integrarea
sistemelor
nu
reprezinta
ingineria
sistemelor,
deci
trebuie
facuta
o
distinctie
astfel
Cnd
Uncele
nct
exemplu
doua
ele sasisteme
relevant
interactioneze
sunt
esteintegrate,
celcorect,
privind
datele
pentru
douade
calculatoare
a realiza
trafic sunt
o functie
distribuite
utilizate
superioara.
n pentru
domenii
a furniza
adiacente.
115

afisarea fluxurilor de trafic din sfera ambelor autoritati. Aceasta este o functie superioara
fata de cea realizata de un sistem individual.
Sistemele interactioneaza corect daca:
transmit datele ca tre toate celelalte sisteme, la intervale regulate sau definite de
timp;
distribuie datele n formate pe care toate celelalte sa le nteleaga;
opereaza cu fiabilitate sporita.
Combinarea a doua sisteme interconectate reprezinta, de asemenea, un sistem.
Principiile ingineriei sistemelor, incluznd modul de proiectare si analiza, se aplica, de
asemenea, sistemelor integrate. Astfel, se obtine o ierarhizare a sistemelor.
3.1.1.1. Conceptele introductive ale ingineriei sistemelor
n ingineria sistemelor, trebuie apreciata diferenta dintre un sistem, un subsistem si o
componenta, figura 3.1.

Figura 3.1. Sistem, subsistem, componenta, model tip piramida.

1. Sistem reprezinta o combinatie de componente care actioneaza mpreuna pentru a

realiza o functie care nu este posibila cu nici una din partile individuale.
2. Subsistem este o grupare de componente, n interiorul sistemului, care realizeaza
o functie identificabila. Un subsistem poate contine mai multe module.
3. Componenta este cea mai mica unitate de baza a sistemului.
Pentru moment, n exemplul anterior fiecare autoritate opereaza cu propriul sistem:
detectorii constituie subsistemul de supraveghere, iar subsistemul de comunicatii consta
din echipamente prin care, se conecteaza calculatorul cu echipamentul extern. n plus,
lund n considerare avantajul datelor combinate ale celor doua sisteme de la autoritatea
regionala, fiecare autoritate opereaza cu un subsistem al sistemului total regional.

Producatorii de automobile, vad automobilul ca un sistem, figura 3.2. Rndul urmator din
aceasta structura - motor, caroserie roti - este alcatuit din subsisteme, iar anvelopa si
butucul rotii sunt componente. Dar, producatorii pot vedea anvelopa si butucul rotii ca
Figurade
3.2.rulare
Automobilul,
ca sistem.
subsistem ce contine multiple elemente (butuc si suprafata
a anvelopei)
ca si
Conceptul sistemelor, subsistemelor si componentelor poate fi descris
ca o ierarhie.
componente.
116

Similar, n cazul specialistilor ITS, trebuie considerat automobilul ca un subsistem al

sistemului de transport, care trebuie sa cuprinda autovehiculul, conduca torul si drumul.
Astfel, este foarte important sa se acorde atentie notiunilor de sistem si subsistem.

3.1.1.2. Ingineria sistemelor ca notiune complexa

n aplicatiile de nceput, inginerii erau concentrati asupra performantelor si ignorau
multi factori importanti, cum ar fi factorul uman, problematica sociala si economica, mediul
de afaceri, asociate cu proiectarea si implementarea sistemului. Aceasta situatie s-a
dovedit a fi nesatisfacatoare.
Un sistem, orict de simplu, trebuie sa ia n considerare usurinta de utilizare, siguranta,
costul de fabricatie, stil, etc. Multe sisteme sunt att de extinse si de complexe, nct unei
singure persoane i va fi imposibil sa nteleaga n detaliu toti acesti factori.

Figura 3.3. Ingineria sistemelor tehnice complexe.

n principal, procesele din ingineria sistemelor trebuie sa ia n considerare urmatorii

factori:
Consideratii tehnice procesul trebuie sa se supuna legilor naturale si capacitatile
de performanta ale componentelor si subsistemelor folosite. Consideratiile includ
ntelegerea aspectelor tehnice ale cerintelor sistemului, specificatiile si
constrngerile.
Aspecte economice si valorice ingineria sistemelor trebuie sa aleaga ntre
alternative bazate pe proiectare, nu numai din punct de vedere tehnic ci, si de cost
si valori relative.
Consideratii industriale si politice rezultatele proiectarii trebuie sa raspunda
nevoilor clientilor, n mod obisnuit definiti ca organizatii care platesc pentru crearea
sistemului.
Tabelul 3.2. Optimizarea sistemului de management al traficului.
Aspecte de
optimizare Detectori cu bucla inductiva Detectori radar
Tehnice Masurarea volumului, vitezei si
gradului de ocupare. Masurarea vitezei.
Instalarea ntrerupe traficul
Economice
Instalare usoara fara blocarea
Instalarea perechilor de detectori
de circulatie pentru
detectarea
si valorice cea mai precisa metoda
benzilor
de trafic.
furnizeaza
Industriale
(volume)
si pentru ingineria si
incidentelor si afisarea pe
de colectare a datelor.
comerciale
planificarea transporturilor.
Furnizeaza nregistrari de
date
Furnizeaza
internet.
117
date despre viteze

Optimizarea sistemului clasic de management al traficului poate fi realizata printr-o

comparatie ntre monitorizarea traficului, prin folosirea unor detectori bucla inductiva sau a
detectorilor radar.

Comparatia ntre consideratiile tehnice, economice si industrial/politice sunt prezentate

n tabelul 3.2.
3.1.1.3. Dimensiunile multiple ale ingineriei sistemelor
Aprecierea caracteristicilor multi-dimensionale este foarte importanta . Toate produsele
considerate n tabelul 3.3, constituie subiectul criteriilor descrise anterior si ele necesita,
pentru a sprijini proiectarea si dezvoltarea lor, un proces bazat pe ingineria sistemelor. n
perioada actuala, inginerii nu mai pot ignora nici unul dintre aceste aspecte, daca vor sa
proiecteze un produs folositor si vandabil.
Tabelul 3.3. Proiectarea diferitelor produse pe baza teoriei ingineriei sistemelor.
Aspecte industriale si
Produs Aspecte tehnice Aspecte economice si
valorice
comerciale
Gama de frecvente.
Marimea unitatilor.
Cost.
Marime.
Tehnologia
semiSistem
Distributia bornelor de
Aspect.
conductorilor.
stereo
iesire.
Particularitati clienti
Control la distanta.
Amortizarea investitiei.
(folosirea echipamentului).
Standardizare.
Viteza.
Aspect.
Periferice.
Calculator
Standardizare.
Performante.
Drumuri

Comercial sau personal.

Cost. Cerinte de spatiu.
Portabilitate.
nvatare
Particularitati client.

Reducere zgomot.
Capacitate.
Costuri de constructie. Amenajari tranzit.
Viteza limita.
Taxat si netaxat.
Generarea traficului.
Tipuri de vehicule.
Mediu.

Capacitatea pasageri.
Putere.
Optiuni.
Automobile
Capacitate
de ncarcare
Tractiune fata/ tractiune
spate.

Pret de cumparare.
Costuri de mentenanta.

Particularitati client.
Culoare.
Stil.
Distributie.
Siguranta.

Proiectarea drumurilor, inclusa n tabelul 3.3, este probabil cea mai veche forma de
inginerie a sistemelor datorita procesului extins de planificare si de proiectare cerut. n
continuare este prezentata o reprezentare a modului n care se aplica ingineria sistemelor
procesului de proiectare. Pentru o ntelegere mai usoara, procesul este mpartit n patru
faze: planificarea, proiectarea preliminara, proiectarea detaliata si planificarea
operationala .
3.1.2. MODELE DE PROCES DIN INGINERIA SISTEMELOR
Modelul tip V este cea mai folosita reprezentare a proceselor din ingineria sistemelor,
aplicata sistemelor avansate de transport. Acesta defineste secventele si corelatia dintre
activitatile
realizate
procesului.
secvential.
PasiiAcest
reprezentati
model de
n diagrama
analiza a fost
suntopreponderent
abordare dominanta
executatinntr-o
maniera
Modelul
ingineria
definita
tipsistemelor
de
CASCADA
trei modele
n anii
defineste
posibile
80. ale
procesul
procesului:
liniar n care fazele
118succesive sunt

 Modelul tip SPIRALA , folosit pentru a descrie dezvoltarea iterativa a proiectarii

sistemului.
Modelul tip EVOLUTIV, care poate fi executat ca un proces secvential sau unul n
care, anumite faze, pot fi executate n paralel.
Utilizarea acestor modele depinde de caracteristicile sistemului ce trebuie dezvoltat.
3.1.2.1. Modelul tip V a ciclului de viata al unui sistem
Modelul tip V a fost creat pentru a defini ordinea n care este dezvoltat un sistem
bazat pe o tehnologie informatica (IT). El ncepe cu dezvoltarea conceptului de OPERARE,
are la baza faza de IMPLEMENTARE si ajunge la final n faza de EXPLOATARE SI MENTENANTA
nchiznd astfel prin faza de EVALUARE bucla.

Fiecare faza din partea dreapta a modelului, este echivalenta cu o faza din partea
stnga. Figura 3.4 prezinta cazul modelului V general, iar figura 3.5 cazul modelului V a
ciclului de viata al unui sistem inteligent de transport.

Figura 3.4. Modelul general de tip V al ciclului de viata.

Partea stnga a modelului tip V cuprinde urmatoarele faze:

Conceptul de Operare defineste modul n care va fi utilizat sistemul, n cazul
general, iar pentru arhitectura unui sistem inteligent de transport se identifica cu
nevoile utilizatorilor.
Cerinte definesc ceea ce va face sistemul. Cerintele sunt dezvoltate, n mod
obisnuit, folosind cel putin doua niveluri de detaliere.
Proiectare defineste modul n care, va fi proiectat sistemul, la cele doua niveluri
de detaliere.
Implementarea constructia sistemului.
Partea dreapta a modelului tip V cuprinde:
Integrarea si testarea - asamblare si interconectare
Verificarea subsistemelor si a sistemului n ansamblu privind implementarea
corecta.
procesul de verificare, pentru
a confirma ca rezultatul fiecarei faze succesive este n
conformitate
n cazul arhitecturii
cu rezultatul
unui
Exploatare
fazei
sistem
anterioare.
inteligent
si mentenanta
Procesul
de transport
.de evaluare
(fig. 3.5)
a arhitecturii
este foarteunui
important
proces
119

este necesar pentru a asigura ca arhitectura sistemului este conform cu nevoile

utilizatorilor.

Figura 3.5. Modelul tip V al ciclului de viata n cazul sistemelor inteligente de transport.

Pasul final n dezvoltarea sistemului este evaluarea, deci, reprezinta estimarea abilitatii
sistemului de a raspunde noilor cerinte si identificarea nevoilor potentiale pentru un nou
sistem. Evaluarea confirma daca sistemul este potrivit conceptului de operare.
Printre obiectivele procesului de evaluare n cazul arhitecturii ITS pot fi amintite:
sa confirme functiile necesare furnizarii serviciilor ITS cerute;
sa identifice modul n care arhitectura contine aceste functii si sprijina conexiunile
necesare pentru a furniza aceste servicii;
sa identifice lipsa oricarei legaturi, ntre functiile care ar putea fi furnizate, n scopul
producerii serviciilor stabilite;
sa confirme abilitatea arhitecturii de a sprijini modificarile componentelor sale sau/si
schimbarile conditiilor;
sa confirme abilitatea arhitecturii de a conduce la aplicatii fiabile, din punct de
vedere tehnic, politic si financiar;
sa confirme abilitatea arhitecturii de a conduce la aplicatii care pot fi gestionate,
mentinute si utilizabile, sub diverse moduri de operare, n deplina siguranta.
Procesul de evaluare a ciclului de viata consta n patru tipuri deferite de proceduri:
Verificarea compararea datelor de iesire a fiecarei faze individuale a evolutiei
sistemului cu rezultatele fazei anterioare, obiectivul fiind de a asigura ca rezultatele
noii faze ndeplinesc cerintele specificate n rezultatele fazei anterioare.
ntotdeauna, verificarea cere sa se faca o comparare (de exemplu, rezultatele
testului cu rezultatele asteptate).
Analiza faza a evaluarii ciclului de viata, care implica compilarea si cuantificarea
intrarilor si iesirilor pentru un produs sistem dat n ntreg ciclul de viata (conform
ISO 14050: 1998/DAM 1).
rezultatelor asteptate cu intentia de a gasi defectele unui produs. Se poate retine ca
Testarea
procesarea
ofertei
unui
set de
marimi corectitudinea,
de intrare, a conditiilor
si daca,
testarea poate
fi utilizata
doar
pentru
a verifica
daca si numai
Validarea
anumite procese
Validarea
- cere
demonstrarea
tinnd
capot
decizia
cont
fi de
testate.
faptului
sa
testele
se ia realizate,
ca
pe un
baza
produs
rezultatelor
sistemul
satisface
saprocesului
poata
cerintele
fi integrat.
de
prestabilite.
verificare si,
120

3.1.2.2. Modelul tip CASCADA

Figura 3.6. Modelul tip cascada al ciclului de viata al sistemelor.

Modelul tip CASCADA descrie o metoda de evolutie liniara si secventiala. Dezvoltarea

tip cascada are obiective distincte pentru fiecare faza de dezvoltare. O data completata o
faza de dezvoltare, se trece la urmatoarea faza si nu se mai revine la situatia precedenta,
asemeni unei cascade.
n practica, ingineria sistemelor poate permite revenirea la faza anterioara, pe baza
experientei acumulate n pasul curent. De exemplu, daca pe durata proiectarii, se constata
ca o schimbare minora a cerintelor va avea ca rezultat costuri de implementare mai
scazute, cerinta poate fi modificata.
Modelul tip cascada include aceeasi pasi ca cei identificati pentru modelul V. Ei sunt
doar aranjati ntr-un astfel de format, care sa arate progresia liniara.
Avantaje:
este aplicabil sistemelor mici, bine definite;
cere mai putina munca dect alte modele si poate fi folosit n mod sigur, daca
circumstantele sunt potrivite.
3.1.2.3. Modelul tip SPIRALA
Modelul tip SPIRALA este folosit pentru a reprezenta dezvoltarea iterativa a proiectarii
sistemului. n alte cuvinte, proiectarea initiala este definita de un prototip. Aceasta este
urmata de analiza prototipului, incluznd dezvoltarea conceptului de operare.

Figura 3.7. Modelul tip spirala al ciclului de viata al sistemelor.

121

n cadrul modelului tip spirala exista patru stadii: alegerea obiectivelor, evaluarea

riscului si reducere, dezvoltarea si validarea si cea de-a patra, planificarea. Acest proces
poate fi repetat de cte ori este nevoie, cu mbuna tatiri si analize suplimentare. Faza de
proiectare n detaliu si cea de implementare sunt demarate abia cnd proiectantii si
consumatorii convin ca prototipul ndeplineste nevoile lor.
Avantaje:
flexibilitatea proiectarii permite schimba ri care sa fie implementate n diferite stadii
ale proiectului;
functia de control este angajata, n mod permanent, de durata implementarii
proiectului;
este recomandat pentru proiectele cu definire neadecvata a cerintelor.
Dezavantaje:
procesul iterativ poate necesita un interval mai mare de timp;
cere evaluarea riscului si expertiza prototipului.
3.1.2.4. Modelul EVOLUTIV ca model de dezvoltare tip V
Modelul EVOLUTIV poate fi reprezentat de diagrama tip V. Liniile din diagrama
prezentata n figura 3.8 reprezinta modele tip V multiple care sunt executate secvential. Se
ncepe cu o viziune initiala si se executa fazele de planificare si proiectare urmate de
dezvoltarea fazei pentru fiecare iteratie.

Figura 3.8. Modelul evolutiv al ciclului de viata.

n fiecare faza sunt inclusi toti pasii maturizarii sistemului (asa cum este reprezentat n
diagrama tip V). La sfrsitul procesului, cumpara torul este responsabil pentru operarea si
mentenanta fazei finale. La sfrsitul fieca rei faze exista o evaluare pentru a determina
daca cerintele fazei urmatoare, necesita modificari pe baza experientei consumatorului n
faza curenta. Fara a fi reprezentat n figura , anumite activitati din fiecare iteratie se pot
suprapune.
Avantaje:
simplitatea;
sistemului,
exemplu,
probleme
pe
bazadezvoltarea
lectiei
legate
nvatate
defiusor
buget);
lasau
predecesor;
proiectele
furnizeaza
daca
sunt nregistrate
mari
maximum
pot fi separate
de
probleme,
oportunitati
n fazele
subproiecte
pentru
urma
toare
mici,
pot
mai
fiecarei
ntrziate
dede
condus;
versiuni
anulate
succesive
(de a
122

 ntruct pot fi amnate iteratiile urmatoare, sunt minimizate schimbarile privitoare la

cerinte.
Dezavantaje:

timpul total de expansiune a sistemului poate creste;

este dificil de implementat daca, functiile/cerintele nu pot fi mpartite logic n faze.

Figura 3.9. Desfasurarea n timp a modelului evolutiv.

Aceasta reprezentare cronologica a modelului evolutiv demonstreaza ca este posibil

ca, anumite faze, sa se realizeze n paralel. Modelul evolutiv poate fi executat, n principal,
ca un proces secvential sau, planificarea unei faze se poate realiza n timp ce faza
precedenta este nca n curs de desfasurare. Beneficiarul poate ncepe operarea si
ntretinerea pentru aceasta faza, imediat ce fiecare faza a fost acceptata.
3.1.2.5. Compararea modelelor de proces
Modelul tip cascada este un proces liniar si este cel mai simplu dintre modelele
discutate.
Modelul tip spirala implica, nainte de a executa produsul final, folosirea mai multor
prototipuri. Acest model este cel mai potrivit cnd nu se cunoaste cu precizie
obiectivul final si sistemul nu poate fi mpartit, cu usurinta, n mai multe
componente.
Modelul evolutiv presupune adaugarea unor caracteristici n timp. n cazul n care
sistemul poate fi mpartit n componente, acesta este cel mai potrivit model.
n proiectarea sistemelor complexe este posibil sa se foloseasca oricare dintre aceste
modele, combinate. Este important doar ca modelul sa fie definit n faza de lansare a
proiectului, astfel nct, sa poata fi urmat pe ntreaga durata a proiectului.
3.2. PROCESUL DE PLANIFICARE
Procesul planificarii unui sistem de transport inteligent poate fi similar cu planificarea
unei vacante. Comparatia este prezentata n tabelul 3.4, care prezinta etapele procesului
de
planificare
pentru un sistem
avansatntre
de m
anagement
al traficului.
Fiecare
pasi,
proiectare
si implementare.
Diferenta
cele
doua consta
n succesiunea
ndintre
care sunt
printre
selectarea
celei
mai potrivite
abordari
este
esential
un
realizatecare
aceste
activitati.
ntrebarea
la care
trebuiecontractuale,
sa se raspunda
este
daca ,pentru
o agentie
sistem bine
publica
, un planificat.
sistem integrator, sau un contractor din sectorul energetic, ar trebui sa faca
Modelele
tip cascada si spirala , includ aceleasi activitati fundamentale
- planificare,
aceasta munca.
123

Procesul de contractare determina evaluarea acestor responsabilitati. Acest proces

distribuie responsabilitatile organizatiilor implicate n implementarea sistemului. Nu are
importanta cte responsabilitati sunt stabilite sectorului privat (consultanti, sisteme
integratoare sau contractor din domeniul energetic). Agentia locala trebuie sa ramna
implicata n dezvoltarea sistemului.

Se recomanda ca n dezvoltarea unui sistem de orice importanta (cu buget mai mare
de 500 mii de dolari) sa fie stabilita o agentie publica locala responsabila cu
managementul proiectului, n caz contrar proiectul nu va putea fi implementat.
Tabelul 3.4. Procesul de planificare.
Etapele planificarii Planificarea vacantei Planificarea ITS
Tipul sistemului
Tipul vacantei (plaja,
Autostrazi
obiective
istorice,
Scenariu
Artere rutiere, artere si autostrazi integrate
parcuri de distractii.

Cerinte Cost, distante,

Probleme de rezolvat
Congestie normala
Managementul incidentelor
confortabilitate.
Supravegherea traficului

Restrictii Buget, durata vacantei. Buget, timp de instalare

Limitari de personal
Panouri cu mesaje variabile, informare prin
Nivel ridicat al
Mijloc de
transport,
internet,
detectori, camere de luat vederi cu
functiilor
cazare, restaurante.
circuit nchis

n mod traditional abordarea contractuala pentru proiectele privind proiectarea si

executia de artere rutiere este ntotdeauna aceeasi.

Figura 3.10. Dezvoltarea generica a procesului.

Fiecare dintre alternativele contractuale poate fi descrisa n aceeasi termeni, folosind

diagrama din figura 3.10. La nivelul superior, etapele se identifica cu fazele amintite
anterior.
Angajarea unui consultant pentru proiectarea drumului, selectarea unui contractor, cu
oferta avantajoasa pentru construirea drumului. Aceasta abordate este inclusa n
prezentarea urmatoare, dar nu asa se procedeaza n cazul ITS.

Responsabilitatile
Printre
fiecarui
alternativele
participant
deprocesului
abordare
sunt prezentate
contractuala
n tabelul
pot fi
3.5.
alese:
Figura
3.11.
Dezvoltarea
consultant/contractor.
124

Tabelul 3.5. Responsabilitatile participantilor la realizarea unui sistem.

Participant Planificare Proiectare Executie Testare
Agentie Da Recenzeaza Inspecteaza Observa
Consultant Optional Proiecteaza Consiliere Consiliere
Contractor Nu Nu Executa Conduce

Consultant/Contractor. Consultantul sau personalul tehnic al agentiei publice poate

fi implicat n sistemul de planificare. Consultantul (expert) proiecteaza sistemul si
realizeaza programele, precum si un set de specificatii. Specificatiile sunt elaborate
sub forma documentelor de oferta. Pentru a instala sistemul este selectata oferta
cel mai scazut nivel al costurilor de implementare.
Sistem Manager. Este selectata, pe baza calitatii propunerii sale, o firma de
consultanta, cu abilitati de integrare. Costurile nu reprezinta un factor determinant
n selectarea procesului. Firma de consultanta poate fi implicata n planificarea
sistemelor. Expertul proiecteaza sistemul si produce programele cerute pentru
operare. El este responsabil pentru integrarea sistemelor (se asigura ca
subsistemele comunica, cu fiecare dintre celelalte, si lucreaza mpreuna ca un
sistem). Specificatiile expertului sunt folosite de agentie pentru a procura
echipamente si a contracta servicii de specialitate.

Figura 3.12. Dezvoltarea procesului Sistem Manager.

Integrator de sisteme. Un contract integrator de sisteme este o componenta a

contractului manager de sistem, n care, este ales integratorul pentru a furniza
programele si serviciile de integrare a sistemelor cerute pentru implementare.
Aceasta selectie poate fi realizata folosind un proces de selectie de tip consultant,
deoarece aceasta implica pastrarea serviciilor personalului.
Proiectare/Executie. Plaseaza maximum de responsabilitate contractorului, dar nu
scuteste agentia de rolul de ndrumare si revizie a evolutiei dezvoltarii sistemului.
Procesul de proiectare/executie poate fi implementat n mai multe feluri, ceea ce
face dificila generalizarea lui.
3.2.1. Procesul de exprimare a viziunii
Un element fundamental al fazei de planificare este definirea viziunii sistemului.
Viziunea reprezinta exprimarea larga a obiectivelor pe termen lung ale sistemului.
Cteva exemple de exprimari tipice n ingineria de trafic, ce pot fi luate n considerare,
de trafic n
vorcontinuare:
fi coordonate de-a lungul arterelor si autostrazilor. Fluxurile de trafic ce
sunt prezentate
se deplaseaza
ntre nodurile
de ntreruperi
circulatie, vor
fi controlate
astfel
de maniera,
1. Sistemul
va furniza
mai putine
ale fluxurilor
de ntr-o
trafic n
regiune.
Fluxurile
nct sa nu fie afectate de limitarile legislative. Mesajele catre automobilisti vor fi
2. Informarea
stabilite, astfel
planificarea
nca
timp
nct
latoriilor
real
sa aiba
vade
fi un
la
diseminata
un
format
capastandard
tcatre
la celalalt.
public
si continut.
ntr-o
Informatia
maniera
include
faciliteaza
durata
125 va care

cala toriei pentru toate modurile de trans port, inclusiv timpii necesari deplasarii pe

jos. Informatia va fi diseminata folosind internetul.

3. Sistemul va facilita miscarea sigura si eficienta a vehiculelor comerciale de-a lungul
retelei rutiere. Miscarea vehiculelor comerciale va fi simplificata prin statiile de
colectare a taxelor, se reduc ntrzierile n statiile de cnta rire si inspectie si
furnizeaza constrngeri extinse privind vitezele de deplasare ale camioanelor.
n mod obisnuit, viziunea nu cuprinde mai mult de trei paragrafe, completate de un text
potrivit pentru detalierea managementului la nivel local. Acest text trebuie sa justifice
dezvoltarea viziunii si sa descrie modul n care, utilizatorii sistemului de transport, sunt
afectati de aceasta viziune.
Exprimarea viziunii este importanta din urmatoarele motive:
Obliga toate agentiile afectate de implementarea sistemului sa fie de acord, n
termeni simpli, cu privire la obiectivul principal al sistemului. Nu sunt necesari
termeni de specialitate n cazul discutiilor.
Nivelul de detaliere va angaja cel mai ridicat management sunt stabiliti
participantii care trebuie sa fie de acord nainte de finalizarea enuntului viziunii.
Dezvoltarea unei viziunii care obliga participantii sa participe la discutii unii cu
ceilalti. Daca sunt bine conduse, ntlnirile pentru enuntul viziunii, vor genera
dialogul ntre participanti, care face cunoscuta agenda personala a participantilor,
obiective nvecinate si nevoi functionale.
Ajutoarele stabilesc prioritatile si asigura ca sistemul ce urmeaza a fi dezvoltat
raspunde n totalitate nevoilor participantilor.
n stabilirea viziunii pot fi considerate etapele urmatoare.
Identificarea jucatorilor pune n evidenta cel mai nalt nivel de management.
Planificarea reuniunii. n cadrul primei reuniuni participantii sunt informati asupra
posibilitatilor, limitarilor si riscurilor.
Descrierea scopului reuniunii. Se defineste viziunea. Sunt explicate rezultatele dorite.
1. Daca la reuniune participa mai mult de 10 15 persoane, grupul trebuie divizat n
subgrupuri (ateliere) pentru a fi mai productive.
2. Fiecare grup are atribuita sarcina de a identifica trei dintre cele mai importante
probleme de trafic din regiune.
3. Fiecare grup este instruit sa identifice solutiile tehnice pentru rezolvarea acestor
probleme. n aceasta etapa , nu intereseaza constrngerile legate de buget sau
tehnologiile curente.
4. Sunt reasamblate grupurile de lucru pentru a se compara rezultatele lor. Se aleg 5
pna la 10 rezultate dintre cele mai amintite. Se analizeaza rezultatele pentru a fi
retinute. Prin colaborare, sunt dezvoltate 3 -5 seturi de probleme si solutii.
5. Sunt discutate 3 pna la 5 paragrafe (pentru a se constitui baza pentru enuntul
viziunii) care reprezinta obiectivele pe termen lung care se adreseaza acelor seturi
de probleme solutii.
6. Se
constituie
un grup
restrns care
da forma
a documentului
viziunii
a ajuta
n etapa
viitoare
de planificare,
darva
suficient
definala
larg pentru
a evita predefinirea
sistemului.
Daca
exista,
un
consultant
sau
un
manager
de
sistem,
deja
angajat
solutiilor tehnice. Declaratia viziunii sistemului constituie primul pas n dezvoltarea cu
trebuie
sa
ndeplineasca
aceasta
responsabilitate.
succes
Enuntul
aacestia
unuirealizat
sistem
aratt
putea
de complex
fi similarcacelui
cel al
deja
sistemelor
amintit. El
avansate
va fi suficient
de
de specific pentru
126transport.

3.2.2. DEFINIREA CERINTELOR SISTEMULUI

Cuvntul cerinta este definit ca o nevoie, o necesitate exprimata . Un enunt sugestiv

pentru ntelegerea notiunii de cerinta ar fi, de exemplu:
Mncarea este o necesitate. Rabdarea este o cerinta n nvatare.
nainte de a decide cine poate fi implicat n sistem, este foarte important sa se
nteleaga conceptul de cerint e de nivel superior. Aceasta necesita sa se faca o
delimitare ntre definitia cerintei si definitia functiilor.
n termeni ai sistemelor avansate de transport, nevoia de a disemina orarul autobuzelor
este o cerinta. Diseminarea timpilor de sosire a autobuzelor folosind mesaje variabile la
oprire este o functie.
n acelasi limbaj, nevoia de a disemina timpii de sosire ai autobuzelor pe ruta
autobuzului la toate opririle majore n interiorul orasului reprezinta o cerinta detaliata. Pe
de alta parte nevoia de a disemina timpii de sosire ai autobuzelor este o cerinta de nivel
inferior.
Tabelul 3.6. Definirea cerintelor si functiilor.
Categorie
Cerinte de nivel
aplicatie
superior Cerinte detaliate Functie
Detectare mai rapida a
Comunicare digitala ntre
Management
ntrzieri reduse pe
incidentului.
centrele de management al
trafic
durata
incidentelor.
Raspuns
mai rapid la
incidentului.
detectarea incidentului.
Afisarea pe internet a
Diseminarea
legaturilor dintre timpii de
Diseminarea
legaturilor
informatiilor privind
calatorie.
dintre timpii de
timpiiInformare
de sosire
Afisarea pe internet a orarelor
calatori
calatorie
pentru
pentru toate modurile
autobuzelor pentru diferite
transportul rutier.
de transport.
trasee.
ncurajarea
abonamentelor
Transport
pentru
simplificarea
public
achitarii
biletului de
calatorie.
Operare
vehicule
comerciale

Simplificarea achitarii
bietului de calatorie
pentru autobuz, tren si
parcare.
Cresterea sigurantei
Siguranta
sporita n stricte
prin constrngeri
deplasare.
legate de marimea si
greutatea camionului.

Implementarea sistemului de
comert electronic pentru
achitarea abonamentelor de
calatorie cu autobuzul, trenul
si pararilor pentru tranzit.
Implementarea sistemului de
cntarire din mers.
Implementarea sistemelor de
detectare a camioanelor nalte.

Eforturile inginerilor de trafic se concentreaza nca de la nceput pentru definirea

corespunzatoare a cerintelor utilizatorilor. n cazul ITS America de exemplu, si nu numai,
sunt definite 32 servicii catre utilizatori care se regasesc n Programul National ITS.
Aceste servicii au fost transpuse n mai mult de 100 de cerinte ale utilizatorilor cu
scopul de a raspunde solicitarilor principale privind managementul traficului, dar si
sistemele avansate de control al traficului si informarea calatorilor.
sistemelor. Ea permite inginerului
sa stabileasca cerintele utilizatorilor printr-o functie
3.2.3. TRASABILITATEA
specifica a sistemului care asigura satisfacerea completa a acestor cerinte. Reversul este,
Trasabilitatea
este o Ea
caracteristica
devedere
importanta
a proceselor
din ingineria
de asemenea,
adevarat.
permite ca,extrem
avnd n
o cerinta,
sa fie stabilite
toate
functiile sistemului, cu scopul de a garanta faptul ca nu au fost create
127functii suplimentare.

Cerintele serviciilor catre utilizatori pot fi regasite n documente dedicate trasabilitatii n

documentatia arhitecturii ITS. Tabelul 3.7 prezinta un exemplu pentru pachetul de servicii

si cerinte ale serviciilor catre utilizatori.

Tabelul 3.7. Pachetul de servicii si cerinte ale serviciilor catre utilizatori.
Serviciu utilizatori Exemple de cerinte ale serviciilor catre utilizatori
Controlul traficului va utiliza o functie de supraveghere trafic.
Control
trafic
Supravegherea
va include o functie de detectare a vehiculelor cu
capacitatea de a detecta vehiculele, cu precizie si n timp real.
Management
Va include o functie a serviciilor de planificare si programe pentru a
transport
public operatiunile de planificare si programare trafic de calatori.
automatiza

Serviciile catre utilizatori continute n arhitectura ITS la nivel national definesc cerintele
de nivel superior identificate de echipa care a creat sistemul.
Pe durata etapei de planificare este recomandat ca lista cerintelor sa fie transpusa n
definirea functiilor de nivel superior. Aceste functii sunt numite, n cadrul arhitecturii ITS,
specificatii de proces. Documentatia de specialitate a sistemelor inteligente ofera n detaliu
functiile de nivel superior. Acestea reprezinta o descriere scurta a procesului prezentnd
activitatile, datele de care este nevoie si care trebuie furnizate. Fiecare specificatie de
proces include o lista de intrari si iesiri ale fluxurilor de date, o descriere legata de cerinte
(pentru trasabilitate) si fluxurile de iesire (pentru analiza ncarcarii). De asemenea, sunt
incluse descrieri generale de tipul celor prezentate n exemplele urmatoare (n original).
Exemplul 1.
1.6.0 (ITS) shall provide a Traffic Control capability. Traffic Control provides the capability to
efficiently manage the movement of traffic on streets and highways. Four functions are provided
which are (1) Traffic Flow Optimization, (2) Traffic Surveillance, (3) Control Function, and (4)
Provide Information. This will also include control of network signal systems with eventual
integration of freeway control.
1.6.1 Traffic Control shall include a Flow Optimize function to provide the capability to optimize
traffic flow.
1.6.1.1 The Flow Optimize function shall employ control strategies that seek to maximize
traffic-movement efficiency.
1.6.1.2 The Flow Optimize function shall include a Wide Area optimization capability, to include
several jurisdictions.
1.6.1.2.1 Wide area optimization shall integrate the control of network signal systems with the
control of freeways.
1.6.1.2.2 Wide area optimization shall include features that provide preferential treatment for
transit vehicles.
1.6.2 Traffic Control shall include a Traffic Surveillance function.
Exemplul 2
1.1.1.1---Process Traffic Sensor Data
Overview: This process shall be responsible for collecting surveillance obtained from the
roadside, vehicles, pedestrians (travellers using other modes of transport), railroad grade and
multimodal
process
shall be
able to
both passive
flows showncrossings.
above; (b)The
where
necessary
convert
thereceive
data obtained
in (a)(e.g.
frompresence)
analogueand
to digital
active
(e.g.
tag)
data
from
vehicles.
Where
any
of
the
data
is
provided
in
analogue
form,
the
form, and calibrate the data; (c) periodically send all of the surveillance data to other
processes
in
process
shall
be
responsible
for
converting
it
into
digital
form
and
calibrating.
The
converted
data
the Manage Traffic function via the solicited output data flows shown above; (d) complete a full
shall
beall
sent
to other
for outputs
distribution,
analysis
and storage.
scan of
inputs
and processes
generate the
in lessfurther
than the
time interval
between successive
activations.
Functional Requirements: This process shall: (a) continuously monitor the
128solicited data input

n exemplul 2, sunt definite doua tipuri de date obtinute de la vehicule: date active si
date pasive. Acestea se pot referi la datele transmise de la vehicul sau, la datele despre
vehicule, colectate de senzorii plasati n infrastructura rutiera. Nu este foarte clar nsa
daca, de exemplu, noua tehnologie celulara de localizare geografica a vehiculelor cu
ajutorul careia vehiculele sunt urmarite prin transmisii cu telefoane celulare, poate fi
considerata activa sau pasiva. n recomanda ri nu este stabilita precis tehnologia de
achizitie a datelor, aceasta activitate ramnnd n responsabilitatea coordonatorilor
proiectului.

3.3. PROCESUL DE PROIECTARE

Faza de proiectare a proiectului ncepe abia dupa ce a fost identificat bugetul, definite
functiile de nivel superior si a fost dezvoltat planul de contractare. Pe durata acestei faze,
functiile generale sunt transpuse n proiectarea unui sistem fizic care identifica fluxurile de
date, arhitectura echipamentelor si functiile detaliate, figura 3.13.

Figura 3.13: Legatura ntre serviciile catre utilizatori si arhitectura fizica a sistemului ITS.

Acesta activitate poate fi un pr oces relativ simplu, dar exista multe consideratii de ordin
tehnic, incluznd: analiza alternativelor legate de echipament, prototipuri si dezvoltarea
cerintelor detaliate. Procesul poate fi repetat, functie de modelul de proces utilizat.
3.3.1. TRANSPUNEREA CERINTELOR N FUNCTII
Cerintele generale si de detaliu, fara considerarea conexiunilor dintre echipamente si
programe, sunt deja dezvoltate la ncheierea procesului de planificare. nsa, nu au fost
stabilite aspecte ca: numarul de locatii ale computerelor, programele instalate pe acestea,
interconectarea echipamentelor si comunicarea dintre ele. Provocarea ingineriei
sistemelor pe durata fazei de proiectare, este de a defini aceasta corelatie, cunoscuta ca
dezvoltarea arhitecturii fizice a sistemului.
Pasii implicati n realizarea acestui proces includ: reevaluarea cerintelor functionale si
dezvoltarea fluxurilor de date; dezvoltarea criteriilor de evaluare a calitatii proiectarii;
crearea si compararea proiectelor alternative; selectarea alternativei preferate de proiect;
identificarea standardelor potrivite; dezvoltarea cerintelor functionale detaliate; gestionarea
achizitiei sistemului.
Conceptul
de trasabilitate
este
pe duratact
acestui
proces,pentru
obtinndu-se
pentru
toate cerintele,
ca exista
attimplementat
sistemele hardware
si software
realizarea
informatii complete privind cerintele sistemului si detalii privind functiile.
acestora si au fost elaborate teste pentru a verifica operarea corespunzatoare a
Trasabilitatea
omentinuta
importanta
majora
pentru
garanta
ca functiile
ndeplinite
sistemului.
Trasabilitatea are
estematricea
trasabilitatii.
prin
crearea
uneiabaze
de date
folosita
pentru
a genera
129 sunt

Tabelul 3.8. Exemplu de matrice de trasabilitate.

Nr.
cerinta Cerinta Nr.
functie
1.0 Masurarea tariei traficului.

Functia

1.1 Colectarea datelor de trafic de la detectori plasati n

infrastructura rutiera.
1.2 Procesarea datelor provenite de la detectorii plasati n
infrastructura rutiera.
Diseminarea
conditiilor
de
1.0
1.2.1.
medii pe baza datelor nregistrate de
traficCalculul vitezei
detectorii plasati n infrastructura rutiera.
1.2.2. Estimarea corelatiilor ntre vitezele nregistrate de
detectorii plasati n infrastructura rutiera.
1.3 Stocarea corelatiilor obtinute n baze de date.
2.0 Regruparea datelor pentru afisarea pe internet.

Exemplul din tabelul 3.8 arata un model de matrice pentru un sistem de informare
asupra calatoriei cu functii complexe, descrise de numere cu o cifra sau doua si functii de
nivel inferior descrise cu mai mult de doua cifre. n acest exemplu, o cerinta se ntinde pe
functii de nivel superior si doua de nivel inferior.
Tabelul 3.9. Matricea de trasabilitate inversa.
Nr.
funct ie Funct ia Nr.
cerinta
1.0 Diseminarea conditiilor de trafic.
2.0 Managementul incidentelor.
2.1 intensitatii
Detectarea automata a incidentelor.
1.0 Masurarea
traficului.
2.2 Informarea publicului asupra conditiilor de trafic
rezultate din incident.
1.0 Diseminarea conditiilor de trafic.
2.0 Managementul incidentelor.
Colectarea datelor de
2.1 Detectarea automata a incidentelor.
1.1 n
la detectorii plasati
infrastructura rutiera. 2.2 Informarea publicului asupra conditiilor de trafic
rezultate din incident.
1.0 Diseminarea conditiilor de trafic.
Procesarea datelor
2.0 Managementul incidentelor.
provenite de la
2.1 Detectarea automata a incidentelor.
1.2
detectorii plasati n
infrastructura rutiera. 2.2 Informarea publicului asupra conditiilor de trafic
rezultate din incident.

Cerinta

Matricile de trasabilitate sunt elemente importante ale proceselor din ingineria

sistemelor. Ele sprijina proiectarea (asigura definirea corecta a functiilor pentru fiecare
cerinta), dezvoltarea (furnizeaza un mecanism de urmarire a stadiului de dezvoltarea
programelor) si testarea (poate fi definit un test pentru fiecare functie).
Matricea de trasabilitate inversa, tabelul 3.9, este, de asemenea, foarte utila . Acest tip
de matrice poate fi folosit pentru a determina aspectele ce sunt afectate de anumite functii.
Matricea de trasabilitate inversa este utila, n mod special, pe durata desfas urarii si testarii,
pentru a garanta ca au fost luate n considerare toate conexiunile dintre functii.
cerintelor utilizatorilor si3.3.2.
functiilor
complexe, altfel
ARHITECTURA
ITSdenumite specificatii. Nu a fost facuta
nici o mentiune despre modul n care sunt stabilite functiile pentru sisteme si subsisteme
n celeIdentificarea
prezentatearhitecturi
nacestor
paragrafele
anterioare,
procesul
fost centrat
pe identificarea
specifice.
aspecte
fizice,
figura
este cunoscuta
3.14.
ca aprocesul
de
130creare a unei

MODULUL 4. INGINERIA SISTEMELOR APLICATA SISTEMELOR AVANSATE DE TRANSPORT

Figura 3.14. Procesul de creare a unei arhitecturi ITS.

Figura 3.15. Arhitectura fizica a sistemelor inteligente de131

transport.

Arhitectura fizica a sistemului de transport este asociata cu cele patru tipuri de

subsisteme, figura 3.15: subsistemul calatorilor, subsistemul centrelor, subsistemul
vehiculelor, subsistemul infrastructurii rutiere.

3.3.2.1. Subsistemul calatorilor

Cuprinde echipamentele utilizate de calatori pentru a accesa serviciile ITS, att nainte
de efectuarea calatoriei, ct si pe durata ei.
Subsistemul Acces personal la informare permite ca latorilor sa primeasca informatii
despre trafic de acasa, de la locul de munca sau, direct, n zonele generatoare de ca latorii.
Asa cum sugereaza si numele, acest subsistem foloseste instrumente aflate sub control
personal.
Subsistemul Sprijin la distanta pentru calatori furnizeaza diseminarea informatiei ca tre
utilizator prin intermediul unor echipamente, cum ar fi, chioscurile sau monitoarele de
informare. Acest subsistem sprijina monitorizarea sigurantei publice prin folosirea
camerelor video n circuit nchis sau a altor echipamente de supraveghere si informare, n
caz de urgenta, n zonele de interes public.
3.3.2.2. Subsistemul centrelor
Subsistemul centrelor furnizeaza functii de management si administrare, coordoneaza
conexiunile dintre modurile de transport si aspectele juridice si comunica cu sub-sistemele
drum, vehicul, calatori.

Figura 3.16. Subsistemul centrelor.

Acest subsistem include centrele mentionate n figura 3.16.

3.3.2.3. Subsistemul vehiculelor
Subsistemul vehiculului care include sisteme de informare generala a conducatorului
auto si sisteme de siguranta aplicabile vehiculelor de orice tip.

Figura 3.17. Subsistemul

132
vehiculelor.

Cele patru subsisteme vehicule comerciale, vehicule de tranzit, vehicule de interventie

si vehicule pentru constructii si mentenanta sunt subsisteme ale flotei de vehicule,

adaugnd abilitati ITS unice vehiculelor speciale.
3.3.2.4. Subsistemul infrastructurii rutiere
Cuprinde infrastructura rutiera inteligenta distribuita de-a lungul retelei de transport;
operarea infrastructurii rutiere n cazul sistemelor inteligente de transport este guvernata,
de obicei, doar de un centru, chiar daca pot fi conectate centre multiple; interfata directa
cu vehiculele;
Acest subsistem realizeaza functia de supraveghere, furnizeaza informatii si executa
planul de control.
Cele patru subsisteme ale infrastructurii rutiere sunt, cum se poate constata din figura
3.14: drumurile; sisteme de colectare a taxelor; managementul parcarilor; verificarea
vehiculelor comerciale.
Un alt element important al arhitecturii fizice a unui sistem ITS l reprezinta asa numitii
terminatori. Terminatorii reprezinta persoanele, sistemele si mediul general care este n
interconectare cu sistemul inteligent de transport.

Figura 3.18. Subsistemul terminatorilor.

Att arhitectura logica si cea fizica au acelasi set de terminatori. Acestia sunt clasificati
n patru categorii, astfel:
Terminatorii UMANI, n numar de 21 se refera la:
conducatorul auto,
personalul de operare a traficului si
operatorii sistemului de interventie.
Pot fi amintiti n aceasta categorie: administratorul datelor arhivate, conduca torul auto
al vehiculului comercial, managerul vehiculului comercial, inspectorul privind operarea
vehiculelor comerciale, conducatorul auto, personalul interventiilor de urgenta, operatorul
sistemului de urgenta, personalul centrului de constructii si mentenanta, operatorul
parcarii, pietonii, administratorul sistemului de taxare, operatorul de taxare, personalul
operatiunilor de trafic, conducatorul vehiculului de tranzit, managerul parcului de vehicule
de tranzit, operatorii sistemului de tranzit, utilizatorii traficului de tranzit, calatorii.
Terminatorii de MEDIU, n numa r de 6, definesc
mediul nconjura tor;
drumul si obstacole potentiale;
mediul zonelor de securitate,
traficul general,
Cei 32 terminatori
alte
de12
vehicule.
SISTEM
caracteristicile
terminatori
includ
apartin
vehiculelor.
sisteme
de ALTE
de mesaje
SISTEME.
variabile,
133 institutii financiare si