Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Архитектура интеллектуальных транспортных систем = Intelligent Transport Systems’ Architecture. Учебное пособие
.pdf
51
Multi-modal interfaces – links to other modes when required, e.g. travel
information, multi-modal crossing management.
The FRAME model used for the Functional View is based on hierarchical
Data Flow Diagrams. At the highest level is the Context Diagram (fig. 3.8)
which shows all the functionality supported by the FRAME architecture inside
a box labelled “System” surrounded by a set of “Terminators”, which are
outside the boundary of the system. Each Terminator represents some thing,
or person, to which the system will send data and/or from which it will receive
data. As there is a large amount of functionality in the FRAME architecture
(2-3000 elements in total), its size is managed using hierarchies of functions
and terminators.
Fig. 3.8. FRAME highest level is the Context Diagram
The FRAME produces a set of files that contain tables providing details
of the contents of the functional, physical and organizational viewpoints. It is
also possible to export the contents of the viewpoints as a separate database
for use with tools such as Access.
Due to the flexible nature of the FRAME Architecture, because it is
intended to be easily adapted to suit individual ITS implementations, it has not
been possible to create an automatic diagram creation feature. But these can
be easily created using the tables and a drawing tool such as Visio.
52
4. ITS ARCHITECTURE AND HUMAN FACTORS
Intelligent Transport Systems (ITS) can support road users in various
ways, with information and warnings, and various levels of assistance and
automation, depending on the service. Road users interact both with ITS and
the wider transport system in complex and sometimes unpredictable ways.
There is a need to understand fully the broader context, its dynamic
characteristics and the role and responsibilities of its different stakeholders.
It is only then that best results from any intervention will be obtained – with
a high probability of user acceptance and adoption.
Human factors is the branch of science and technology that includes
what is known and what is conjectured about human behavior and biological
characteristics. It can be applied to the specification and design of products
and services – and their evaluation, operation and maintenance.
ITS technologies provide users with an interface – known as the Human
Machine Interface or HMI. “Behind” the interface is the logic and software of
the interaction which contributes greatly to its “look and feel”. Human
Machine Interaction (also abbreviated to HMI) is a key component of human
factors. Designing or choosing an HMI that is appropriate for the context of
use (such as “while driving” or “at a bus stop”) can have a decisive effect on
the outcome.
Proper attention to human factors can enhance the safety, effectiveness
and ease of use of Intelligent Transport Systems and Services for individuals
and for widely different groups of users. A key point is the variability within
users – and within specific groups of users, such as “car drivers”,
“pedestrians”, “Traffic Control Centre Operators” or a “Mobile Safety Patrol”.
Users have different needs and motivations. For example, the task to be
performed by a cyclist is very different from that of a control room operative
or a road maintenance worker.
The importance of the broader road transport environment within which
ITS informs and assists users requires an emphasis on “user-centered design”.
It is important that road users are involved in ITS design. A complete
understanding of the tasks they need to perform and their scope for error is
vital. The importance of piloting, feedback and monitoring in any ITS or other
transport system design, its introduction and its operation cannot be understated.
53
Relevant ITS standards for HMI cover areas such as vehicle design, the
design of infrastructure (signage for example), standards for ITS in control
rooms, for tunnel design and management, and for public transport. The needs
of vulnerable road users are especially important here.
The design of the Human Machine Interface (HMI) has to support the
user and promote safety in the transport environment. The following provides
some key advice based on human factors principles:
1) when a technical system such as ITS is introduced into a societal
context, complexity is likely to emerge. Getting it right is not easy - consult
human factors professionals where necessary;
2) users of ITS come in all shapes and sizes and with different
expectations and abilities. For example, older users of technology may have
more difficulties than younger ones – so ITS should take account of this
diversity;
3) adopt a user-centered approach to design and introduction of ITS –
the benefits outweigh the apparent upfront costs;
4) find out the real needs of users. Simply automating what they
currently do themselves may not be the best solution;
5) involve actual users – but remember that they are individuals. Do not
expect them all to behave the same;
6) human error is inevitable – expect it, and develop ITS designs to
reduce errors and mitigate their effects;
7) use standards and guidelines where appropriate – they contain
a wealth of knowledge and experience;
8) always pilot before full implementation – this applies from simple
questionnaires to complex real-time ITS;
9) evaluate the ITS through trials in realistic contexts. Depending on
results and feedback from users – you will probably need to adjust the system
or service, or modify the context of use, to achieve the desired outcomes;
10) set up mechanisms for monitoring ITS use and receiving feedback from
users. They know, often better than you do, what works and what does not.
These points may appear to be “common sense” but there are many
examples of design and implementation of ITS where this common sense has
clearly failed.
54
Human performance describes how easily and efficiently an individual
achieves a certain outcome – such as navigating to an address, crossing the
road or buying a bus ticket.
Human performance is based on a physical and cognitive (mental)
control “system” that is the result of millions of years of evolution. Human
action is largely effective and adaptive even when carrying out complex tasks
– but humans are not machines – whatever role they are undertaking. It is
important to understand the limits and the variability of human performance
so that transport systems and ITS can be designed and operated accordingly.
Performance varies between people and an individual’s performance also
varies depending on a complex interplay of factors. These variations can make
or break the success of new applications of ITS, such as cooperative driving.
Humans can interact with the outside world, including ITS, in myriad
ways and there is a wide variety of technology available to assist this
interaction. The most common HMI components used are described here. HMI
elements – good, poor and indifferent – are invariably present in computer
systems and ITS. For example:
desktop computer-use – by persons at home in advance of their
journey or in control rooms
personal mobile devices such as tablets and smartphones
public access personal interaction stations
Public displays may also incorporate important HMI features – such as:
public announcements that use an electronically stored or generated
voice – or are automatically preceded by an “Earcon” (recognizable sound
denoting, for example, information)
public visual displays (traffic and pedestrian lights, variable signage)
variable message signs
It is a commonly-held ‘truth’ that people have five basic senses:
vision;
hearing;
smell;
touch;
taste.
55
In fact people have others senses as well, including: vestibular (balance
and movement), kinesthetic (relative position of parts of the body), pain,
a sense of temperature and a sense of time passing. All these allow people to
interpret the world around them, at different levels.
The context of use describes the conditions and environment in which
users interact with ITS. Examples include:
a driver of a car trying to find a route from an information system
while driving in heavy traffic and running late for an appointment;
a user buying a public transport ticket from a vending machine in
bright sunlight when seated in a wheelchair;
an operator of a traffic control facility setting a variable message sign
for the roadway from an office environment;
a technician replacing electronic signs on an elevated platform above
a road in a strong wind.
The context describes the main issues likely to have a bearing on the
interaction such as “who” “when” “where” and the environmental conditions.
The context of use is an important consideration when designing how
users interact with ITS. It can affect motivation, performance, attitudes and
behaviour of the users and the overall efficiency and effectiveness of the
interaction. An ITS device should not be described as “usable” or “ergonomic”
without also describing the context in which that use takes place.
The rationale behind the development of ITS is the need for high
efficiency and quality in new and innovative transport services. The goal of
these services is either to meet a certain need for the movement of people and
goods – or to supply a specific endeavor (or activity) with the correct amounts
of its necessary components at the right time and at the right location. These
activities are called transport and logistics respectively. By implication, the
design of these services will include modern information and communication
technologies (ICT) for the exchange of information in real time and the result
is an “intelligent” transport system.
From their everyday activities, people identify needs for movement
between specific locations and become travelers. They engage in trip planning
56
and, if successful, a trip plan will be created by linking a sequence of transport
options to serve the journey – if necessary based on different transport means.
These transport options can either be chosen from available information
(in timetables, for example) or can be made known to someone (who can
organize such options) as dynamic demands on transport. These travel
demands and travel patterns are today normally captured by surveys and
observations on a yearly basis to inform the production of static timetables.
The planning of a journey includes a matching exercise between the total
travel demand and the future availability of vehicles to serve that demand and
provide the transport service. The matching will be successful only if no
disturbances in the traffic process occur and no characteristics of an open-loop
control system are evident.
Designers often build technical systems without completely
understanding the tasks to be performed. Intelligent Transport Systems (ITS)
need to be designed to be both useful and usable. Being usable is not enough
if the system is not first useful. Users of ITS are diverse individuals – they do
not all think the same way and they can be inconsistent and unpredictable.
It is not surprising that it is often difficult for the designers of technology
to understand exactly the real needs of their potential users, how the
technology will be used and how use will change as familiarity with the system
or service develops. This is particularly the case for complex systems such as
ITS in the broader transport context. The goal of good design is for complexity
to be made to appear simple or intuitive to its users.
The complexity of ITS processes and their dynamics makes it essential
to use sound design principles for robustness. For this reason, ITS require
feedback of information from different process states using appropriate
sensors. The feedback will also provide the input to adaptive control
algorithms for decision-making by users – and make the processes less
sensitive to disturbances. The complex nature of transport systems involving
the interaction of many different systems and services is clear from the
information feedback loops and the varied timescales used in the different
decision-making processes.
57
Human error becomes virtually inevitable with the large number of
different links and connections in the networks and processes of modern
transport systems. In the transport domain one of the most critical situations is
that of driver-vehicle interaction – as mistakes, slips and lapses in the primary
driving tasks will have safety implications.
As well as reducing critical errors, there are many other practical reasons
for involving users:
people are diverse and inconsistent. By understanding their
characteristics and taking them into account in the design – the effectiveness
and efficiency of the ITS is likely to increase;
there can be considerable benefits in drawing on the creativity, ideas
and expertise of users in the design, development and introduction process;
users sometimes have the ability to disrupt or reject ITS, which can
cause service interruptions or other problems. Appreciating and responding to
negative issues during development is only possible if users are involved;
safety is an important issue for Road Network Operators and they may
have a responsibility of care towards workers and transport users.
Understanding user interaction with ITS can help the promotion of safety.
The overall message is that ITS should not be designed, developed or
introduced without involving those who must use it. A holistic approach is
required which acknowledges and accounts for the interactions between ITS
and its users.
58
5. ITS ARCHITECTURE FUNCTIONAL VIEWPOINT
Because the FRAME architecture is intended for use within the European
Union it conforms to the precepts of subsidiarity, and thus does not mandate
any physical or organizational structure on a Member State. It comprises only
a set of User Needs which describe what ITS can provide, and a Functional
View showing how it can be done. The Methodology, which is supported by
computer-based tools, assists the creation of logically consistent sub-sets of
the FRAME architecture Functional View, and the creation of subsequent
Physical Views.
Integrated ITS services are complex, and it is not possible to describe
them completely in a single model or diagram. Instead we use a number of
different models, each one concentrating on a different aspect of the integrated
ITS services. As an example consider how people might describe a car. Some
are interested in their color and style, others are interested in the interior
design. Technical issues, e.g. maximum speed, fuel consumption is another
area to be considered as, of course, is the price. None of these attributes is
sufficient to describe a car on its own, but together they built up a total picture
i.e. they are each different views, or viewpoints, of a car. n a similar way we
use a number of different views to describe a set of integrated ITS services
which, together, form the ITS architecture. The FRAME methodology use of
the term “Views” follows the recommendations of IEEE 1471. The alternative
term of “Architecture” is still used elsewhere, but we feel that an architecture
made up of views is more comprehensible than one that is made up of
architectures.
Whilst there are a very large number of possible Views, there are four
principle views that are used by most users of the FRAME architecture – The
Functional, Physical, Communications and Organizational Views.
The Functional View (sometimes called the Logical View) describes the
functionality (what is to be done) to create the various ITS services. The
FRAME architecture uses Data Flow Diagrams to define the Physical View,
as these not only have the properties needed for the FRAME Architecture, i.e.
the ability to be partitioned into consistent sub-sets, but they have been proven
to be fully comprehensible by all those who need to understand them, in
particular those with a non-technical background. A typical data flow diagram
59
is made up of Functions, that “do” things, Data Stores that store sets of data for
a length of time (but are not necessarily full databases), and Functional Data
Flows that pass data between then, as shown in the example below (fig. 5.1).
Fig. 5.1. FRAME architecture functional view
The FRAME functional architecture consists of nine functional areas,
each with a unique number and a description. Each of the functional areas
contains the functions for its purpose.
The Functional Architecture consists of low level functions which
satisfy the user needs by processing data and elaborating information. The low
level functions are grouped according an arborescent architecture in high level
functions in nine functional areas, very close to transportation services: Each
low level function belongs to one high level function which belongs to one
Functional area. The Functional areas are:
1) Provide Electronic Payment Facilities
This area provides the functionality to perform the electronic payment
for different services provided by the other functional areas within the
architecture. It has an interface with the financial clearinghouse terminator to
enable actual payment transactions to be made. Data can be transmitted from
or to other Functional Areas like, for example, “Manage Traffic” (access
criteria, accident warning...) or “Law Enforcement” (fraud notification or
fraud detection).
60
2) Provide Safety and Emergency Facilities
This area comprises the management of what response is provided when
an emergency occurs, and the notifications of stolen vehicles. This includes
services like the treatment of e-call coming from a driver (terminator) or
automatic e-call coming from the area Provide Advanced Driver Assistance
Systems.
3) Manage Traffic
This area manages the traffic flows in an efficient way to use the road
space and minimize the impact of vehicles on the environment. The
communication possibilities include the provision of priority for emergency
services. This Functional Area is very central and manages a lot of data
exchange with the other Functional areas and with a lot of Terminators
(Driver, Road Pavement, weather systems...).
4) Manage Public Transport Operations
This area is responsible for managing public transport services in an
efficient way.
5) Provide Advanced Driver Assistance Systems
This area’s functionality provides communications facilities between
the vehicle’s systems, other vehicle systems, the road infrastructure. and/ or
other Functional Areas like, for example “Manage Traffic” or “Manage
Emergencies”.
6) Provide Traveler Journey Assistance
The main focus of this area is the planning and completing trips for
travellers, and the opportunity to make requests for travel information.
7) Provide Support for Law Enforcement
This area is responsible for reporting violations to the law enforcement
agencies, but does not include the detection of over-weight vehicles and
individual vehicle pollution levels.
8) Manage Freight and Fleet Operations
This area provides facilities for the management of freight and fleet
operations for:
– A static freight and fleet operations center, where the route will be
chosen and this may involve the use of modes other than that provided by road
transport.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]