Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Архитектура интеллектуальных транспортных систем = Intelligent Transport Systems’ Architecture. Учебное пособие
.pdf
61
– The managing of the operation of a fleet of freight vehicles with
scheduling and the specification of drivers’ duties and vehicle maintenance.
– Providing functionality for freight and fleet management that is
positioned on-board a freight vehicle for receiving instructions about route
plans and schedules or other information.
9) Provide Support for Cooperative Systems
This area provides the functionality that is needed to support the
implementation of Cooperative Systems that cannot be wholly assigned to
other areas, like “Manage traffic” or “Provide Advanced Driver Assistance
Systems”.
Steps to build a functional architecture are the following:
– Identify the user needs that define the services to be provided.
– Select functions from the trace table, which provide a cross reference
from user needs to the functions that help to satisfy them.
– Identify their functional areas or sub-functional group.
– Confirm that the selected functions are reasonable.
– Confirm that those functions “nearby” but not selected, should be
omitted.
– Select the data flows needed by the selected functions.
– Select the data stores needed by the selected data flows.
– Select the additional data flows needed by the selected data stores.
– Identify the terminators (nodes to outside world) with all these data
flows.
Example of FRAME architecture functional viewpoint for Traffic
Adaptive Crossing is shown on fig. 5.2.
The ARC-IT Functional Viewpoint provides an analysis of abstract
functional elements and their logical interactions. This is in direct contrast to
the physical and communications viewpoints that focus on engineering
concerns of how functions are implemented, where they are allocated, how
they transfer information, which protocols are used, and what method is used
to implement them. In other words, the Functional talks about "the what" while
the Physical and Communications are more concerned with "the how."
62
Fig. 5.2. FRAME architecture functional viewpoint Traffic Adaptive Crossing
Stakeholders that take a project development role in an ITS deployment
may be informed by the functional viewpoint, in particular the requirements,
which are allocated to functional objects in the Physical View. Mostly, this
would be stakeholders filling the role of Service Provider, Application
Developer or Device Developer. The functional view can help these
stakeholders answer questions such as:
What kinds of data are required to implement a given service?
What functionality is required to implement a given service?
The ARC-IT Functional Model is developed using a Structured Analysis
methodology, based on the work of Hatley/Pirbhai. Previous versions of the
63
National ITS architecture depicted the logical architecture using YourdonDemarco Data Flow Diagrams; while the Functional Model does not include
those graphics, it does use some of the same structural artifacts:
Process: A function or activity that is required to support service
package needs. A Process performs actions to achieve an objective or to
support actions of another process. This may involve data collection, data
transformation, data generation, data generation or processing in performing
those actions. The most detailed processes (sometimes called primitives) are
defined in Process Specifications (P-Specs).
Process Specification (p-spec): The textual definition of the most
detailed processes. The process specification includes an overview, a set of
functional requirements, and a complete set of inputs and outputs.
Data Flows: Representations of data flowing between processes or
between a process and an external physical object (or terminator) in the
functional view. Data flows are aggregated together to form high-level
information flows in the physical view.
Terminator: An external physical object that represents a system beyond
the architecture boundary. A terminator may be a source and/or a sink for
information. ARC-IT does not define any of the internal functionality of
a terminator.
The Functional View defines Processes to control and manage system
behavior, such as monitoring, and other active control elements that are part
of describing the functional behavior of the system.
64
6. ITS ARCHITECTURE PHYSICAL VIEWPOINT
A Physical View shows where, physically, each Function and Data Store
is to be located. The Physical Viewpoint, sometimes called physical
architecture, is the result of grouping together the defined functions in the
functional architecture from every single service into physical entities.
A group of functions in a physical location is called a sub-system. Each subsystem of functions may, or may not, be divided into modules. The following
section describes the physical elements that may be used:
1. Sub-systems
Each system normally consists of two or more sub-systems, and each
sub-system consists of one or more element of the functional architecture
(functions, data stores) and physical data flows communicate with other subsystems and terminators. It is important that each sub-system includes all the
parts of the functional architecture that exist in the same physical location.
Example locations can be:
Central – the place that is used by parts of a system to collect and manage
the storage and processing of traffic data, toll payments, freight shipping
orders, and/or the generation of traffic management measures, or fleet
management instructions, with or without human intervention, e.g. a traffic
control/information centre, or a freight and fleet management center.
Roadside – the place that is used by parts of a system for the detection
of traffic, vehicles and pedestrians, or the collection of tolls, and/or the
generation of traffic management measures, and/or the provision of
information and commands to drivers and/or pedestrians.
Vehicle – a device that is capable of moving through the road network
and carrying one or more people (bicycles, motorcycles, cars, public transport
vehicles) and/or goods (vans and any other form of vehicle able to carry freight
on roads) in which parts of system can be installed during manufacture or can
be added on later.
Personal device – a nomadic device in which part of the system can be
installed so that it can be easily used (and possibly carried) by travellers as one
of their personal possessions.
Freight device – a device in which part of the system can be installed so
that it is an integral part of a freight carrying unit, e. g. freight container, trailer,
or vehicle body.
65
Kiosk – a device, usually located in a public place, into which part of
the system can be installed to enable travellers to have limited and controlled
access to some of its facilities.
But other names can be used, e.g. the name of a building instead of
“Central”, in order to make things clear to the reader.
The example below (fig. 6.1) shows the above Functions and Data Stores
allocated either to Sub-System X or to Sub-System Y. A consequence on this
is that the two Functional Data Flows FDFi and FDFj now have to pass
between the two Sub-Systems and thus comprise a single Physical Data Flow.
Fig. 6.1. FRAME architecture physical view
2. Modules
A sub-system may consist of two or more modules and each module has
the same properties as the sub-system but its own separate physical identity.
The main difference between modules and sub-systems is that each module is
more likely to contain functionality from a single area of the function
architecture. Another reason for using modules is to create physical
components that contain a grouping of functionality that is more logical from
a manufacturing or physical design view point. Modules also communicate
with each other using physical data flows.
3. Terminators
A terminator is an external entity representing the outside world,
connected to the architecture by dataflows. Terminators are the source of the
66
data used by the system or the destination of information generated by the
system. A terminator might be an external system (e.g. weather system),
a human entity (e.g. driver, traveller), a physical entity (e.g. road pavement)
or an organisation (e.g. service provider).
4. Physical data flows
Physical data flows are the communication links within a system –
between sub-systems, modules and to/from terminators. Each physical data
flow consists of one or more functional data flows.
5. Terminator data flows
The terminator data flows are data flows which provide the
communication links between sub-systems/modules and the outside world –
terminators.
Example of physical diagram (FRAME) for Cooperative Systems
(CoSy) is shown on fig.6.2.
Fig. 6.2. Cooperative Systems (CoSy) physical diagram (FRAME)
67
The ARC-IT Physical Viewpoint represents physical elements that
operate in the field and the backoffice, the functionality contained within those
elements, the roles elements play in delivering user services, and the
connections between those elements.
The Physical Viewpoint is an engineering viewpoint: it lies closer to
design than the functional viewpoint, and leads directly to the
Communications Viewpoint. The bounds of an element in the Physical View
are constrained by the Enterprise view (who owns, who operates etc.),
informed by the Functional (what does it do) and ultimately specified in
accordance with physical constraints.
All stakeholders will find the Physical viewpoint informative. The
Physical provides the basis for Service Packages, which are a concise,
comparatively easy to read and follow diagrammatic artifact that
communicates notions of service delivery, functionality, information
exchange and concerns related to those concepts. The Physical Viewpoint
enables the engineer to answer questions such as:
What physical entities are involved in the delivery of a given service?
What interfaces are required between different physical elements?
What functionality is allocated to physical entities?
What are the security considerations for information exchanged between
physical elements?
What are the security considerations for physical devices?
The physical view describes the transportation systems and the
information exchanges that support ITS. In this view, the Architecture is
depicted as a set of integrated Physical Objects (Subsystems and Terminators)
that interact and exchange information to support the Architecture service
packages. Physical Objects are defined to represent the major physical
components of the ITS architecture. Physical Objects include subsystems, and
terminators that together provide a set of capabilities that are more than would
be implemented at any one place or time. Subsystems are Physical Objects
that are part of the overall Intelligent Transportation System and provide the
functionality that is 'inside-the-boundary' of ITS. Terminators are Physical
Objects that lie at the boundary of ITS and supply information needed by ITS'
functions or receive information from ITS. Functional Objects break up the
subsystems into deployment-sized pieces and define more specifically the
68
functionality and interfaces that are required to support a particular Service
Package. Information Flows depict the exchange of information that occurs
between Physical Objects (Subsystems and Terminators). The information
exchanges in the Physical View are identified by Triples that include the
source and destination Physical Objects and the Information Flow that is
exchanged.
The Physical view is related to the other Architecture views. Each
Functional Object is linked to the Functional View, which describes more
precisely the functions that are performed and the details of the data that is
exchanged by the object. Physical Objects and Functional Objects are also
depicted as Resources in the Enterprise view, which describes the
organizations that are involved and the roles they play in installing, operating,
maintaining, and certifying all of the components of the Architecture.
At the heart of the physical view, the physical objects are organized into
six different Classes that define ITS at the highest level of abstraction. A
general "ITS" Class covers all of ITS while five more specific classes (Center,
Support, Field, Vehicle, and Personal) are used to group physical objects based
on where they reside and fundamentally how they behave and interact with
other physical objects. Each of the classes is shown in the figures below (fig. 6.3).
Fig. 6.3. ARC-IT physical objects scheme
Considering the architecture from this most abstract (highest) level, the
general interactions between physical objects can be shown at the class level
as shown in the figure below. Note that all of the interactions (Center to
69
Center, Center to Field, etc.) are part of ITS, so they are all included in the ITS
Class. Only specific interactions apply to the more specific classes. For
example, the Center to Center interaction only applies to Center- and SupportClass physical objects. Center to Center communications does not apply to
Field-, Vehicle-, or Personal-Class physical objects (fig. 6.4).
Fig. 6.4. ARC-IT physical objects primary interconnections scheme
Each of these Classes include one or more subsystems that are revealed
at the next level of detail in the following figure. As shown, if we know the
Class of a subsystem (e.g., Center), then we know generally how it interacts
with other subsystems (e.g., a Center interacts with other Centers using 'Center
to Center' Communications). The 'ITS Object' is the only subsystem defined
for the "ITS" Class. Specific connections are not shown for the ITS Object in
the figure since it can represent any ITS system, of any class, so it might be
interconnected using any of the connections shown.
While it may not be intuitive at first, the "ITS Object" serves an
important purpose in the ARC-IT physical view. The ITS Object is used in
ARC-IT to define functionality and interfaces that may apply to any ITS
device or system, regardless of Class. For example, obtaining security
certificates and then using those certificates to support encryption and
authentication is required for secure communications whether a particular ITS
device is in a Center, a Support system, Field Equipment, Vehicle Equipment,
70
or a Personal Device. Using the ITS Object, ARC-IT defines the functionality
and interfaces for core functions like this just once, instead of having to
redundantly define the same core functions for every subsystem (fig. 6.5).
Considering this reuse objective, we can think of the ARC-IT physical
objects in a hierarchy with the ITS Object at the top as shown in the following
figure. The most generally-applicable functions and interfaces that may apply
to all of ITS are defined at this level. Class-level physical objects like "Center"
are shown at the next level of the hierarchy. Functions and interfaces that are
shared by all ITS Centers, but not by subsystems of other classes, are defined
in the "Center" physical object. Finally, the most specific physical objects like
"Authorizing Center" and "Commercial Vehicle Administration Center"
include more specific functions and interfaces unique to that type of Center.
Fig. 6.5. ARC-IT subsystem diagram
The Physical Viewpoint defines the following objects:
1. Physical Object (P-Object): Person, place, or thing that participates in
ITS. Physical Objects are defined in terms of the applications they support, the
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]