Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Архитектура интеллектуальных транспортных систем = Intelligent Transport Systems’ Architecture. Учебное пособие
.pdf
71
processing they include, and their interfaces with other physical objects. They
are grouped into five classes: Center, Field, Support, Personal and Vehicle.
Physical Objects are defined with scope such that they are under the control
of a single Enterprise Object.
2. Center: An element that provides application, management,
administrative, and support functions from a fixed location not in proximity to
the road network. The terms "back office" and "center" are used
interchangeably. Center is traditionally a transportation-focused term, evoking
management centers to support transportation needs, while back office
generally refers to commercial applications.
3. Field: Infrastructure proximate to the transportation network which
performs surveillance (e.g. traffic detectors, cameras), traffic control (e.g.
signal controllers), information provision (e.g. Dynamic Message Signs
(DMS)) and local transaction (e.g., tolling, parking) functions. Typically
governed by transportation management functions running in centers. Field
also includes connected vehicle roadside equipment and other non-DSRC
wireless communications infrastructure that provides communications
between mobile elements and fixed infrastructure.
4. Support: A center that provides a non-transportation specific service.
Typically these are enabling functions, such as communications facilitation,
security or management.
5. Personal: Equipment used by travelers to access transportation
services pre-trip and en route. This includes mobile/handheld as well as
desktop equipment owned and operated by the traveler.
6. Vehicle: Vehicles, including driver information and safety systems
applicable to all vehicle types.
7. Functional Object: The building blocks of the physical objects of the
physical view. Functional objects group similar processes of a particular
Physical Object together into an "implementable" package. The grouping also
takes into account the need to accommodate various levels of functionality.
Since Functional Objects are both the most detailed components of the
physical view and tied to specific service packages, they provide the common
link between an interface-oriented architecture definition and deploymentoriented applications. Functional Objects provide the functionality defined by
P-Specs in the Functional View.

72
8. Information Flow: Information that is exchanged between physical
objects in the physical view. Information flows and their associated
communication requirements provide the highest-level definition of
interfaces. Information flows are related to entity relationships in the
Enterprise View, and are more fully detailed in the Communications View.
Information Flows are characterized by Flow Characteristics, which imply
various communications protocol standards. They are always accompanied by
a provision agreement relationship. Such relationships are formal if both
participants are centers, support or field equipment. They are nearly always
informal if between two mobile objects. If between mobile and fixed, the
relationship may be formal if personalized or individually targeted
information is exchanged.
9. Triple: The combination of P-Object source, Information Flow and
P-Object destination. The Triple is the foundational structure used to define
an interface.
Fig. 6.6. ARC-IT Roadway Closure Management physical diagram

73
10. Subsystem: Physical object with defined functionality. Inside the
ARC-IT system boundary.
11. Terminator: Physical object without defined functionality. Outside
the ARC-IT system boundary.
12. Service Package (Physical) Diagram: A summary diagram
illustrating all of the P-Objects, Functional Objects and Information Flows
likely needed to support the Service Package. Service Package diagrams may
support more than one use case. Physical Service Package diagrams use the
following graphics to illustrate physical elements (fig. 6.6).
Conclusion
Many developing economies will have little or no experience of ITS.
This means that there will be very few existing ITS deployments and where
they do exist, they will often be standalone having no links with any other
systems. Thus any new ITS implementation will be starting from what is
virtually a "greenfield site". In this situation, creating and using ITS
architectures is virtually a "must" since it provides the greatest opportunity for
assessing all of the options for component and communications
configurations. This should be done without the influences of suppliers and
providers, who will inevitably be keen to sell their own products, but should
take account of what standards are available, particularly for communications.
Creating and using ITS architectures will provide the opportunity to
specify components and communications that will produce an ITS
implementation that is "open" – one that uses open, or publicly available,
standards to which anyone can conform. This will in turn widen the potential
supplier and provider base, in other words make it easier for a broader range
of companies to tender for the supply of components and the provision of
communications. This will apply not only to the initial ITS implementation
but also to future expansions and upgrades, thus avoiding the trap of being
"locked into" a particular source of components and communications.

74
Reference List
1. ITS Terminology: General ITS and Traffic Terms (1000 series). URL:
https://rno-its.piarc.org/en/system/files/media/file/its_terminology_1000_series_1.pdf
2. FRAME The European ITS Framework Architecture: https://frame-
next.eu/
3. US DOT. The National ITS architecture URL: www.its.dot.gov/arch/
4. ARC-IT https://www.arc-it.net/
5. The artefacts in the FRAME architecture URL: https://frame-
next.eu/downloads-and-documents/
7. Review of European, and world-wide, state of the art ITS architecture
activities URL: https://frame-next.eu/downloads-and-documents/
8. FRAME architecture - Theory of Operations (All Parts)
9. Key Concepts of the National ITS architecture URL: https://www.arc-
it.net/documents/keyconcepts/keyconcepts.pdf
10. Regional ITS architecture guide URL: https://www.arc-
it.net/documents/raguide/raguide.pdf
11. Regional Architecture Development for Intelligent Transportation. URL:
https://www.arc-it.net/tools/RAD-ITv9Help.pdf
12. National ITS architecture. Physical Architecture URL: https://www.arc-
it.net/documents/physical/physical.pdf
13. ISO (the International Organization for Standardization)
https://www.iso.org/
14. ESTI URL: https://www.etsi.org/
15. IEEE. Institute of Electrical and Electronics Engineers. URL:
https://standards.ieee.org/
16. ISO 14812, Intelligent transport systems – Vocabulary
17. ISO 14813-1:2015 Intelligent transport systems – Reference model
architecture(s) for the ITS sector – Part 1: ITS service domains, service groups and
services
18. ISO 14813-5: Intelligent transport systems – Reference model
architecture(s) for the ITS sector – Part 5: Requirements for architecture description
in ITS standards
19. ISO 14813-7: Intelligent transport systems – Reference model
architecture(s) for the ITS sector – Part 7: ITS standards framework
20. ISO 17419:2018(en) Intelligent transport systems – Cooperative systems
– Globally unique identification
21. Harmonized Architecture Reference for Technical Standards URL:
http://htg7.org/html/methodology/architecture.html

75
Contents
1. INTRODUCTION TO ITS ARCHITECTURE…………………………
3
1.1.
Аnatomy of ITS architecture……………………………………...
7
1.2.
Framework ITS architectures……………………………………..
12
2. ITS STANDARDS……………………………………………………...
16
2.1.
About standards…………………………………………………...
16
2.2.
Applying standards………………………………………………..
22
2.3.
Standards organizations…………………………………………...
25
3. ITS ARCHITECTURE EMPLOYMENT………………………………
28
3.1.
Reasons for creating. Benefits and risks…………………………..
28
3.2.
The use of ITS architectures in the ITS implementation process…..
32
3.3.
ITS architectures using……………………………………………
35
3.3.1.
Using the US ITS architecture………………………………
41
3.3.2.
Using the European ITS
Framework Architecture (FRAME).......................................
49
4. ITS ARCHITECTURE AND HUMAN FACTORS…………………….
52
5. ITS ARCHITECTURE FUNCTIONAL VIEWPOINT…………………
58
6. ITS ARCHITECTURE PHYSICAL VIEWPOINT……………………..
64
Conclusion…………………………………………………………………
73
Reference List……………………………………………………………...
74

76
Учебное издание
Зырянов Владимир Васильевич
Феофилова Анастасия Александровна
АРХИТЕКТУРА
ИНТЕЛЛЕКТУАЛЬНЫХ ТРАНСПОРТНЫХ СИСТЕМ
=
INTELLIGENT TRANSPORT SYSTEMS’ ARCHITECTURE
Редактор Е.В. Хейгетян
Компьютерная обработка: Е.В. Хейгетян
____________________________________________________
В печать 17.05.2023.
Формат 60×84/16. Объем 4,8 усл. п. л.
Тираж 100 экз. Заказ № 802. Цена свободная
____________________________________________________
Издательский центр ДГТУ
Адрес университета и полиграфического предприятия:
344003, г. Ростов-на-Дону, пл. Гагарина, 1
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
