Sunteți pe pagina 1din 30

UNIVERSITATEA „POLITEHNICA” DIN BUCUREȘTI

FACULTATEA TRANSPORTURI

Departamentul Telecomenzi și Electronică în Transporturi


ITS

Proiect SGBDN

Coordonator științific Student


Prof.dr.ing. MINEA MARIUS Cosmin-Ionuț VOICU

București
2018
Cuprins:

 Stadiul platformelor multimedia de informare a călătorilor în


Europa.

 Standarde utilizate pentru baze de data.

 Harți electronice.

 Studiu privind protocoalele și tehnicile de rutare în sistemele cooperative


VANET.

 Cerințele Utilizatorilor.

 Concluzii
1. Stadiul platformelor multimedia de informare a călătorilor în
Europa.
Pe lângă panourile cu informații amplasate în stațiile mijloacelor de transport, utilizatori
sistemului public de transport sunt informați și prin intermediul platformelor multimedia,
care sunt reprezentate de site-uri web și aplicații mobile.
Astfel sistemul de informare a călătorilor din Londra pune la dispoziția utilizatorilor un site
web unde aceștia își pot planifica o călătorie. Site-ul este foarte ușor de folosit și de
asemenea sugestiv. Poți planifica o călătorie prin alegerea locului de plecare, care poate de
asemenea să fie detectat prin intermediul rețelei mobile sau a GPS-ului, și destinația.
Apăsând butonul de căutare îți sunt afișate toate rutele posibile către acea destinație, alegerea
rutei rămâne la latitudinea utilizatorului.

Figura 1. Platforma web Londoneză de planificare a unei călătorii .

Site-ul web care oferă informații de călătorie în Berlin este mult mai complex, acesta
oferind călătorilor avertismente în cazul în care pe o rută apare lucrări de mentenanță, astfel
utilizatori pot alege o rută alternativă. Acest site este disponibil în două limbi, germană respectiv
engleză. Acesta oferă informații de călătorie, informații despre prețul biletelor de călătorie și
timpi de sosire al mijloacelor de transport. Acesta platformă combină toate mijloacele de
transport inclusiv trenul pentru a oferi o gamă diversă de alternative de călătorie pe distanțe mari.
Figura 2. Platforma web de planificare călătorie Berlin.

Utilizatori transportului public din Budapesta au la dispoziție de asemenea o platformă web


de unde își pot planifica o călătorie. Această platformă combină toate mijloacele de transport
pentru a oferi posibilitatea utilizatorilor de a călători pe distanțe mai mari. Dacă alegem să dăm
click pe ruta unui autobuz ni se va afișa ora la care ajunge autobuzul în fiecare stație. Site-ul are
în componență și o hartă a orașului Budapesta unde îți este prezentată poziția în timp real a
autobuzului. Sistemul de asemenea oferă informații despre modelul autobuzului și dacă acesta
dispune locuri pentru persoane cu dizabilități.

Figura 3. Sistemul de informare a călătorilor în timp real Budapesta .

Platforma web a sistemului de informare a călătorilor din orașul Oslo oferă de asemenea
informații în timp real despre poziția autobuzelor. Acest sistem dispune de un planificator de
călătorie care, asemănător cu sistemele prezentate, combină mai multe mijloace de transport. Și
acest site este tradus și în limba engleză. Și acest sistem dispune de o hartă pentru a arăta în timp
real poziția unui autobuz pe hartă.
Figura 4. Sistem de informare a călătorilor în timp real Oslo.

Acestea sunt doar câteva din orașele care au implementat un sistem de informare a călătorilor
în timp real prin intermediul unor site-uri web.
Alte țări care pun la dispoziție astfel de planificatoare de călătorie sunt: Irlanda: care oferă
informații despre sosirea mijloacelor de călătorie, informații despre prețul unei călătorii și
poziționarea pe hartă a vehiculului; Portugalia; Viena; Ucraina care oferă și o aplicație pentru
mobilele Android.

La nivelul României in Iași sistemul de informare în timp real al călătorilor este realizat prin
integrarea unor măsuri din proiectul Archimedes, respectiv sistemul de management al traficului
– GPS, sistemul de supraveghere video, staţiile de transport public.
asigura informarea a utilizatorilor de mijloace de transport în comun prin:

- afişarea staţiilor pe ecranele din autobuze şi tramvaie, staţia curentă şi următoarele 3


staţii;
- afişarea legăturilor dintre autobuze şi tramvaie pe ecranele din autobuze;
- afişarea autobuzelor si tramvaielor şi ruta pe care merg, dar şi minutele până la sosirea
acestora, în staţiile R.A.T.P.;
- informație în timp real: ora, numărul autobuzului / tramvaiului, mesaje si anunţuri
importante;
- dialog direct cu publicul călător – sistem de mesagerie internă: transmiterea de mesaje
importante, în timp real, dinspre R.A.T.P. şi Primaria Iaşi, către publicul călător (trasee,
investiţii, tarife şi modificări, program);
- sistem de entertainment (știri, meteo, obiective de vizitat etc.) şi informare publică – o
călătorie mai plăcută într-un mediu mai modern, având cele mai noi tehnologii şi tendinţe
în domeniu.
La ora actuala pentru București exista un proiect in lucru pentru a se realiza un sistem de
informare a calatorilor din transportul public.

Figura 5. Macheta aplicație InfoTransApp.

In Brașov sa implementat un sistem automat de taxare, un sistem de raportare, un sistem


de gestiune a resurselor companiei, un sistem de management al vehiculelor, un sistem de
informare a călătorilor prin echiparea staţiilor de călători cu panouri de informare, un sistem
de supraveghere video, un sistem de prioritizare vehicule transport public în intersecţii
semaforizate, un Centru de comandă şi dispecerat la Direcţia Centrală a RAT Braşov,
echiparea a peste 200 de mijloace de transport în comun cu sisteme de monitorizare a
traficului, implementarea unui sistem informatic la Autobază, instalarea a 30 de automate de
vânzare titluri de călătorie în oraș.

Figura 6. Sistemul de informare calatori din orașul Brașov


2. Standarde utilizate pentru baze de data.

2.1 Tehnologia NoSQL


Limbajul SQL a fost inventat în 1970 la IBM. Acest limbaj a fost dezvoltat pentru a lucra cu date
structurate conform modelului relaţional al lui Edgar F. Codd şi reprezintă limbajul standard
pentru bazele de date relaţionale. SQL permite construirea de interogări pentru analiza unor
cantităţi mari de date structurate şi contibuie la buna desfăşurare a activităţilor economice ale
unei companii. Un exemplu concret este reprezentat de obţinerea de indicatori de performanţă
pentru fiecare departament în parte.
Deşi în prezent nu există competitori reali pentru SQL, problema se schimbă în cazul
aplicaţiilor web. În acest caz, nu există o multitudine de asocieri inner şi outer pentru calcule
complexe ci mai degrabă se foloseşte o gândire orientată obiect, îndeosebi datorită MVC
(Model– View–Controller). Pentru a transforma aceste modele orientate obiect în baze de date
relaţionale au loc diverse procese de normalizare ce rezultă în ierarhii complexe de tabele şi
îndepartează întregul model de principiile modelării orientate obiect. Faptul că limbajul SQL
permite interogări dinamice asupra unor seturi de date complexe este nefolositor prin folosirea
unei baze de date SQL doar pentru stocarea persistentă a datelor orientate obiect.

Bazele de date relaţionale tradiţionale nu pot face însă faţă provocărilor actuale aduse de
către Big Data. În ultima vreme bazele de date de tipul NoSQL sunt din ce în ce mai populare
pentru stocarea datelor de mari dimensiuni.
Conform definiţiei date de Rick Cattell, bazele de date NoSQL prezintă şase trăsături de bază:
1. Abilitatea de a scala orizontal pe mai multe servere;
2. Abilitatea de a replica şi distribui datele pe mai multe servere;
3. CLI (call level interface) caracterizat prin simplitate (în contrast cu SQL binding);
4. Un model concurenţial mai slab decat modelul relaţional (ACID);
5. Utilizarea eficientă a indexării distribuite şi a RAM pentru o stocare eficientă;
6. Abilitatea de a adăuga dinamic noi atribute la înregistrările existente.
Bazele de date NoSQL au apărut din necesitatea unor companii precum Google, Facebook sau
Twitter de a manipula cantităţi imense de date cărora bazele de date tradiţionale pur şi simplu nu
le pot face faţă. Aşa că bazele de date NoSQL au fost proiectate pentru a stoca volume foarte
mari de date în general fără o schemă fixă şi partiţionate pe multiple servere. Bazele de date
NoSQL oferă moduri flexibile de lucru, suport pentru copierea datelor mult mai simplu şi mai
uşor, un API simplu, şi coerenţa eventuală a datelor. Bazele de date NoSQL devin astfel NoSQL
(Not Only SQL) sunt baze de date non relaţionale . Principalul avantaj al utilizării bazelor de
date NoSQL este acela că permit lucrul eficient cu date structurate, precum e-mailul, multimedia,
procesoare de text. Bazele de date NoSQL, ca nouă generaţie de baze de date: nu sunt
relaţionale, sunt distribuite, sunt Open Source şi se caracterizează prin scalabilitate orizontală. O
altă caracteristică importantă a sistemelor NoSQL este arhitectura “shared nothing” prin care
fiecare nod-server este independent, nu partajează memorie sau spaţiu.
Bazele de date NoSQL au o structură mai simplă şi o tehnologie diferită pentru stocarea şi
extragerea datelor decât bazele de date relaţionale şi oferă performanţe mai bune pentru analize
în timp real sau pe volume mari de date. Într-o bază de date NoSQL nu există o schemă propriu-
zisă a datelor, ele fiind stocate ca perechi cheie-valoare (foarte eficient şi flexibil, dar datele nu
sunt self-describing), sau de coloane (folosit pentru date împrăştiate), sau document (folosit
pentru depozite XML, dar ineficient ca performanţă), sau graf (folosit pentru traversări
relaţionate, dar ineficient la căutări) .
Astfel mişcarea NoSQL reprezintă o încercare de a depăşi limitările modelului relaţional şi un
pas de trecere către NewSQL şi anume relaţional plus extra funcţionalităţi NoSQL.
Cele mai populare baze de date NoSQL în acest moment sunt: Cassandra, Mongodb, CouchDB,
Redis, Riak, Membase, Neo4j şi HBase.
Pentru a putea exemplifica practic bazele de date NoSQL am ales să analizăm baza de
date NoSQL MongoDB. În opinia noastră acesată bază de date este uşor de folosit pentru
utilizatorii de RDBMS-uri. MongoDB lucrează cu date nestructurate şi organizează aceste date în
format document. Implementarea acestei baze de date este mai uşoară decat un RDBMS
deoarece ea urmăreşte modelul cheie valoare şi nu are nevoie de o schemă predefinită a datelor.
Conceptele acesteia pornesc de la concepte tradiţionale, de aceea întelegerea filosofiei acestei
baze de date este ceva uşor de realizat. Prezentul articol urmăreşte atât prezentarea generală a
bazei de date cât şi instalarea şi utilizarea ei.
MongoDB este o bază de date open-source NoSQL scrisă în C++. Aceasta poate conţine
mai multe baze de date, colecţii şi indecşi. În unele cazuri (baze de date şi colecţii ) aceste
obiecte pot fi create implicit. Odată create, ele se găsesc în catalogul sistemului
db.systems.collection, db.system.indexes. Colecţiile conţin documente (BSON). Aceste
documente conţin la rândul lor mai multe câmpuri. În MongoDB nu există câmpuri predefinite
spre deosebire de bazele de date relaţionale, unde există coloanele care sunt definite în momentul
în care tabelele sunt create. Nu există schemă pentru câmpurile dintr-un document, acestea
precum şi tipurile lor pot varia. Astfel nu există operaţia de „alter table” pentru adăugare de
coloane. În practică este obişnuit ca o colecţie să aibă o structură omogenă, deşi nu este o cerinţă,
colecţiile putând avea structuri diferite. Această flexibilitate presupune uşurinţă în migrarea şi
modificarea imaginii de ansamblu asupra datelor.
2.2 SQL
SQL (Structured Query Language) este limbajul care înglobează mai multe componente,
dintre care cele mai importante sunt: componenta de descriere a datelor (LDD - Limbaj de
Descriere a Datelor), (Data Description Language - DDL) şi componenta de manipulare a datelor
(LMD - Limbaj de Manipulare a Datelor) (Data Manipulation Language - DML).

a. Standardul DATEX II
Implementarea politicii de transport la nivel european i a prevederilor directivei nr. 2010/40/EU
presupune existenta a unui sistem eficient de susținere a mobilității si accesibilitătii. Astfel, a
fost propusă dezvoltarea schimbului de informa ii referitoare la traficul rutier.
Standardul DATEX a fost implementat pentru facilitarea circulației informațiilor între centre de
management al traficului, centre de informare si furnizori de servicii. El constituie o referință̆ în
domeniu pentru aplicațiile elaborate în ultimii 10 ani. Protocolul de schimb al datelor DATEX II
reprezintă a doua generație a standardului, implicând un număr din ce în ce mai mare de factori
implicați în monitorizarea drumurilor. Acest standard a devenit referință pentru toate aplicatiile
care au drept scop colectarea si furnizarea de informatii referitoare la conditiile de desfăsurare a
traficului rutier.
DATEX II este un limbaj electronic standardizat, pentru că facilitează colectarea, prelucrarea si
transmiterea de informatii între furnizori si utilizatori. Datele se referă la următoarele aspecte :
- lucrări de drumuri;
- managementul traficului (manual sau automat);
- informatii despre congestie în trafic;
- controlul fluxului de trafic;
- informatii despre parcare;
- date despre conditiile meteorologice (ploaie, zăpadă, vânt, ceată, praf etc.);
- informatii despre timpi de deplasare între diferite puncte;
evenimente rutiere etc.
A fost dezvoltat si menținut prin intermediul proiectelor europene: Easy Way, Easy Way II, EIP,
EIP +.
Versiunea curenta care a fost publicata este V2.3. Versiunea 3.0 este sub dezvoltare.
Mesajele de avertizare sunt mapate pe standardul de mesaje XML si trimise prin intermediul
HTTP sau WSDL/SOAP.

b. Standardul Transmodel
Transmodel este modelul european de referință a datelor pentru transportul public și constituie o
ofertă către companiile de transport public și alți furnizori de servicii legate de procesul de
transport al pasagerilor (planificare, operare și informare), furnizorilor de produse software care
susțin aceste procese și consultanților și alți experți care acționează în domeniul transportului
public în cel mai larg sens.

Modelul de date de referință, dezvoltat la nivel conceptual, poate sprijini dezvoltarea aplicațiilor
software, interacțiunea sau combinația lor într-un sistem informatic integrat și organizarea și
gestionarea informației sistemului care guvernează utilizarea mediului telematic existent într-o
companie (sau grup de companii) care rulează aplicații informatice care susțin diferitele zone
funcționale ale transportului public.
Modelul de date de referință (Transmodel v6) acoperă următoarele domenii de date:
- Descrierea rețelei: rute, linii, modele de călătorie, modele de sincronizare, modele de
servicii, puncte de oprire programate și locuri de oprire: această parte corespunde
descrierii rețelei ca în Transmodel V5.1 extinsă de părțile relevante ale IFOPT
(EN28701);
- Informații de sincronizare și programare a vehiculelor: timpul de funcționare, călătorii cu
autovehiculele, orarul de zi al vehiculelor;
- Informații oferite pasagerilor: planificări de călătorie in timp real;
- Operațiuni de monitorizare și control: date operaționale zilnice, urmărirea vehiculelor,
acțiunii de control
- Gestionarea tarifelor de călătorie

c. Standardul IFOPT

IFOPT (EN 28701),este un standard european de definire a unui model de date pentru
identificarea obiectelor fixe în transporturile publice (de exemplu, punctele de oprire, zonele de
oprire, stațiile, traseele utilizate de pietoni, intrările etc.), integrat în prezent în EN 12896: 2014.

d. Standardul SIRI
Interfața de servicii pentru informații în timp real (SIRI) specifică un standard de interfață
europeană pentru schimbul de informații despre performanța planificată, curentă sau proiectată a
operațiunilor de transport public în timp real între diferite sisteme informatice.
SIRI cuprinde un set modularizat atent de servicii funcționale discrete pentru operarea sistemelor
de informații publice de transport.
SIRI își propune să integreze cele mai bune standarde naționale și de proprietate din întreaga
Europa, acestea fiind oferite folosind o schemă modernă de tip XML și terminologia și
conceptele de modelare TransModel.
SIRI este destinat să fie utilizat pentru a face schimb de informații între servere care conțin sate
despre vehiculele de transport public în timp real sau date privind timpul de călătorie. Acestea
includ centrele de control ale operatorilor de transport și sistemele informatice care utilizează
informații în timp real ale vehiculelor pentru a opera sistemul, precum și sistemele din aval care
furnizează informații de călătorie publicului prin afișajele de oprire și la bord, dispozitivele
mobile etc.
SIRI utilizează limbajul eXtensible Markup Language (XML) pentru a defini mesajele sale. Se
face o separare atentă între transport (cum sunt transportate datele) și sarcina utilă (datele de
domeniu schimbate)

e. Standardul TPEG2
Sistemul Transport Protocol Experts Group (TPEG) este similar standardului RDS–TMC, cu
deosebirea că datele TPEG sunt independente de client, locație si mijloc de transmitere a
informatiilor. Tehnologia este un instrument modular care cuprinde următoarele aplicații:
- mesaje referitoare la conditiile de desfășurare a traficului, incidente, lucrări, congestie
etc.;
- informatii despre transportul în comun;
- informatii despre parcare etc. Informatiile sunt transmise prin:
- tehnologie radio (DAB – Digital Audio Broadcasting);
- sisteme multimedia (DMB – Digital Multimedia Broadcasting);
- tehnologie video (DVB – Digital Video Broadcasting);
- internet (IP – Internet Protocol).

f. Standardul CORBA

Common Object Request Broker Architecture este utilizat in industrie pe scara larga, initiativa
de standardizare deschisa, dezvoltata de Object Management Group (OMG). Acesta fiind diferit
de modelul traditional client-server, oferind o solutie orientata pe obiecte care nu forteaza nici un
protocol particular si nici un limbaj de programare particular, sistem de operare sau platforma
hardware.
Interface Definition Language (IDL) este un limbaj specific pentru interfete construit pentru a
servicii (metode/functii) ale obiectelor CORBA la distanta.
Object Request Broker este o magistrala pentru obiecte care ofera un mecanism transparent
pentru expedierea cererilor si receptionarea raspunsurilor catre si de la obiecte, indiferent de
mediu si locatia lor. Ofera interfete catre serviciile CORBA care-I permit construirea de medii de
aplicatii distribuite customizate.

Avantajele COBRA:
- Independenta de sistemul de operare si de limbajul de programare
- Integrarea aplicațiilor existente
- Infrastructura bogata in obiecte distribuite
- Transparenta locației
- Transparenta rețelei
- Interfață de invocare dinamica
Dezavantaje COBRA:
- Investiție inițială ridicata. Aplicațiile bazate pe COBRA necesita investiții enorme in ceea
ce privește training-ul si lansarea arhitecturi, chiar si pentru aplicațiile de dimensiuni
mici.
- Disponibilitatea serviciilor COBRA. Serviciile obiect specificate de OMG lipsesc încă in
produse care implementează conceptele.
- Scalabilitatea. Datorita naturii strâns cuplate a arhitecturi COBRA orientate pe legături.
scalabilitatea înaltă așteptată in aplicațiile companiilor poate sa nu fie atinsa.

g. DAB
DAB este imun la sursele de interferente fata de un radio conventional. Daca ascultati un radio in
masina se observa ca receptia este influentata de prezenta copacilor sau a cladirilor aflate pe
traseu. In oras semnalul este distorsionat datorita receptiilor multiple generate de reflexia
semnalului de catre cladiri. Modul de transmisie in cazul DAB a fost in asa fel gandit incat
receptia se face pe mai multe purtatoare care sunt selectate de catre un processor aflat in aparatul
de receptie incat este demodulata acea purtatoare care este de calitatea cea mai buna.
Conform specificatiilor tehnice elaborate a fost aleasa banda de frecventa BIII 174- 240 Mhz si
banda L 1,452-1,466 Ghz pentru emisie terestra ( T-DAB ) respectiv banda L 1,468-1,490 Mhz
pentru satelit ( S-DAB ).
3. Harți electronice.
Din punct de vedere al utilizarilor pentru navigatie, la ora actuala exista doua tipuri de harti
electronice, si anume:
– Hartile Raster – care sunt alcatuite din matrici de elemente care genereaza pixeli
alb-negru sau color, in functie de elementele matricii.
– Hartile Vectoriale – sunt generate de matrici de date mult mai complexe, care
practic vor genera puncte, linii, suprafete, text.
Avantajele hartilor de tip Raster sunt urmatoarele:
– Utilizarea familiara deoarece foloseste aceleasi simboluri si culori ca si hartile de
hartie;
– Sunt copii exacte ale hartilor de hartie avand aceeasi relevanta si integritate;
– Utilizatorul nu poate omite din neglijenta informatii de navigatie de pe display;
– Costuri de producere reduse in comparatie cu hartile de tip vectorial;
– Posibilitatea utilizarii cataloagelor oficiale pentru harti pe plan global, de exemplu
hartile ARCS au acoperire aproape globala;
Dezavantajele hartilor de tip Raster:
– Utilizatorul nu poate particulariza modul de dispunere;
– La utilizarea suprapunerii vectoriale pot aparea umbre pe imagine;
– Nu pot fi intrebuintate fara o baza de date aditionala cu un sistem de referinta
comun;
– Nu pot furniza in mod direct indicatii si avertizari pentru utilizator
Figura 7. Hărți de tip Raster

Figura 8. Hărți de tip Raster

Avantajele hartilor Vectoriale sunt:


– Asezarea informatiilor in directoare permite selectarea datelor afisate;
– Modul de afisare poate fi personalizat de catre utilizator;
– Posibilitatea de modificare a scarii de expunere fara distorsionarea imaginii;
– Indicatiile si avertizarile pot fi furnizate in situatii periculoase, cum ar fi depasirea
conturului de siguranta;
– Obiectele pot fi ilustrate utilizand diferite simboluri ca cele utilizate in hartile
Raster sau de hartie;
– Informatia din harta poate fi corelata cu alte echipamente cum ar fi radarul ARPA.
Dezavantajele hartilor de tip Vectorial:
- tehnic sunt mult mai complexe;
- au costuri de productie ridicate si timp indelungat de producere;
- acoperirea nu este inca globala;
- este dificil de asigurat calitatea si integritatea informatiei vectoriale afisate;
- instruirea pentru utilizarea lor este mult mai complexa decat pentru hartile tip
Raster.

Figura 9. Harta de tip Vectorial.

Exista doua formate oficiale pentru hartile Raster:


– Harti raster BSB, care contin toate datele aflate in hartile pe suport de hartie emise
de NOAA (National Oceanic and Atmospheric Administration), incluzand
corectiile emise saptamanal.
– UKHO – ARCS (United Kingdom Hydrographic Office – Admirality Raster
Chart Service) (Serviciul pentru harti Raster al Amiralitatii Britanice) si AHO
(Australian Hydrographic Office) (Oficiul Hidrografic Australian) produc harti
Raster conform standardelor si utilizand hartile pe suport de hartie editate de
Amiralitatea Britanica.
Echipamentul ECDIS este un sistem informational de navigatie cuprinzand parte hardware,
vizualizare software si harti vectoriale oficiale, toate acestea trebuind sa fie conforme cu
standardele cerute pentru acest tip de echipament, care pe langa alte aspecte cuprind standardele
referitoare la structura informatiei din harti, cerinte minime de vizualizare si specificatiile
minime ale echipamentului.
3.1 Servicii webmapping

Serviciile de webmapping funcționează după principii și protocoale de comunicatie similare


serviciilor web clasice (XML-RPC, UDDI, WSDL, SOAP). Rolul acestor este deosebit de
important în contextul actual, cînd asistăm, pe de o parte, la o expansiunea continuă a surselor și
canțității de date geospațiale stocate, iar pe de altă parte, la o creștere a nevoii de a accesa aceste
date. Privit sub acest aspect, WMS joacă un rol dublu:

 facilitează accesul consumatorilor la surse de date aflate la distanță;


 asigură furnizorilor o metodă standardizată de partajare a datelor;
În principiu, standardul WMS este adresat programatorilor care dezvoltă aplicații client
sau server, cu suport pentru WMS. În acest sens oferă descrieri tehnice a modului în care
trebuiesc implementate metode pentru:

 interogarea serverului pentru a obține o listă a tipului de informații pe care il poate livra
(GetCapabilities);
 solicitarea și transferarea unei harți/set de date (GetMap);
 obținerea informații asociate unei hărți/entități (GetFeatureInfo).

Avantajele majore ale utilizării unei metode standardizate de partajare/accesare a datelor


geospațiale constau în sporirea producțivității (eliminarea timpilor necesari dezvoltării
unei metode proprii) și asigurarea interoperabilității cu restul aplicațiilor compatibile
WMS. Utilizatorii finali sînt cei mai cîștigați, putînd să suprapună și să interogheze, într-
o manieră transparentă, hărți aflate pe mai multe servere. În momentul de față există o
multitudine de soluții, comerciale (Ex: Ionic, ESRI) și open-source (Ex: Mapserver,
Geoserver, uDig, gvSIG, JUMP, QuantumGIS, GRASS, degree), atît pentru partea de
client cît și pentru cea de server.

WMS produce hărți georeferențiate, în format digital (raster: PNG, GIF, JPEG sau
vector: SVG, WebCGM). Acestea pot fi vizualizate sau interogate în diferite contexte.
Prin utilizarea formatelor vectoriale sau a celor raster ce suportă transparență (GIF, PNG)
este posibilă combinarea mai multor seturi de date pentru a forma o singură hartă.
Principala carență a WMS este dată de imposibilitatea editării datelor. Pentru a suplini
acest minus, OGC a dezvoltat standardul complementar Web Feature Service (WFS).

Serverele WMS interacționează cu clienții prin intermediul protocolului HTTP. Aplicația


client poate fi o distribuție GIS desktop sau o aplicație de webmapping.

Figura 10. Accesarea datelor prin intermediul WMS.

4. Studiu privind protocoalele și tehnicile de rutare în sistemele cooperative


VANET.

Retele de comunciatie VANET sunt retele auto-organizate, ce permit vehiculelor sa comunice


intre ele, fara a fi necesara o infrastructura specifica. Acestea sunt conforme cu standardul de
comunicatie wireles IEEE 802.11p, ce defineste norme de siguranta pentru circulatia vehiculelor
si alte aplicatii de trafic. Comisia Federala de Comunicatii (FCC) a alocat o latime de banda de
75MHz, la o frecventa de 5.9GHz pentru comunicatiile de raza scurta intre vehicule (V2V) sau
cele intre vehicule si infrastrucuta (V2I) – definite anterior. Retelele VANET utilizeaza
comunicatie pe raza scurta DSRC (1000m) atat pentru V2V cat si pentru V2I.

Scopul retelelor VANET este de a forma, analiza, dirija si a asigura un sistem de transport
inteligent (ITS).
4.1 Arhitectura VANET
In cadrul retelelor VANET, fluxul de informatii poate fi difuzat, colectat si analizat prin
intermediul infrastructurii existente, prin utilizarea retelelor ad hoc sau prin combinarea celor
doua tehnici.

Clasificarea retelelor VANET:


- Retele strict celulare;
- Retele strict ad hoc;
- Retele ad hoc hibride.
Retelele strict celulare sunt destinate fluxului de date genetat de partea de infotainment –
navigare web, informatii de presa, informatii de trafic, informatii de vreme, download, navigare
web etc. Acest tip de retele mai poarta si denumirea de WLAN insa au dezavantajul major de a
depinde de existenta infrastructurii fixe.

Figura 11. Retea strict celulara

Limitarile acestui tip de retea pot fi depasite prin utilizarea unei retele de tip strict ad hoc, bazata
exclusiv pe comunicatie intre vehicule. Raza limitata de transmisie si mobilitatea ridicata
cauzeaza schimbari rapide de topologie in retea, fapt ce poate cauza erori de routare precum si
probleme de partitionare.

Figura 12. Retea strict ad-hoc


Pentru a beneficia de avantajele ambelor tipuri de retele, s-a propus utilizarea un retele ad hoc
hibride, ce combina cele doua tipuri de retele anterior prezentate.
Figura 13. Retea ad hoc hibrida.

O serie de studii, au demonstrat valoarea factorului de atenuare al ratei de transmisie a datelor in


functie de distanta si obstacole.

Protocoalele de rutare bazate pe pozitie utilizeaza pozitia geografica a acestora ori de cate ori
nodul sursa comunica cu nodul destinatie, calea dintre cele doua fiind stabilita prin GPS sau alte
servicii de localizare.
Atunci cand nodul sursa transmite un pachet de date catre un nod receptor, se stabileste calea
fluxului de date in functie de locatia celor doua, si de distanta dintre acestea (se verifica daca
nodul sursa si nodul destinatie se afla in raza de transmisie). Nodul sursa transmite mesajul catre
nodul vecin aflat in raza de transmisie, care la randul sau paseaza mesajul catre nodul vecin pana
la atingerea nodului destinatie.
In protocoalele de rutare bazate pe pozitie, ignorarea informatiilor legate de fluxul de trafic poate
degrada performanetele de transmisie mesajelor prin accesarea unor noduri redundante, fapt ce
conduce la intarzieri ce pot avea urmari grave in trafic.
TFOR este un protocol de rutare destinat unui scenariu ce include existenta unui sistem inteligent
de gestiune si control al traficului atat din mediul urban cat si din cel rural. In cadrul acestui
protocol, liniile de transmisie sunt asemanate drumurilor bidirectionale cu mai multe benzi.
Prin intermediul unor algoritmi specifici, se determina ce intersectii trebuie degrevate de trafic
respectiv ce intersectii pot suporta trafic suplimentar. Acest protocol utilizeaza informatii in timp
real din satelit pentru determinarea fluxului de trafic. Se creaza astfel celule de trafic cu
destinatie (sau cale de rulare) partial comuna in functie de valorile de flux receptionate. Celulele
de trafic sunt conduse de un lider (un vehicul aflat in centrul celulei) care genereaza permanent
semnale ce contin informatii despre numarul de vehicule ce se deplaseaza in cadrul celulei catre
destinatie, numarul de vehicule detectate ce se deplaseaza in sens invers celulei, un id al rutei, un
id al celului precum si coordonatele celulei. Si in cadrul acestei metode sunt prezente tehnici de
recuperare a cailor optime de rulare catre destinatie (carry-and-forward technique).

5. Cerințele Utilizatorilor.

Cerintele Utilizatorului Functiile Asociate


10.2.0.1 Sistemul trebuie sa fie capabil sa ofere 4.7.1 Furnizeaza o interfata calatorului ce
ambele tipuri de planificare calatorie: spontan sau utilizeaza serviciul on-demand
planificat 4.7.2 Planificarea serviciului on-demand
4.7.3 Implementarea serviciului on-demand
4.7.5 Furinizeza o interfata operatorului
serviciului on-demand
10.2.0.2 Sistemul trebuie sa fie capabil sa ofere o 4.7.1 Furnizeaza o interfata calatorului ce
varietate de metode de cautare a calatoriei utilizeaza serviciul on-demand
4.7.1 Furnizeaza o interfata calatorului ce 4.7.2 Planificarea serviciului on-demand
utilizeaza serviciul on-demand
4.7.2 Planificarea serviciului on-demand
10.2.0.3 Sistemul trebuie sa fie capabil sa 4.7.2 Planificarea serviciului on-demand
furnizeze acces la o varietate de destinatii pe o
larga arie geografica4.7.2 Planificarea serviciului
on-demand
10.2.0.4 Sistemul trebuie sa fie capabil sa 4.7.2 Planificarea serviciului on-demand
furnizeze legaturii cu serviciile de transport
interurbane si regionale
10.2.0.5 Sistemul trebuie sa ofere calatorului o 4.7.1 Furnizeaza o interfata calatorului ce
interfata care sa fie simpla ne necisitand utilizeaza serviciul on-demand
completarea multor campuri pentru a planifica o
calatorie. De asemenea sistemul trebuie sa accepte
o varietate de metode de plata

10.2.1.3 Sistemul trebuie sa ofere toate 4.7.1 Furnizeaza o interfata calatorului ce


informatiile necesare pentru a pregatii o calatorie utilizeaza serviciul on-demand
10.2.1.2 Sistemul trebuie sa prezica timpul 4.7.2 Planificarea serviciului on-demand
necesar pentru a realiza o călătorie particulara

10.2.1.4 Sistemul trebuie sa fie capabil sa 4.7.2 Planificarea serviciului on-demand


furnizeze un serviciu in care calatori asteapta o
perioada minima pentru ca raspunsul cereri sa fie
indeplinit adica vehiculul pubilic sa ajunga

10.2.1.6 Sistemul trebuie să fie capabil sa 4.7.4 Monitorizarea serviciului on-demand al


localizeze și sa identifice vehiculele responsive la vehiculului
o cerere de transport public

10.2.1.7 Sistemul trebuie să fie capabil sa 4.7.3 Implementarea serviciului on-demand


planifice o călătorie on-demand în timp real

10.2.1.8 Sistemul trebuie să fie capabil sa 4.7.2 Planificarea serviciului on-demand


planifice calatoriile vehiculelor într-un timp optim
10.2.1.9 Sistemul trebuie să ofere posibilitatea 4.7.1 Furnizeaza o interfata calatorului ce
calatorului sa specifice dacă are nevoi speciale utilizeaza serviciul on-demand
cum ar fi: copii, dizabilitati etc.
10.2.2.1 Sistemul trebuie să fie capabil sa ofere o 4.7.3 Implementarea serviciului on-demand
comunicatie duplex intre vevicule și centrul de 4.7.4 Monitorizarea serviciului on-demand al
control
vehiculului
10.2.2.2 Sistemul trebuie sa ofere o comunicatie 4.7.3 Implementarea serviciului on-demand
duplex de voce intre vehicul și centrul de comanda 4.7.4 Monitorizarea serviciului on-demand al
vehiculului
10.2.3.1 Sistemul trebuie să fie capabil sa îl 4.7.3 Implementarea serviciului on-demand
informeze pe șofer cu privire la ruta optima, cu 4.7.4 Monitorizarea serviciului on-demand al
privire la un anumit criteriu ales.
vehiculului
10.2.4.1 Sistemul trebuie să fie capabil sa ofere 4.7.4 Monitorizarea serviciului on-demand al
statistici în legătura cu modul de utilizare vehiculului
4.7.5 Furinizeza o interfata operatorului
serviciului on-demand
10.2.4.2 Sistemul trebuie să fie capabil sa ofere 4.7.4 Monitorizarea serviciului on-demand al
statistici în legătura cu nivelul de satisfactie al vehiculului
utilizatorilor
4.7.5 Furinizeza o interfata operatorului
serviciului on-demand
Fig 14. Cerintele Utilizatorului

5.1 Arhitectura Funcțională

Fig.15. Arhitectura funcțională si funcțiile asociate


Descrierea funcțiilor asociate:

4.7.1 Furnizeaza o interfata calatorului ce utilizeaza serviciul on-demand.

1) Un HMI prin care călătorii înaintea călătoriei pot solicita un serviciu la cerere pentru o
parte din călătoria sa sau pentru întreaga călătorie.

2) HMI-ul ii permite calatorului sa introduca informații cu privire la călătoria dorita, cum


ar fi originea, destinația, timpii de sosire plus alte informații relecvante cum ar fi: posesia de
bagaje, călătoria cu copii, călătoria cu persoane cu dizabilitati etc.

3) O data ce calatorul a acceptat serviciul propus, HMI-ul va permite de asemenea să se


solicite plata serviilor și să se poată confirme acceptarea doar după ce plata a fost finalizata.

4) O interfata separata prin care plățile pt fi efectuate printr-o metoda sigură.

4.7.2 Planificarea serviciului on-demand

1) Capacitatea de a planifica serviciile on-demand conform criteriilor introduse de


călător în formularul de pre călătorie.

2) Capacitatea de a planifica serviciile folosind cerintele calatorului, plus datele despre


reteaua rutiera, conditiile curente de trafic, serviciile curente programate si serviciile oferite de
alte moduri de transport.

3) Capacitatea de a planifica servicii folosind rute care sunt cele mai eficiente.

4) O data ce ruta și costul au fost determinate acestea sunt trasmise către functionalitatea
de HMI a calatorului.

5) Atunci cand informațiile sunt confirmate de către călător acestea sunt trimise
functionalitati de implementare.

6) În cazul în care serviciul este respins, este posibil să se recalculeze traseul și ceilalți
parametrii înainte ca aceștia să fie trimiși către functionalitatea interfetei de călătorie.
4.7.3 Implementarea serviciului on-demand

1) Capacitatea de a implementa serviciul conform cu cererea confirmată de către călător.

2) Pentru punerea în aplicare a unui serviciu, este posibil să se utilizeze vehiculul și


șoferul cel mai adecvat și să se furnizeze șoferului detaliile serviciului.

3) O parte a punerii în aplicare a serviciului implica, de asemenea, furnizarea unei


călătorii care are o anumita ora de sosire a vehiculului care îl va prelua pe călător.

4) În timpul punerii în aplicare a serviciului, exista posibilitatea de a lua legătura cu


șoferul vehiculului pentru a cunoaște poziția exactă a vehiculului.

5) În cazul în care vehiculul este în intarziere acestuia ii se poate aplica o prioriate în


scopul de a fi în programul de timpii planificat.

6) Posibilitatea de a propune modificari la traseul de serviciu planificat de către


conducătorul vehiculului, dacă acest lucru va inbunatati performantele serviciului.

7) Capacitatea de a transmite starea de defect a vehiculului către centrul de control.

8) Capacitatea de a creea și stoca detalii privind performanța livrarii de serviciilor și a


vehiculelor implicate, astfel încât acestea sa poată fi trimise functionalitatii interfetei cu
operatorul dacă acesta le solicita.

4.7.4 Monitorizarea serviciului on-demand al vehiculului

1) Capacitatea de a monitoriza starea vehiculului care furnizeaza serviciul la cerere.

2) Un HMI prin care conducătorul vehiculului poate schimba mesaje (voce/date) cu


functionaliteatea de implementare.

3) Capacitatea de a include o interfata separata prin care informațiile pot fi furnizate


pasagerilor, inclusiv informații cu privire la timpii de sosire.
4) Capacitatea de a furniza informații cu privire la stare vehiculului și numărul de
pasageri la functionalitatea de implementare și de a menține o evidenta a modului în care
serviciile au fost livrate către vehicul.

4.7.5 Furinizeza o interfata operatorului serviciului on-demand

1) Un HMI prin care operatorul serviciului care ofera transport public la cerere poate
gestiona prestarea de servicii.

2) HMI-ul permite operatorului sa stabileasca criteriile utilizate pentru planificarea


serviciului la cerere, sa gestioneze utilizarea unitatilor de stocare și a vehiculelor și sa obțină
access la rapoarte privind livrarea de servicii.

5.2. Arhitectura Fizica


Arhitectura fizică, orientată pe proiectarea sistemului, distribuie procesele definite de arhitectura
logică a subsitemelor fizice, pe baza specificaţiilor proceselor funcţionale şi a locului unde trebuie
efectuate funcţiile.

O arhitectură fizică defineşte şi descrie modul în care componentele arhitecturii funcţionale pot fi
grupate, pentru a forma entităţi fizice. Principalele caracteristici ale acestor entităţi sunt, în primul
rând, faptul că ele furnizează unul sau mai multe dintre serviciile ce sunt cerute de către necesităţile
utilizatorilor iar, în al doilea rând, faptul că ele pot fi create. Acest proces de creare poate implica
entităţi fizice, cum ar fi structuri amplasate pe drum şi diferite forme de echipamente, entităţi care
nu sunt fizice, cum ar fi software-ul, sau combinaţii ale celor două. În arhitectura fizică ITS aceste
entităţi fizice sunt numite „sisteme etalon”.

Toate „sistemele etalon” pot fi compuse din două sau mai multe subsisteme. Un subsistem execută
una sau mai multe sarcini definite şi poate fi oferit ca un produs comercial. Fiecare subsistem poate
fi compus din una sau mai multe părţi ale arhitecturii funcţionale (funcţii şi depozite de date) şi
poate comunica cu alte subsisteme şi cu unul sau mai multe terminale. Aceste comunicaţii pot fi
furnizate prin folosirea fluxurilor fizice de date.
Fig.16. Arhitectura fizica a sistemului de informare calatorii de pe dispozitivele mobile.

Pentru informarea calatorilor la nivelul autovehiculul sistemul instalat are următoarea schema
bloc:

antena
Display Informare
Calatori Autobuz
Modul
GPS

Stocare
Unitate centrala Modul
Date
3G/4G
Local

Sursa Alimentare
5.3 Arhitectura de comunicatie
O arhitectură de comunicaţie defineşte şi descrie mijloacele care asigură schimbul de
informaţii dintre diferitele părţi ale sistemului. Acest schimb de informaţii este realizat folosind
fluxurile fizice de date descrise în arhitectura fizică. Arhitectura de comunicaţie defineşte şi descrie
mijloacele prin care sunt realizate fluxurile fizice de date pentru unele dintre „sistemele etalon”
din arhitectura fizică ITS.

O analiza a fluxurilor fizice de date ce vor duce la identificarea caracteristicilor legaturilor


fizice prin care se vor vehicula datele, de exemplu :

 Tipul datelor vehiculate (date brute, imagini, voce etc.)


 Modul fizic pentru transferul datelor (radio, cablu, fibra optica)
 Cerinte de securitate (accesul la bazele de date, securitatea transmisiilor de
date)
 Cerinte pentru capacitatea de transfer a datelor (rata de transfer)
5.4. Arhitectura Organizationala
Analiza actorilor implicaţi nu se rezumă numai la cei care operează sistemul ci, are în vedere şi
actorii implicaţi în toate fazele proiectului de dezvoltare, implementare şi operare a sistemului.

Organizaţie Strategie Arhitectura Finantare Proiect Implementare Operare

Instituţii europene C C R I I I

Autorităţi publice şi locale R C R I I I

Consultanti(RATB) R R I A I I

Proiectanţi (UTI)
C C I R A A

Furnizori (UTI)
I I I A R A

Operatori (RATB)
R A C I R R
Călători (utilizator sistem)
I I I I - I

Fig.17 Matricea RACI

Pentru o înţelegere şi definire cât mai exactă a relaţiilor ce apar între entităţile organizatorice
implicat în sistemul ITS, se vor defini mai multe astfel de matrice de alocare a responsabilităților
pentru diferitele aspecte legate de sistemele inteligentede transport. Dintre acestea cele mai
importante sunt: operarea, întreţinerea, colectarea beneficiilor, dezvoltare şi extindere. Aşa cum se
poate observa în tabelul de mai sus, responsabilităţile în implementarea unui sistem inteligent de
transport sunt: responsabil (R) – acea entitate care are responsabilitatea îndeplinirii unei activităţi,
implicat (A) – participă la realizarea unei activităţi sau acţiuni, consultat (C) – este consultat cu
privire la o acţiune sau activitate din proiect şi informat (I) este informat cu privire la o activitate
a proiectului.

5.5 Arhitectura de Securitate


Securitatea, în acest context, reprezintă protejarea persoanelor, a informaţiilor vehiculate în
activităţile specifice transportului, a vehiculelor/ navelor şi a infrastructurii de transport (căi de
rulare/ navigare, terminale, poduri, tuneluri şi alte componente ale sistemului de transport).

Sistemele ITS sunt subiectul ameninţărilor de securitate ca şi celelalte sisteme care utilizează
tehnologia informaţiei, telecomunicaţii şi electronică, iar soluţiile care vizează contracararea
atacurilor de securitate sunt în special similare cu cele dezvoltate până în acest moment în alte
domenii care utilizează aceste tehnologii.

Securitatea pentru domeniul ITS are două componente majore:


 Securizarea ITS (S-ITS): sistemele ITS trebuie să fie disponibile pentru realizarea
funcţiilor lor şi toate informaţiile şi componentele lor să fie protejate la ameninţările de
securitate. Aceasta este abordarea internă/ intrinsecă a securităţii sistemelor inteligente de
transport.
 Ariile ITS de securitate (ITS-S): sistemele inteligente de transport trebuie să
îmbunătăţească securitatea transportului pentru modul respectiv de transport. Aceste
sisteme trebuie să ajute şi să ofere suport celorlalte componente ale sistemului de transport
pentru îmbunătăţirea securităţii acestuia. Aceasta este abordarea externă/ extrinsecă a
securităţii sistemelor inteligente de transport.
6. Concluzii
Sistemele Inteligente de Transport oferă prin intermediul tehnologiei informației și a
sistemelor de comunicații un transport mai sigur, mai eficient și confortabil. În mod particular
Sistemul de informare a călătorilor în transportul public este o aplicație SIT, aceasta oferind
utilizatorilor de transport public diverse informații cu privire la sosirea mijlocului de transport
sau rute alternative în cazul în care acesta întârzie. Călătorii pot primi aceste informații prin
intermediul mai multor mijloace de informare cum ar fi panouri LCD sau LED amplasate în
stații sau prin intermediul unei pagini web sau chiar prin intermediul unei aplicații mobile.
Pentru a realiza funcțiile descrise mai sus sistemul de informare a călătorilor are ca date de
intrare informațiile de la receptori GPS de pe vehicul care transmite centrului de management
poziția curentă a vehiculului și informații de la cititorul de etichete RFID care transmite poziția
unui vehicul la un anumit moment dat, ca date de ieșire avem informațiile care vin de la centrul
de management către panourile informative, aplicațiile mobile sau chiar un site web.
Comunicația între vehicul, centru de management și clientul final se realizează prin intermediul
tehnologiei wireless sau a ethernet-ului. Tehnologiile wireless cuprind: tehnologia GPRS,
ZigBee, și Bluetooth.
Acest sistem a fost implementat în mai multe țări din Europa printre care și în România în
orașul Brașov. Sistemele implementate în Europa se deosebesc de cel implementat în Brașov prin
faptul că pun la dispoziția călătorilor site-uri web unde aceștia își pot planifica o călătorie, pot
alege cea mai scurtă cale de a ajunge de la un punct A la un punct B. Spre exemplu sistemul de
informare a călătorilor implementat în Berlin oferă pe lângă informațiile menționate mai sus și
informații despre eventualele lucrări de mentenanță a drumului care se realizează pe o linia unui
vehicul, astfel utilizatori sistemului de transport public pot alege cel mai avantajos mijloc de
transport.
Majoritatea sistemelor de informare a călătorilor din transportul public folosesc ca metodă de
identificare a vehiculului localizarea prin intermediul poziționări GPS și în sistemele mai vechi
din Londra și București se folosesc balizele radio pentru a identifica poziția la un anumit moment
a unui vehicul. Având în vedere popularitatea identificări obiectelor prin etichete RFID,
sistemele de informare a călătorilor au implementat de asemenea această metodă pentru a crește
precizia identificări și a calibra sistemul la un anumit moment de timp. Această metodă de
identificare a vehiculelor lucrează în paralel cu sistemul de identificare prin GPS.
Prin implementarea unui sistem de informare a călătorilor în timp real, utilizatori
transportului public au mult mai multă încredere în furnizorul de transport, își pot planifica
călătoria cu mult timp înainte, pot alege un mijloc de transport alternativ în cazul în care intervin
întârzieri și nu în ultimul rând transportul public devine un transport eficient și inteligent.
Consider că un furnizor de transport public trebuie să aibă în vedere faptul că călători au dreptul
să le fie furnizate informații despre ora la care sosește un anumit vehicul. De asemenea un sistem
de informare creează printre călători un sentiment că timpul se scurge mai ușor

7. Bibliografie.

1) http://curierul-iasi.ro/sistem-de-informare-a-calatorilor-transportului-public-6165
2) http://www.transmodel-cen.eu

3) http://erticonetwork.com/eu-commission-adopts-datex-ii-format-for-real-time-traffic-
information-services/

4) https://eur-lex.europa.eu/legal-content/RO/TXT/?uri=CELEX%3A32016D0209

5) http://www.datex2.eu/user-forum/2_Bruns_SIRI.pdf

6) http://web.info.uvt.ro/~petcu/distrib/TDS1-RO.pdf

7) http://www.antech.ro/pdf/RADIO_DIGITAL_DAB.pdf

8) Lucrare de licență, Voicu Cosmin Ionuț, 2017. Sisteme de informare a calatorilor in


transportul public.

9) http://www.geo-spatial.org/articole/i-servicii-web-geospatiale-wms

10) https://ruter.no/en/journey-
planner/Stoppested/(3010005)Tollboden/Avganger/#st:1,sp:0,bp:0