Sistem de autoghidare a vehiculelor

Masterand: Crivatu Marius Danut

 Cuprins
1. Introducere

1.1 Descrierea sistemului inteligent de transport

1.2 Schema bloc

2. Utilizatori si cerinte ale acestora

3. Arhitectura functionala

3.1 Functiile sistemului

3.2 Fluxurile de date

4. Arhitectura fizica

4.1 Definirea componentelor fizice

5. Arhitectura de securitate

6. Concluzii

7.Bibliografie
1. Introducere

1.1 Descrierea sistemului inteligent de transport

Sistemul inteligent de transport ales pentru acest proiect are rolul de a securiza
transportul pe caile rutiere si totodata de a oferi un plus de confort utilizatorilor.
Acest sistem de autoghidare functioneaza cu ajutorul semnalului oferit de
sateliti pentru a se pozitiona si pentru a putea pastra traseul. Directia vehiculelor este
asigurata de un modul de control hidraulic care la randul sau este controlat de
unitatea centrala de comanda si control.

1.2 Schema bloc

Display
Satelit Informator de bord

Antena GPS ECU

(receptor) Unitarea
electronica de control

Controlul hidraulic
al directiei

Blocul Satelit – este reprezentat de satelitii GPS sau satelitii unui furnizor de
servicii de localizare de precizie
Antena GPS – contine receptorul se semnal GPS
ECU – reprezinta unitatea centrala ce control si comanda a intregului sistem
Display – partea hardware ce afisaza informatiile si cu ajutorul careia se pot
introduce diverse date
Controlul hidraulic al directiei – reprezinta un modul ce primeste informatiile
necesare pentru a controla partea hidraulica a directiei vehicului
2. Utilizatori si cerinte ale acestora
Sistemul de autoghidare reprezinta un sistem menit sa asigure o siguranta
suplimentara si un confort sporit pentru conducatorii vehiculelor. In acest moment,
sistemul nu este accesibil pe scara larga insa pe viitor toate vehiculele vor dispune de
acesta.

Cerintele utilizatorilor fata de acest sistem pot fi diferite. In continuare voi

prezenta cateva exemple de cerinte ale acestor:

6.4.0.1 Sistemul va oferi călătorilor rute recomandate către destinații

specificate.
6.4.0.3 Sistemul trebuie să știe unde se află în cadrul rețelei de drumuri

3. Arhitectura funtionala
3.1 Functiile sistemului
Sistemul trebuie sa recomande utilizatorilor rute catre destinatiile dorite.
Sistemul trebuie sa cunoasca locatia exacta in raport cu reteaua de drumuri.
Deasemenea, sistemul trebuie sa asiste soferul cu informatii, cu directie activa
si deasemenea sa poata trasa selectata pentru drum.
Figura2. Diagrama 6.5 Prepare Trip Plan
 Figura 3. Diagrama 6.5.3.9 Plan Trip Details

Figura 4. Diagrama 6.3.10 Implement Trip Plan and Track Traveller

 3.2 Fluxurile de date
Trebuie sa contina harti digitale pentru ca soferul sa poata planifica un traseu.
Este necesar sa contina date analogice sau digitale cu ajutorul carora se poate
determina pozitia exacta a soferului, pentru a putea planifica o ruta.
Trebuie sa cunoasca date legate de drum, inclusiv limitele de viteza si semnele
de circulatie, pentru a putea calatori in siguranta.
Tabelul 1. Cerinte functionale (6.5.10)
Descriere
a continuously monitor for the receipt of the basic trip parameters data flow from the pre-trip traveller
b when the data flow in (a) is received, if required send the request applicable General Trip Preferences (GTP) parameters data flow to the
GTP management function and wait for the response in the requested applicable GTP parameters data flow
c send the request preferences data flow requesting any changes to the GTP data to the pre-trip traveller and wait for the response in the
additional trip parameters data flow
d when the response data flow is received in (c), use its contents and all the other data provided by the traveller to prepare the trip plan
requirements, put them in the traveller trip requirement data flow and send it to the Trip Planning function
e as a result of (d) wait for the receipt of the traveller trip description data flow from the Trip Planning function and when it is received,
store the trip plan description internally for later use
f output the trip plan description received in (e) to the pre-trip traveller in the initial trip plan data flow
g as a result of (f) wait for a response from the pre-trip traveller in the modified trip parameters data flow
h use the data provided by the data flow in (g) to modify the original trip parameters, put them in the modified trip plan requirements data
flow and send it to the Trip Planning function
i as a result of (h) await receipt of the traveller trip description data flow from the Trip Planning function and when it is received store the
trip plan description internally for later use
j output the alternative trip plan description received in (i) to the pre-trip traveller in the trip alternatives data flow and wait for a response
from the pre-trip traveller in the modified trip parameters data flow
k continue repeating (e) through (i) until no modified parameters are provided by the pre-trip traveller in the modified trip parameters data
flow, but giving each revised trip plan description a new identity so that it can be retrieved instead of the other trip plan descriptions
l output the select trip data flow to the pre-trip traveller and await a response through the input of the trip selection data flow
m use the input in (l) to select the required trip plan description from the internal store and check to see if any bookings need to be made and
paid for, or the trip plan service needs to be paid for
n if the answer in (m) is YES, send the selected trip plan description to the Make Trip Bookings and Payments function in the full trip
description for bookings data flow;
o as a result of (n) continuously monitor for receipt of either the request trip planning payment or advanced payment needed data flows from
the Make Trip Planning Payment and Bookings function
p then the data flow in (o) is received, send either the request trip planning payment or advanced payment needed by trip plan data flows to
the pre-trip traveller and await receipt of either the trip planning payment or booking approval data flows from the pre-trip traveller
q the either of the data flows in (p) is received, send either the trip planning payment or the booking approval data flows to the Make Trip
Booking and Payment function
r as a result of (q) continuously monitor for receipt of the full trip description with bookings, or booking mishap data flow from the Make
Trip Booking and Payment function
s when the first data flow in (r) is received, inform the pre-trip traveller through the select trip data flow and send the selected trip plan
description to the Manage Store of Trip Plan Data function in the plan ready for implementation data flow
t if the answer in (m) is NO, send the selected trip description to the Manage Store of Trip Plan Data function in the plan ready for
implementation data flow

Tabelul 2. Fluxuri de date logice (6.5.10)

Fluxuri de Nume Descriere
date logice
ft.ptt-
additional_trip_ It contains trip parameters provided by the Traveller that are in addition to, or modifications of, those available from
parameters as General Trip Preferences (GTP).
ft.ptt-
basic_trip_para It contains basic data about the trip that is to be planned and may include data such as, the date on which the trip will
meters be made (or start), the locations of the origin and destination of the trip, the departure and arrival times, places to be
visited (or passed through, i.e. way points) for the trip, places to be avoided, travel modes to be used and/or avoided,
the type of road Vehicle that will be used for all of part of the trip, the identity of the Traveller preparing the trip
(enables their General Trip Preferences (GTP) to be used, if available), the number of Travellers and information
about any goods that are being carried.
ft.ptt-
booking_appro It contains confirmation from the Traveller that bookings are to be made for other services needed as part of a trip
Intrare val and includes details of how the payments are to be made.
ft.ptt-
final_approval It contains confirmation that the schedule for a trip is now acceptable to the Traveller.
 ft.ptt-
modified_trip_p It contains modifications to the original trip plan data that the Traveller provides after the initial trip plan has been
arameters provided, and will consist of items such as alternative modes of travel and alternative places to be passed through
between the origin and the destination.
ft.ptt-
revised_bookin It contains revisions that the Traveller is making to previously made choices for advanced payments needed as part of
g_choices a trip plan. These revisions are usually needed because payment for the previous choices has failed.
ft.ptt-
trip_planning_p It contains details of how the payment that the Traveller is making for the use of trip planning services is to be made.
ayment
ft.ptt-
trip_selection It contains confirmation that the trip parameters are now acceptable to the Traveller.
ptja_advanced_
payment_neede It contains information for output to the Traveller about advanced payment(s) that are needed from the Traveller
d before the preparation of a trip plan can be completed.
ptja_booking_
mishap It contains information for output to the Traveller about the failure of the process to make bookings that are needed
for the creation of a trip plan.
ptja_full_trip_d
escription_with It contains the description of a planned trip that does include bookings for one or more services for which payment
_bookings has successfully been made and which now requires final approval from the Traveller.
ptja_requested_
applicable_GTP It contains the requested parameters from the General Trip Preferences Data store that are applicable to the trip that is
_parameters being planned by a particular Traveller. The identity of the Traveller whose Preferences are being provided must be
included.
ptja_request_tri
p_planning_pay It contains a request that is to be output to the Traveller for payment to be made as part of the creation of a trip plan.
ment
ptja_traveller_tr
ip_description It contains the description of a trip that has been produced in response to a request from a Traveller. Details such as
the origin, destination, other places to be passed through during the trip, modes being used for each part of the trip,
plus details of the required PT services and those provided by other modes. Any changes from the trip as originally
proposed by the Traveller will be highlighted.
ptja_booking_a
pproved It contains confirmation from the Traveller that bookings made as part of the creation of a trip plan are approved.
ptja_cancel_bo
okings_for_trip It contains a request to "cancel bookings" for a previously prepared trip plan, the identity of which is included with
the request.
ptja_full_trip_d
escription_for_ It contains the full description of a trip including portions covering all the modes agreed with the Traveller.
Iesire bookings
ptja_modified_t
rip_plan_requir It contains revised data about a Traveller’s intended trip plan. It is sent when a Traveller wishes to revise the data
ements because the trip plan that has been produced is not to their satisfaction.
ptja_request_ap
plicable_GTP_ It contains a request for the supply of parameters from the General Trip Preferences Data Store that are applicable to
parameters the trip that is being planned by a particular Traveller. The identity of the Traveller requesting the Preferences must
be included.
ptja_traveller_tr
ip_requirement It contains the description of a trip that a Traveller is planning, including origin, destination, places to be included in
the trip, modes for each part of the trip, plus details of required PT services and those provided by other modes and
information from the GTP Data Store.
ptja_trip_planni
ng_payment It contains the details provided by the Traveller that need to be sent to the Financial Clearinghouse so that payment
can be made as part of the creation of a trip plan
ptja_trip_plan_r
eady_for_imple It contains the description of a planned trip that has received final approval from the Traveller and is now ready for
mentation implementation when requested by the Traveller.
tt.ptt-
advanced_paym It contains a request to the Traveller for payment for those services included in a trip plan that has been accepted by
ent_needed_by the Traveller, and for which advanced payment and booking is required.
_trip_plan
tt.ptt-
booking_misha It contains details for the Traveller of details about failure of payment for either the trip planning service or for
p bookings that are part of the trip plan and for which advanced payment is required.
tt.ptt-
initial_trip_plan It contains the initial version of the trip plan produced using the first set of trip plan parameters provided by the Pre-
trip Traveller.
tt.ptt-
itinerary_initial It contains the initial itinerary for the trip (trip plan) based on information provided by the Traveller.
 tt.ptt-
request_prefere It contains a request for the Traveller to provide details of any preferences for the trip that are not included in the
nces General Trip Preferences (GTP) data through the additional parameters data flow.
tt.ptt-
request_trip_pla It contains a request to the Traveller for payment for the use of the trip planning services, without which the trip plan
ning_payment will not become available for use. (Note: the use of this and the corresponding "payment" data flow is optional and
depends on what the trip planning service provider wants to do in a particular ITS implementation.)
tt.ptt-select_trip
It contains a request for the Pre-trip Traveller to select a trip description from those that have just been prepared.
tt.ptt-
trip_alternatives It contains proposals for trip plans that may not completely conform to the preferences, plus "primary" and
"secondary" criteria provided by the Traveller. They are therefore considered as alternatives to the trip plan that has
been (or would have been) produced form the data originally provided by the Traveller.

Tabelul 3 Cerintele functionale (6.5.3.9)

Descriere
a continuously monitor for the receipt of the traveller trip requirements and vehicle trip plan request data flows
b when the traveller trip requirements data flow is received in (a), use the trip planning information to fulfil the traveller's trip request from the
stores of Road Trip Planning Data and/or PT Trip Planning Data and produce a trip plan
c in addition to (b) include in the trip plan a choice from different routes for the road part of the trip that use the motorway networks, secondary
road networks, scenic routes and so forth depending on the criteria provided by the traveller and the travel information operator, plus
recommendations received from TCC's in the inter-urban recommended routes and urban recommended routes data flows
d in addition to (b) and (c) include in the trip plan a choice of travel modes, where they provide sensible alternatives, or have been requested by
the traveller
e if required by the traveller details of both single and return trips, including those where the date of the return part of the trip may be some time
ahead of that for the outward part shall be included in the trip plan
f when the preparation of a new/revised trip plan is completed, it shall be sent back to the traveller interface in the traveller trip description data
flow
g as a result of (f) continuously monitor for receipt of the modified trip plan requirements data flow and if received within a short time, repeat (b)
to (g) using the revised requirements
h when the vehicle trip plan request data flow is received in (a), use the data it contains to produce a vehicle based trip plan, fulfilling the
requirements of (c) and (e) but include other information such as the need to book parking places for freight vehicles so that goods can be
loaded or unloaded
i when the preparation of a new/revised trip plan is completed, it shall be sent back to the vehicle interface in the vehicle trip plan response data
flow
j all trip plans shall include any appropriate warnings about the existing conditions, safety recommendations and the expected conditions at the
planned time of travelling on the route(s) that they include
k when revising a part completed trip plan, propose alternative modes and/or times of travel to those in the remainder of the plan
l all trip plans shall be produced according to criteria that are set up and modified by the travel information operator so that trips conform to the
current travel and/or traffic management policies
m it shall be possible to prepare trip plans with a minimum set of road traffic data that only includes travel times for each segment of the road
network
n continuously monitor for receipt of any of the data flows from the Provide Trip Planning Operator Interface function
o when the request trip planning criteria data flow is received in (n), collect the criteria from the internal store of criteria used in (c) and send it
back the toe Provide Trip Planning Operator Interface function in the requested trip planning criteria data flow
p when the update trip planning criteria data flow is received in (n), use its contents to update the internal store of criteria used in (c)
q continuously monitor for receipt of the vehicle trip plan criteria changes data flow
r when the data flow in (q) is received, update the part of the internal store of criteria used in (c) that is used to prepare vehicle trip plans.

Tabelul 4. Fluxuri de date logice (6.5.3.9)

Fluxuri de Nume Descriere

date logice
fesp.gip-
poi_informatio It contains information, such as their location, opening times, price of service, nearest transport service points, access
n information, etc. about "Points of Interest" (e.g. monuments, museums, parks, gardens, etc.) in a specific locality. The
arrival of the Data Flow may be as a result of a previous request, or it may be unsolicited.
fesp.gip-
ps_information It contains information such as location, opening times, services that are provided, prices, etc. about "Personal
Intrare Services" (e.g. doctor, chemist, etc.,) in a specific locality. The arrival of the Data Flow may be as a result of a
previous request, or it may be unsolicited.
fesp.mmtip-
requested_trave It contains previously requested information about a journey involving the use of transport modes other than the
l_information private car, or a road-based freight vehicle.
mt.ptja_inter-
urban_recomm It contains routes through the inter-urban road network that are being recommended by the TCC, either as a result of
ended_routes Operator input, or as part of a traffic management strategy. The recommended routes may apply to all Vehicles or to
specific type(s) of Vehicle.
 mt.ptja_urban_r
ecommended_r It contains routes through the urban road network that are being recommended by the TCC, either as a result of
outes Operator input, or as part of a traffic management strategy. The recommended routes may apply to all Vehicles or to
specific type(s) of Vehicle.
pepf.ptja_servic
e_price It is used to provide the tariff associated with a service. The data flow includes the following elements:
- operator or external service provider ID,
- service ID- other parameters allowing a definition of the service (level of quality, duration, period of day or year,
etc.)
- tariff, possibly modulated according to the kind of contract, and the mode of payment.
pshvs.ptja_revis
ed_vehicle_trip It contains revised data about the way in which the Vehicle Trip Plan that a Driver is currently using is to be
_plan_requirem modified. It is sent when it is necessary for the Trip Plan to be changed, either because the Driver has requested it, or
ents because the road conditions have changed such that the trip plan needs to be improved.
pshvs.ptja_vehi
cle_trip_plan_c It contains suggested changes to the criteria used to create Vehicle Trip Plans. These changes are based on the
riteria_changes experiences gained from implementing already prepared Trip Plans and will be used in future Trip Plan preparation.
pshvs.ptja_vehi
cle_trip_plan_r It contains data from which a Vehicle Trip Plan is to be prepared. Most of the data will have been provided by the
equest Driver, either directly for this trip, or from data provided for previous trips. Other data may be provided by Vehicle
Systems.
ptja_modified_t
rip_plan_requir It contains revised data about a Traveller’s intended trip plan. It is sent when a Traveller wishes to revise the data
ements because the trip plan that has been produced is not to their satisfaction.
ptja_request_tri
p_planning_crit It contains a request for the current criteria that are used in the planning of trips in order to comply with trip planning
eria and/or travel management policies for output to the Travel Information Operator.
ptja_retrieve_P
T_trip_plannin It contains data about Public Transport services that is being retrieved from the PT Trip Planning Data Store for use in
g_data planning a Traveller’s trip.
ptja_retrieve_ro
ad_trip_plannin It contains data about the road network and its forecast conditions that is being retrieved from the Road Trip Planning
g_data Data Store for use in planning a Traveller’s trip.
ptja_revised_tri
p_plan_require It contains revised data about the way in which the trip plan that a Traveller is currently using is to be modified. It is
ments sent when it is necessary for the trip plan to be changed, either because the Traveller has requested it, or because the
travel conditions have changed such that the trip plan needs to be improved.
ptja_traveller_tr
ip_requirement It contains the description of a trip that a Traveller is planning, including origin, destination, places to be included in
the trip, modes for each part of the trip, plus details of required PT services and those provided by other modes and
information from the GTP Data Store.
ptja_update_tri
p_planning_crit It contains an update to the current criteria that are used in the planning of trips in order to comply with trip planning
eria and/or travel management policies.
ptja.pepf_servic
e_contract_info It contains all the information necessary to define the different types of contract that a user can place with an operator.
The data flow includes the following elements :
- operator ID
- list of all potential contracts, for each one (some parameters being optional) :
- service ID
- other parameters defining the service (level of quality, ...)
Iesire - geographical area covered
- period covered
- quantity of service purchased
- tariff
- mode of payment
ptja.pepf_servic
e_data It contains information about the different services available to the user and answers a request made by the user. The
data flow may include the following elements, depending on the request :
- type of service (transport, information, parking, …)
- type of information (schedule, access conditions, tariffs, …)
- location of service
- date / time of service- tariff- operator ID.
ptja.pshvs_revis
ed_vehicle_trip It contains the results from a request for changes to a Vehicle Trip Plan that was previously prepared for the Driver and
_plan_for_appr is now being implemented. The request was initiated because either the Driver wants to change this Trip Plan during
oval its implementation, or the road conditions make a change advisable. In both cases the revised Trip Plan will be
presented to the Driver for acceptance before it is implemented.
ptja.pshvs_vehi
cle_trip_plan_r It contains the description of a Vehicle Trip Plan that has been produced as a result of a previous request, resulting
esponse from input from the Driver.
 ptja_other_mod
e_data_for_trav It contains data about the services provided by other transport modes that has been obtained for use in Traveller Trip
el_information Plans and is now being made available for use in travel information.
ptja_pos/
pi_data_for_tra It contains data about Point of Interest (POI) and Personal Services (PS) that has been obtained for use in Traveller
vel_information Trip Plans and is now being made available for use in travel information.
ptja_requested_
trip_planning_c It contains the requested current criteria that are used in the planning of trips in order to comply with trip planning
riteria and/or travel management policies for output to the Travel Information Operator.
ptja_revised_tri
p_plan_for_app It contains the results from a request for changes to a trip plan that was previously prepared for the Traveller and is
roval now being implemented. The request was initiated because either the Traveller wanted to change this trip plan during
its implementation, or the travel conditions make a change advisable. In both cases, the revised trip plan will be
presented to the Traveller for acceptance before it is implemented.
ptja_toll_data_f
or_travel_infor It contains data about toll for bridges and tunnels and other parts of the road network that has been obtained for use in
mation Traveller Trip Plans and is now being made available for use in travel information.
ptja_traveller_tr
ip_description It contains the description of a trip that has been produced in response to a request from a Traveller. Details such as
the origin, destination, other places to be passed through during the trip, modes being used for each part of the trip,
plus details of the required PT services and those provided by other modes. Any changes from the trip as originally
proposed by the Traveller will be highlighted.
tesp.gip-
request_poi_inf It contains a request for information, such as location, opening times, price of service, nearest transport service points
ormation about " Points of Interest", e.g. monuments, museums, parks, gardens. etc. in a specific locality
tesp.gip-
request_ps_info It contains a request for information, such as location, opening times, services available, prices, etc., about "Points of
rmation Interest", e.g. doctors, chemists, etc. in a specific locality.
tesp.mmtip-
request_travel_i It contains a request for information about a journey involving the use of transport modes other than the private car, or
nformation a road-based freight vehicle.

Tabelul 5 Cerinte functionale (6.3.10)

Descriere
a continuously monitor for receipt of the trip plan for implementation data flow
b when the data flow in (a) is received, implement the trip plan that it contains
c continuously monitor for the receipt of the traveller location data flow and from its contents and the stored digital
map data determine the current location of the traveller
d send the result of (c) to the Monitor Trip Plan Implementation function in the traveller location data flow
e use the result of (c) to determine which part of the trip plan to implement
f if required by the trip plan load the trip guidance instructions data flow with the next instruction for the Traveller
and send it to the Provide Traveller Trip Interface function
g whilst (c) to (f) are being implemented, continuously monitor for receipt of the implement updated trip plan data
flow
h when the data flow in (g) is received, stop implementation of the current trip plan and wait for (a) again
i when the data flow containing trip plan is received, store its contents internally and continue with (c) to (f), starting
from the last know location of the Traveller

Tabelul 6. Fluxuri de date logice (6.3.10)

Fluxuri de date Nume Descriere

logice
fesp.g-
trip_plan_implement It contains digital map data for use in the implementation of a trip plan by a Traveller.
Intrare ation_map_data
flds-
ptja_traveller_locatio It contains analogue or digital data from which functionality can determine the current location of a
n Traveller for implementing a trip plan.
ptja_imlpement_upda
ted_trip_plan It contains a command to implement the updated version of the current trip plan, which will be
automatically sent by the trip plan data store management Function.
ptja_trip_plan_for_i
mplementation It contains all the data that describes the trip, e.g. origin, destination, way points, and the preferences of the
 Traveller, and is used to implement the trip. It can be multi-modal, can use multiple intermediate
destinations (way points) and can be for a private person or a larger group of people. For a further
description refer to the Private Trip File Description.
Iesire ptja_traveller_locatio
n_for_trip_monitorin It contains the current location of the Traveller during the course of the implementation of a trip plan and is
g used to monitor the progress of the Traveller.
ptja_trip_guidance_in
structions It contains the step by step instructions that the Traveller has to follow in order to implement the requested
trip plan and applies for all modes of travel that are included in the plan.

4. Arhitectura fizica

4.1 Definirea componentelor fizice

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ă.
Pentru gruparea funcţiilor în entităţi fizice este necesară definirea acestor
entităţi, ca subsisteme ale sistemului în cauză (definirea acestor subsisteme se face
prin atribuirea unui nume şi a unei locaţii fizice – amplasament).
 In continuare trebuiesc alocate functiile catre entitatile fizice definite anterior.
Identificarea modulelor componente fiecărui subsistem, precum şi alocarea funcţiilor
către subsisteme, conduce în mod automat la realizarea următoarei etape de alocare a
funcţiilor către module.
 Pentru ca un sistem sa fie functional, trebuie ca toate componentele sale fizice
si functionale sa comunice intre ele.

5. Arhitectura de securitate
Securitatea informației se ocupă cu protejarea informației și sistemelor
informatice de accesul neautorizat, folosirea, dezvăluirea, întreruperea, modificarea
or distrugerea lor.
Cele trei componente ale securității informației sunt: confidențialitatea,
integritatea și disponibilitatea. Confidențialitatea este asigurata prin criptarea
informației. Integritatea se obține prin mecanisme și algoritmi de dispersie.
Disponibilitatea e asigurata prin întărirea securității rețelei sau rețelelor de sisteme
informatice și asigurarea de copii de siguranță.
6. Concluzii
Sistemele de autoghidare pentru autovehicule reprezinta inca o tehnologie la
nivel de proiect, aceasta nefiind accesibila la scara larga nefiind inca disponibila
pentru utilizatorii cotidieni. Cu toate aceste exista deja un sistem apropiat de acesta,
ce a fost dezvoltat de producatorul American de masini electrice Tesla. Acest sistem
se numeste Autopilot si este capabil sa adapteze viteza de mers in functie de limitele
afisate de semnele de circulatie, mentine directia vehiculului, recunoaste liniile
continue si discontinue, franeaza automat atunci cand este nevoie si poate
deasemenea sa mentina trasa drumului. Pentru a fi functional, acest sistem dispune de
12 senzori cu ultrasunete si o camera video aplasata in fata vehiculului.
Din punctul meu de vedere, aceste sisteme de autoghidare vor fi prezente pe
toate autovehiculele in viitor pentru a spori siguranta si confortul conducatorilor auto
dar si a pietonilor.

7. Bibliografie
http://www.frame-online.net/?q=the-architecture/selection-tool.html

Arhitecturi ITS – suport curs

teslamotors.com