0% found this document useful (0 votes)
8 views21 pages

Understandin,: Architecture

It's notes

Uploaded by

Manoj Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views21 pages

Understandin,: Architecture

It's notes

Uploaded by

Manoj Singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Understandin,

the ITS
3 Architecture

INTRODUCTION
3.1
An ITS architecture is the framework within which a system of ITS projects is developed
interconnections and information
the different
components.
It defines
components of ITS and the flow
betwe
The primary components of an ITS architecture are subsystems and iinformation

flows.
Subsystems: Subsystems are individual pieces of the overall ITS which perform specific
traveller information, managing traffic, or responding to emerg
functions
Subsystems as providing
suchcan be asociated with specific organisations/departments/agencies such as public
management agencies, or transit Drovide
safety agencies, transportation services, emergency other subsystems wihi
They are either sources or users of information or both provided by
roadside equipment
the boundary of ITS architecture. Subsystems may include centre systems,
vehicle equipment and traveller devices related to ITS.
Information flows: Information flows define the information that is transferred and exchanged
between subsystems such as traffic information, or surveillance and sensor control data
They depict integration of ITS by illustrating the information links between subsystems. This
integration in ITS, is not limited to technical but also include institutional dimension. The
system interfaces require cooperation and shared responsibilities on the part of owners and
operators of each participating system.
ITS architecture can be defined as comprehensive framework or picture of functions tht
must be performed (user services) through physical entities where these functions reside
the subsystems and interfaces between subsystems (information flows) for communicaton
requirements for interfaces and stakeholder roles.
The ITS architecture offers aframework for conceptualising, planning, defining, developin
and integrating various components of intelligent transportation Systems. It describes thee way
different ITS components should interact with each other to address the transportation problems

22
Understanding the ITS Architecture 23
wih awide variety of options. It is similar to building architecture wherein an architect plan
and design a building considering various functions of subsystems such as bed room, Iiving
non), bathroom and kitchen to be integrated in the building. ITS architecture describes various
functions and detail responsibilities to cach stakeholder of ITS, A common and standard 115
architecture is recommended throughout a region so that it can integrate various subsystems
and also address various issues concerning different agencies. The following issues need to be
tent in mind while developing an effective ITS Architecture:
(a) Interoperability: The ITS subsystems are required to be used by many departments like
raffic police, transport department, municipality, public transport operators, etc. The 115
architecture should be so designed and developed that the information collected, function
implemented or any equipment installed are interoperable by different departments/agencies in
different states and regions.
data
(b) Information sharing capabilities: Huge amount of data is generated by ITS. This
The ITS architecture shall
can be analysed to improve and manage traffic system in the city. agencies.
be designed to facilitate seamless sharing of information among various different
communication towers
(c) Sharing of infrastructure: The infrastructure like regional
operations to optimise the cost
constructed by var1ous private agencies may be used for ITS resources/infrastructure may
of the ITS implementation. The provision of sharing of existing
be built in the ITS architecture.

3.2 FUNCTIONALITIES REQUIRED FOR USER SERVICE


provision of a user service required a number of functions to be performed by the system.
The so that the system can be designed
Each functionality of a user service needs to be defined a traffic control user are presented
accordingly. For illustration, the user service requirements for
in Box 3.1.
User service requirements for traffic control user
Box 3.1
provides the capability to efficiently manage the movement of traffic on streets and
Objective: To
highways.
Functions:
" Traffic flow optimisation
" Traffic surveillance
" Traffic control
" Information sharing
User service requirement:
flow.
flow optimidation function to optimise traffic
" Traffic control shall include a traffic that maximise traffic-movement efficiency.
optimisation shall employ control strategies
" Traffic flow area optimisation capability, to cover
severaljurisdictions.
Traffic flow optimisation shall include a wide of network signal systems with the control of
express
area optimisation shall combine the control
" Wide
ways. transit vehicles to promote public
optimisation shall facilitate preferential treatment for
Wide area
transport in a city. control (TC).
Traffic surveillance function should be part of Traffic
24 Intel igent Transport Systets
3.3 LOGICAL ARCHITECTURE
The
service requirements.
A
number
defines
of
a set functions
of
are necded to meet userflows that are necded to
functions and information
lomeetgical uscrarchitect
of ITS are defined by
requirements. The interaction of different components
particular function can Nit as aservc
process. The and data flows involved in a describes the be ojc
graphically byprocesses
data flow diagrams (DFDS). Figure 3.1 in
is divided into teraction rsubpreporceesTrdtseAe
of
Management Process with other processes. Each process termed more
The subprocess is
further divided into subprocesses which are process
(P-specs) lowest level. These p--sppecs are
at
requiremnents.
required to be performed to meet userspecification,
servic

Provide
driver and
traveller
Provide serviceS
Manage
electronic
payment
emergency
services
Services

Provide
vehicle Manage
Traffic commercial
monitoring management vehicles
and control

Manage
maintenance
and
Construction

Manage
transit

FIGURE 3.1 High level ITS logical architecture.

3.4 PHYSICAL ARCHITECTURE


The functions described in logical architecture which serve the same purpose are groupc
into subsystems. These subsystems form a physical entity to deliver functions. The data flo
of logical architecture is also integrated to define interfaces between subsystems. Figure 32
deseribes the functions Aand Bof logical architecture assigned to subsystem Ain physial
architecture. Both the architecture forms the core of ITS.
Understanding the lTS Arhitedur 25
Logical architecture
(functions or processes)

Data flow
Function B FunctionA 4 Function C Function D

Subsystem Subsystem
Architecture flow

Physical architecture
(group functions together)
FIGURE 3.2 Function from logical to the physical architecture.
The physical architecture of ITS describes the physical subsystems and architectural flows
based on the logical architecture. The subsystems can be broadly classified in four groups
as centres, field, vehicle, and travellers. The subsystems and communications that comprise
the physical architecture are presented in Figure 3.3. The subsystems represent collection of
functions required for the same transportation need and closely correspond to physical elements
of transportation management system.
Vehicle group corresponds to different types of vehicles (normal, emergency, commercial,
transit and construction vehicles). The different ways a traveller can access information on the
status of the transportation system are represented by the traveller group. Similarly, the units
of ITS comprise of roadway, security management, toll collection, parking management and
commercial vehicle check. The centre subsystem comprises traffic management, emergency
management, toll administration, transit management, etc. as described in Figure 3.3.
There are following four different types of communication systems used in ITS application:
(a) Fixed point to fixed point communications
(b) Wide area wireless communications
(c) Vehicle to vehicle communications
(d) Field to vehicle communications
Traffic management subsystem is connected with communications to get real-time
information of the transportation system through roadway subsystem which comprises of signal
control, detectors, camera, Variable Message Sign (VMS), etc.
26 ntelligent Thansport Systems
Traveller Centres
Commercial
Remote
taveller Traftie Emergency TOI vehicle
|adninistration adininisration
Maintenance
und

Support management managemnent COnstnuction


Fleet and
Personal Information Archived data
Emissions Transit freight managernent
information
Ccess
service
management managenent management
provider

communciations
Fixed point to fixed point

Wide area wireless


Vehicle Roudway

Security
Emergency monitoring
vehicle

TOI
Commercial
collection
vehicle

Transit
Parking
management
vehicle

Maintenance Commercial
and
vehicle
construction check

Vehicles Fields

FIGURE 3.3 ITS physical architecture showing subsystems and communications.

3.5 ORGANISATIONAL ARCHITECTURE


A number of departments/organisations/stakeholders are engaged in a system like traffic
management. Organisational architecture represents the involvement of various organisations/
stakeholders associated to be a part of the traffic management centre (or central control centre)
such asnational highways authority of India (NHA), raffic police, municipal corporation, public
work department (PWD), mobile/Wi-Fi service providers, utility service provider companies,
etc. for the control and management of traffic movement, incident management, maintenance of
street lights, traveller information service, commercial vehicle management, electronic payment
systems, safety services, emergency management services, etc. The organisational architecture is
also used to define role, responsibilities and involvement of various stakeholders in a system.
A clear distribution of work amongst all the agencies is always desirable to bridge any gap
and to analyse the reasons of any failure of the system so that corrective action may be taken.
Understanding the ITS Architecture 27
3.6 EQUIPMENT PACKAGES
The similar functions of a particular subsystem can be grouped together and implemented by
a package of hardware and software facilities. The grouping helps in cost optimisation and
easy implementation of ITS services. The equipment package is developed by grouping a set
of functions of a particular subsystem.
For example, a traffic management centre (TMC) equipment package may provide the
capability for traffie managers to monitor and manage the traffic flow at signalised intersections.
The package analyses the collected data from traffic surveillance equipment and implements
control plans for signalised intersections. TMC signal control equipment package contains five
p-specs:
(a) Traffic operation personnel traffic interface
(b) Process traffic data
(c) Select strategy
(d) Determine indicator state for road management
(e) Output control data for roads

3.7 MARKET PACKAGE


Aset of equipment packages that are required to work together to provide a given transportation
service may be clubbed to form a market package. Most market packages are made up of
equipment packages from two or more subsystems. The market package are designed to address
specific transportation problems and needs.
The market package for TMC provides the central control and monitoring equipment,
communication links and the signal control equipment that support local street control or arterial
traffic management. The various signal control systems dynamically adjusted control plans and
strategies basedon current traffic conditions and priority requests.

3.8 NEED OF ITS ARCHITECTURE TO SOLVE PROBLEMS IN


URBAN AREA

ITS architecture is a useful tool for integrating ITS technique into conceptualising and planning
process. The ITS architecture describes the comprehensive set of data that is required to be
shared by various agencies of transportation network. With the knowledge of what data must be
shared, these agencies can develop a common interest in cooperating planning efforts between
all transportation projects.
As vehicle miles travelled (VMT) and congestion has been growing rapidly in the cities
with no end in sight, precision technology has become essential for transportation planning. As
urban areas are expanding and more roadways are interlinked with one another, operations and
maintenance of this technology is imperative. Therefore, ITS architecture has been developed
as the best way to oversee the physical and virtual networks interacting with ITS. At the same
time, as ITS technologygrows, the ITS architecture also needs to adapt to new ITS technology.
28 nteligent Tiansport Syems
3.9 EXAMPLES OF ITS ARCHITECTURE: ITS ARCHITECTURE
IN DIFFERENT COUNTRIES
The major developed countries of the world have taken the lead in developing ITS system
architectures customised to their own needs. Some notable examples are US, the European
Union, and Japan. Many other countries, both developed and developing, have developed and
defined their own national ITS architectures based on these architectures.

3.9.1 National ITS Architecture of US


The National ITS Architecture of US provides a common framework for planning, defining,
developing, and integrating intelligent transportation systems. It is a comprehensive and rationa]
that reflects the involvement of a broad cross-section of the ITS community (transportation
practitioners, systems engineers, system developers, technology specialists, consultants, etc.).
The architecture defines:
(a) The functions/utilities (e.g. gather traffic information or request a route) that are
required for ITS.
(b) The physical entities or subsystems where these functions/utilities reside (e.g., the field
or the vehicle).
(c) The information flows and data flows combine these functions and physical subsystems
together into an integrated system.
Architecture layers
The National ITS Architecture offers a framework for planning, programming, and implementing
comprising of two technical
intelligent transportation systems. The architecture framework is
operate in the context of an
layers, a transportation layer and a communication layer, which
institutional layer.
mechanisms, and
Institutional layer: It comprises of the institutions, policies, funding maintenance of an
operation, and
processes that are required for effective implementation,
considered as the base because strong
intelligent transportation system. The institutional layer is programme. The
institutional support and effective decisions are foundation to an effective ITS
layer.
objectives and requirements for ITS are formalised in institutional
described in terms of
Transportation layer: It is used where the transportation solutions are definitions which are
and data
the subsystems and interfaces along with underlying functionality of the National ITS Architecture.
required for each transportation service. This layer is the heart
between
Communications layer: It provides for the accurate and timely sharing of information
systems to support the transportation solutions.

User services bundles and user service


The user service bundle consists of following services:
(a) Travel and traffic management user services:
(6) Pre-trip travel information
(5) En-route driver
information
Understanding the ITS Architecture 29
(ün Route guidance
iv) Ride matching and reservation
() Traveller services information
(vi) Traffic control
(v) Incident management LIBRARY
OLOG
(vi) Travel demand management
ix) Emissions testing and mitigation
(3) Highway rail intersection HU8L
(b) Public transportation management (user services bundle) user services:
(G) Public transportation management
() En-route transit information
(ii) Personalised public transit
(iv) Public travel security
(c) Electronic payment (user services bundle) user services:
) Electronic payment services
(d) Commercial vehicle operations (user services bundle) user services:
Ö) Commercial vehicle electronic clearance
(ü) Automated roadside safety inspection
(iü) On-board safety and security monitoring
(iv) Commercial vehicle administrative processes
(v) Hazardous materials security and incident response
(vi) Freight mobility
(e) Emergency management (user senvices bundle) user services:
(6) Emergency notification and personal security
(i) Emergency vehicle management
(iii) Disaster response and evacuation
() Advancedvehicle safery systemns (user services bundle) user services:
i) Longitudinal collision avoidance
(i) Lateral collision avoidance
(i1) Intersection collision avoidance
(iv) Vision enhancement for crash avoidance
(v) Safety readiness
(vi) Pre-crash restraint deployment
(vii) Automated vehicle operation
(g) Information management (user services bundle) user services:
) Archived data
(h) Maintenance and construction management (user services bundle) user services:
) Maintenance and construction operations
30 eligent Thunsport Systems
Ditterent users of the National Architecture
use the logical architecture
different ways:
(a) Public sector agencies: Most public sector employees are not
to review
the logical architecture directly, however, they are required logical
be prese
therequisoftware
red 10nted here
to vernify that it meets their requirements. They may use the architecture to deal Wwiy
own system and interface requirements specifications.
(b) Consultants: They often are required to create logical and physical
operalio
ardetcahiiltectures that aantde
traceable to their user's requirements. Hence, integration and organisation of the

opvihydsediSical by
the logical architectures is of paramount interest to them. The additional
logical architecture may also support developers as they begin to implement aprpro t
3.9.2 ITS Architecture for Canada
The ITS Architecture for Canada provides a comprehensive framework for
integration
the coordinated deployment of ITS programmes within the public and private sectors. to guide
a starting point from where stakeholders of ITS can work together to achieve .It offers
among different ITS elements to ensure integrated ITS deployment for a region. The archity
defines interaction among physical components of the transportation system inclwa: compatibility
travellers, vehicles, roadside devices, and control centres. It also specities the informat:
and communications system requirements, how data should be exchanged and used. an0n
standards required to facilitate information sharing. Overall, the ITS Architecture for Canad
describes the functionality of different ITS components and the information flows requirei
among ITS elements to achieve total system goals.
The various components of the logical architecture required for the architecture framework
have also been defined, including components such as user
service requirements, process
specifications, data flows, and data flow diagrams. The logical architecture of the
architecture has been developed in parallel with the physical architecture. This is unlike ITS
the
US work which developed the logical architecture first and then physical architecture.
Regional ITS architecture
The regional ITS architecture is an important tool used in
and project implementation. It can help in transportation planning, programming
in a more cost-effective fashion. It identifying opportunities for making ITS investmenis
defines how to develop a regional ITS
will be a cornerstone of planning for
effective architecture, whiel
and operation of inter-agency coordination and for deployme
technology-based projects.
User services bundles and user
The user services of the ITS services of canadian architecture
bundles as against7 bundles in the Architecture for Canada have been organised into 8
and traffic US National ITS user so
management
two separate bundles: (a)
user service bundle of Architecture,
the US
In case of
Canada, he into
The ITS Travel information services and Architecture
(b) Traffic
has been separated
Architecture
user services are for Canada management
includes 35 user services. Of these Servi 6
developed specifically for the ITS Architecture for 35 user services,
29
Canada. The remaining
Understanding the ITS Architectun 31
Bser services are based on the 31 user services from the US National Architecture, A number
of the US user services are either combined into single user services, or divided into separate
user servVices as shown below:
(a) Traveller information services
() Traveller information (ii) Route guidance and navigation
(i) Ride matching and reservation (iv) Traveller services and reservations

(b) Trafic management services


() Traffic control (ii) Incident management
(i) Travel demand management (iv) Environmental conditions management
(v) Operations and maintenance (vi) Automated dynamic warning and enforcement
(vii) Non-vehicular road user safety (vii) Multi-modal junction safety and control
(c) Public transport services
) Public transport management
(iü) En-route transit information
(ii) Demand responsive transit
(iv) Public travel security
(d) Electronicpayment services
() Electronic payment services
(e) Commercial vehicle operations
(i) Commercial vehicle electronic clearance
(i) Automated roadside safety inspection
(i) On-board safety monitoring
(iv) Commercial vehicle administrative processes
(v) Intermodal freight management
(vi) Commercial fleet management
() Emergency management services
() Emergency notification and personal security
() Hazardous material planning and incident response
(iii) Disaster response and management
(iv) Emergency vehicle management
(g) Vehicle safety and control systems
(i) Vehicle-based collision avoidance
(i) Infrastructure-based collision
(ii) Sensor-based driving safety
avoidance
(iv) Safety readiness enhancement
(v) Pre-collision restraint
(vi) Automated vehicle deployment
operation
Systems
32 Intelligent Thansport
services
(h) Information warehousing
environmental data
management
() Weather and management
(i) Archived data
Architecture Eramework for Europe
Intelligent Transport Svstems (1TS) Architecture tor Europe is also called The FRAME
3.9.3 ITS
describes the top- -level
(Figure
Architecture
3,4), The FRAME all the ITS
applications and
It services
is at a which
requirements
Architecture
use cases,
functionalities, or theimplementation
for almost
somewhere in the European Union.
"leve" have
for
Deen consideredused as a reference by all ITS
architects in Europe,
may
and is intended
to
be necessary. The be the
Such
which
Systems FRAME
architecture of other
that it can be building the other types ofcompliance at the intertaces
toundation for guarantee and an open European so that
Architecture enables them offered to cross-border ttravellers,
can be
to of market
seamless services developed.
can be
compatible components
Data collection'
interfaces
User TRAME
interfaces "Support for Manage public
safety and transport
emergencies Freight and fleet
operations

and
Manage
Trip plarmation
travel
traffic
Cooperative Support for law
ITS enforcement
Road
tolling

fMulti-modal; Other
transport (non-transport)
interfaces ,systems' interfaces

reproduced
Frame Architecture of ITS in Europe (Source: http://frame-online.eu,
FIGURE 34 The FRAME Forum.)
permission from the leve!

recommendations from the high


The FRAME Architecture was developed as per
resolution of the Council ofMinisterS.
group on transport telematics duly supported by aproject KAREN in October 2000. It has s
developed and first published by the EC funded
Understanding the 1IS Architecture 33
heen modified and updated to include user tools and expand the range of ITS services it can
support, including cooperative systems (connected vehicles as it is known in the USA). The
nlerlving objective of this initiative was to encourage the deployment of (mainly road-based)
IIS in Europe by creating a framework which would provide a systematic basis for planning
IIS inplementations, facilitale their integration when multiple systems were to be deployed,
and help to ensure inter-operability, including across European borders.
The FRAME expresses architecture from a number of viewpoints such as:
() Userneeds to define what the stakeholders want an ITS tool to provide in terms of
services to be delivered.
(b) Functional architecture defines the functionalities needed by the ITS tools to meet the
user needs. The functional architecture consists of functional areas, which are further
divided into functions. Each area has data flow diagrams (DFDs) to describe how the
functions relate to each other, to Data Stores, and to the outside world through the
data flows.
(c) Physical architecture describes how functions can be combined into physical locations
to form implementable systems, considering any user needs that have physical as well
as functional requirements. It consists of a series of "Example Systems" and provides
a broad methodology for deployment and implementation.
(d) Communications architecture describes the communications links which are required to
support physical data flows. It provides an analysis of the communications requirements
for several of the "Example Systems" from the physical architecture, and describes
current communication technologies and standards.
(e) Deployment study have shown how to deploy the systems derived from the architecture
and describes ways to migrate existing systems to conform to FRAME.
() Cost benefit study helps in predicting the likely costs and benefits that can be expected
from deploying the architecture.
The functionality within the 'Functional View' as part of the FRAME Architecture covers
many ITS domains, which enables it to support a wide range of ITS related services. For better
appreciation and convenience, this functionality has been further divided into the functional
areas shown in Figure 3.5.
Functional areas and functions-european ITS frameworh architecture
(a) General
() Architectural properties (ii) Data exchange
(iii) Adaptability (iv) Constraints
(v) Continuity (vi) Cost/Benefit
(viü) Expandability (viii) Maintainability
(ix) Quality of data content (x) Robustness
(xi) Safety (xii) Security
(xii) User friendliness (xiv) Special needs
Inlelligent TiansportSystems Provide support
34
Provide support for law enforcement
for cooperative systems
Manage
ireight and fleet
Provide satety operations
and emergency
facilities
Manage
public transport
Provide traveller operations
Jourmey
assistance
Provide support
Provide for host vehicle
electronic services
payment facilities
Manage traffic
htip:/frame-online exl
FRAME Architecture of ITS in Europe (Source:
FIGURE 3.5 Requirements for reproduced with permission).

maintenance
(b) Infrastructure planning and
planning support (ii) Infrastructure maintenance management
) Transport
(c) Law enforcement
(0) Policing/Enforcing traffic regulations
(d) Financial transactions
(i) Electronic financial transactions
(e) Emergency services
) Emergency notification and personal security
() Emergency vehicle management
(iü) Hazardous materials and incident notification
() Travel information and guidance
) Pre-trip information (ii) On-trip driver
(iii) Personal information services
(iv) Route guidanceinformation
and navigation
(g) Traffic, incidents and demand
G) Traffic control
management
(G) Incident management
(1ü) Demand management
(v) Safety enhancements for
(v) vulnerable road users
Intelligent junctions and links
Understanding the 1TS Anhitectun 35
h) Intellgent vehicle systems
0) Vision enhancenent () Automated vehicle operation
) Longitudinal collision avoidance (iv) Lateral collision avoidance
(v) Safety readiness (vi) Pre-crash restraint deployment
0 Freight and Jleet management
) Commercial vehicle pre-clearance
i) Commercial vehicle administrative processcs
(i) Automated roadside safety inspection
(iv) Commercial vehicle on-board safety monitoring
(v) Commercial fleet management
) Public transport management
i) Public transport managemnent (i)) Demand responsive public transport
(ii) Shared transport managenent (iv) On-trip public transport information
(v) Public travel security

An ITS architecture using FRAME


FRAME Architecture has been
The methodology for creating an ITS Architecture from the
The use of particular technologies or supplier products is not prescribed
described in Figure 3.4.
in the FRAME Architecture for following reasons:
become obsolete through
(a) The ITS Architectures created using the methodology will not
advances in technology, or product development.
opens up the possibility for the development of new technologies to enable particular
(b) It
functionality to be provided.
presented in Figure 3.6 are
Stakeholder aspirations: Stakeholder aspirations from ITS stakeholders for the services
various
statements that express the expectations and desires of the
the ITS implementation expected to provide. The stakeholders are supposed to write them.
that from the architecture team. Broadly, there
but experience has revealed that help is often needed
are four classes of stakeholder, as follows:
organisations/agencies/departments that need ITS services
(a) Want ITS: This class comprises efficiently. This class also includes public
to enable their road networks to be used safely and
operators and freight operators where ITS can enable them to improve the efficiency
transport
with which they move people and goods.
comprises the end users who use ITS services and/or operate the
(b) Use ITS: This class classes
a multi-modal journey as well as all
equipment. It includes travellers, commuters on operatorS.
and specialist system
of vehicle driver; freight shippers; public transport mangers
This class represents those who frame regulations and standards. It includes
(c) Rule ITS: the various standards making bodies.
(state) government and
hattonal governments, regional
equipment and system manufacturers, communications
(d) Make ITS: The class comprises the
providers and the system integrators.
36 Intelligent Transport Systems
Service providers, e.g- travel information and trip planning, may be in one Of
Want. Use and Make ITS classes. nOre the
Results of
stakeholder meetings Stakebolder
aspirations

User needs

FRAME
Relbetween
ationships
architecture subsystems,
modules
and aspirations
Functional
Vicwpant

sDeeif
Physical
viewpoint

Deployment plan
cost/benefit analysis
Cormmunications organisational issues
specifications risk analysis
Conmunications
Viewpoint
FIGURE 36 Stake holder's aspirations (Source. http:/fframe-online.eu/ reproduced with
pernission)
User needs: It is normal to find that the stakeholder aspirations will have
in a variety of styles. Sometirnes they can also be obscure and specified formally
latest technology. Therefore, it is important to re-write them in a inconsistent with time and
suitable for the next stage in the process. The result is a specific and consistent manner which is
well-defined set of user
needs which express the stakeholder aspirations in a consistent and judicious
is clear and whose properties are testable. manner meaning
Functional viewpoint: The FRAME
that make up the FRAME Architecturemethodology
uses the tern viewpoints" for the parts
and its resultant ITS Architectures. This follows the
reconnendations of IEEE 1471. A functional viewpoint (also called a logical viewpoiny
shows the functionality that are required to fulfil the user needs. and bence the
aspirations. While using the FRAME Architecture, the functíonal viewpoint is stakeholdera
data flow diagrams (DFDs) that contain functions, data presented
that flows between them. Each of these is provided withstores
and terminators, and the o
its own description which, in tis
Understanding the 17S Architecture 37

af functions, includes statements explaining what they do. Since the FRAME Architecture
ee of a functional viewpoint that satisties all of its user needs, the architecture team only
is required
to select those parts of it that serves the user needs that have been mapped tohave
the
aspirations that
akeholder aspirations. New tunctions are only needed for stakeholder
be added.
reouired new user needs to
architecture tearn can
Physical viewpoint: Once the functional viewpoint is completed, the
lcate each item of functionality to a location, either within asubsystem (Figure 3.7), or
component (subsystem or module)
within a module that is part of a subsystem. After this, the functions and data stores contained
snecifications can be developed from the definitions of the
within them.

Physical data flow


Functional PDF = FDE + FDE
data flow

Function H
Function A FD
Function M

Data FunctionBFDEL Function 1


store

Subsystem Y
SubsystemX

Physical viewpoint
Functional viewpoint
http://frame-online.eu/
FIGURE 3.7 Physical viewpoint of ITS Architecture in Europe, (Source:
reproduced with permission).
also applies to the
The context diagram produced as part of the functional viewpoint
item and the links needed by the
physical viewpoint. It again shows the ITS as a singleoutside it.
functionality within it to communicate with the entities
Communications viewpoint: As evident from the diagram above, a consequence of allocating
the functionality to subsystems (and modules) is that it is immediately visible which functional
data flows lie within a subsystem (or module), and which pass between one subsystem and
another, or between one module and another. Those which pass between subsystems or modules
between subsystems,
make up the physical data flows, and represent a communication channel
and/or between modules.
includes principles: government
The The needed
3.9.4 other Architecture
certainaspirations
of constraints.links
another
Architectures
wellfacilitate
Traceability:
importantdeployed. by
An toalso desired centre, 38
areas expectations, ensure
(a)
(b) development The of (c) (bobjectives A for Ansubsystems
lead analysing Sinceby
r Like ) (a) Japanese aspirations identified ntelligent
foenvironment.
needs aspirations to traceability can analysis
standard at
connectible The Efficient Japanese reason
traceability
creating an any Assuring Assuring A satisfy that to the
enumeration maintainable owners and be development
and development ministries ITS cannot the roadside, the
other of and the introduced.by of of Tansport
ITS that development the System without a ITS helps
contents
evolving that given cansubsystems to
matrix dependability
the the
major with ITS thus normally al l
standards the the architecture
involved quickly
be ITS implementation
and th e set meet the physical it in
of architecture
otherarchitectureJapaneseItThSe of Architecture System met can
Architecture, Thus of todefinition of a Systems
national
user technologies. expandable way
domestic need of"for be aspect "standard" workvehicle), each
as parts of in expectations, their find and be
services, which through
thosedeployed data
an are ITS, f or free", created for
presented system of Architecture immediate out
modules of physical are
Japan'would
s would
integrated
and to extra flows it
those planningmeans can
the interfaces the located
intelligentencourage inwas i.e., to need th e communications. is
logical
aITS international cooperation developed subsystems at
FRAME be that possible data
in lead architecturebe components
havingit indicate
in process.
the
Figure advanced intelligent may goals.
consideration tothat at
architectures, able the same
applied pass
different
to for flow.
architecture, transport ITS implement one
Architecture
an to in identified be Suchphysical the AlIl between
end
to
3.8. with and/orfound service time, incommunications develop
The
information ITS be ITS applications 1999
wastransportation that
relationship of e
flexible
meet to standards system VERTIS, a of the
thusers. places
the that matrix
viewpoint. are components due format
guidedtheby through modules. that the any needs services same the
a was required to
methodology (e.g.,
Japanese
physical subsystems it financial ItITS
and as is can the way, can of
interoperable now the between to
mentioned
system possible constraints
contained play and analysis in
telecommunications also to This and be everywhere a
architecture ITS calledjoint satisty established
and the traffic
changingfollowingtwo indicate enables
and/or communications
the an
efforts to dependability is terminators in
architecture ITS the important specificatio
and below: meet stakeholder
a of in the manaoe
modules
whether given funds, most
ability that
Japan. of the form
and inter social some before
five set ITS itrol e
asITS to i
Assistance(c) (b) (a)
Development Detca
veices
warning
Danger
Assistance
(iv) (ii) f(ior) ) Electronic
(0) ()Advances
) Wbawicl
Whehai
cvve
Automated Provision Electronic ProvisionProvision Sing
vehicles
dìvers
ostacles
humans)
in (acckdents
Sensing ITanaemnt
wcathert
rattic,
driving
safefor toll (aday, tratic
Road Humans
navigation Areas FIGUREITS3.8 Huun
of collection
toll of of Vehicle
oonor
highway Vehicles
driving destination-related
route intertae
driving collection and
guidance systems User inkmasnRalaits Centres
systems and systems 000wTRInikations
vehicles)
and
oodode Dehca
shrtran Tratiefoe
Ask
road Architecture,
Services ent
traffic Cvttiativs
brudasing)and Wt
W ovel
conditions information oonimnicatios
Roadside mless
information Raayplancalculstion T
Roatmanaement
Japan Tratie
Mow
tnitic oomunications
information vehiclesohst;xces)
Seusingtuceidents,
(reproduced (ssible
infomation
management
contiol
plan mgee Riahway
Tieptlannnge plan Understanding
acration infivnutin
ollect
such
manaement nfomatios
Extemal
as Cyniaval
with intertsce
Human satelliteas oolction iyenl t

permission).
the
lTS
services check-in
and
Reservations
transportation
ete.issuance
ticket information
network
access
BankingInformationprevention emergency
disaster roadside
Provision
ofinformation
and Provistonfacilities
support
activity onofgovernment
information
related business,
Provision
Imassmedia, entertaiment
travel,of
and infornation related Ihovision
Nghtieeing
andtravel,of Archtecture
for services
elementsExternal
use of
public
39
Thansport Systems
40 Intelligent management
Optimisation of traffic
(d) low of incident
Optimisation of traffic
restriction
information in case
() of traffic
() Provision management
eficiency in road
(e) Increasing maintenance operations
lmprovemet of information
()
Provision of roadway
hazard commercial vehicles
()
Management of
specially permitted
()
public transport
(D Spportfor for public transport information operations management
) Provision operations and
(ü) Assistance for public transport operations
efficiency in commercial vehicle
(g) Increasing vehicle operations management
commercial
() Assistance forplatooning of commercial vehicles
() Automated
(h) Supportfor pedestrians guidance
() Pedestrian route
Vehicle-pedestrian accident avoidance
(ü)
Support for emergency vehicle operations
()
notification
() Automatedemergency emergency vehicles and support for relief activities
(m) Route guidance for
() General telecommunications societ
the advanced information and
Utilisation of information in
)
TRANSPORTATION SYSTEMS
3.10 ADVANCED RURAL
(ARTS), US
technologies are being developed for urban areas. The application of IIS
Generally, the ITS development, rural areas encompass a significant portion of
to rural transportation is a recent
roads have a unique set of priorities and needs associated
area
the transportation system. Ruraltypes of travel upon them and their maintenance and operations
with the characteristics of the to improve
The US Department of Transportation (DOT) for the frst time envisaged ARTS
areas.
the transport system in the rural of the ITS programi
This strategic plan has been prepared by DOT for the ARTS portion rural ITS options a
The plan focuses on the Federal Government's role in developing conception to Via
prudently managing emerging ITS technologies within rural settings from
options for implementation. (CPAS)
The ARTS Strategic Plan organises rural needs into seven critical programme areas
CPA 1: Traveller safety and security
CPA 2: Emergency services
Understanding the 1TS Architecturr 41

Rural Needs and Critical Program Areas

CPA I CPA 2 CPA3 CPA 4 CPA7


Traveller Tourism and Public CPA 6 Commercial
Emergency ctures
safety and services Travel traveller Flcet vehicle
security 0&M operations
inlormation, mobility

Evaluation

Needs
Evaluauation e

National Architecture

Technologies Standards y
m
User e

services
with Market Service t
rural
extensions
packages packages

Functions

Planning and operating

Evalution agencies
and
jurisdictions

Research and development Development incentives Mainstreaming

Federal Role via Program Plan

FIGURE 3.9 Advanced Rural Transportation Systems (ARTS), US.

CPA 3: Tourism and travel information services


CPA 4: Public traveller/mobility services
CPA 5: Infrastructure operations and maintenance
CPA 6: Fleet operations and maintenance
CPA 7: Commercial vehicle operations
42 nteligent Tansport Systems
The National ITS Architecture defines various concepts for the
layered structure consists of infrastructure that must be provided in ARTS as a system
applications that ultimately deliver services. The infrastructure will common to
public domain and will follow standards to be open to innovative be developed support many
from the private sector. ARTS activities will define the and competitive
infrastructure needed to serve the in thlargely
and then facilitate deployment of this
issues common to many CPAs, such as infrastructure. This layered structure also
communications in rugged and remote ap licaCPAtion.
be addressed by ARTS

in Figure 3.9.
activities.
ITS, but to make sure that the The purpose
rural needs and
of the ARTS is not to
conditions
interoperable, national and international system. The are
develop aareas that
represented in
schematic plan of what will rura
eseparmaptheasise
ARTS, US is
3.11 SUMMARY show
As
discussed in the preceding
architecture.
traffic
To
on an area develop a full section,toone can appreciate the role
system
or corridor basis regulate orderly traffic flow and
at city level, importance of he
increasingly
important to becoming
a state
a necessity for city committed to
a
and
level or country level, safe
ITS movement i
various develop system architecture based on thedevelop ITS architecture
and traffic functions/subsystems
to support themonitoring, incident
within a
system. is a
detection and
It linkage
framework
and programme.
stage of
within
It is therefor
involvement of
and data flows systemand architecture, physical emergency support can be which ITS functions
organis ati
organisations be interfacedarchitecture
are to on architecture
based developed.
on dealing with the physical
In order
properly. support and subsystems
coordination from various
3.1 What do you Questions
3.2
Explain primaryunderstand ITS
3.3 What
by
of ITSArchitecture?
34 are component s
thedifferent component
Explain
(a) Logical folarchitecture s of ITSofArchitecture.
lowing in the context
(b) Physical architecture Archi
ITS tecture?
(c) Organisational architecture
3.5 What do
Architecture:
you
1TS architecture?
3.6
37
understand by
Explain need of ITS equipment package and
the
Write a
3%
Develop an ITSnote on ITSArchitecture to ofsolveUS. problemarket
short
package in the
Architecture
Architecture plan for your ms in
urban area.
cOnte
city.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy