Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Архитектура интеллектуальных транспортных систем = Intelligent Transport Systems’ Architecture. Учебное пособие
.pdf
41
can be adapted to include local variations or new services if users follow the
detailed guidance that is provided (See Using the FRAME Architecture)
If the services described by the stakeholders have a "US flavour" then
the US National ITS architecture is the obvious starting point – particularly if
it is used for a single ITS implementation. In this case it is only the content of
the services that is the deciding factor.
If there is not a good match between the services selected by the
stakeholders and the US User Services or Service Packages, then the FRAME
architecture is a better starting point as it will be easier to adapt.
3.3.1. Using the US ITS architecture
One of the two main starting points for creating a new ITS architecture
from an existing ITS architecture is the US National ITS architecture.
ARC-IT is a reference architecture that provides a common basis for
planners and engineers with differing concerns to conceive, design and
implement systems using a common language as a basis for delivering ITS,
but does not mandate any particular implementation. The National ITS
architecture was developed over 25 years ago in order to:
Provide a National "Vision" for ITS.
Guide Sound ITS Planning and Investments at the State and Local
Level.
Identify and Scope Need for ITS Standards.
The planning attributes for which this connection is defined are:
Planning Factors: There are seven planning factors defined by the most
recent Transportation authorization bill, Fixing America's Surface
Transportation (FAST), that metropolitan planning organizations (MPOs) and
states should consider when developing their transportation plans.
Goals: Transportation planning begins with a set of broad goals that
reflect the desired outcomes and the transportation vision for the region. The
representative goals included in the ARC-IT mapping to planning are closely
tied to the planning factors.
Objectives: Each of the goals in a metropolitan or statewide
transportation plan is supported by one or more 'objectives' that define what
needs to occur to accomplish the goals. A range of objectives are included in
42
the ARC-IT mapping to planning, gathered from a variety of references and
recent transportation plans, that reflect the spectrum of objectives that are used
in current practice.
In order to guide the investments in ITS at the state and local level,
23 CFR 940 requires the creation of a Regional ITS architecture, which is
defined by the regulation as "a regional framework for ensuring institutional
agreement and technical integration for the implementation of ITS projects or
groups of projects". The definition of the components of a Regional ITS
architecture and an approach for the update or development of these
architectures is provided Regional ITS architecture Definition and
Development.
A regional ITS architecture can effectively bridge the gap between
strategic planning for an integrated surface transportation system and the ITS
projects that support that strategic vision. The principal value of a regional ITS
architecture is that it provides a context for projects that include ITS so that
each project can build a piece of a larger system. The regional ITS architecture
can be used to visualize and articulate the overall ITS system for the region so
that all the stakeholders in a region spend their money compatibly instead of
competitively. Connection between planning attributes defined by the USDOT
and the views of ARC-IT is shown below (fig. 3.4).
Fig. 3.4. Connection between transportation planning and ARC-IT
The implementation of transportation projects can be seen as a lifecycle
as shown below and the regional ITS architecture can be used to support the
planning, programming, and implementation of those projects.
43
The diagram above (fig. 3.5) shows the transportation project lifecycle
at the highest level. Starting at the top of the diagram, goals and objectives of
the transportation system are identified in long-range planning. To meet these
goals and objectives, strategies and projects to implement the strategies are
identified. To deploy the projects, funding must be secured via the federal
transportation programming and/or agency budgeting processes. Once
funding has been secured for a project, it can be implemented. Once
implemented, it is operated and maintained (O&M). During O&M ideas for
improvement or replacement are identified and fed into the long-range
planning process to begin the cycle again.
Fig. 3.5. Regional ITS architecture usage in the transportation lifecycle
The regional ITS architecture supports three of these major steps –
planning, programming, and implementation.
1. Use in Long Range Transportation Planning. A regional ITS
architecture can be used to support metropolitan and statewide long-range
transportation planning. A regional architecture provides a means by which
peer agencies can jointly define their vision for ITS development based on
regional goals and objectives. Using the regional ITS architecture, a region
can plan for technology application and integration to support more effective
planning for operations.
2. Use in Programming/ Budgeting. A regional ITS architecture can be
used to support the programming/ budgeting of projects in metropolitan and
44
statewide regions. The regional ITS architecture provides a high-level
description of ITS projects, which can serve as an input the definition and
prioritization that occurs during programming/ budgeting.
3. Use in Project Development. By starting with the regional
ITS architecture, the steps taken by each project will be on the path to fulfilling
the broader objectives set forth in the long-range transportation plan.
A well-maintained regional architecture that is created and maintained using
RAD-IT provides context for ITS projects and the initial input for the systems
engineering for a project. Once a project has been articulated in RAD-IT, the
systems engineer can use SET-IT to develop project specific output. Projectrelevant information from RAD-IT can be used within SET-IT to support not
only the development of a project architecture, but also the systems
engineering documentation such as Concept of Operations and System
Architecture Document.
Fig. 3.6. Regional ITS architecture components
The components that make up an architecture include (fig. 3.6):
• Architecture Scope
Architecture Scope provides a description of the region for which an
ITS architecture is developed. There are three dimensions to the scope:
geographic, time horizon, and scope of services
45
• List of Stakeholders
Stakeholders are the agencies and organizations that own, operate,
maintain or use the ITS systems in the region as well as other agencies/
authorities/ other-entities that have an interest in regional transportation issues
(e.g., MPOs, etc.). This includes both public and private organizations.
• Connection of architecture to Regional Planning Goals, Objectives,
and Strategies
Connecting a region’s planning processes to the ITS services in the
architecture makes the architecture more useful to the region and more
maintainable over time. Transportation planning considers changes to be made
to a region’s transportation network in order to address regional needs. These
needs are expressed by a set of goals, objectives or strategies. A goal is a broad
statement that describes a desired end state. In the metropolitan or statewide
transportation planning process, goals stem from the values inherent in the
area’s vision 1(e.g. Increase the safety of the transportation system for
motorized and non-motorized users). Objectives are specific, measurable
statements related to the attainment of goals2. Strategies are approaches that
a region may take to address the goals or objectives.
• Inventory of ITS Elements
Each stakeholder agency, company, or group owns, operates,
or maintains ITS systems in the region. In this step, a comprehensive inventory
of these existing and planned systems is developed based on existing
information and stakeholder input. ITS Elements are the systems, devices, or
equipment, that provide ITS services or share information as part of the ITS
services. An inventory also includes non-ITS elements that provide
information to or get information from the ITS elements. A comprehensive
inventory of “ITS elements” is one of the key building blocks for a regional
ITS architecture that represent these systems.
• Regional ITS Services
The services performed by ITS systems meet the stakeholders’ needs
for a region and demonstrate how the elements are connected. ITS services are
transportation services performed using ITS elements that are deployed to
meet the region’s operational goals and objectives. In a regional ITS
architecture service packages are used to identify the pieces of the architecture
that are required to implement a particular ITS service.
46
• User Needs
In a regional ITS architecture User Needs provide a starting point
to determine system requirements that the ITS elements will need to satisfy
in order to implement the ITS services. A user need is a capability that
is identified to accomplish a specific goal or solve a problem that is to be
supported by the system. ARC-IT defines a set of user needs for all users that
participate in ITS. These needs are apportioned to service packages according
to the ability of those service packages to address these needs. User needs are
then traced to requirements that are written for each functional object.
• Operational Concept (Stakeholders' Roles and Responsibilities)
Typically, in transportation stakeholders own, develop, operate, or
maintain portions of the transportation system. Responsibilities cover
activities that the stakeholders engage in as they perform their roles. For
example, an agency that operates traffic signal systems will be responsible for
providing adequately trained staff, maintenance of the system, and provision
of information about the system to other agencies and the public.
• System Functions and Requirements
Functional requirements are a high-level description of the required
functionality for each ITS element to provide the ITS services that have been
identified for the region. They describe WHAT a system must do to provide
the ITS services. In a regional ITS architecture, the functional requirements
focus on the high-level requirements that support regional integration. For a
project ITS architecture, these are broken down into more detailed
requirements to document fully the functionality of the system.
• System Interfaces Supporting the Services
‾ This part of the architecture identifies the information to be exchanged
between systems. Interfaces include the electronic exchange of information
between ITS elements. Interfaces can be defined by at two levels:
• Interconnects: Communications paths that carry information between
elements. The majority of the interconnects are various types of
communications links. Some of the key types of communications links
relevant to regional ITS architectures are Center to Center (C2C), Center to
Field (C2F), Field to Field (F2F), Wide Area Wireless (WAW), and Short
Range Wireless, including Dedicated Short Range Communications (DSRC).
47
• Information Flows: Information that is exchanged between elements,
including a high-level description of the information transmitted from one
element to another.
• Communications and Device Standards
‾ Identifying which ITS standards to use in a region helps with the
overall interoperability of the systems deployed among different agencies
using different devices from various vendors. ITS standards are documented
technical specifications sponsored by a Standards Development Organization
(SDO) to be used consistently as rules, guidelines, or definitions of
characteristics. ITS Standards are primarily defined for interfaces between ITS
elements, but they can also be defined for ITS elements as in the physical
cabinet and traffic controller standards developed by the National Electrical
Manufacturers Association (NEMA) and other organizations and Society of
Automotive Engineers (SAE) standards developed for motor vehicles.
• Interagency Agreements to support ITS services and projects
‾ Agreements between stakeholders define the integration planned
between their systems, the plans for maintaining and operating the elements
and each other’s funding responsibilities. To deploy the services and projects
defined in the architecture, agreements between stakeholders may be required
especially when inter-jurisdictional interfaces are involved. The architecture
should list the agreements needed in order for cooperation and integration to
be achieved, including how to deploy interfaces, who maintains and operates
the elements, and how the operations will be funded.
• Sequence of Regional ITS Projects
‾ Defining a sequence of projects as part of the regional ITS architecture
helps readers see just how things will be rolled out in their region. According
to CFR 940, Intelligent Transportation System (ITS) is defined as “electronics,
communications, or information processing used singly or in combination to
improve the efficiency or safety of a surface transportation system.” An ITS
project is any project that in whole or in part funds the acquisition of
technologies or systems of technologies that provide an ITS service. Project
sequencing is defined as any relevant ordering of the projects in order to
contribute to the integrated regional transportation system depicted in the
regional ITS architecture.
As shown in the figure 3.6 the scope of the architecture defines what
will be included in each of the other components. Each of the components is
48
connected to other parts of the architecture. Stakeholders are related to the
Inventory, Agreements, and the Roles and Responsibilities. Inventory is
connected to Functions/Requirements, Services/User Needs, and Interfaces.
Functions are also related to Services and Interfaces. Services are also related
to Roles and Responsibilities and Interfaces as well as Planning
Objects/Strategies. Interfaces are also related to Standards. Projects are at the
bottom to indicate that each component is implemented in a project.
While the components listed above constitute the architecture baseline,
a key consideration is what documents, files or databases hold the information
from these components. The most common artifacts are:
– RAD-IT file. This file contains the details of components described
above
– Documentation. The most common documentation is an Architecture
document that describes the different components and may contain the
architecture maintenance plan. Some architectures put all the details of their
architecture in a document (or documents), usually in lieu of having a web
site. Sometime a maintenance or use plan are separate documents and
sometimes chapters in a single architecture document. Documentation can also
include spreadsheet information such as architecture changes planned for the
next update.
• Diagram files. Some architectures create customized service package
diagrams that are contained in separate applications such as Visio or
PowerPoint.
• Web files. Many architectures create a web-based version of the
architecture. The set of files comprising the web site are another key artifact.
In addition to the components of the architecture being maintained
above, it is also important to document the resources that were used along the
way to develop the architecture – the Region’s Transportation Plan, TIP, ITS
Strategic Plans, TSMO plans, various studies, as well as other regional ITS
architecture. Document these other resources with their titles, dates or
versions, and where they can be found so that future maintainers can
understand some of the background that supported the development of this
regional ITS architecture and remember that changes to those documents may
affect the architecture.
49
3.3.2. Using the European ITS Framework Architecture (FRAME)
One of the two main starting points for creating a new ITS architecture
from an existing ITS architecture is the European ITS Framework
Architecture, commonly known as the FRAME architecture. This example is
based on the work done to create an ITS architecture for a local road authority
in the UK (the County of Kent) who has given permission for its use in this
web resource.
The FRAME architecture was created to provide a minimum stable
framework necessary for the deployment of integrated and inter-operable ITS
within the European Union.
The FRAME architecture comprises the top level requirements and
functionality, or the Use Cases, for almost all the ITS applications and services
that have been considered for implementation somewhere in the European
Union. It is at a “level” such that it can be used as a reference by all ITS
architects, and is intended to be the foundation for building the other types of
architecture that will be necessary. It will enable them to guarantee compliance
at the interfaces of other systems so that seamless services can be provided to
cross-border travelers, and an open European market of compatible
components can be established.
The FRAME architecture is not intended to be used in its entirety,
instead users select the applications and services that they want for their
Nation, Region, City, etc. and create a sub-set that conforms to their
requirements. Using the FRAME architecture to do this has two big
advantages:
Most of the work has already been done, and there are FREE Tools
available from this website to help you do the rest.
If adjacent authorities both have ITS architectures based on FRAME
then it is easy to identify commonalities so that common services can be
integrated to provide inter-operability.
Note: The FRAME architecture does NOT provide detailed designs for
equipment. It only describes what is required and not, how to make it. It has
already been used by a number of Nations, Regions, Cities and Projects.
A distinctive feature of the FRAME architecture is that it is designed to
have sub-sets created from it, and is thus unlikely to be used in its entirety
50
(fig. 3.7). Indeed, on occasions, it contains more than one way of performing
a service and the user can select the most appropriate set of functionalities to
deliver it in that environment. Thus the FRAME architecture is not so much
a model of integrated ITS, as a framework from which specific models of
integrated ITS can be created in a systematic and common manner.
Fig. 3.7. FRAME – the Framework Architecture Made for Europe
(source http://frame-online.eu/)
The FRAME architecture now covers the following areas of ITS:
Electronic Fee Collection;
Emergency Notification and Response – Roadside and In-Vehicle
Notification;
Traffic Management – Urban, Inter-Urban, Parking, Tunnels and
Bridges, Maintenance and Simulation, together with the Management
of Incidents, Road Vehicle Based Pollution and the Demand for Road Use;
Public Transport Management – Schedules, Fares, On-Demand
Services, Fleet and Driver Management;
In-Vehicle Systems – includes some Cooperative Systems;
Traveller Assistance – Pre-Journey and On-Trip Planning, Travel
Information;
Support for Law Enforcement;
Freight and Fleet Management;
Provide Support for Cooperative Systems – specific services not
included elsewhere, e.g. bus lane use, freight vehicle parking;
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]