UNIVERSITATEA „POLITEHNICA” DIN BUCUREȘTI

FACULTATEA TRANSPORTURI

Departamentul Telecomenzi și Electronică în Transporturi

Sisteme Inteligente pentru Transporturi

PROIECT
ARHITECTURI ALE SIT

Coordonator științific Masterand

Conf. Dr. Ing. Ec. Florin Codruț Ing. Andrei – Cristian SIMION
NEMȚANU

București
2020
UNIVERSITATEA „POLITEHNICA” DIN BUCUREȘTI
FACULTATEA TRANSPORTURI

Departamentul Telecomenzi și Electronică în Transporturi

Sisteme Inteligente pentru Transporturi

Analizarea evenimentelor
surprinse de centrul de
control al traficului

Coordonator științific Masterand

Conf. Dr. Ing. Ec. Florin Codruț Ing. Andrei – Cristian SIMION
NEMȚANU

București
2020
Cuprins

Capitolul 1. Arhitectura funcțională............................................................................ 1

1.1 NEVOILE UTILIZATORULUI ........................................................................................... 1

1.2 CAPABILITATEA SISTEMULUI ....................................................................................... 1

1.3 DIAGRAMELE SISTEMULUI DORIT................................................................................. 9

1.3.1 Diagrama 5.1.1.2 .................................................................................................... 9
1.3.2 Diagrama 7.1.3.3 .................................................................................................. 10
1.3.3 Diagrama sistemului dorit .................................................................................... 11

Capitolul 2. Arhitectura fizică .................................................................................... 13

2.1 ECHIPAMENTE NECESARE .......................................................................................... 13

2.2 CONFIGURAREA SISTEMULUI DORIT ........................................................................... 14

Capitolul 3. Arhitectura de comunicații .................................................................... 16

3.1 CONEXIUNI ................................................................................................................ 16

3.2 DETALII DESPRE CONEXIUNI ...................................................................................... 16

3.2.1 Infrastructura orașului........................................................................................... 16

3.2.2 Sistem de notificare intern .................................................................................... 17
3.2.3 Sistem de avertizare și alerte de urgență .............................................................. 17
Capitolul 4. Arhitectura organizațională .................................................................. 18

4.1 ROLURI ȘI RESPONSABILITĂȚI .................................................................................... 18

4.2 ALOCAREA RESPONSABILITĂȚILOR ............................................................................ 18
Capitolul 5. Securitate ................................................................................................. 20

5.1 DEFINIȚII ................................................................................................................... 20

5.2 CLASIFICĂRI .............................................................................................................. 21

5.3 SECURITATEA SISTEMELOR ........................................................................................ 21

Capitolul 6. Concluzii .................................................................................................. 23

Bibliografie .............................................................................................................................. 24
Anexa 1. Browsing tool........................................................................................................... 25
Lista materialului grafic

FIGURA 1. DIAGRAMA 5.1.1.2 ........................................................................................................................... 9

FIGURA 2. DIAGRAMA 7.1.3.3 – PARTEA I.................................................................................................... 10

FIGURA 3. DIAGRAMA 7.1.3.3 – PARTEA II .................................................................................................. 10

FIGURA 4. DIAGRAMA 7.1.3.3 – PARTEA III ................................................................................................. 11

FIGURA 5. DIAGRAMA 7.1.3.3 – PARTEA IV ................................................................................................. 11

FIGURA 6. SCHEMA BLOC A SISTEMULUI DORIT ..................................................................................... 12

FIGURA 7. CAMERE VIDEO [2]........................................................................................................................ 13

FIGURA 8. CENTRUL DE CONTROL AL TRAFICULUI DIN BUCUREȘTI [3] ........................................... 14

FIGURA 9. IMAGINE REDATĂ DE O CAMERĂ TERMOGRAFICĂ CU INFRAROȘU [4] ......................... 14

FIGURA 10. ARHITECTURA FIZICĂ A SISTEMULUI DORIT ...................................................................... 15

FIGURA 11. ARHITECTURA DE COMUNICAȚII A SISTEMULUI DORIT. CONEXIUNI.......................... 16

FIGURA 12. BROWSING TOOL ........................................................................................................................ 25

Lista tabelelor

TABELUL 1. CLASIFICAREA ȘI ALEGEREA NEVOILOR UTILIZATORULUI ........................................... 1

TABELUL 2. DESCRIEREA TERMENILOR ....................................................................................................... 1

TABELUL 3. CERINȚE FUNCȚIONALE (5.12.6) [1] ......................................................................................... 2

TABELUL 4. FLUXURI DE DATE LOGICE (5.12.6) [1] .................................................................................... 2

TABELUL 5. PREZENTARE GENERALĂ (7.1.3) [1] ......................................................................................... 3

TABELUL 6. CERINȚE FUNCȚIONALE (7.1.3) [1] ........................................................................................... 4

TABELUL 7. FLUXURI DE DATE LOGICE (7.1.3) [1] ...................................................................................... 6

TABELUL 8. ALOCAREA RESPONSABILITĂȚILOR .................................................................................... 19

TABELUL 9. CONCLUZII FINALE ................................................................................................................... 23

Capitolul 1. Arhitectura funcțională
1.1 Nevoile utilizatorului
Tabelul 1. Clasificarea și alegerea nevoilor utilizatorului
Grup Departament Secție Nevoile utilizatorului Funcții asociate
5 5.1 5.1.1 5.1.1.2 ➔ 5.12.6
➔ 3.1.1.5.10
7 7.1 7.1.3 7.1.3.3 ➔ 3.1.2.13.1
➔ 3.1.2.14.1

Tabelul 2. Descrierea termenilor

Termen Descriere
5 Emergency Services
5.1 Emergency Notification and Personal Security
5.1.1 Stolen Vehicles
5.1.1.2 The system shall be able to detect a vehicle when it has been stolen.
5.12.6 Detect Illegal Use
7 Traffic Management
7.1 Traffic Control
7.1.3 Traffic Control Centres
The system shall be able to provide a graphical representation of the road network
7.1.3.3
(including equipment, incidents, traffic condition etc....) to TCC operators.
3.1.1.5.10 Provide Urban Traffic Operator Interface
3.1.2.13.1 Provide Inter-urban Road Operator Mgt Interface
3.1.2.14.1 Provide Inter-urban Road Operator Cmd Interface

Notă #1: Pornind de la ideea de a construi un sistem care să identifice vehiculele furate (5.1.1),
se dorește implementarea unei funcții similare în centrul/centrele de control al traficului (7.1.3).
Prin intermediul anumitor echipamente de detecție o astfel de funcție se poate implementa cu
ușurință într-un astfel de sistem, așadar, totodată, se reduce și numărul de sisteme care se pot
instala într-un oraș inteligent. Planul acestui proiect este de a analiza comportamentul
persoanelor și de a monitoriza traficul din mediul urban.

1.2 Capabilitatea sistemului

În primă fază, ca sistemul să îndeplinească și funcția de detecție a vehiculelor furate,
acesta trebuie să detecteze utilizarea ilegală a vehiculelor (5.12.6), prin urmare:
1. The ability to send a message to the relevant authority whenever a signal is received
indicating that the Vehicle is not being used properly;
2. The message shall include the Vehicle location, which shall be received from other
functionality. [1]

1
Tabelul 3. Cerințe funcționale (5.12.6) [1]
Nr. crt. Descriere
whenever the illegal use data flow is received indicating that the vehicle is being used
illegally, send the stolen vehicle notification data flow to functionality in the Provide
a.
Safety and Emergency Facilities Functional Area and include in it the vehicle ID and
vehicle location
when as a result of (a) the send stop message data flow is received, send the stop stolen
b.
vehicle data flow to the communicate with in-vehicle systems function
when after completing (a) the vehicle position for illegal use data flow is received, check
if the vehicle has moved and if so, resend the stolen vehicle notification data flow to
c.
functionality in the Provide Safety and Emergency Facilities Functional Area and
include in it the new vehicle location
when the vehicle ID for illegal use or vehicle position for illegal use data flows are
d.
received retain their contents for use when the vehicle is being used illegally

Tabelul 4. Fluxuri de date logice (5.12.6) [1]

Fluxuri
de date Nume Descriere
logice
It contains an instruction that is to be
passed on the Vehicle Systems for the
psef.pshvs_stolen_vehicle_stop_message
stolen Vehicle to be stopped by being
disabled.
It contains data that indicates that the
Intrare
pshvs_illegal_use vehicle is being used without having
passed the correct checks.
pshvs_vehicle_ID_for_illegal_use It contains the vehicle ID.
It contains data on the current vehicle
pshvs_vehicle_position_for_illegal_use
position derived from one or more means.
It contains the actual notification message
pshvs.psef_stolen_vehicle_notification from a vehicle which is currently in
"stolen" status.
Ieșire It contains an instruction to be passed on
to the Vehicle System to disable the
pshvs_stop_stolen_vehicle
Vehicle, i.e. prevent it from being driven
from its current location.

2
 În cea de-a doua fază, se analizează funcționalitățile sistemului centrului de control al
traficului care îndeplinesc cerințele utilizatorului pentru implementarea unei astfel de soluții,
așadar:

Tabelul 5. Prezentare generală (7.1.3) [1]

Nr. crt. Descriere
1. The ability for the Road Network Operator to manage the control of traffic in the
urban road network by changing the current urban traffic control strategy,
except when it is imposed as part of an incident or demand management strategy,
or to provide selective vehicle priority.
2. The ability of the Road Network Operator to examine and update the sequence
of urban traffic control strategies that are implemented automatically, to see the
"log" of previously implemented urban traffic control strategy changes and to
3.1.1.5.10
provide data that will be used to update the store of Urban Road Static Data
through the Manage Urban Static Traffic Data Function.
3. The provision of information to the Road Network Operator about the success
or failure of any requested changes.
4. The ability of the Road Network Operator to request and be provided with the
current contents of the store of Urban Road Static Data through the Manage
Urban Static Traffic Data Function.
1. A HMI that enables the Road Network Operator to manage the control of traffic
using the inter-urban road network.
2. The HMI shall enable the Road Network Operator to provide commands that
change the current inter-urban traffic control strategy and to override the use of
lanes in the road network, except when it is imposed as part of an incident or
demand management strategy, or to provide selective Vehicle priority.
3. The HMI shall have the ability to inform the Road Network Operator of the
success or failure of the requested change.
3.1.2.13.1
4. The HMI shall have to ability to enable the Road Network Operator to examine
and update the sequence of inter-urban traffic control strategies that are
implemented automatically, and to see the "log" of previously implemented inter-
urban traffic control strategy changes.
5. The HMI shall have to ability to output requests to the Road Network Operator
for a check to be made of the availability of auxiliary lanes (hard shoulders),
and for the Operator to provide an available/not available response so that
traffic can be directed to use it, or not.
1. A HMI that enables the Road Network Operator to manage the control of traffic
using the inter-urban road network.
2. The HMI shall enable the Road Network Operator to provide commands that
3.1.2.14.1
change the current inter-urban traffic control strategy and to override the use of
lanes in the road network, except when it is imposed as part of an incident or
demand management strategy, or to provide selective Vehicle priority.

3
 3. The HMI shall have the ability to inform the Road Network Operator of the
success or failure of the requested change.
4. The HMI shall have to ability to output requests to the Road Network Operator
for a check to be made of the availability of auxiliary lanes (hard shoulders),
and for the Operator to provide an available/not available response so that
traffic can be directed to use it, or not.

Tabelul 6. Cerințe funcționale (7.1.3) [1]

Nr. crt. Descriere
a. continuously monitor for the receipt of the input data flows from the Operator
b. when the urban traffic commands data flow is received check that it is a valid
instruction from the Operator and that all the parameters required by the
command are present, otherwise get the Operator to provide them
c. if the data flow in (b) contains updates to the urban traffic management
strategies that are implemented automatically, or a request for output of the
current strategies then send them to the Provide Planned Urban Traffic
Management function using the planned urban data update data flow
d. as a result of (c) wait for the planned urban data output data read data flow to
arrive and when it does, output its contents to the Operator in the urban traffic
responses data flow
e. if the data flow in (b) contains an actual command to change the way that the
traffic using the urban road network is being managed, send it to the Implement
Urban Traffic Commands function in the operator urban management request
3.1.1.5.10 data flow
f. as a result of (e) wait for the operator urban management response data flow to
be received and when it is, output its contents to the Operator in the urban traffic
responses data flow
g. if the data flow received in (a) contains the urban static network data or a request
for its output, send it to the Manage Urban Road Static Data function in the
urban static data changes data flow
h. as a result of (g) wait for the operator urban road static data response data flow
to be received and when it is, output its contents to the Operator in the data flow
containing urban static road data
i. if the data flow in (b) contains a speed setting send it to the Manage Urban
Traffic Speeds function in the operator urban speed override data flow
j. if the data flow in (b) contains an override to the current use of lanes in a segment
of the urban road network, send it to the Manage Urban Road Network Lanes
function in the urban operator lane override data flow.
a. continuously monitor for receipt of the inter-urban road static network data and
inter-urban traffic management commands data flows from the Road Network
3.1.2.13.1
Operator plus the operator inter-urban auxlane check request data flow from the
Manage Lanes in the Inter-urban Road Network function

4
 b. when the first data flow in (a) is received, check its contents and if it contains
new and/or changes to the road network static data, send it to the Manage Inter-
urban Static Road Data function in the inter-urban static data changes data flow
c. if the contents of the data flow received in (b) contains a request for the current
inter-urban road network static data, send this request to the Manage Inter-
urban Static Road Data function in the inter-urban static data changes data flow
d. as a result of (b) or (c), continuously monitor for receipt of the operator inter-
urban road static data response data flow
e. when the data flow in (d) is received, output its contents to the Road Network
Operator in the data flow containing inter-urban static road data
f. when the second data flow in (a) is received, check its contents and if they are
an update, or a request for output, send them in the planned inter-urban data
update data flow to the Manage Planned Inter-urban Strategy Changes function
g. as a result of (f) continuously monitor for receipt of the planned inter-urban data
output data flow
h. when the data flow in (g) is received, output its contents to the Road Network
Operator in the inter-urban traffic responses data flow
i. if as a result of (f) the second data flow in (a) is found to contain command(s)
for change(s) in the management of traffic, decide which function(s) should
receive the commands
j. if as a result of (i) the contents are a change to the current strategy, send the
contents of the data flow in the operator inter-urban management request data
flow to the Manage Inter-urban Traffic Commands & Messages function
k. if as a result of (i) the contents are other changes, send the contents of the data
flow in either the inter-urban operator lane override data flow to the Manage
Lanes in the Inter-urban Road Network function, or in the inter-urban road legal
speeds data flow to the Manage Inter-urban Road Network Speeds & Headways
function
l. as a result of (j) continuously monitor for the receipt of the operator inter-urban
management response data flow and when it is received, output its contents to
the Road Network Operator in the inter-urban traffic responses data flow
m. if the third data flow in (a) is received, output its contents to the Road Network
Operator in the inter-urban traffic responses data flow
n. as a result of (m) continuously monitor for receipt of the inter-urban traffic
management commands data flow from the Road Network Operator
o. when the data flow in (n) is received, output its contents to the Manage Lanes in
the Inter-urban Road Network function in the inter-urban auxlane check
response data flow.
a. continuously monitor for receipt of the inter-urban command output override or
request inter-urban output monitoring data flows from the Road Network
3.1.2.14.1 Operator
b. when the first data flow in (a) is received, check its contents to see if it is imposing
or cancelling an override

5
 c. if in (b) an override is being imposed, send the details to the Output Inter-urban
Traffic Commands & Messages function in the inter-urban command override
status data flow
d. if in (b) an override is being cancelled, send the cancellation request to the
Output Inter-urban Traffic Commands & Messages function in the inter-urban
command override status data flow
e. as a result of (c) or (d), continuously monitor for receipt of the inter-urban
command override response data flow from the Output Inter-urban Traffic
Commands & Messages function
f. when the data flow in (e) is received, output its contents to the Road Network
Operator in the inter-urban command override response data flow
g. if the second data flow in (a) is received, check its contents and send the request
for output to be monitored to the Output Inter-urban Traffic Commands &
Messages function in the inter-urban command monitoring status data flow
h. as a result of (g), continuously monitor for receipt of the inter-urban command
monitoring response data flow from the Output Inter-urban Traffic Commands
& Messages function
i. when the data flow in (h) is received, output its contents to the Road Network
Operator in the inter-urban command monitoring response data flow.

Tabelul 7. Fluxuri de date logice (7.1.3) [1]

Fluxuri de date
Nume Descriere
logice
fo.rno- It contains static data about the urban road network that the
urban_road_static_netw Road Network operator wants added to the Data Store (D3.7)
ork_data containing this type of data.
fo.rno- If contains input from the Operator that will direct and monitor
urban_traffic_command the operation of the traffic management Functions that serve the
s urban road network.
It contains responses to previous requests form the Operator for
actions to be performed by the Provide Urban Traffic
mt_operator_urban_traff Management Function. These responses comprise but are not
ic_management_respons limited to such things as the confirmation of the previously
Intrare
e requested change of urban traffic management strategies, and
the "log" containing details of previous urban traffic
3.1.1.5.10 management strategy implementations.
It contains either the response to a previous request from the
mt_operator_urban_traff
Operator for urban traffic static data, or acknowledgement that a
ic_static_data_response
data update has been completed (or failed).
It contains either confirmation that data about planned changes
mt_planned_urban_data in traffic management strategies for the urban road network has
_read been updated, or details of the planned changes. This data flow
will be in response to a previous request from the Operator.
It contains a request from the Operator to change the lane use
setting on one or more parts of the urban road network. This may
mt_operator_urban_lane
Ieșire override the current speed setting, imposed by the operator, or
_override
automatically as part of a time of day dependent sequence of
changes. The lane use setting may be for allocation of a lane to a

6
 specific type of vehicle, to close one or more lanes, or to change
the direction of traffic flow in one or more lanes.
It contains a request from the Operator to change the speed
setting on one or more parts of the urban road network. This may
mt_operator_urban_spee
override the current speed setting, imposed by the operator, or
d_override
automatically as part of a time of day dependent sequence of
changes.
It contains requests form the Operator for actions to be
performed by the Provide Urban Traffic Management Function.
mt_operator_urban_traff These requests comprise but are not limited to such things as the
ic_management_request imposition of urban traffic management strategies, and the
output of the "log" containing details of previous urban traffic
management strategy implementations.
mt_operator_urban_traff It contains updated and/or additional urban static road data that
ic_static_data_request is to be loaded into the Data Store D3.7.
It contains either new or changed data that defines planned
changes to traffic management strategies for the urban road
mt_planned_urban_data network, or a request for the output of this data. This data is for
_update use by the Function that generates requests for the
implementation of these planned changes in traffic management
strategies.
mt_urban_static_data_c It contains updated and/or additional urban static road data that
hanges is to be loaded into the Data Store D3.7.
to.rno- It contains an output of the data about the urban road network
urban_static_road_data currently held in the Data Store of static data.
If contains output from the Operator in response to previous
to.rno-
commands directing and monitoring the operation of the traffic
urban_traffic_responses
management Functions that serve the urban road network.
fo.rno-inter- It contains static data about the inter-urban road network that
urban_road_static_netw the Road Network operator wants added to the Data Store (D3.8)
ork_data containing this type of data.
It contains input from the Road Management Operator that may
be updates to the inter-urban road network static data, or
fo.rno-inter-
changes to the planned sequence of commands for the
urban_traffic_managem
management of the inter-urban road network, or actual
ent_commands
management commands themselves that will override those that
are already being implemented.
mt_operator_inter- It contains a request to the operator to check manually via CCTV
urban_auxlane_check_re or by support of local authorities if the auxiliary lane in the inter-
quest urban road network is not occupied before making it available.
3.1.2.13.1 Intrare
It contains responses to previous requests form the Operator for
actions to be performed by the provide inter-urban traffic
mt_operator_inter- management Function. These responses comprise but are not
urban_management_res limited to such things as the confirmation of the previously
ponse requested change of inter-urban traffic management strategies,
and the "log" containing details of previous inter-urban traffic
management strategy implementations.
mt_operator_inter- It contains either the response to a previous request from the
urban_road_static_data_ Operator for inter-urban traffic static data, or acknowledgement
response that a data update has been completed (or failed).
mt_planned_inter- It contains either confirmation that data about planned changes
urban_data_output in traffic management strategies for the inter-urban road network

7
 has been updated, or details of the planned changes. This data
flow will be in response to a previous request from the Operator.
It contains a request from the Operator to change the lane use
setting on one or more parts of the urban road network. This may
override the current lane setting, imposed by the operator, or
mt_inter- automatically as part of a time of day dependent sequence of
urban_operator_lane_ov changes. The lane use setting may be for allocation of a lane to a
erride specific type of vehicle, to close one or more lanes, to change the
direction of traffic flow in one or more lanes, to advise the
drivers not to change lanes, or to make the auxiliary lane
available.
mt_inter-
It contains updated and/or additional inter-urban static road
urban_static_data_chang
data that is to be loaded into the Data Store D3.8.
es
mt_operator_inter- It contains the confirmation of the Operator that the requested
urban_auxlane_check_re auxiliary lane in the inter-urban road network is not occupied
sponse and can be made available for driving.
It contains requests form the Operator for actions to be
performed by the provide inter-urban traffic management
mt_operator_inter- Function. These requests comprise but are not limited to such
urban_management_req things as the imposition of inter-urban traffic management
uest strategies, and the output of the "log" containing details of
Ieșire previous inter-urban traffic management strategy
implementations.
mt_operator_inter- It contains an operator request for urban traffic static data, or
urban_road_static_data_ updates to the static data in the Inter-urban Traffic Static Data
request Store.
It contains a request from the Operator to change the speed
setting on one or more parts of the inter-urban road network.
mt_operator_inter-
This may override the current speed setting, imposed by the
urban_speed_override
operator, or automatically as part of a time of day dependent
sequence of changes.
It contains either new or changed data that defines planned
changes to traffic management strategies for the inter-urban
mt_planned_inter- road network, or a request for the output of this data. This data is
urban_data_update for use by the Function that generates requests for the
implementation of these planned changes in traffic management
strategies.
to.rno-inter- It contains an output of the data about the inter-urban road
urban_static_road_data network currently held in the Data Store of static data.
If contains output from the Operator in response to previous
to.rno-inter-
commands directing and monitoring the operation of the traffic
urban_traffic_responses
management Functions that serve the inter-urban road network.
fo.rno-inter- It contains instructions from the Road Network Operator to
urban_command_output commence or stop overriding one or more of the strategies being
_override used to manage some or all of the inter-urban road network.
It contains a request from the Road Network Operator to
fo.rno-request_inter- commence or stop monitoring the messages and sign states that
3.1.2.14.1 Intrare
urban_ouput_monitoring are currently being output to Drivers using the inter-urban road
network.
mt_inter-
It contains details of some or all of the messages and sign states
urban_command_monit
that are currently being output to Drivers using all or parts of the
oring_data

8
 inter-urban road network managed by the system. These details
will be updated in real time as they change.
It contains the response to a previous request from the Road
mt_inter-
Network Operator to override some or all of the messages and/or
urban_command_overri
sign states that are currently being output to all or parts of the
de_response
inter-urban road network managed by the system.
It contains a request to start or stop monitoring some or all of the
mt_inter-
current messages and sign states being output to Drivers using
urban_command_monit
all or parts of the inter-urban road network managed by the
oring_state
system.
It contains instructions to commence or stop the override some or
mt_inter-
all of the messages and sign states currently being output to
urban_command_overri
Drivers using all or parts of the inter-urban road network
Ieșire de_status
managed by the system.
to.rno-inter- It contains the response to a previous request from the Road
urban_command_overri Network Operator for the current strategy output to be
de_response overridden.
to.rno-inter- It contains the current state of messages and sign states being
urban_output_monitorin output to Drivers using the inter-urban road network and is
g updated in real-time.

Notă #2: Având toate aceste informații, se poate desfășura construirea și dezvoltarea sistemului
dorit. Funcțiile implementate în centrul de control al traficului permit adăugare funcției de
detectare a vehiculelor furate.

1.3 Diagramele sistemului dorit

1.3.1 Diagrama 5.1.1.2

Figura 1. Diagrama 5.1.1.2

9
1.3.2 Diagrama 7.1.3.3

Figura 2. Diagrama 7.1.3.3 – Partea I

Figura 3. Diagrama 7.1.3.3 – Partea II

10
 Figura 4. Diagrama 7.1.3.3 – Partea III

Figura 5. Diagrama 7.1.3.3 – Partea IV

1.3.3 Diagrama sistemului dorit

Notă #3: Ceea ce este colorat cu verde reprezintă nevoile pe care le-a cerut utilizatorul, însă
celelalte elemente din diagramă sunt necesare pentru funcționalitatea completă a sistemului
dorit. Evident, elementele din diagramă care nu sunt colorate cu verde au în componența lor
alte funcționalități, care, de altfel, duc la însușirea unui alt sistem, dar pentru că sistemul dorit
impune anumite funcționalități, au fost reprezentate în ansamblu doar cele necesare pentru
construirea acestuia.
Notă #4: În continuare se dorește integrarea celor două sisteme într-un singur sistem. Prin
urmare, trebuie să se găsească și să se explice cea mai compatibilă corespondență între
funcționalitățile celor două sisteme. Se va construi o schemă bloc în care se prezintă sistemul
dorit, iar legătură dintre funcționalități va fi făcută de către funcțiile care pot îndeplini cerințele
utilizatorului.

11
 Figura 6. Schema bloc a sistemului dorit

Personal, soluția cea mai optimă pentru compatibilitatea între aceste două sisteme, în
vederea faptului că se dorește un singur sistem pentru a respecta cerințele și nevoile
utilizatorului, este prezentată în Figura 6, iar detaliile despre funcțiile alese se regăsesc în
Tabelul 4 și în Tabelul 7.

12
Capitolul 2. Arhitectura fizică
2.1 Echipamente necesare
Ținând cont de faptul că soluția dorită este raportată la un sistem ce va fi folosit în
centrele de control al traficului, evident primul echipament de care soluția convenită are nevoie
este reprezentată de camerele video.

Figura 7. Camere video [2]

Centrele de control al traficului trebuie să aibă în componența lor echipamente care pun
la dispoziția personalului tot ce este nevoie ca persoanele abilitate să aibă acces la infrastructura
orașului, acestea să observe ceea ce se petrece în fiecare clipă, evident imaginea video fiind
redată pe monitoarele din dotarea centrelor, iar pentru soluția dorită să se integreze un algoritm
care să analizeze comportamentul persoanelor, dar și modul în care vehiculele circulă prin oraș.
Totodată, se pot instala și camere care pot analiza comportamentul persoanelor, starea
de spirit și limbajul corpului. Pentru acest lucru este necesară folosirea camerelor termografice
cu infraroșu.

Notă #5: Se recomandă ca algoritmul să fie construit de către o echipă formată din psihologi,
medici și, evident, informaticieni.

13
 Figura 8. Centrul de control al traficului din București [3]

Figura 9. Imagine redată de o cameră termografică cu infraroșu [4]

2.2 Configurarea sistemului dorit

Din informațiile anterioare, s-a creat o privire de ansamblu asupra sistemului care
îndeplinește nevoile utilizatorului.
În continuare, este reprezentată arhitectura fizică a sistemului dorit de către utilizator,
în care vor fi ilustrate entitățile corespunzătoare cât și legătura dintre acestea.

14
 Figura 10. Arhitectura fizică a sistemului dorit

Notă #6: Arhitectura fizică a fost elaborată în urma reprezentării sistemului dorit în schema
bloc (vezi Figura 6).

15
Capitolul 3. Arhitectura de comunicații
3.1 Conexiuni

Figura 11. Arhitectura de comunicații a sistemului dorit. Conexiuni

3.2 Detalii despre conexiuni

3.2.1 Infrastructura orașului

• Fibra optică – este o fibră de sticlă sau plastic care transportă lumină de-a lungul său.
Fibrele optice sunt folosite pe scară largă în domeniul telecomunicațiilor, unde permit
transmisii pe distanțe mai mari și la lărgimi de bandă mai mari decât alte medii de
comunicație. Fibrele sunt utilizate în locul cablurilor de metal deoarece semnalul este
transmis cu pierderi mai mici, și deoarece sunt imune la interferențe electromagnetice.
Fibrele optice sunt utilizate și pentru iluminat și transportă imagine, permițând astfel
vizualizarea în zone înguste. Unele fibre optice proiectate special sunt utilizate în diverse
alte aplicații, inclusiv senzori și laseri. [5]
• Cablul coaxial – este un cablu electric care are un conductor interior înconjurat de un strat
izolator tubular și de o tresă conductivă tubulară. Multe cabluri coaxiale au, de asemenea o
manta exterioară izolatoare. Termenul de coaxial provine de la conductorul interior unic și
tresa exterioară, rezultând o axă de simetrie. [6]

16
• Camera video – este un dispozitiv de înregistrare a imaginilor sub forma unor semnale
electrice. [7]
• Ethernet – este denumirea unei familii de protocoale de rețele de calculatoare bazată pe
transmisia cadrelor și utilizată la implementarea rețelelor locale de tip LAN1. [8]
• Wi-Fi – este numele comercial pentru tehnologiile construite pe baza standardelor de
comunicație din familia IEEE2 802.11 utilizate pentru realizarea de rețele locale de
comunicație (LAN) fără fir (wireless, WLAN3) la viteze echivalente cu cele ale rețelelor cu
fir electric de tip Ethernet. [9]
• GSM4 – este standardul de telefonie mobilă (celulară) cel mai răspândit din lume, precum
și numele rețelei de telefonie respective. Atributul „mobil” al multor aparate și dispozitive
actuale se referă în primul rând la conectivitatea lor (fără fir, prin semnale radio) la sistemul
GSM, practic din orice punct de pe glob unde există oameni. Din aceasta rezultă și
mobilitatea utilizatorului. [10]
• Senzori de detecție – sunt o componentă tehnică care poate determina calitatea sau mai
degrabă cantitatea măsurată a proprietăților fizice și chimice cum ar fi: temperatura,
radiațiile termice, umiditatea, presiune, sunetul și luminozitatea. Aceste măsuri sunt
convertite în semnale electrice (e.g. bucla inductivă, senzori piezoelectrici, senzori cu
ultrasunete, senzori cu infraroșu etc.). [11]

3.2.2 Sistem de notificare intern

• Mail – desemnează sisteme pentru transmiterea sau primirea de mesaje, de obicei prin
Internet. Tot „e-mailuri” („corespondențe”, „mesaje”) se numesc și mesajele individuale
trimise prin aceste sisteme. Cuvântul provine din engleză de la electronic mail, poștă
electronică. [12]
• Alerte pop-up – notificare afișată peste ferestrele deja deschise ale utilizatorului.

3.2.3 Sistem de avertizare și alerte de urgență

• GPS5 – este un sistem global de navigație prin satelit și unde radio. Sistemul GPS este o
rețea de sateliți care orbitează în jurul Pământului în puncte fixe deasupra planetei,
transmițând semnale tuturor receptorilor aflați la sol. Aceste semnale conțin un cod de timp
și un punct de date geografice care permit utilizatorului să primească poziția exactă în care
se află, viteza și ora din orice regiune de pe planetă. GPS funcționează în orice condiții
meteorologice, oriunde în lume, 24 ore pe zi. [13]
• eCall – este un sistem instalat în vehicule în toate țările UE care efectuează automat un apel
gratuit către numărul de urgență 112, în cazul în care vehiculul este implicat într-un accident
rutier grav. [14]

1
LAN – Local Area Network
2
IEEE – Institute of Electrical and Electronics Engineers
3
WLAN – Wireless Local Area Network
4
GSM – Global System for Mobile Communications
5
GPS – Global Positioning System

17
Capitolul 4. Arhitectura organizațională
4.1 Roluri și responsabilități
Pentru demararea acestui proiect este necesară implementarea unei strategii pentru
diferitele etape care vor avea loc: dezvoltare, implementare, operare și mentenanță a sistemului.
În etapa de dezvoltare a sistemului iau parte următoarele entități organizatorice:
1. Instituții europene;
2. Ministere (Ministerul Transporturilor, Infrastructurii și Comunicațiilor, Ministerul
Finanțelor Publice);
3. Municipalitate (primării), prin intermediul centrelor de control al traficului;
4. Asociații și organizații ale principalilor producători de echipamente;
5. Servicii de informație și securitate.

Primul pas, pentru punerea în aplicare a prevederilor strategiei din domeniu, este
elaborarea unei arhitecturi cadru (care ulterior va fi baza unei arhitecturi de sistem), care va
putea oferi principalele elemente pentru dezvoltarea armonioasă a sistemelor ITS din spațiul
urban. La definirea și elaborarea arhitecturii cadru și a celei de sistem se pot implica următoarele
entități organizatorice: toate cele prezentate anterior (dacă au dezvoltate compartimente sau
departamente specializate pe această problematică) la care se adaugă instituții de cercetare
(institute, centre sau universități) și companii specializate în instrumente de dezvoltare a
arhitecturilor organizaționale. [15]
Următoare etapă este aceea de proiectare a sistemului, în aceasta fiind implicate
următoarele entități organizatorice:
• Beneficiarul sistemului;
• Operatorul sistemului;
• Proiectantul sistemului (acesta este responsabilul acestei activități);
• Posibili furnizori sau integratori de sisteme ITS;
• Utilizatorii finali ai sistemului.

După elaborarea proiectului tehnic și de execuție, urmează etapa de implementare a

proiectului (această etapă este în responsabilitatea furnizorului) care va fi succedată de etapa de
operare a sistemului dorit (această ultimă etapă poate fi în responsabilitatea operatorului sau și
a beneficiarului proiectului).

4.2 Alocarea responsabilităților

În Tabelul 8 este reprezentată alocarea responsabilităților fiecărei entități care a luat
parte la construirea sistemului.

18
Tabelul 8. Alocarea responsabilităților
Organizație Strategie Arhitectura Proiect Implementare Operare Mentenanță
Instituții
R6 R C/I7 C/I C/I C/I
europene
Autorități
publice și R R C/I C/I C/I C/I
locale
Asociații și
A8 C9 C/I C/I C/I C/I
organizații
Beneficiari A A A A A A
Consultanți A R A A C C
Proiectanți A C R A A A
Furnizori A C A R A A
Operatori A C A A R R

6
R – Realizator
7
C/I – Consultat și informat
8
A – Autoritate
9
C – Consultat

19
Capitolul 5. 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). [16]
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.

5.1 Definiții
Securitatea reprezintă faptul că un sistem asigură un anumit grad de protecție împotriva
pericolelor, pierderilor sau atacurilor. Nu există sisteme sau entități care să ofere un grad de
securitate total (100%). [16]
Există o strânsă legătură între securitatea sistemelor și siguranța acestora, în special
pentru sistemele componente sistemului de transport. Astfel, un atac de securitate, devine
prioritar în tratare atunci când afectează funcționarea sistemului, respectiv când scade gradul
de siguranță în utilizare a acestuia.
Securitatea intrinsecă a sistemelor inteligente de transport se referă la funcțiile de
securitate pe care le au aceste sisteme pentru a se proteja de atacuri de securitate astfel încât
sistemul să ofere un anumit nivel de siguranță și un anumit nivel de serviciu (LoS10). Astfel un
sistem de management al traficului rutier, având componente distribuite, va necesita conectarea
acestora printr-o infrastructură de comunicații de date. Această infrastructură este în general
publică (pentru a scădea costurile de dezvoltare, întreținere și operare pentru aceste sisteme).
Acest lucru va conduce la necesitatea existenței unor funcții de securitate ale sistemului pentru
a evita eventualele atacuri asupra sistemului datorită utilizării în comun a infrastructurii de
securitate. În acest exemplu soluția este de realizare a unui VPN11 peste rețeaua Internet și
respectiv existența unor funcții de securitate a sistemului care să creeze și să gestioneze acest
VPN.

10
LoS – Level of service
11
VPN – Virtual Private Network

20
5.2 Clasificări
Funcțiile de securitate ale unui sistem inteligent de transport pot fi clasificate după mai
multe criterii: [16]
1. După aria acoperită de aceste funcții:
• Funcții de securitate locale – acestea privesc numai anumite componente ale sistemelor
ITS, care sunt amplasate în poziții ușor accesibile;
• Funcții de securitate globale – acestea se referă la acele funcții care acoperă întreg
sistemul;
• Funcții de securitate extinse – acestea privesc atât sistemul ITS (din componența căruia
fac parte) cât și alte sisteme cu care acesta cooperează, fiind vorba de un export de
securitate.
2. După locul implementării acestor funcții:
• Funcții interne de securitate – acestea sunt implementate în sistemul respectiv;
• Funcții externe de securitate – acestea sunt implementate în alte sisteme cu care acesta
cooperează dar sunt folosite și de acesta.
3. După durata utilizării acestora:
• Funcții permanente de securitate – acestea sunt funcții implementate în sistemul ITS
respectiv și care sunt active permanent;
• Funcții periodice de securitate – sunt funcții care sunt activate periodic în corelație cu
diverse activități ce sunt specifice respectivelor sisteme (de exemplu activarea unor astfel
de funcții în zilele în care se fac sincronizări de date între diverse servere și/sau baze de
date);
• Funcții temporare de securitate – acestea sunt activate numai în situații critice;
• Funcții provizorii de securitate – acestea fiind dezvoltate în urma constatării unui caz de
risc de securitate care nu a fost prevăzut inițial și care va genera o funcție de securitate
din categoriile anterioare.
4. După modul de activare a acestor funcții:
• Funcții de securitate activate automat;
• Funcții de securitate activate manual;
• Funcții de securitate activate mixt – unele componente (subfuncții) fiind activate automat
și altele manual. Acestea din urmă necesitând intervenția și decizia unui operator uman.

5.3 Securitatea sistemelor

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. [16]
În acest subcapitol se vor exemplifica elementele unei arhitecturi de securitate pentru
un sistem de acordare a priorității pentru anumite vehicule (ale transportului public sau pentru

21
intervenții în caz de urgență) bazat pe identificarea vehiculului cu ajutorul recunoașterii
numărului de înmatriculare (prin utilizarea procesării de imagini achiziționate cu camere
specializate).
ITS poate fi utilizat la îmbunătățirea securității sistemelor de transport. Câteva arii de
securitate definesc modurile în care ITS poate fi utilizat pentru detectarea, contracararea și
recuperarea în urma amenințărilor împotriva sistemului de transport.
Infrastructura de transport poate fi monitorizată și protejată de către o gamă largă de
tehnologii ITS. Securitatea infrastructurii de transport include monitorizarea infrastructurii de
transport (ex: poduri, tuneluri și centre de management) pentru identificarea potențialelor
amenințări folosind senzori și echipamente de urmărire. Amenințările asupra infrastructurii pot
rezulta ca urmare a acțiunilor naturii (ex: uragane, cutremure), atacurilor teroriste și a altor
incidente ce pot cauza pagube ale infrastructurii.

22
Capitolul 6. Concluzii
Tabelul 9. Concluzii finale
Notă Descriere
Pornind de la ideea de a construi un sistem care să identifice vehiculele furate (5.1.1), se
dorește implementarea unei funcții similare în centrul/centrele de control al traficului (7.1.3).
Prin intermediul anumitor echipamente de detecție o astfel de funcție se poate implementa cu
1
ușurință într-un astfel de sistem, așadar, totodată, se reduce și numărul de sisteme care se pot
instala într-un oraș inteligent. Planul acestui proiect este de a analiza comportamentul
persoanelor și de a monitoriza traficul din mediul urban.
Având toate aceste informații, se poate desfășura construirea și dezvoltarea sistemului dorit.
2 Funcțiile implementate în centrul de control al traficului permit adăugare funcției de
detectare a vehiculelor furate.
Ceea ce este colorat cu verde reprezintă nevoile pe care le-a cerut utilizatorul, însă celelalte
elemente din diagramă sunt necesare pentru funcționalitatea completă a sistemului dorit.
Evident, elementele din diagramă care nu sunt colorate cu verde au în componența lor alte
3
funcționalități, care, de altfel, duc la însușirea unui alt sistem, dar pentru că sistemul dorit
impune anumite funcționalități, au fost reprezentate în ansamblu doar cele necesare pentru
construirea acestuia.
În continuare se dorește integrarea celor două sisteme într-un singur sistem. Prin urmare,
trebuie să se găsească și să se explice cea mai compatibilă corespondență între
4 funcționalitățile celor două sisteme. Se va construi o schemă bloc în care se prezintă sistemul
dorit, iar legătură dintre funcționalități va fi făcută de către funcțiile care pot îndeplini
cerințele utilizatorului.
Se recomandă ca algoritmul să fie construit de către o echipă formată din psihologi, medici
5
și, evident, informaticieni.
Arhitectura fizică a fost elaborată în urma reprezentării sistemului dorit în schema bloc (vezi
6
Figura 6).

Notele prezente în acest proiect reprezintă concluzii trase asupra cerințelor pe care
utilizatorul le-a dorit.
Dezvoltarea acestui sistem dovedește faptul că se pot face grupări între mai multe
sisteme astfel încât permite infrastructurii orașului să înglobeze și să integreze mai multe astfel
de sisteme inteligente.
Funcția de detecție a vehiculelor furate nu necesită o acțiune în plus a operatorului
uman. După cum s-a precizat în acest proiect, implementarea unui algoritm va face ca sistemul
dorit de utilizator să beneficieze de această funcționalitate fără ca operatorii din centrele de
control al traficului să-și concentreze atenția și asupra acestei caracteristici.
Pornind de la această caracteristică implementată în centrele de control al traficului, se
pot aduce mult mai multe îmbunătățiri deoarece echipamentele folosite permit interconectarea
cu alte sisteme inteligente.

23
Bibliografie
[1] „FRAME ARCHITECTURE”. [Online]. Valabil la: https://frame-online.eu/frame-
architecture/the-browsing-tool.
[2] C.R., „Peste 100 de camere video pentru titlul de cel mai sigur oraș”, 2019. [Online].
Valabil la: https://news.securityportal.ro/stiri/business-si-tehnologie/peste-100-de-
camere-video-pentru-titlul-de-cel-mai-sigur-oras/.
[3] M. Apostolescu, „Centrul de control al traficului din București”, București FM, 2017.
[4] „Thermal camera”. [Online]. Valabil la: https://www.wfla.com/news/international/heat-
camera-at-tourist-attraction-spots-womans-breast-cancer/.
[5] „Fibra optică”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Fibră_optică.
[6] „Cablu coaxial”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Cablu_coaxial.
[7] „Cameră video”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Cameră_video.
[8] „Ethernet”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Ethernet.
[9] „Wi-Fi”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Wi-Fi.
[10] „GSM”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/GSM.
[11] „Senzor de detecție”. [Online]. Valabil la:
https://ro.wikipedia.org/wiki/Senzor_de_mișcare.
[12] „E-mail”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/E-mail.
[13] „GPS”. [Online]. Valabil la: https://ro.wikipedia.org/wiki/Global_Positioning_System.
[14] „eCall”. [Online]. Valabil la: https://europa.eu/youreurope/citizens/travel/security-and-
emergencies/emergency-assistance-vehicles-ecall/index_ro.htm.
[15] I. D. E. T. Arhitecturi, „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.”
[16] I. D. E. T. Arhitecturi, „[studiu privind implementarea sistemelor inteligente de
transport - arhitecturi] 5.4”, pp. 140-149.

24
Anexa 1. Browsing tool

Figura 12. Browsing tool

25