m4 Ingineria Sistemelor Aplicata Transporturilor

APLICAŢII TELEMATICE ÎN SISTEMELE AVANSATE DE TRANSPORT RUTIER

MODULUL 4 INGINERIA SISTEMELOR APLICATĂ SISTEMELOR INTELIGENTE DE TRANSPORT

4.1. Introducere în ingineria sistemelor.................................................................115 4.1.1. Sistem şi ingineria sistemelor................................................................115 4.1.1.1. Conceptele introductive ale ingineriei sistemelor..........................116 4.1.1.2. Ingineria sistemelor ca noţiune complexă.....................................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 viaţă al unui sistem............................119 4.1.2.2. Modelul tip CASCADĂ...................................................................121 4.1.2.3. Modelul tip SPIRALĂ.....................................................................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 cerinţelor sistemului...............................................................127 4.2.3. Trasabilitatea........................................................................................127 4.3. Procesul de proiectare...................................................................................129 4.3.1. Transpunerea cerinţelor în funcţii..........................................................129 4.3.2. Arhitectura ITS.......................................................................................130 4.3.2.1. Subsistemul călătorilor..................................................................132 4.3.2.2. Subsistemul centrelor...................................................................132 4.3.2.3. Subsistemul vehiculelor................................................................132 TEST 8.................................................................................................................134

114

MODULUL 4. INGINERIA SISTEMELOR APLICATĂ SISTEMELOR AVANSATE DE TRANSPORT

3. INGINERIA SISTEMELOR APLICATĂ SISTEMELOR AVANSATE DE TRANSPORT 3.1. INTRODUCERE ÎN INGINERIA SISTEMELOR 3.1.1. SISTEM ŞI INGINERIA SISTEMELOR „Un sistem este un ansamblu de elemente aflate în corelaţie sau în interacţiune”. (conform ISO/DIS 9000: 2000) „Un sistem este un ansamblu integrat, format din unul sau mai multe procese, hardware, software, facilităţi şi oameni, care furnizează o capabilitate de a satisface o necesitate specificată sau un obiectiv specificat”. (conform ISO/CEI 12207:1995) „Ingineria sistemelor este o abordare interdisciplinară şi un mijloc, care permite realizarea cu succes a sistemelor”. „Ingineria sistemelor integrează toate disciplinele şi grupurile de specialişti în efortul de echipă formând un proces dezvoltat structural, care porneşte de la concept pentru a ajunge la execuţie şi operare.” „Ingineria sistemelor ia în considerare atât nevoile de afaceri cât şi cele tehnice ale tuturor participanţilor, cu scopul de a furniza calitatea produselor care satisfac nevoile consumatorilor (utilizatorilor)”. Importanţa ingineriei sistemelor nu poate fi subliniată suficient. Procentul neobişnuit de mare al defecţiunilor sistemelor bazate pe programe în domeniul tehnologiei informaţiei (IT) se schimbă esenţial când proiectele sunt conduse de participanţi experimentaţi. Nu sunt disponibile încă statistici specifice proiectelor ITS, cunoscut fiind faptul că modul de înregistrare a datelor pentru aceste proiecte este mai deficitar decât pentru oricare alt sistem. Comunitatea ITS întâmpină dificultăţi similare ceea ce nu ar trebui să surprindă, deoarece proiectele ITS: • trebuie să opereze în timp real, 24 de ore pe zi, şapte zile pe săptămână; • implică interfaţa cu echipamentul provenind de la mulţi furnizori fără beneficiul unor interfeţe standardizate; • se bazează, în mare parte, pe programe care sunt ele însele mai puţin fiabile; • implică clienţi (de obicei agenţii publice) cu puţină experienţă în achiziţia tehnologiei informaţiei pe care se bazează proiectele. Cum se poate constata din tabelul 3.1, probabilitatea de succes a proiectelor majore de transport rutier se îmbunătăţeşte considerabil prin cunoştinţele individuale experimentate ale celor care conduc proiectul şi participă la implementarea lui. Tabelul 3.1: Probabilitatea de succes a unui proiect ITS. Rezultate Anulări Întârzieri Activităţi corecte

Clienţi experimentaţi

Management cu experienţă

40% 39% 21%

35% 37% 28%

Toţi participanţii au experienţă (profesionalism) 1% 2% 97%

Integrarea sistemelor nu reprezintă ingineria sistemelor, deci trebuie făcută o distincţie între aceste două noţiuni. Integrarea sistemelor se referă la interconectarea sistemelor, astfel încât ele să interacţioneze corect, pentru a realiza o funcţie superioară. Un exemplu relevant este cel privind două calculatoare utilizate în domenii adiacente. Fiecare calculator colectează date de trafic referitoare la drumuri în sfera autorităţii sale. Când cele două sisteme sunt integrate, datele de trafic sunt distribuite pentru a furniza 115


afişarea fluxurilor de trafic din sfera ambelor autorităţi. Aceasta este o funcţie superioară faţă de cea realizată de un sistem individual. Sistemele interacţionează corect dacă: • transmit datele către toate celelalte sisteme, la intervale regulate sau definite de timp; • distribuie datele în formate pe care toate celelalte să le înţeleagă; • operează cu fiabilitate sporită. Combinarea a două sisteme interconectate reprezintă, de asemenea, un sistem. Principiile ingineriei sistemelor, incluzând modul de proiectare şi analiză, se aplică, de asemenea, sistemelor integrate. Astfel, se obţine o ierarhizare a sistemelor. 3.1.1.1. Conceptele introductive ale ingineriei sistemelor În ingineria sistemelor, trebuie apreciată diferenţa dintre un sistem, un subsistem şi o componentă, figura 3.1.

Figura 3.1. Sistem, subsistem, componentă, model tip piramidă.

1. Sistem – reprezintă o combinaţie de componente care acţionează împreună pentru a realiza o funcţie care nu este posibilă cu nici una din părţile individuale. 2. Subsistem – este o grupare de componente, în interiorul sistemului, care realizează o funcţie identificabilă. Un subsistem poate conţine mai multe module. 3. Componentă – este cea mai mică unitate de bază a sistemului. Pentru moment, în exemplul anterior fiecare autoritate operează cu propriul sistem: detectorii constituie subsistemul de supraveghere, iar subsistemul de comunicaţii constă din echipamente prin care, se conectează calculatorul cu echipamentul extern. În plus, luând în considerare avantajul datelor combinate ale celor două sisteme de la autoritatea regională, fiecare autoritate operează cu un subsistem al sistemului total regional.

Figura 3.2. Automobilul, ca sistem.

Conceptul sistemelor, subsistemelor şi componentelor poate fi descris ca o ierarhie. Producătorii de automobile, văd automobilul ca un sistem, figura 3.2. Rândul următor din această structură - motor, caroserie roţi - este alcătuit din subsisteme, iar anvelopa şi butucul roţii sunt componente. Dar, producătorii pot vedea anvelopa şi butucul roţii ca subsistem ce conţine multiple elemente (butuc şi suprafaţa de rulare a anvelopei) ca şi componente. 116


Similar, în cazul specialiştilor ITS, trebuie considerat automobilul ca un subsistem al sistemului de transport, care trebuie să cuprindă autovehiculul, conducătorul şi drumul. Astfel, este foarte important să se acorde atenţie noţiunilor de sistem şi subsistem. 3.1.1.2. Ingineria sistemelor ca noţiune complexă În aplicaţiile de început, inginerii erau concentraţi asupra performanţelor şi ignorau mulţi factori importanţi, cum ar fi factorul uman, problematica socială şi economică, mediul de afaceri, asociate cu proiectarea şi implementarea sistemului. Aceasta situaţie s-a dovedit a fi nesatisfăcătoare. Un sistem, oricât de simplu, trebuie să ia în considerare uşurinţa de utilizare, siguranţa, costul de fabricaţie, stil, etc. Multe sisteme sunt atât de extinse şi de complexe, încât unei singure persoane îi va fi imposibil să înţeleagă în detaliu toţi aceşti factori.

Figura 3.3. Ingineria sistemelor tehnice complexe.

În principal, procesele din ingineria sistemelor trebuie să ia în considerare următorii factori: • Consideraţii tehnice – procesul trebuie să se supună legilor naturale şi capacităţile de performanţă ale componentelor şi subsistemelor folosite. Consideraţiile includ înţelegerea aspectelor tehnice ale cerinţelor sistemului, specificaţiile şi constrângerile. • Aspecte economice şi valorice – ingineria sistemelor trebuie să aleagă între alternative bazate pe proiectare, nu numai din punct de vedere tehnic ci, şi de cost şi valori relative. • Consideraţii industriale şi politice – rezultatele proiectării trebuie să răspundă nevoilor clienţilor, în mod obişnuit definiţi ca organizaţii care plătesc pentru crearea sistemului. Tabelul 3.2. Optimizarea sistemului de management al traficului. Aspecte de optimizare Tehnice Economice şi valorice

Industriale şi comerciale

Detectori cu buclă inductivă •

Măsurarea volumului, vitezei şi gradului de ocupare.

• •

Instalarea întrerupe traficul Instalarea perechilor de detectori furnizează cea mai precisă metodă de colectare a datelor.

•

Furnizează înregistrări de date (volume) pentru ingineria şi planificarea transporturilor.

117

Detectori radar • Măsurarea vitezei. •

Instalare uşoară fără blocarea benzilor de trafic.

•

Furnizează date despre viteze de circulaţie pentru detectarea incidentelor şi afişarea pe internet.


Optimizarea sistemului clasic de management al traficului poate fi realizată printr-o comparaţie între monitorizarea traficului, prin folosirea unor detectori buclă inductivă sau a detectorilor radar. Comparaţia între consideraţiile tehnice, economice şi industrial/politice sunt prezentate în tabelul 3.2. 3.1.1.3. Dimensiunile multiple ale ingineriei sistemelor Aprecierea caracteristicilor multi-dimensionale este foarte importantă. Toate produsele considerate în tabelul 3.3, constituie subiectul criteriilor descrise anterior şi ele necesită, pentru a sprijini proiectarea şi dezvoltarea lor, un proces bazat pe ingineria sistemelor. În perioada actuală, inginerii nu mai pot ignora nici unul dintre aceste aspecte, dacă vor să proiecteze un produs folositor şi vandabil. Tabelul 3.3. Proiectarea diferitelor produse pe baza teoriei ingineriei sistemelor. Aspecte economice şi Aspecte industriale şi Produs Aspecte tehnice valorice comerciale Gama de frecvenţe. Cost. Mărime. Mărimea unităţilor. Distribuţia bornelor de Aspect. Sistem Tehnologia semiconductorilor. ieşire. Particularităţi clienţi stereo Amortizarea investiţiei. (folosirea echipamentului). Control la distanţă. Standardizare. Viteză. Comercial sau personal. Aspect. Cost. Cerinţe de spaţiu. Calculator Periferice. Învăţare Portabilitate. Standardizare. Particularităţi client. Performanţe. Reducere zgomot. Capacitate. Costuri de construcţie. Amenajări tranzit. Drumuri Viteză limită. Taxat şi netaxat. Generarea traficului. Tipuri de vehicule. Mediu. Capacitatea pasageri. Particularităţi client. Putere. Culoare. Opţiuni. Preţ de cumpărare. Stil. Automobile Capacitate de încărcare Costuri de mentenanţă. Distribuţie. Tracţiune faţă/ tracţiune Siguranţă. spate.

Proiectarea drumurilor, inclusă în tabelul 3.3, este probabil cea mai veche formă de inginerie a sistemelor datorită procesului extins de planificare şi de proiectare cerut. În continuare este prezentată o reprezentare a modului în care se aplică ingineria sistemelor procesului de proiectare. Pentru o înţelegere mai uşoară, procesul este împărţit în patru faze: planificarea, proiectarea preliminară, proiectarea detaliată şi planificarea operaţională. 3.1.2. MODELE DE PROCES DIN INGINERIA SISTEMELOR Modelul tip „V” este cea mai folosită reprezentare a proceselor din ingineria sistemelor, aplicată sistemelor avansate de transport. Acesta defineşte secvenţele şi corelaţia dintre activităţile procesului. Paşii reprezentaţi în diagramă sunt preponderent executaţi într-o manieră definită de trei modele posibile ale procesului: • Modelul tip CASCADĂ defineşte procesul liniar în care fazele succesive sunt realizate secvenţial. Acest model de analiză a fost o abordare dominantă în ingineria sistemelor în anii ’80.

118


•

Modelul tip SPIRALĂ, folosit pentru a descrie dezvoltarea iterativă a proiectării sistemului. • Modelul tip EVOLUTIV, care poate fi executat ca un proces secvenţial 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 viaţă al unui sistem Modelul tip „V” a fost creat pentru a defini ordinea în care este dezvoltat un sistem bazat pe o tehnologie informatică (IT). El începe cu dezvoltarea conceptului de OPERARE, are la bază faza de IMPLEMENTARE şi ajunge la final în faza de EXPLOATARE ŞI MENTENANŢĂ închizând astfel prin faza de EVALUARE bucla. Fiecare fază din partea dreaptă a modelului, este echivalentă cu o fază din partea stângă. Figura 3.4 prezintă cazul modelului V general, iar figura 3.5 cazul modelului V a ciclului de viaţă al unui sistem inteligent de transport.

Figura 3.4. Modelul general de tip V al ciclului de viaţă.

Partea stângă a modelului tip V cuprinde următoarele faze: • Conceptul de Operare – defineşte modul în care va fi utilizat sistemul, în cazul general, iar pentru arhitectura unui sistem inteligent de transport se identifică cu nevoile utilizatorilor. • Cerinţe – definesc ceea ce va face sistemul. Cerinţele sunt dezvoltate, în mod obişnuit, folosind cel puţin două niveluri de detaliere. • Proiectare – defineşte modul în care, va fi proiectat sistemul, la cele două niveluri de detaliere. • Implementarea– construcţia sistemului. Partea dreaptă a modelului tip V cuprinde: • Integrarea şi testarea - asamblare şi interconectare • Verificarea subsistemelor şi a sistemului în ansamblu privind implementarea corectă. • Exploatare şi mentenanţă. În cazul arhitecturii unui sistem inteligent de transport (fig. 3.5) este foarte important procesul de verificare, pentru a confirma că rezultatul fiecărei faze succesive este în conformitate cu rezultatul fazei anterioare. Procesul de evaluare a arhitecturii unui proces

119


este necesar pentru a asigura că arhitectura sistemului este conform cu nevoile utilizatorilor.

Figura 3.5. Modelul tip V al ciclului de viaţă în cazul sistemelor inteligente de transport.

Pasul final în dezvoltarea sistemului este evaluarea, deci, reprezintă estimarea abilităţii sistemului de a răspunde noilor cerinţe şi identificarea nevoilor potenţiale pentru un nou sistem. Evaluarea confirmă dacă sistemul este potrivit conceptului de operare. Printre obiectivele procesului de evaluare în cazul arhitecturii ITS pot fi amintite: • să confirme funcţiile necesare furnizării serviciilor ITS cerute; • să identifice modul în care arhitectura conţine aceste funcţii şi sprijină conexiunile necesare pentru a furniza aceste servicii; • să identifice lipsa oricărei legături, între funcţiile care ar putea fi furnizate, în scopul producerii serviciilor stabilite; • să confirme abilitatea arhitecturii de a sprijini modificările componentelor sale sau/şi schimbările condiţiilor; • să confirme abilitatea arhitecturii de a conduce la aplicaţii fiabile, din punct de vedere tehnic, politic şi financiar; • să confirme abilitatea arhitecturii de a conduce la aplicaţii care pot fi gestionate, menţinute şi utilizabile, sub diverse moduri de operare, în deplină siguranţă. Procesul de evaluare a ciclului de viaţă constă în patru tipuri deferite de proceduri: • Verificarea – compararea datelor de ieşire a fiecărei faze individuale a evoluţiei sistemului cu rezultatele fazei anterioare, obiectivul fiind de a asigura că rezultatele noii faze îndeplinesc cerinţele specificate în rezultatele fazei anterioare. Întotdeauna, verificarea cere să se facă o comparare (de exemplu, rezultatele testului cu rezultatele aşteptate). • Analiza – fază a evaluării ciclului de viaţă, care implică compilarea şi cuantificarea intrărilor şi ieşirilor pentru un produs sistem dat în întreg ciclul de viaţă (conform ISO 14050: 1998/DAM 1). • Testarea – procesarea ofertei unui set de mărimi de intrare, a condiţiilor şi rezultatelor aşteptate cu intenţia de a găsi defectele unui produs. Se poate reţine că testarea poate fi utilizată doar pentru a verifica corectitudinea, dacă şi numai dacă, anumite procese pot fi testate. • Validarea - demonstrarea faptului că un produs satisface cerinţele prestabilite. Validarea cere ca decizia să se ia pe baza rezultatelor procesului de verificare şi, ţinând cont de testele realizate, sistemul să poată fi integrat. 120


3.1.2.2. Modelul tip CASCADĂ

Figura 3.6. Modelul tip cascadă al ciclului de viaţă al sistemelor.

Modelul tip CASCADĂ descrie o metodă de evoluţie liniară şi secvenţială. Dezvoltarea tip cascadă are obiective distincte pentru fiecare fază de dezvoltare. O dată completată o fază de dezvoltare, se trece la următoarea fază şi nu se mai revine la situaţia precedentă, asemeni unei cascade. În practică, ingineria sistemelor poate permite revenirea la faza anterioară, pe baza experienţei acumulate în pasul curent. De exemplu, dacă pe durata proiectării, se constată că o schimbare minoră a cerinţelor va avea ca rezultat costuri de implementare mai scăzute, cerinţa poate fi modificată. Modelul tip cascadă include aceeaşi paşi ca cei identificaţi pentru modelul V. Ei sunt doar aranjaţi într-un astfel de format, care să arate progresia liniară. Avantaje: • este aplicabil sistemelor mici, bine definite; • cere mai puţină muncă decât alte modele şi poate fi folosit în mod sigur, dacă circumstanţele sunt potrivite. 3.1.2.3. Modelul tip SPIRALĂ Modelul tip SPIRALĂ este folosit pentru a reprezenta dezvoltarea iterativă a proiectării sistemului. În alte cuvinte, proiectarea iniţială este definită de un prototip. Aceasta este urmată de analiza prototipului, incluzând dezvoltarea conceptului de operare.

Figura 3.7. Modelul tip spirală al ciclului de viaţă al sistemelor. 121


În cadrul modelului tip spirală există patru stadii: alegerea obiectivelor, evaluarea riscului şi reducere, dezvoltarea şi validarea şi cea de-a patra, planificarea. Acest proces poate fi repetat de câte ori este nevoie, cu îmbunătăţiri şi analize suplimentare. Faza de proiectare în detaliu şi cea de implementare sunt demarate abia când proiectanţii şi consumatorii convin că prototipul îndeplineşte nevoile lor. Avantaje: • flexibilitatea proiectării permite schimbări care să fie implementate în diferite stadii ale proiectului; • funcţia de control este angajată, în mod permanent, de durata implementării proiectului; • este recomandat pentru proiectele cu definire neadecvată a cerinţelor. Dezavantaje: • procesul iterativ poate necesita un interval mai mare de timp; • cere evaluarea riscului şi 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 prezentată în figura 3.8 reprezintă modele tip V multiple care sunt executate secvenţial. Se începe cu o viziune iniţială şi se execută fazele de planificare şi proiectare urmate de dezvoltarea fazei pentru fiecare iteraţie.

Figura 3.8. Modelul evolutiv al ciclului de viaţă.

În fiecare fază sunt incluşi toţi paşii maturizării sistemului (aşa cum este reprezentat în diagrama tip V). La sfârşitul procesului, cumpărătorul este responsabil pentru operarea şi mentenanţa fazei finale. La sfârşitul fiecărei faze există o evaluare pentru a determina dacă cerinţele fazei următoare, necesită modificări pe baza experienţei consumatorului în faza curentă. Fără a fi reprezentat în figură, anumite activităţi din fiecare iteraţie se pot suprapune. Avantaje: • simplitatea; • furnizează maximum de oportunităţi pentru dezvoltarea fiecărei versiuni succesive a sistemului, pe baza lecţiei învăţate de la predecesor; • dacă sunt înregistrate probleme, fazele următoare pot fi întârziate sau anulate (de exemplu, probleme legate de buget); • proiectele mari pot fi separate în subproiecte mici, mai uşor de condus; 122


întrucât pot fi amânate iteraţiile următoare, sunt minimizate schimbările privitoare la cerinţe. Dezavantaje: • timpul total de expansiune a sistemului poate creşte; • este dificil de implementat dacă, funcţiile/cerinţele nu pot fi împărţite logic în faze. •

Figura 3.9. Desfăşurarea în timp a modelului evolutiv.

Această reprezentare cronologică a modelului evolutiv demonstrează că este posibil ca, anumite faze, să se realizeze în paralel. Modelul evolutiv poate fi executat, în principal, ca un proces secvenţial sau, planificarea unei faze se poate realiza în timp ce faza precedentă este încă în curs de desfăşurare. Beneficiarul poate începe operarea şi întreţinerea pentru această fază, imediat ce fiecare fază a fost acceptată. 3.1.2.5. Compararea modelelor de proces •

Modelul tip cascadă este un proces liniar şi este cel mai simplu dintre modelele discutate. • Modelul tip spirală implică, înainte de a executa produsul final, folosirea mai multor prototipuri. Acest model este cel mai potrivit când nu se cunoaşte cu precizie obiectivul final şi sistemul nu poate fi împărţit, cu uşurinţă, în mai multe componente. • Modelul evolutiv presupune adăugarea unor caracteristici în timp. În cazul în care sistemul poate fi împărţit în componente, acesta este cel mai potrivit model. În proiectarea sistemelor complexe este posibil să se folosească oricare dintre aceste modele, combinate. Este important doar ca modelul să fie definit în faza de lansare a proiectului, astfel încât, să poată fi urmat pe întreaga durată a proiectului. 3.2. PROCESUL DE PLANIFICARE Procesul planificării unui sistem de transport inteligent poate fi similar cu planificarea unei vacanţe. Comparaţia este prezentată în tabelul 3.4, care prezintă etapele procesului de planificare pentru un sistem avansat de management al traficului. Fiecare dintre paşi, printre care selectarea celei mai potrivite abordări contractuale, este esenţial pentru un sistem bine planificat. Modelele tip cascadă şi spirală, includ aceleaşi activităţi fundamentale - planificare, proiectare şi implementare. Diferenţa între cele două constă în succesiunea în care sunt realizate aceste activităţi. Întrebarea la care trebuie să se răspundă este dacă, o agenţie publică, un sistem integrator, sau un contractor din sectorul energetic, ar trebui să facă această muncă. 123


Procesul de contractare determină evaluarea acestor responsabilităţi. Acest proces distribuie responsabilităţile organizaţiilor implicate în implementarea sistemului. Nu are importanţă câte responsabilităţi sunt stabilite sectorului privat (consultanţi, sisteme integratoare sau contractor din domeniul energetic). Agenţia locală trebuie să rămână implicată în dezvoltarea sistemului. Se recomandă ca în dezvoltarea unui sistem de orice importanţă (cu buget mai mare de 500 mii de dolari) să fie stabilită o agenţie publică locală responsabilă cu managementul proiectului, în caz contrar proiectul nu va putea fi implementat. Tabelul 3.4. Procesul de planificare. Etapele planificării Scenariu

Planificarea vacanţei Tipul vacanţei (plajă, obiective istorice, parcuri de distracţii.

Cerinţe

Cost, distanţe, confortabilitate.

Restricţii

Buget, durata vacanţei.

Nivel ridicat al funcţiilor

Mijloc de transport, cazare, restaurante.

Planificarea ITS Tipul sistemului Autostrăzi Artere rutiere, artere şi autostrăzi integrate Probleme de rezolvat Congestie normală Managementul incidentelor Supravegherea traficului Buget, timp de instalare Limitări de personal Panouri cu mesaje variabile, informare prin internet, detectori, camere de luat vederi cu circuit închis

În mod tradiţional abordarea contractuală pentru proiectele privind proiectarea şi execuţia de artere rutiere este întotdeauna aceeaşi.

Figura 3.10. Dezvoltarea generică a procesului.

Fiecare dintre alternativele contractuale poate fi descrisă în aceeaşi termeni, folosind diagrama din figura 3.10. La nivelul superior, etapele se identifică cu fazele amintite anterior. Angajarea unui consultant pentru proiectarea drumului, selectarea unui contractor, cu ofertă avantajoasă pentru construirea drumului. Această abordate este inclusă în prezentarea următoare, dar nu aşa se procedează în cazul ITS.

Figura 3.11. Dezvoltarea procesului consultant/contractor.

Responsabilităţile fiecărui participant sunt prezentate în tabelul 3.5. Printre alternativele de abordare contractuală pot fi alese: 124


Tabelul 3.5. Responsabilităţile participanţilor la realizarea unui sistem. Participant Agenţie Consultant Contractor

•

•

Planificare Da Opţional Nu

Proiectare Recenzează Proiectează Nu

Execuţie Inspectează Consiliere Execută

Testare Observă Consiliere Conduce

Consultant/Contractor. Consultantul sau personalul tehnic al agenţiei publice poate fi implicat în sistemul de planificare. Consultantul (expert) proiectează sistemul şi realizează programele, precum şi un set de specificaţii. Specificaţiile sunt elaborate sub forma documentelor de ofertă. Pentru a instala sistemul este selectată oferta cel mai scăzut nivel al costurilor de implementare. Sistem Manager. Este selectată, pe baza calităţii propunerii sale, o firmă de consultanţă, cu abilităţi de integrare. Costurile nu reprezintă un factor determinant în selectarea procesului. Firma de consultanţă poate fi implicată în planificarea sistemelor. Expertul proiectează sistemul şi produce programele cerute pentru operare. El este responsabil pentru integrarea sistemelor (se asigură că subsistemele comunică, cu fiecare dintre celelalte, şi lucrează împreună ca un sistem). Specificaţiile expertului sunt folosite de agenţie pentru a procura echipamente şi a contracta servicii de specialitate.

Figura 3.12. Dezvoltarea procesului Sistem Manager.

•

•

Integrator de sisteme. Un contract integrator de sisteme este o componentă a contractului manager de sistem, în care, este ales integratorul pentru a furniza programele şi serviciile de integrare a sistemelor cerute pentru implementare. Această selecţie poate fi realizată folosind un proces de selecţie de tip consultant, deoarece aceasta implică păstrarea serviciilor personalului. Proiectare/Execuţie. Plasează maximum de responsabilitate contractorului, dar nu scuteşte agenţia de rolul de îndrumare şi revizie a evoluţiei dezvoltării sistemului. Procesul de proiectare/execuţie poate fi implementat în mai multe feluri, ceea ce face dificilă generalizarea lui.

3.2.1. Procesul de exprimare a viziunii Un element fundamental al fazei de planificare este definirea viziunii sistemului. Viziunea reprezintă exprimarea largă a obiectivelor pe termen lung ale sistemului. Câteva exemple de exprimări tipice în ingineria de trafic, ce pot fi luate în considerare, sunt prezentate în continuare: 1. Sistemul va furniza mai puţine întreruperi ale fluxurilor de trafic în regiune. Fluxurile de trafic vor fi coordonate de-a lungul arterelor şi autostrăzilor. Fluxurile de trafic ce se deplasează între nodurile de circulaţie, vor fi controlate într-o astfel de manieră, încât să nu fie afectate de limitările legislative. Mesajele către automobilişti vor fi stabilite, astfel încât să aibă un format standard şi conţinut. 2. Informarea în timp real va fi diseminată către public într-o manieră care facilitează planificarea călătoriilor de la un capăt la celălalt. Informaţia va include durata 125


călătoriei pentru toate modurile de transport, inclusiv timpii necesari deplasării pe jos. Informaţia va fi diseminată folosind internetul. 3. Sistemul va facilita mişcarea sigură şi eficientă a vehiculelor comerciale de-a lungul reţelei rutiere. Mişcarea vehiculelor comerciale va fi simplificată prin staţiile de colectare a taxelor, se reduc întârzierile în staţiile de cântărire şi inspecţie şi furnizează constrângeri extinse privind vitezele de deplasare ale camioanelor. În mod obişnuit, viziunea nu cuprinde mai mult de trei paragrafe, completate de un text potrivit pentru detalierea managementului la nivel local. Acest text trebuie să justifice dezvoltarea viziunii şi să descrie modul în care, utilizatorii sistemului de transport, sunt afectaţi de această viziune. Exprimarea viziunii este importantă din următoarele motive: • Obligă toate agenţiile afectate de implementarea sistemului să fie de acord, în termeni simpli, cu privire la obiectivul principal al sistemului. Nu sunt necesari termeni de specialitate în cazul discuţiilor. • Nivelul de detaliere va angaja cel mai ridicat management – sunt stabiliţi participanţii care trebuie să fie de acord înainte de finalizarea enunţului viziunii. • Dezvoltarea unei viziunii care obligă participanţii să participe la discuţii unii cu ceilalţi. Dacă sunt bine conduse, întâlnirile pentru enunţul viziunii, vor genera dialogul între participanţi, care face cunoscută agenda personală a participanţilor, obiective învecinate şi nevoi funcţionale. • Ajutoarele stabilesc priorităţile şi asigură că sistemul ce urmează a fi dezvoltat răspunde în totalitate nevoilor participanţilor. În stabilirea viziunii pot fi considerate etapele următoare. Identificarea „jucătorilor” – pune în evidenţă cel mai înalt nivel de management. Planificarea reuniunii. În cadrul primei reuniuni participanţii sunt informaţi asupra posibilităţilor, limitărilor şi riscurilor. Descrierea scopului reuniunii. Se defineşte viziunea. Sunt explicate rezultatele dorite. 1. Dacă la reuniune participă mai mult de 10 – 15 persoane, grupul trebuie divizat în subgrupuri (ateliere) pentru a fi mai productive. 2. Fiecare grup are atribuită sarcina de a identifica trei dintre cele mai importante probleme de trafic din regiune. 3. Fiecare grup este instruit să identifice soluţiile tehnice pentru rezolvarea acestor probleme. În această etapă, nu interesează constrângerile legate de buget sau tehnologiile curente. 4. Sunt reasamblate grupurile de lucru pentru a se compara rezultatele lor. Se aleg 5 până la 10 rezultate dintre cele mai amintite. Se analizează rezultatele pentru a fi reţinute. Prin colaborare, sunt dezvoltate 3 -5 seturi de probleme şi soluţii. 5. Sunt discutate 3 până la 5 paragrafe (pentru a se constitui baza pentru enunţul viziunii) care reprezintă obiectivele pe termen lung care se adresează acelor seturi de probleme – soluţii. 6. Se constituie un grup restrâns care va da forma finală a documentului viziunii sistemului. Dacă există, un consultant sau un manager de sistem, deja angajat aceştia trebuie să îndeplinească această responsabilitate. Enunţul realizat ar putea fi similar celui deja amintit. El va fi suficient de specific pentru a ajuta în etapa viitoare de planificare, dar suficient de larg pentru a evita predefinirea soluţiilor tehnice. Declaraţia viziunii sistemului constituie primul pas în dezvoltarea cu succes a unui sistem atât de complex ca cel al sistemelor avansate de transport. 126


3.2.2. DEFINIREA CERINŢELOR SISTEMULUI Cuvântul “cerinţă” este definit ca “o nevoie, o necesitate exprimată”. Un enunţ sugestiv pentru înţelegerea noţiunii de cerinţă ar fi, de exemplu: „Mâncarea este o necesitate. Răbdarea este o cerinţă în învăţare.” Înainte de a decide cine poate fi implicat în sistem, este foarte important să se înţeleagă conceptul de cerinţe de nivel superior. Aceasta necesită să se facă o delimitare între definiţia cerinţei şi definiţia funcţiilor. În termeni ai sistemelor avansate de transport, nevoia de a disemina orarul autobuzelor este o cerinţă. Diseminarea timpilor de sosire a autobuzelor folosind mesaje variabile la oprire este o funcţie. În acelaşi limbaj, “nevoia de a disemina timpii de sosire ai autobuzelor pe ruta autobuzului la toate opririle majore în interiorul oraşului” reprezintă o cerinţă detaliată. Pe de altă parte “nevoia de a disemina timpii de sosire ai autobuzelor” este o cerinţă de nivel inferior. Tabelul 3.6. Definirea cerinţelor şi funcţiilor. Categorie Cerinţe de nivel Cerinţe detaliate aplicaţie superior Detectare mai rapidă a Management Întârzieri reduse pe incidentului. trafic durata incidentelor. Răspuns mai rapid la detectarea incidentului. Informare călători

Diseminarea informaţiilor privind timpii de sosire pentru toate modurile de transport.

Diseminarea legăturilor dintre timpii de călătorie pentru transportul rutier.

Transport public

Încurajarea abonamentelor pentru simplificarea achitării biletului de călătorie.

Simplificarea achitării bietului de călătorie pentru autobuz, tren şi parcare.

Operare vehicule comerciale

Siguranţă sporită în deplasare.

Creşterea siguranţei prin constrângeri stricte legate de mărimea şi greutatea camionului.

Funcţie Comunicare digitală între centrele de management al incidentului. Afişarea pe internet a legăturilor dintre timpii de călătorie. Afişarea pe internet a orarelor autobuzelor pentru diferite trasee. Implementarea sistemului de comerţ electronic pentru achitarea abonamentelor de călătorie cu autobuzul, trenul şi parărilor pentru tranzit. Implementarea sistemului de cântărire din mers. Implementarea sistemelor de detectare a camioanelor înalte.

Eforturile inginerilor de trafic se concentrează încă de la început pentru definirea corespunzătoare a cerinţelor utilizatorilor. În cazul ITS America de exemplu, şi nu numai, sunt definite 32 servicii către utilizatori care se regăsesc în Programul Naţional ITS. Aceste servicii au fost transpuse în mai mult de 100 de cerinţe ale utilizatorilor cu scopul de a răspunde solicitărilor principale privind managementul traficului, dar şi sistemele avansate de control al traficului şi informarea călătorilor. 3.2.3. TRASABILITATEA Trasabilitatea este o caracteristică extrem de importantă a proceselor din ingineria sistemelor. Ea permite inginerului să stabilească cerinţele utilizatorilor printr-o funcţie specifică a sistemului care asigură satisfacerea completă a acestor cerinţe. Reversul este, de asemenea, adevărat. Ea permite ca, având în vedere o cerinţă, să fie stabilite toate funcţiile sistemului, cu scopul de a garanta faptul că nu au fost create funcţii suplimentare.

127


Cerinţele serviciilor către utilizatori pot fi regăsite în documente dedicate trasabilităţii în documentaţia arhitecturii ITS. Tabelul 3.7 prezintă un exemplu pentru pachetul de servicii şi cerinţe ale serviciilor către utilizatori. Tabelul 3.7. Pachetul de servicii şi cerinţe ale serviciilor către utilizatori. Serviciu utilizatori Control trafic Management transport public

Exemple de cerinţe ale serviciilor către utilizatori • •

Controlul traficului va utiliza o funcţie de supraveghere trafic. Supravegherea va include o funcţie de detectare a vehiculelor cu capacitatea de a detecta vehiculele, cu precizie şi în timp real.

•

Va include o funcţie a serviciilor de planificare şi programe pentru a automatiza operaţiunile de planificare şi programare trafic de călători.

Serviciile către utilizatori conţinute în arhitectura ITS la nivel naţional definesc cerinţele de nivel superior identificate de echipa care a creat sistemul. Pe durata etapei de planificare este recomandat ca lista cerinţelor să fie transpusă în definirea funcţiilor de nivel superior. Aceste funcţii sunt numite, în cadrul arhitecturii ITS, specificaţii de proces. Documentaţia de specialitate a sistemelor inteligente oferă în detaliu funcţiile de nivel superior. Acestea reprezintă o descriere scurtă a procesului prezentând activităţile, datele de care este nevoie şi care trebuie furnizate. Fiecare specificaţie de proces include o listă de intrări şi ieşiri ale fluxurilor de date, o descriere legată de cerinţe (pentru trasabilitate) şi fluxurile de ieşire (pentru analiza încărcării). De asemenea, sunt incluse descrieri generale de tipul celor prezentate în exemplele următoare (î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 crossings. The process shall be able to receive both passive (e.g. presence) and active (e.g. tag) data from vehicles. Where any of the data is provided in analogue form, the process shall be responsible for converting it into digital form and calibrating. The converted data shall be sent to other processes for distribution, further analysis and storage. Functional Requirements: This process shall: (a) continuously monitor the solicited data input flows shown above; (b) where necessary convert the data obtained in (a) from analogue to digital form, and calibrate the data; (c) periodically send all of the surveillance data to other processes in the Manage Traffic function via the solicited output data flows shown above; (d) complete a full scan of all inputs and generate the outputs in less than the time interval between successive activations. 128


În exemplul 2, sunt definite două tipuri de date obţinute de la vehicule: date active şi date pasive. Acestea se pot referi la datele transmise de la vehicul sau, la datele despre vehicule, colectate de senzorii plasaţi în infrastructura rutieră. Nu este foarte clar însă dacă, de exemplu, noua tehnologie celulară de localizare geografică a vehiculelor cu ajutorul căreia vehiculele sunt urmărite prin transmisii cu telefoane celulare, poate fi considerată activă sau pasivă. În recomandări nu este stabilită precis tehnologia de achiziţie a datelor, această activitate rămânând în responsabilitatea coordonatorilor proiectului. 3.3. PROCESUL DE PROIECTARE Faza de proiectare a proiectului începe abia după ce a fost identificat bugetul, definite funcţiile de nivel superior şi a fost dezvoltat planul de contractare. Pe durata acestei faze, funcţiile generale sunt transpuse în proiectarea unui sistem fizic care identifică fluxurile de date, arhitectura echipamentelor şi funcţiile detaliate, figura 3.13.

Figura 3.13: Legătura între serviciile către utilizatori şi arhitectura fizică a sistemului ITS.

Acesta activitate poate fi un proces relativ simplu, dar există multe consideraţii de ordin tehnic, incluzând: analiza alternativelor legate de echipament, prototipuri şi dezvoltarea cerinţelor detaliate. Procesul poate fi repetat, funcţie de modelul de proces utilizat. 3.3.1. TRANSPUNEREA CERINŢELOR ÎN FUNCŢII Cerinţele generale şi de detaliu, fără considerarea conexiunilor dintre echipamente şi programe, sunt deja dezvoltate la încheierea procesului de planificare. Însă, nu au fost stabilite aspecte ca: numărul de locaţii ale computerelor, programele instalate pe acestea, interconectarea echipamentelor şi comunicarea dintre ele. Provocarea ingineriei sistemelor pe durata fazei de proiectare, este de a defini această corelaţie, cunoscută ca dezvoltarea arhitecturii fizice a sistemului. Paşii implicaţi în realizarea acestui proces includ: reevaluarea cerinţelor funcţionale şi dezvoltarea fluxurilor de date; dezvoltarea criteriilor de evaluare a calităţii proiectării; crearea şi compararea proiectelor alternative; selectarea alternativei preferate de proiect; identificarea standardelor potrivite; dezvoltarea cerinţelor funcţionale detaliate; gestionarea achiziţiei sistemului. Conceptul de trasabilitate este implementat pe durata acestui proces, obţinându-se informaţii complete privind cerinţele sistemului şi detalii privind funcţiile. Trasabilitatea are o importanţă majoră pentru a garanta că funcţiile sunt îndeplinite pentru toate cerinţele, că există atât sistemele hardware cât şi software pentru realizarea acestora şi au fost elaborate teste pentru a verifica operarea corespunzătoare a sistemului. Trasabilitatea este menţinută prin crearea unei baze de date folosită pentru a genera matricea trasabilităţii. 129


Tabelul 3.8. Exemplu de matrice de trasabilitate. Nr. Nr. Funcţia Cerinţa funcţie cerinţă 1.0 Măsurarea tăriei traficului. Colectarea datelor de trafic de la detectori plasaţi în 1.1 infrastructura rutieră. Procesarea datelor provenite de la detectorii plasaţi în 1.2 infrastructura rutieră. Diseminarea 1.0 condiţiilor de Calculul vitezei medii pe baza datelor înregistrate de 1.2.1. trafic detectorii plasaţi în infrastructura rutieră. Estimarea corelaţiilor între vitezele înregistrate de 1.2.2. detectorii plasaţi în infrastructura rutieră. 1.3 Stocarea corelaţiilor obţinute în baze de date. 2.0 Regruparea datelor pentru afişarea pe internet.

Exemplul din tabelul 3.8 arată un model de matrice pentru un sistem de informare asupra călătoriei cu funcţii complexe, descrise de numere cu o cifră sau două şi funcţii de nivel inferior descrise cu mai mult de două cifre. În acest exemplu, o cerinţă se întinde pe funcţii de nivel superior şi două de nivel inferior. Tabelul 3.9. Matricea de trasabilitate inversă. Nr. Nr. Funcţia Cerinţă funcţie cerinţă 1.0 Diseminarea condiţiilor de trafic. 2.0 Managementul incidentelor. Măsurarea intensităţii 1.0 2.1 Detectarea automată a incidentelor. traficului. Informarea publicului asupra condiţiilor de trafic 2.2 rezultate din incident. 1.0 Diseminarea condiţiilor de trafic. Managementul incidentelor. Colectarea datelor de 2.0 1.1 la detectorii plasaţi în 2.1 Detectarea automată a incidentelor. infrastructura rutieră. Informarea publicului asupra condiţiilor de trafic 2.2 rezultate din incident. 1.0 Diseminarea condiţiilor de trafic. Procesarea datelor 2.0 Managementul incidentelor. provenite de la 1.2 2.1 Detectarea automată a incidentelor. detectorii plasaţi în Informarea publicului asupra condiţiilor de trafic infrastructura rutieră. 2.2 rezultate din incident.

Matricile de trasabilitate sunt elemente importante ale proceselor din ingineria sistemelor. Ele sprijină proiectarea (asigură definirea corectă a funcţiilor pentru fiecare cerinţă), dezvoltarea (furnizează un mecanism de urmărire a stadiului de dezvoltarea programelor) şi testarea (poate fi definit un test pentru fiecare funcţie). Matricea de trasabilitate inversă, tabelul 3.9, este, de asemenea, foarte utilă. Acest tip de matrice poate fi folosit pentru a determina aspectele ce sunt afectate de anumite funcţii. Matricea de trasabilitate inversă este utilă, în mod special, pe durata desfăşurării şi testării, pentru a garanta că au fost luate în considerare toate conexiunile dintre funcţii. 3.3.2. ARHITECTURA ITS În cele prezentate în paragrafele anterioare, procesul a fost centrat pe identificarea cerinţelor utilizatorilor şi funcţiilor complexe, altfel denumite specificaţii. Nu a fost făcută nici o menţiune despre modul în care sunt stabilite funcţiile pentru sisteme şi subsisteme specifice. Identificarea acestor aspecte este cunoscută ca procesul de creare a unei arhitecturi fizice, figura 3.14. 130


Figura 3.14. Procesul de creare a unei arhitecturi ITS.

Figura 3.15. Arhitectura fizică a sistemelor inteligente de transport. 131


Arhitectura fizică a sistemului de transport este asociată cu cele patru tipuri de subsisteme, figura 3.15: subsistemul călătorilor, subsistemul centrelor, subsistemul vehiculelor, subsistemul infrastructurii rutiere. 3.3.2.1. Subsistemul călătorilor Cuprinde echipamentele utilizate de călători pentru a accesa serviciile ITS, atât înainte de efectuarea călătoriei, cât şi pe durata ei. Subsistemul Acces personal la informare permite călătorilor să primească informaţii despre trafic de acasă, de la locul de muncă sau, direct, în zonele generatoare de călătorii. Aşa cum sugerează şi numele, acest subsistem foloseşte instrumente aflate sub control personal. Subsistemul Sprijin la distanţă pentru călători furnizează diseminarea informaţiei către utilizator prin intermediul unor echipamente, cum ar fi, chioşcurile sau monitoarele de informare. Acest subsistem sprijină monitorizarea siguranţei publice prin folosirea camerelor video în circuit închis sau a altor echipamente de supraveghere şi informare, în caz de urgenţă, în zonele de interes public. 3.3.2.2. Subsistemul centrelor Subsistemul centrelor furnizează funcţii de management şi administrare, coordonează conexiunile dintre modurile de transport şi aspectele juridice şi comunică cu sub-sistemele drum, vehicul, călători.

Figura 3.16. Subsistemul centrelor.

Acest subsistem include centrele menţionate în figura 3.16. 3.3.2.3. Subsistemul vehiculelor Subsistemul vehiculului care include sisteme de informare generală a conducătorului auto şi sisteme de siguranţă aplicabile vehiculelor de orice tip.

Figura 3.17. Subsistemul vehiculelor.

132


Cele patru subsisteme vehicule comerciale, vehicule de tranzit, vehicule de intervenţie şi vehicule pentru construcţii şi mentenanţă sunt subsisteme ale flotei de vehicule, adăugând abilităţi ITS unice vehiculelor speciale. 3.3.2.4. Subsistemul infrastructurii rutiere Cuprinde infrastructura rutieră inteligentă distribuită de-a lungul reţelei de transport; operarea infrastructurii rutiere în cazul sistemelor inteligente de transport este guvernată, de obicei, doar de un centru, chiar dacă pot fi conectate centre multiple; interfaţa directă cu vehiculele; Acest subsistem realizează funcţia de supraveghere, furnizează informaţii şi execută 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 parcărilor; verificarea vehiculelor comerciale. Un alt element important al arhitecturii fizice a unui sistem ITS îl reprezintă aşa numiţii terminatori. Terminatorii reprezintă persoanele, sistemele şi mediul general care este în interconectare cu sistemul inteligent de transport.

Figura 3.18. Subsistemul terminatorilor.

Atât arhitectura logică şi cea fizică au acelaşi set de terminatori. Aceştia sunt clasificaţi în patru categorii, astfel: Terminatorii UMANI, în număr de 21 se referă la: • conducătorul auto, • personalul de operare a traficului şi • operatorii sistemului de intervenţie. Pot fi amintiţi în această categorie: administratorul datelor arhivate, conducătorul auto al vehiculului comercial, managerul vehiculului comercial, inspectorul privind operarea vehiculelor comerciale, conducătorul auto, personalul intervenţiilor de urgenţă, operatorul sistemului de urgenţă, personalul centrului de construcţii şi mentenanţă, operatorul parcării, pietonii, administratorul sistemului de taxare, operatorul de taxare, personalul operaţiunilor de trafic, conducătorul vehiculului de tranzit, managerul parcului de vehicule de tranzit, operatorii sistemului de tranzit, utilizatorii traficului de tranzit, călătorii. Terminatorii de MEDIU, în număr de 6, definesc • mediul înconjurător; • drumul şi obstacole potenţiale; • mediul zonelor de securitate, • traficul general, • caracteristicile vehiculelor. Cei 32 terminatori de SISTEM includ sisteme de mesaje variabile, instituţii financiare şi alte vehicule. 12 terminatori aparţin de ALTE SISTEME. 133


TEST 8 1. Ce definiţie consideraţi potrivită pentru noţiunea de „ingineria sistemelor”?

2. Consideraţi că lansarea unui program ITS trebuie să respecte criteriile de inginerie a sistemelor?

3. Reprezentaţi structura piramidală a unui automobil, ca sistem.

4. Care sunt factorii luaţi în considerare în abordarea proceselor din ingineria sistemelor?

5. Enunţaţi câteva cerinţe pentru un sistem de semaforizare.

6. Care sunt modelele de proces din ingineria sistemelor?

7. Care sunt elementele (etapele) comune ale acestor tipuri de modele?

8. Ce înţelegeţi prin „viziune” a unui sistem? Exemplificaţi.

9. Reprezentaţi arhitectura ITS.

10. Cum se face conexiunea dintre sistemele unei arhitecturi ITS?

134

m4 Ingineria Sistemelor Aplicata Transporturilor

Recommend Documents