Why Create an ITS architecture?

Within any single country or region, there are likely to be large differences between the set of ITS services useful for big cities and for rural areas. Many ITS applications (such as navigation and location based services) are market driven. In road network operations there are always key stakeholder groups, public authorities and private sector organisations with a part to play (for example - in motorway network management, traffic control and toll road operations). Each has different organisational areas of competence or responsibility (such as road safety, public transport, fleet logistics, policing and public security). Each has its own policy goals. Alongside there are the wider community objectives of improving road safety, transport efficiency and environmental quality. The process of stakeholder consultation is intended to take account of the bigger picture – to identify what ITS services are viable and how they should be implemented. This is outlined in the diagram below, which shows that the first step is to define the policy goals, and then identify the services that will support these goals. Stakeholders nominate the ITS services that will run either fully or partially within their own domains. These are then amalgamated to provide a set of services that have been jointly selected by all stakeholders.

Figure 21: Expression of Policy Goals in ITS Service Selection

The process of getting stakeholders involved should start by asking them to describe in their own words the services that they want the ITS deployment to include. In discussion these descriptions can then be modified so that they will support the policy goals. (See later more detailed section on "Describing the Services")(See How to Create One?) It can be very beneficial if this is done through a "stakeholder conference" so that the various groups can meet each other, discuss the options and understand each other's requirements. Often this will lead to the realisation that some of the services can be enhanced by exchanging data or information between different stakeholders.

For example, the highway network operators may be planning to deploy ITS for electronic tolling and automatic incident detection. This functionality can be adapted to give high-quality traffic and traveller information, with point-to-point journey times. An alliance between the network operators, toll road companies and the information service providers is needed to make this happen. The consortium will need to agree joint use of the ITS infrastructure, protocols for information exchange, and the data and information that they will use. All can be included in a common ITS architecture which serves the needs of all the partners.

Another example might involve the motorway network operators considering the use of ramp metering to maintain smooth traffic flow. An undesirable side effect can be long queues of vehicles that spill out onto the surrounding roads causing gridlock. Measures are needed to ensure that this does not happen. There may also be pressure to prioritise buses and coaches and other high-occupancy vehicles waiting on the ramp. The two network operators - for the motorways and the surrounding roads – need to design their traffic management policies and ITS deployments to minimise the conflict. This might involve some form of demand management with measures to encourage modal shift.

These examples emphasise the value of taking a broad view of the ITS deployment rather than each agency or organisation working in isolation. Collaborative working early on - to define the full scope of ITS deployment - means that changes can be made at relatively low cost before systems are designed and equipment has been purchased.

Benefits of creating and using ITS architectures

Risks of not using ITS architectures

WORDS OF ENCOURAGEMENT

The USe of ITS ArchitectureS in the ITS implementation process

The use of ITS architectures in the ITS implementation process comes before any of the components or communications have been purchased or designed. This is because they do not contain any reference to technologies. In fact the component specifications and communications requirements produced from ITS architectures can be used as input to the procurement process. This is illustrated by the diagram below.

[Figure 1] The use of ITS architectures in the ITS implementation process

Organisations use various terms for the procurement process – such as "Requests for Proposals", "Call for Tenders" or "Request for Solicitations". What is important is that the architecture is included in the contract documents and is used by suppliers, communications providers and system integrators when developing their proposals. This ensures that the specification for components and communications will deliver the ITS services described by the stakeholders.

As part of their bid responses - suppliers, communications providers and system integrators can be asked to illustrate their proposals with their own system, software, hardware, data and communications architectures, all of which are low-level or component architectures. Each one can be compared with the ITS architecture to make sure that they conform to requirements and show a good understanding of what the stakeholders want.

 

ITS architectures are also included in the systems engineering "V" model, as illustrated by the diagram below. (See Systems Engineering)

Figure 2: ITS architecture in the Systems Engineering

Other Architecture Methodologies

There are a few other architecture methodologies that are in use around the world, which are mentioned here for completeness. Probably the most common of these are Enterprise Architectures, the Open Group Architecture Framework (TOGAF) and Object Orientated/UML Architectures. All three approaches cover more than just the architecture and go into system implementation and maintenance.

Enterprise Architectures

An Enterprise Architecture is a well-defined practice that can be used by organisations to guide the development of their businesses. It considers the business to be an "enterprise" and is perhaps the successor to "business architectures" that use business process modelling techniques. The concept of an Enterprise Architecture is attributed to John Zachmann when he worked for IBM in the 1980's and was responsible for the "Zachmann Diagram". It has been developed and updated several times since by organisations such as the Enterprise Architecture Centre of Excellence (EACOE at http://www.eacoe.org). As far as is known, Enterprise Architectures have never been used for ITS implementations. The creation and use of ITS architectures does fit well with the Zachmann Diagram and is part "Business Model" and "System Model", with the preparation of the service descriptions being part of its "Scope" phase.

The Open Group Architecture Framework (TOGAF)

Another methodology that can be used for ITS implementation is TOGAF (The Open Group Architecture Framework – see http://www.togaf.org/). It is robust and used in many parts of the world, backed by a strong user community that offers professional certification for those that use it (TOGAF practitioners). TOGAF Architecture Development Methodology (ADM) divides architecture creation and use into several phases as shown in the figure below. The phases are similar to the steps shown in the figure on ITS architecture in the Systems Engineering "V" Model. (See Systems Engineering)

Figure 20: Relationship between the TOGAF Architecture Development Methodology (ADM) and typical ITS Architectures

Some phases of TOGAF are not covered either by high-level ITS architectures or by low-level ITS component architectures. These additional phases can cover subsequent steps in the ITS implementation process, such as procurement, installation, and operation. Including these steps within the architecture has the advantage of delivering both the actual solution, as well as closing the loop and updating the ITS architecture.

More information about the use of TOGAF in the Australian National ITS Architecture project can be found at: http://www.austroads.com.au/road-operations/network-operations/national-its-architecture#

Object Orientated Architectures

Object orientated methodology has been long established for software and system design and is almost always illustrated using the Unified Modelling Language (UML). So far as is known only two ITS architectures have adopted it: the ITS architecture developed by ISO TC204 in 1998 and the Australian ITS Architecture, which was developed a few years later. based on ISO.

The ISO ITS architecture has largely remained untouched since it was produced and may now be lacking in support for many of the ITS services used today. The Australian ITS Architecture was also little used. In the last few years, Australia has begun development of a new Australian National ITS Architecture. It is following the route taken by most High-Level ITS Architectures (See What is ITS Architectures?) that have been developed around the world and using the methodology described in this module.

It is probably true to say that the object orientated methodology is inappropriate for use by people outside of the IT industry since it requires practice to become familiar with it. This methodology is more appropriate for low level (or component level) ITS architectures that are used by system and software developers.

ISSUES FOR DEVELOPING ECONOMIES

How to Create an ITS Architecture?

There are two ways to create ITS architectures, either starting from nothing or by modifying an existing ITS architecture. Both approaches are directly related to the type of architecture from which they will be created (which could be either a “model” architecture such as the US National ITS Architecture or a framework architecture such as the European FRAME Architecture).

There has been much experience with ITS research, development and deployment - which is captured in two widely used architectures that exist today. The US and FRAME architectures have evolved with ITS over the past 20 years. Both have been refined to keep pace with ITS development and deployment in the two regions – and domestic and international standards have been developed, based on them. It would be very expensive to approach a new architecture development starting "from nothing". Adapting or adopting ITS functional definition from existing architectures offers a cost effective approach for a new architecture definition provided that the local user needs, institutional set-up and transport context (such as the package of user services, modal choices and traffic mix) are addressed. These may vary considerably from the assumptions inherent in either the US or FRAME Architectures.

The two ways of creating an architecture (start from nothing or adapt an existing architecture) share a common starting point. This is the description of the services that the ITS deployment is to provide - which has to be reflected in the ITS architecture. The process can be summarised as follows:

Service Descriptions -> User Needs -> Functional Definition -> Physical Partitioning -> Communications -> Linkages to Standards.

Operational concepts /Operational requirements

In the process shown above, any detailed concepts about how the services are to be delivered will be part of the “User Needs”. They are often referred to as “operational concepts” and “operational requirements” and are constraints that need to be applied in the ITS implementation process following the creation of the ITS architecture. Examples are a service “must be available all day every day (i.e. 24/7)”, or a service “must be available in the same way everywhere”. To highlight their importance these concepts are best captured in a Concept of Operations (ConOps) document that contains descriptions of how the services will actually work. To do this, the document requires inputs from some of the architecture viewpoints created later on in the ITS architecture creation process. So whilst creation of the ConOps document may be started early on in this process, it cannot be completed until nearer its end. (See Next Steps)

Describing the services

"start From Nothing"

adapt an existing ITS Architecture

Advice to Practitioners

Before a choice can be made between the two starting points, it is important to have discussed and answered the following questions:

• has the scope of the ITS implementation been discussed with the main stakeholders? As a minimum, the outlines of the service descriptions should be created to clarify what the stakeholders are expecting to be delivered
• has it been decided how the ITS architecture will be used? For example is it for a one-off ITS implementation and if so - is it likely that it will be expanded in the future - either by adding new services or expanding the geographic coverage?
• is it going to be an ITS architecture from which other ITS architectures will be created, and if so how much control is to be exercised over the customised ITS architectures that are derived?

The answers to these questions will help to decide which method is to be used to create the ITS architecture. Whatever the answers, use caution if the "Start From Nothing" approach is used because it will require a heavy commitment of resources over a long period of time without the benefit provided by an existing ITS community.

Choosing between the two options to “Adapt an existing ITS architecture” is a balance between the following issues:

• US Architecture – easy to use as a “model” architecture requiring little or no knowledge of the technical detail behind the ITS architecture creation process; but adapting it to incorporate local variations and/or completely new ITS services is not something that many users can do easily (See Using the US Architecture)
• FRAME Architecture – requires a more intimate knowledge of the technical aspects of how to create an ITS architecture, but is very flexible and 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.

Issues for Developing Economies

Developing economies may have little or no existing ITS components or communications. This means that the ITS architecture will be describing what can be viewed as a "greenfield" ITS implementation. It is tempting to think that the best way forward is to adopt the "From Nothing" approach. This is not necessarily true for reasons of cost, complexity and the lack of support from an existing ITS architecture user community.

Further Information

A case study is available on the design of the Abu Dhabi Integrated Transportation Information and Navigation System “i-TINS".(See Case study)

Resources

Before starting work on creating the ITS architecture it is very important to estimate the resources that will be needed. The best way to do this is to split the work of creating the ITS architecture into three phases:

• Phase 1 – creating the service descriptions
• Phase 2 – creating the ITS architecture
• Phase 3 – carrying out the follow-on activities

The numbers of people needed for each phase will depend on the number of stakeholders and the expected scope of the services that the ITS implementation is to provide.

Phase 1 – creating the service descriptions

Experience has shown that it is impractical to have only one person at the meetings with stakeholders to enable the Stakeholder Aspirations to be captured (See How to Create One?). This is because it is virtually impossible to direct the course of a meeting and take meaningful notes of what is said at the same time. Stakeholders can be encouraged to submit written descriptions of the ITS services they need or aspire to (“Stakeholder Aspirations”), but holding stakeholder meetings, either individually or in groups is a better way to gather this type of information. An accurate record of what is said at these meetings will be an invaluable aid to developing the detailed Service Descriptions. Discussions with stakeholders before the architecture is developed are likely to produce “Stakeholder Aspirations” rather than strict, specific Service Descriptions which need to be refined by the Architecture Team before starting work on creating the ITS architecture.

At least two people will be needed for each stakeholder meeting – one to lead the discussion and the other to take notes. If a large number of stakeholder meetings are needed, it may be necessary to deploy teams of two people each, so that meetings between non-related groups of stakeholders can be held in parallel. For most ITS implementations, the time taken to produce the service descriptions to the level of detail required, will be about 6 months, since it is usually necessary to talk to stakeholder representatives whose diaries are often very full.

Phase 2 – creating the ITS Architecture

Previous experience suggests that having more than one person working on the actual creation of the ITS architecture does not save time or effort and may produce inconsistencies within it. The best solution is to have one person creating the architecture and at least one person to review it.

If the ITS architecture is be created from either the US National ITS Architecture or the European FRAME Architecture, then the time required should be relatively short - about one month should be sufficient and includes the creation of the physical viewpoint. If the "Start from Nothing" approach is taken, then the time taken will be considerably longer – probably about 9 months for a small scale ITS project and up to 2 years for a more extensive architecture.

Phase 3 – carrying out the follow-on activities

Creating the different viewpoints for an ITS architecture (physical, communications, organisational) and analysing other aspects of the ITS implementation (deployment, cost-benefit, risk analysis) (See What is an ITS Architecture) can be undertaken by several people – if necessary working in parallel. The possibilities for parallel working can best be seen from the diagram below.

Relationships between different ITS architecture viewpoints and other aspects of ITS implementation

Many of the links are bi-directional because work on one view or viewpoint can affect the contents of a previously created view or viewpoint. So for example, physical and communications constraints identified by work on their viewpoints can require changes to the way that the functionality is partitioned in the functional viewpoint.

It is tempting to think that some ITS architectures will not need all of these viewpoints or an analysis of the other aspects, for example when the ITS architecture for a research and development project. In practice this is not true. What will vary is the level of detail that is needed, so that for example, an ITS architecture for a single service may require less detail in its organisational viewpoint, plus a much simpler treatment of deployment, cost/benefit and risk.

To create all of these viewpoints and other outputs three people will be needed and they should be able to complete the work in three months. Obviously if less detail is required then the amount of effort reduces, which can be expressed either as a reduction in people or in the time taken.

Overall estimate of resources required to create an ITS architecture

The following table summarises the three phases of ITS architecture creation.

The conclusion from the table is that between 2 and 4 people will be needed for a period of up to 10 months. It is advisable for each team member to work on the three phases of architecture development rather than focusing just on one.

Resources needed to maintain an ITS architecture

Once the ITS architecture has been created, it needs to be maintained and kept relevant if it is to continue to serve a useful purpose. The resources required to do this should be small, with two people needed for a period of about 6 months every 12-18 months – but this will depend on the size of the project. The need to update the ITS architecture will depend on the speed of the evolution of ITS and the stakeholders’ need for implementing new ITS applications.

Advice to practitioners

When allocating resources, it is helpful to keep in mind the long term situation and the need to keep the ITS architecture consistent with the continual evolution of ITS. For large ITS architectures, such as those with several different types of service (for example, traffic management, public transport and tolling) it will be cost effective to employ the same person to create and maintain the architecture. The dividends will be reduced staff resource time because of retained knowledge, which in turn can be translated into reduced costs. Stakeholders will be dealing with someone who knows about the ITS architecture, which will inspire them with confidence.

ISSUES FOR DEVELOPING ECONOMIES

It is possible that there will be no suitable local expertise to create the architecture but dependency on the use of consultants will be expensive. A better plan may be to train at least two locally-based people to create the ITS architecture and carry out the maintenance work – drawing on a mentor for help and advice. The locally based people do not have to be software or hardware engineers - in fact it is probably better if they are not. Computer literacy, willingness to learn and enthusiasm are the prime requirements, with some knowledge of ITS being a great help. Local staff will be better placed to appreciate what the stakeholders want from ITS.

Using the US 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.

US National ITS Architecture Turbo Architecture tool provides facilities that enable users to tailor and expand the architecture content to meet the needs of their particular ITS implementation. The adaption process is described in parts of the “Help” facility for the Turbo Architecture tool, but users may find it helpful to obtain specialist assistance and advice before starting.

The steps to follow

Using the US National ITS Architecture to create the ITS architecture that will support the services agreed with the stakeholders means taking the following steps.

Step 1. On the US Architecture website (http://www.iteris.com/itsarch/) select the "User Services" tab. This will open a new window that displays a list of User Service Bundles and User Services, as shown below. User Service Bundles, are groups of User Services for similar ITS supported activities, such as Travel and Traffic Management shown below.(Click + to show)

USER SERVICES BUNDLE

Figure 6: US ITS Architecture website opening screen shot

 

Step 2. Clicking on a User Service will open another window containing the overall description of the User Service and descriptions of each of its constituent services, plus where they are used as shown below. The last piece of information can be ignored as it will be taken care of by the Turbo Architecture tool, illustrated below. (Click + to show)

User Service Description

Figure 7: US ITS Architecture website user services page

 

Step 3. Create a spread sheet, then copy and number the service descriptions approved by the stakeholders (See How to Create One) into the two hand columns. Mark the columns to the with headings for the User Services numbers and descriptions that match each service description, plus (optionally) an extra column for assumptions, cross references to other matches, or comments.

Step 4. Go through the service descriptions and find the matching User Services. Copy into the spread sheet the number and text of the User Service(s) into the appropriate row(s) opposite the Stakeholder Service description that they match, duplicating rows if more than one User Service is needed to completely match a Stakeholder Service description. The table that is produced should look something like this:

Step 5. From experience it is a good idea for the Architecture Team to carry out this work individually and then compare their results at the end. The points of agreement can be accepted and the points of disagreement debated. At the end a table will have been produced showing the agreed matches between the Stakeholder Service descriptions and the User Service Descriptions.

Step 6. An alternative method for Steps 1-4 is in Step 1, to select the "Service Packages" tab which will open a new window that displays a list of the ITS service packages that the US Architecture supports. (Click + to show)

Service Packages

Figure 7.1: US ITS Architecture website Service Packages page

Step 7. Clicking on a Service Package will open another window containing its description and a diagram of its constituent parts. There are separate tabs that give access to a variety of other information about the selected package. (Click + to show)

Service Package Description

Figure 7.2: US ITS Architecture website Service Package description page

The spreadsheet created in Steps 3 and 4 will should have "Matching Service Package" as the title of columns 3 and 4, which should contain the identities of the selected Packages.

Step 8. Do not be afraid of deciding that not all parts of one or more Stakeholder Service descriptions can be matched to one or more User Services or Service Packages. Both of these are based on the way that ITS is expected to be implemented in the USA.

Step 9. If you are unhappy with the way that the Stakeholder Service descriptions have been matched to the User Service descriptions or Service Packages, then the US National ITS Architecture needs to be modified to accommodate the service(s) you want to provide. If you need to do this then you should continue with Step 9 and use the Turbo Architecture tool help facility to find the guidance that will show you how to modify the architecture to include extra service packages and their associated elements.

Step 10. The next step is to download the Turbo Architecture tool from its page on the US ITS Architecture website. A link to this is provided by the "TURBO ARCHITECTURE" tab at the top of every webpage and it is recommended that you read this page before commencing to download the Tool. Downloading the Tool will also include a copy of the database it uses that contains the details of the US National ITS Architecture.

Step 11. Although the Turbo Architecture Tool is fairly easy to use, before doing so it is very wise to complete one of its training courses, some of which are available on line. The details of what they contain and how to participate are also available through the US ITS Architecture website with other training resources at the top of every webpage under the "TRAINING/WORKSHOPS" tab.

What do you get?

The Turbo Architecture Tool provides a step by step development of stakeholder needs in terms of the services that they want ITS to deliver. These are traced to physical subsystems and functional requirements. It is also possible to tailor the information flows to suit particular user requirements, provide linkages to standards, and identify stakeholders. This is all contained in a single tool and the products are interrelated, producing diagrams, tables and – for final production – webpages and documentation that make the architecture available to all stakeholders. An example of a diagram showing the subsystems and their interconnections for a typical ITS implementation is provided below (Click + to show).

subsystems and Interconnections

Figure 8: Example of an interconnect diagram produced by the Turbo Architecture tool

In the diagram above the items in "grey" are subsystems in the full US National ITS Architecture that are not being used in this example.

The Turbo Architecture tool can be used to produce further details. These include:

• Tables: these can be created in WORD or EXCEL and provide information about the created ITS architecture such as stakeholders, services, operational concepts, interfaces, standards and many more
• Reports: these are produced in a similar format to reports produced by the ACCESS database tool and can be for a similar range of subjects to the tables
• Diagrams: aside from the subsystem diagram shown in Figure 8, two other diagrams can be produced showing the interconnections and data flows between the system components themselves and between the components and any external entities
• Web Pages: again these can be produced for a similar set of information and are stored as files in a nominated folder ready for use

All of the above are provided using pre-prepared templates, which will contain the selected information. Each table and report can be edited to change the layout or format to suit individual organisation requirements. Examples of these outputs can be seen by opening the "marinara" example, which is included in the Turbo Architecture program files.

Further information

A case study on the development of a national ITS Architecture for Chile is available. (See Case Study)

Further information about US National Architecture and details of training courses can be found from the US National ITS Architecture website at: http://www.iteris.com/itsarch/. This also provides a "Contact Us" link at the top of each web page for those with specific questions.

A fully comprehensive guide to creating ITS architectures from the US National ITS Architecture can be found in the US DoT publication, "Regional ITS Architecture Guidance , Developing, Using and Maintaining an ITS Architecture for your region", available for downloaded as a PDF file free of charge from the US Department of Transport website at: http://www.ops.fhwa.dot.gov/publications/regitsarchguide/raguide.pdf

Using the Framework (FRAME) Architecture

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 steps to follow

To use the FRAME Architecture to create an ITS architecture that will support the services agreed with the stakeholders will involve taking the following steps.

Step 1. Visit the FRAME Architecture website (http://www.frame-online.net/) and select the "Library" tab and click on "FRAME Architecture" as shown below. (Click + to show)

OPtions on the FRAME Home Page

Figure 9: FRAME website opening screen shot

Step 2.  On the next web page that is displayed, download the User Needs (1.4M doc file) plus the pictorial version of the structure of the User Needs (350kB pdf file), as shown below, and save both files. (Click + to show)

select Downloads and Create a spread sheet

Figure 10: Selecting FRAME User Needs files to download

Step3.  Create a spread sheet, then copy and number the Service Descriptions generated by the architecture team (and approved by the stakeholders (See How to Create One?),into the two hand columns. Label the columns to the with headings for the FRAME User Needs Numbers and User Needs Descriptions that elaborate each Service Aspiration, plus (optionally) an extra column for Assumptions, Cross References to Other Matches, or Comments.

Step 4. Go through the Service Descriptions and find the relevant FRAME User Need Descriptions in the "1.4M doc file" downloaded in Step 2. Studying the table of FRAME User Needs will help to identify the Groups of User Needs to consider. For the moment at least, ignore the Group 1 User Need Descriptions as these are "general" and can be used later, in the procurement process. These relate to issues such as adaptability, continuity, data quality, privacy, robustness, safety, security and user friendliness - all of which will need to be addressed in one way of another by various parts of the ITS implementation.

Copy into the spread sheet the Number and Text of the FRAME User Need Descriptions into the appropriate row(s) opposite the Service Aspiration to which they are relevant, duplicating rows if more than one User Need Description is needed to completely match a Service Aspiration. The table that is produced should look like this:

Step 5. From experience it is a good idea for the Architecture Team to carry out this work individually and then compare their results when all the Service Aspirations have been processed. The end result will be consensus on a table showing the agreed list of User Need Descriptions that match the stakeholders’ Service Aspirations.

Step 6. Do not be afraid of deciding that not all parts of one or more the Service Descriptions can be matched to one or more User Need Descriptions. If this happens, the FRAME Architecture can be extended so that it provides the support for these services. How to do this is described in Part 3 of the FRAME Selection Tool Reference Manual, which is available from the same web page as the tool itself – see Step 10 and also Step 7 which follows.

Step 7. If as a result of your work in Steps 5 and 6 you decide that you do need to extend the FRAME Architecture, it is essential to see what is in it. To do this on the FRAME website click on the "FRAME Architecture" tab and select "The Browsing Tool" option, which will show the web page from which the Tool can be downloaded. (Click + to show)

The Browsing Tool

Figure 11: FRAME Browsing Tool download page

Step 8. The Browsing Tool will need to be set-up by following the instructions on the web page, which also explains how to run the Tool. When run, the Tool will initially display its home page, from which the contents of the FRAME Architecture can be viewed. A sample of its display for part of the functionality is shown below (Click + to show) Browsing Tool pages for the data flows and data stores will be similar in appearance, and it is also possible to display data flow diagrams (DFD's).

Step 9.  Navigating through the Architecture can be done using the Navigation Area on the or through the links provided by the "blue" coloured text in the main part of a page. Guidance about how to navigate through the FRAME Architecture using the Browsing Tool is also provided on the home page and in the FRAME web page referred to in Step 7.

Navigating the Browsing tool

Figure 12: Screen shot of FRAME Browsing Tool page

Step 10. Once you are happy with the way that all the service descriptions have been matched to the User Needs, download the FRAME Selection Tool. To do this, click on the "FRAME Architecture" tab at the top of the page and on "The Selection Tool" in the drop down list that appears. The web page that appears is shown in the diagram below and it provides instructions for downloading the Tool, the database it uses, its User Manual (needed for Steps 1-13) and the Reference Manual (needed for Step 6). (Click + to show)

tHe selection tool

Figure 13: FRAME Selection Tool download page

Step 11. Once the Selection Tool has been set up, the User Manual will provide guidance about its use to create ITS architectures. This involves selecting the FRAME User Need Descriptions identified in Steps 4 and 5 and using the Tool to include the functionality needed to support them (functional viewpoint), the physical viewpoint and - if needed - the organisational viewpoint.

The Selection Tool will perform checks on the logical consistency of the functionality that is included from the User Needs you have identified in Steps 4 and 5. It will expect you to resolve any inconsistencies by adding/deleting functions, data flows, data stores and terminators. If you haven't already downloaded the Browsing Tool in Steps 7 and 8, follow the instructions above. It is essential to use this Tool to study the FRAME Architecture to see what is causing the logical inconsistencies.

Step 12. The Selection Tool allows several physical and organisational viewpoints to be created for one functional viewpoint, which is part of the process of finding the optimum configuration (See Next Steps).

Step 13. To create a sub-set ITS architecture, a new physical viewpoint is created that includes as much of the functional viewpoint as is required by the sub-set. Several sub-set ITS architectures can be created from one functional viewpoint using the FRAME Selection Tool. It is possible to experiment by selecting different parts of the functional viewpoint - or to create different physical viewpoints for the same selection.

WHAT DO YOU GET?

The FRAME Selection Tool produces a set of files that contain tables providing details of the contents of the functional, physical and organisational 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.

The frame architecture in practice – kent county council

The following figures illustrate some of the materials that can be produced as a result of creating an ITS architecture from the FRAME Architecture, using the output from the FRAME Selection Tool. They relate to the ITS architecture developed for Kent County Council in the UK and are reproduced by kind permission of that Council.

The diagrams and tables shown below have been created from the tables produced by the FRAME Selection Tool. Using these tables, other diagrams and tables can be created that are important to specifying and visualising the architecture.

Service descriptions

This diagram shows a sample page from the list of service descriptions that were produced from the "stakeholder aspirations" resulting from the stakeholder consultation exercises carried out by Kent County Council (KCC) before the ITS architecture was created.

Figure : Example of service descriptions for the Kent CC ITS Architecture

Context diagram

The "context diagram" shows the communications links to all the entities outside the Kent ITS Architecture. The system boundary is shown by the red dashed line. Some of the communications links that cross the system boundary will be electronic, such as link to the Maintenance Organisation, whilst others will be through human machine interfaces (HMI), such as links to "Operators" and Travellers. In the example shown, the term "operator" means a person responsible for managing a computer system. Other communications links will be different again. For example, links to “Traffic” will be through a variety of mechanisms.

Figure : The Kent CC ITS Architecture Context Diagram with the system boundary

Physical viewpoint

In the example from the Kent ITS Architecture below, all the components have been grouped into three "sub-systems". Other ITS architectures could have more or less of these sub-systems.

Figure : The Kent CC ITS Architecture top level physical viewpoint diagram

Traffic management sub-system

The components within this sub-system have been grouped together to form several "modules", each of which delivers all or part of a service. For each "module" its communications links to the world outside the Kent ITS Architecture are shown and are the same as the links shown in the context diagram. Similar diagrams to this were produced to show the modules in the other two sub-systems.

Figure : A Kent CC ITS Architecture subsystem diagram

communications viewpoint

This is part of the table in the communications viewpoint which shows the requirements for some of the communications links identified in the physical viewpoint. In this particular instance, the link is between two modules in different sub-systems. Other similar tables were produced for other electronic links between modules, sub-systems and for the exchange of data with the outside world. The information in these tables would be used to define the types of links required and help specify the standards with which they must conform.

Figure : A page of the Kent CC ITS Architecture communications viewpoint

its sub-systems related to service Descriptions

This is part of the table that shows the links between the "aspirations" created by the stakeholders and the "modules" in the physical viewpoint. This table is most useful if the services are to be implemented over a period of time, as it shows which "modules" will be needed by each service. In some instances additional services can be provided "for free" because the components specified in the physical viewpoint have the capability to be shared.

Figure : A page from the Kent CC ITS Architecture table of components required by services

additional diagrams and tables

Further information

Free information about using the FRAME Architecture - including extending it - is available from the FRAME Architecture website at: http://www.frame-online.net/. To find some of this information, scroll down the home page to find links for specific topics. The web site’s “FAQ” facility (in the "FRAME ARCHITECTURE" drop down menu) and its pages in the "LIBRARY" drop down menu, for example "Articles and Papers", provide further information. Any questions (and comments) that are not answered by any of these resources can be sent to info@frame-online.net.

Managing the ITS Implementation

The case study on the Abu Dhabi Integrated Transportation Information and Navigation System (i-TINS) provides an example of how a systems approach is applied in practice. (See Case Study: System Integration (Abu Dhabi)) There are two different aspects to managing the implementation of an ITS project, both of which are important.

The first is done by the Project Manager (PM) and covers all of the work, but with a heavy emphasis on the financial and contractual aspects. It also involves dealing with the ITS service users and customers, some of whom may not be represented by any of the key stakeholders.

A second aspect is the technical or engineering part of the work and is done by someone often called the "technical" or "engineering programme manager". This person will concentrate on the programme of technical work involved in the ITS implementation.

Project Management

Project Management includes managing everything that is necessary to complete the ITS implementation to the satisfaction of its stakeholders. At the outset, project management must make sure that there is an agreed project plan in place and that the plan is followed during implementation. The level of detail must be sufficient for all participants to know what they have to do, the timeframe in which it has to be completed, any dependent project-related activities and the availability of any external resources that are required.

As part of the implementation of the project plan, project management will involve:

• setting up, agreeing and managing contracts for suppliers, system integrators and communications providers
• looking after the financial aspects, such as agreeing that payment can be made for work that has been completed
• acting as a "go between" with stakeholders so that they are fully informed about the progress being made by the ITS implementation and any deviations from the planned programme – as well as addressing any concerns that they may have
• dealing with the media and working with publicity consultants to provide information (good and bad) about the project in the most appropriate way possible

Acting as a "go between" with stakeholders is a two-way process. It means representing the project to the stakeholders so that they are informed about what is happening and the reasons for it. It also means representing the stakeholders to the project team to make sure that any concerns are addressed – and to deal with any changes that the stakeholders would like to see. These changes can be anything, from planned events to requirements for services – both of which can change as the project progresses during implementation.

Changes to requirements for services are sometimes collectively known as "requirements creep" and can be a natural result of changes in user attitudes towards ITS and developments in technology that make additional and/or revised services possible. (See How to create one?)

The magnitude of the project management activity will depend on the size and scope of the ITS implementation. Aside from the usual factors such as number and scope of services and transport modes, plus geographical coverage, other factors that affect the size of the activity include the numbers of stakeholders, suppliers and communications providers. Some building work may be needed, such as for a control centre, plus other work such as installation of equipment in different locations (for example the roadside) and sometimes the removal and proper disposal of existing components. None of these tasks and activities should be underestimated as some will have their own particular complexities, such as installing a variable message display over a busy part of the road network necessitating temporary traffic restrictions. All of them will need to appear as items in the project plan.

If most activities take place in the ways and at the times shown in the project plan, then the project management activity is not too onerous. It is when there are deviations from the project plan or when contractual difficulties emerge that the demands on project management increase dramatically, in scale, complexity and content. There will be times when (unfortunately) some delicate diplomacy will be needed if all the activities related to the ITS implementation are to be completed with any degree of satisfaction for everyone that is involved.

The project management activities are best carried out by a dedicated Project Manager (PM) who must be appointed before any work actually starts. Who it is will depend on a number of factors. According to the circumstance the PM may come from:

• a leading supplier
• the system integrator – if one has been employed
• a large and/or dominant stakeholder
• an independent outsider

No matter where they come from, the person who is the PM has to manage all the work to implement ITS on behalf of all those involved, whether they stakeholders or suppliers, and must not favour the interests of a single entity or group at the expense of the others.

Technical or Engineering Programme Management

For the larger ITS implementations which are often complex and have lots of engineering content, it will be beneficial if a separate person is appointed to manage the systems engineering programme. This job can be seen as a "technical project manager" or "engineering manager", because the person doing the job may not get directly involved in the contractual or financial aspects.

The person appointed to be the technical project manager can come from

a dominant supplier, which might be the one that provides all the control and management centre components, or the person, could be from the communications provider.

if a large number of suppliers are involved, a system integrator can be appointed to which the programme manager will belong. The system integrator is often a specialist organisation and should preferably be one with a proven track record of implementing ITS and a knowledge of the particular services that the stakeholders want ITS to provide.

Whatever the origins of the person managing the systems engineering programme, they need to be able to manage all of the steps shown in the system engineering "V" model (See Systems Engineering Programme) according to the project plan.

Advice to Practitioners

Further Information

Project management is now a discipline in it its own . So it should be possible to find someone, or an organisation with the knowledge and experience to perform all the activities correctly and in the way. There are organisations that actively promote the professionalism of project management and offer access to qualifications for project managers. The largest of these is the Project Management Institute (http://www.pmi.org/) that has branches (called chapters) in most parts of the world. It has published a book called "A Guide to the Project Management Body of Knowledge", which is now in its 5th edition.

Technical or Engineering Development

This is the sub-system and component design, plus component development parts of the system engineering "V" model. (See Systems Engineering Programme) They are the parts that appeal to most of those involved in developing ITS technology and generate the most "excitement". This is largely because development work is where the systems are invented, developed, tested and implemented – and where people can be hands-on with the hardware and/or are able to create the software. It is also where things can go seriously wrong, which can have a very significant impact on the timescales and/or costs for the ITS implementation as a whole.

CREATING new technology

The motivation for creating new technology is often that none of the existing technologies will enable a planned service to be implemented. Also creating new technologies to replace what exists can make the implementation of a service easier and/or cheaper, so improving the benefit to cost ratio.

An example of this is the service to detect the numbers of occupants in a vehicle. Until recently, the only way to do this was to have a person located at the roadside so that they could visually check each vehicle as it passed by. Now infrared and video camera technologies have advanced to the point where a camera can do at least some of the checking.

Creating new technology is fraught with risks and must not be undertaken without proper and robust justification. This justification may be difficult to achieve, especially as most ITS implementations are often constrained by time, for instance the stakeholders want the services to be available now, or maybe in a few months, but not in a few years. What stakeholders do not want is an open-ended timescale where nobody really knows how long it will take to develop the required new technology. There are too many real life stories of ITS and other technology-based implementations that have failed because either the new technology could not be created and/or developed, or the resulting product was too difficult or expensive to produce.

Using existing technology

Using technology that has already been developed but has never been applied in practice has less risk than using new technology. It still requires careful assessment and a good robust justification as there are many risks in going from the prototype or development phase to the production phase in technological or engineering development.

Using existing technologies that have proven track records of being successfully used in other ITS implementations provides the least amount of risk. They may also be much cheaper and there may well be a bigger choice of suppliers than for new or prototype technologies.

The Design and Development Processes

Design and Development starts with the component specifications and communications requirements that were created when the ITS Architecture was produced. (See How to Create One) If any currently available components and communications equipment is to be used (sometimes called "off the shelf"), then there is not much to do, other than integrate them together. (See Integration and Testing)

If something new is required, then how the component suppliers and communications providers go about producing them will be kept hidden, largely for commercial reasons. But there are a few things about which project managers, system integrators and others monitoring the ITS implementation can ask questions. The nature of the questions depends on what is being designed and developed and can be broken down into three areas: hardware, software and communications.

Hardware

For many ITS implementations, no new hardware will be needed, so it should be possible to see the actual physical components being produced and to ask for evidence of previous testing, especially where this relates to compliance with regulations. If new hardware is needed then it is not unreasonable to be shown prototypes and/or watch them being tested. It may also be necessary to ensure that any local regulatory approvals that may be needed to locate and operate equipment at the roadside have been gained.

Software

Most ITS implementations will need new software to be created, although it may not be entirely new and may involve the customisation or more serious modification of what already exists. The creation of new software is difficult to monitor because there is nothing "physical" to see. It should, though, be possible to examine the high-level software design and then monitor progress being made with the creation of modules within it, even if they are modifications of what already exists. Getting figures about the number of lines of code produced does not always mean very much on its own. It needs to be coupled with the percentage of the total that it represents.

The software supplier should have a robust and reliable code checking process in place, so that what has been produced is checked (sometimes called a "code walkthrough") before being tested. This particularly applies to software created for services that require access to/from the Internet, if the chance of unauthorised access is to be reduced to almost nothing. In this case it should be possible to carry out intrusion tests to prove that data is tamper proof and is not accessible to others not connected with the ITS implementation.

If data about planned and current traveller movements is being processed compliance with local and/or regional privacy statutes and standards must be carefully checked. Again this may require some testing, or proof that testing has been successfully completed.

If new end user interfaces are being produced, then prototypes must be made available for review and testing, preferably by representatives of the users, rather than any other group.

At one time suppliers were usually required to provide a copy of the software that they had developed for the project as part of their contractual obligations. This was either for use by the stakeholders at some point in the future, or to be held in escrow in case the supplier was unable to make any desired changes in the future. Software now is often so complex and spread across a number of suppliers and components, that this is no longer a realistic option. It also requires one or more of the stakeholders to have the necessary expertise available to use the software, which except for very large organisations is not usually the case.

Communications

Most ITS implementations will use physical communications links that already exist. In some cases, ITS may have to share these links with other unrelated services. Important questions to be asked are:

• Can access to shared communication links by ITS be guaranteed and be within the correct timeframe(s) whenever they are needed?
• Can privacy and security be guaranteed for the ITS related data, particularly?
• What is the failure rate of the links, both those that are shared and those links that will be dedicated to ITS?
• How appropriate are the proposed physical links for the particular data or information transfer that ITS requires?
• What communications related standards are being used by the links?
• How widely have these standards been adopted in other ITS implementations?
• Do those standards and other aspects of the link operation proactively address the need to prevent unauthorised access and to protect the privacy of its users?

Data privacy will be particularly important when data about planned or actual traveller and freight movements is being collected and transmitted across communications links. This will be particularly important if the ITS implementation includes services that are provided by Cooperative ITS (connected vehicles). In either of these cases it is very important to check that all local and/or regional privacy statutes and standards are being followed. (See Data Ownership & Sharing)

In general the communications standards used in ITS implementations should have been produced by standards development organisations such as ISO, IEEE, CEN, ETSI and SAE. (See ITS Standards) Failure to use such standards may have the following impacts:

• the communications are expensive to set up because bespoke equipment and/or dedicated physical links are needed

• inter-operability with other neighbouring ITS implementations may not be possible

• An example of the second point is if a bespoke communications mechanism is used for the link between vehicles and the roadside. This means that all vehicles need to have specific communications units fitted, which may be incompatible with those needed elsewhere, such as in an adjacent geographic area. In some cases this will not matter, for example because vehicles are not taken to the adjacent nation geographic area, but within continents such as Europe, Asia, Africa, plus North, Mid and South America, movement of vehicles across national borders is becoming more common

Advice for Practitioners

Design and development activities are probably the most important parts of the ITS implementation process, but are also the most difficult to monitor. Information about progress can sometimes be gained just by asking the questions of the suppliers and communications providers doing the work. But in the end it can be a question of trusting that suppliers and providers will do what they have said in their contracts. A way to start to build that trust is to ask other organisations that have used the same suppliers and communications providers how did their ITS implementations work out, were there any problems that were unsolved, or could have been prevented by better working practices?

Integration and Testing

Integration is the process by which all the components and communications links needed to provide the services to be delivered by the ITS implementation are brought together and tested with one another. It is often a gradual process, with groups of components being tested first before all of them are tested. When viewed from the "outside", these components appear to work as one – and their individual identities and functions may be hidden. When viewed from the "inside", the components are working together and sharing data.

Integration

Before integration can start, each of the components to be integrated must be tested on its own. This will almost always need to be done in a special environment that enables the inputs from and outputs to the world outside the component to be simulated. An advantage of simulation of the inputs is that it enables the full spectrum of possible values and/or conditions to be tested – including ones that are low probability or unexpected. For outputs, the advantage of simulation is those that are unexpected should not cause problems for other components, or for end users. Once the testing of components on their own has been successfully completed, they can be tested together, which is what the process of integration is all about.

A similar way of working must also be applied to communications links, which may pass through several physical locations and/or use several physical mediums to transfer data from one component to another. It is therefore better to test each part of the link in isolation before testing the whole link as a single entity.

Sequence of Tests

The testing of the components and communications that is carried out in order to integrate them will usually go through the following stages:

1. Component testing – each component tested on its own, with most if not all the external interfaces provided by simulation
2. Group testing – groups of components (sub-systems) are tested together, again with most if not all of the external interfaces provided by simulation
3. System testing – all the sub-systems are tested together using some of the actual external interfaces (for example, one or two traffic signal controllers), but simulating others (for example, variable message displays, which can be very large and not available in the location where system testing is carried out)
4. Site testing – a repeat of system testing once many of the components and communications links have been installed and commissioned in their final physical locations and again using some actual external interfaces
5. Final Acceptance tests – a repeat of site testing but in the presence of, and often with the participation of, the stakeholders, plus others such as control centre operators
6. Initial operation – a sufficiently long test period (months, rather than days or weeks) when all parts of the ITS implementation are available and fully operational

Steps (1) to (3) are usually carried out at the suppliers' premises. If the stakeholders have employed a system integrator, steps (2) and (3) may instead be carried out at the integrator's premises, or at a place of their choosing. Steps (4) and (5) are usually carried out at the location where some of the components are going to operate, such as a control centre. It may be possible to increase the representation of external interfaces to include some of those for end users such as those for car parking and Public Transport. For both these Steps, in addition to a representative sample of external interfaces, communications links should either be included or simulated.

Step (6) is a trial period of operation for the ITS implementation. During this time all of its components and the communications links must be available and being used to provide all of the services the stakeholders expect to see, based on what they wrote in the service descriptions. The trial period should be sufficiently long that any particular situations for which services must be available actually take place – for example major sporting events, particular types of incidents, holiday periods, plus major festivals or New Year celebrations.

Test Specifications

Almost all of the testing steps identified above must be described. The possible exception is Step (6), which is essentially normal operation and may require a different form of description. The descriptions of the testing in the other Steps are provided through test specifications that describe the following in detail:

• the initial conditions, namely the situation prior to the test
• any external interfaces that must either be provided or simulated
• how each test is to be carried out
• the final conditions and expected results

The specifications for each of the tests must be written at the corresponding stage in the system engineering process. For example, the specification for the final acceptance tests must be written when the service descriptions have been created and agreed by the stakeholders. Ideally the stakeholders should write them, but in practice they are often written jointly by the stakeholders and the main supplier, or system integrator. Similarly the factory and site acceptance tests must be written when the component specifications and communications requirements have been produced. Although the stakeholders should be involved, the main supplier or system integrator will do most of the work.

For Step (6) a much simpler test specification should suffice. It may be necessary for the specification to state how acceptance tests will be conducted if any critical situations, such as sporting events, particular incidents, holidays and festivities, do not occur.

Advice to practitioners

Creating good test specifications is a "must" if the components and communications links are going to work as expected. There are no short cuts to this requirement. The other thing to do is to keep a record of what tests have been done, by whom and with what results. If possible get all the tests witnessed by someone from the either the organisation that is responsible for doing the tests, or the organisation(s) that provided what is being tested. This will be particularly useful when repeats of failed tests are needed.

A necessary pre-requisite for the final acceptance that an ITS implementation has been successfully completed is the formal acceptance of the records of the completed tests. This should show that all of them have been successfully completed and that any required repeat testing has also been successfully carried out.

ISSUES FOR DEVELOPING ECONOMIES

Where there is little or no local experience of using ITS amongst the stakeholders it is important to take one or both of the following actions:

• buy in the systems engineering experience – employ someone with experience of implementing and using ITS to carry out some or all of the testing. If not all, then certainly employ external help for the final testing with all the components and communications links
• get local people experienced – send one or more local people to see and perhaps work alongside organisations that have already implemented ITS, particularly the services that are being tested. This should be more than just a one day visit and should enable the people involved to gain first-hand experience of ITS in action from the point of view of the provider, the operator and the user

If possible go for the second action in preference to the first. It will provide lasting benefit once the ITS implementation has finished the final acceptance tests. It will also help with the successful completion of the first few months of ITS service delivery.

ORGANISATIONAL ISSUES

It is advisable to get as many as possible – if not all – of the stakeholders involved in the final acceptance testing before the trial period of operation starts. This will help them to become familiar with what the ITS implementation will do and help to prevent the trial period of operation producing too many "surprises". Also because people from the suppliers, communications providers and/or system integrator will be present at the acceptance tests, any questions from the stakeholders can be answered much more quickly and with more authority.

A good way to get the stakeholders involved in the final acceptance testing is to ask them to provide the people to participate in the testing. So for example, if the ITS implementation includes a control centre from which the road network will be managed, then get the actual operators who will be in the centre to test the services it provides. If some of the system interfaces in the control centre are for Public Transport operators or the Emergency Services, then get those organisations to provide people to test the relevant services. For example if the drivers of Emergency Vehicles can witness the operation of "green waves" they will be able to see and understand the benefits that ITS can provide.

Staffing Levels

The staffing level is the number of people required to operate and manage the ITS implementation so that the services are delivered. It needs to be calculated in two ways:

• the minimum number of people that need to be present at different times of the day
• the total number required, taking account of such things as shift working

How these two totals are calculated will depend on a combination of the following nine factors:

• How many different road transport activities, such as road traffic management, Public Transport management, tolling, parking, separate urban and inter-urban traffic management and travel information, will be covered by the services and how many of them will require separate management?
• How much operator support and supervision will be needed to operate each service?
• Will the each service operate all day every day and for those that do, are the same levels of management required all of the time?
• How many geographic areas will be covered by the services and they will use a single control centre for all areas, or one centre for each area?
• Do the services operate independently of each other and if not, does the inter-action between them enable staff to manage more than one service?
• The number of organisations that will be involved in the operation of the services, such as road operators (urban and/or inter-urban), Public Transport service providers, toll service providers and Police?
• To what extent staff can take management decisions and their levels of responsibility, specifically can operators take any decisions, or must some or all decisions be referred to particular managers?
• What constraints do local employment laws impose, such as setting a maximum number of hours that a person can work continuously and in any week, plus what allowances must be made for holidays, training and sickness?
• Will maintenance be carried out by the organisation that is responsible for the management and operation of the services, or will it be subcontracted to one or more external organisations?

Not all of these factors will be relevant to every ITS implementation – but those that are will determine the maximum staff requirements needed.

Required Skills

The scope and content of the services provided by the ITS implementation will determine the skills that staff will require to possess in order to operate and manage it. Also the level of responsibility to be assigned to each member of staff will be another factor that determines the level of skill. The ideal member of staff will need to possess the following skills:

• Be computer literate, able to operate a computer, with familiarity with the particular type of computer(s) and/or operating system(s) being used an advantage
• Have some knowledge of ITS services, such as what they can do and who will use them
• Have some knowledge of road traffic management practices, such as how traffic signals work, how they can be controlled and vehicle detection
• Have some knowledge of how Public Transport services are provided and the constraints under which they have to operate, such as the need for driver rest periods
• Where an applicant does not possess some of these skills but is otherwise suitable, then training should be offered. This should be initial training and provided when they join to enable them to do at least one job, plus follow-on training to expand the range of jobs that they can do

If the organisation that operates and manages the ITS implementation decides to carry out its own maintenance activities, then a new set of skills will be needed. These will be more technical and may cover such things as component replacement, component repair and software maintenance. Candidates for these staff positions will either need to have had specialist training, or to be provided with it when they start work. Such training will almost always be available from hardware and software component suppliers, but in the case of software may also be available from other organisations.

The maintenance of the communications networks is often best provided by the communications network provider(s). On occasions access will be needed to their premises and/or equipment, some of which may be used by other network customers. It is often useful to have staff capable of diagnosing communications problems, so that the network provider can be contacted and given some vital information about the possible nature of the problem.

Issues for Developing Economies

Getting people with the skills in ITS as described above may be difficult. There may be several options to resolve this issue, but two of the most obvious are:

• buy in the skills from outside
• train local people

Of the two, the first is the short-term solution and may be initially cheaper. In the longer term, training local people is the answer, even if it is more expensive initially. There are many organisations that offer suitable training, and sometimes it can be included in the contracts for suppliers and/or system integrators. Many of them will provide the training either at their own premises, or in the location where ITS is being implemented. The acquisition of experience in communications is probably best as an issue for the communications providers to resolve.

System Maintenance

The organisations that operate and manage ITS systems and services can each decide to do some or all of their own maintenance or sub-contract it to other organisations. The increasing complexity of ITS implementations and the services that they provide tends to promote the idea of using sub-contractors.

Scope of maintenance activities

Advances in the technologies found in the system components and communications networks used by ITS implementations have reduced their need for regular maintenance. The days of frequent periodic maintenance activities for hardware and equipment are fast going and are being replaced by a philosophy summed up by the expression, "if it isn't broken, don't fix it".

Modern day roadside equipment will normally only need occasional replacement of light sources and sensors. Even this is declining with light sources now operating at low voltages. In other respects the trend is for maintenance activities to only be needed following the effects of extreme weather conditions, such as extremes of temperature flooding and high winds. There are some exceptions to this trend, such as mechanical barriers at car parks or bridges, and equipment in tunnels that will need extra safety checks that will need to be carried out on a regular basis.

Control centre and communications equipment is following the trend towards little or no maintenance activities. When anything does go wrong the tendency is to replace rather than repair.

The one exception to the "if it isn't broken, don't fix it" mantra is software which is often updated periodically, either because problems have been found or to include improvements. This is particularly important for any components that will be connected to the Internet, as they must be protected by sophisticated firewalls and software to prevent unauthorised access. Whenever software changes are made Configuration Management (CM) needs to be employed to ensure that the changes are managed and that it is possible to revert to the unchanged version if problems arise.

Using sub-contractors

Except for the large organisations that often manage ITS implementations in cities and across states, provinces or nations, it is usual to employ sub-contractors to carry out maintenance activities. These sub-contractors may be specialist maintenance organisations, or the component suppliers, particularly for roadside components.

Whatever form of sub-contractor is used, the scope and content of their activities must be defined in a contract, sometimes called a Service Level Agreement (SLA). The SLA must define such things as what is to be maintained, the hours and days during which the sub-contractor must attend to a reported fault, the response time for a reported fault, how long a repair can take, at what point must a replacement component be fitted, spare stock holdings, plus the competence and availability of the sub-contractor's staff. A cost structure must also be included, to either fix a price for each activity, or fix an overall price for all maintenance activities. SLA's usually only operate for a fixed period of time (2-5 years) and will need to be renewed when the time has expired, often through a tender submission process.

Not using sub-contractors

The possible exceptions to the use of sub-contractors for maintenance activities are large cities, or other geographic areas for which the scale of the ITS implementation is large, particularly in terms of the amount of hardware used. In these instances the amount of maintenance work required will make the recruitment and training of specialist hardware maintenance staff, providing a stock of spares and a repair facility, a benefit to the organisation operating and managing the ITS implementation. Sometimes the organisations in adjacent areas can combine their maintenance activities to benefit from not using sub-contractors.

Software maintenance is usually different because even in a large ITS implementation there is not the same quantity as there is for hardware, and understanding, modifying and replacing it is more complex. For example, the software for a typical urban traffic control system may have between 250,000 and 500,000 lines of code, which will take a software engineer several months to fully comprehend before any changes can be made. Therefore it is better to get the software supplier(s) to maintain what they have supplied.

Issues for Developing Economies

It is likely that in most countries it will be maintenance of hardware and communications links that will need to be provided, as software maintenance is almost always best to its suppliers.

One way for a developing country to proceed is for ITS maintenance to be done by the component suppliers and communications providers. Quite often a period of maintenance can be included as part of their supply contracts. All the provisos about such things as Service Level Agreement (SLA's) mentioned previously need to be included. Items such as maintenance equipment and spare parts should be stored locally. How the spare parts are provided is something that has to be negotiated as part of the maintenance contract(s). If the service providers take responsibility for ensuring that sufficient spare parts are available it can sometimes be a question of balancing a possible reduction in the cost of maintenance against the greater freedom to change contractors at the end of the maintenance period.

Other factors to be born in mind when negotiating maintenance contracts include what local presence the maintenance contractor(s) will have, and to what extent the contractor(s) will employ local people. The latter can be very important. For the long-term future of the ITS implementation it will be advantageous if the local employees acquire the training to give them the technical skills needed to carry out the maintenance activities.

Diversity of ITS UserS

Designing an ITS product, system or service for the people who will use it is not simply a case of designing to a required specification for a ‘standard’ person, as there is no such thing as a standard person – everyone is different. Whilst people possess certain qualities and limitations that apply, at least in part, to everyone, they are by no means universal. For example, it is possible to quantify reasonable upper limits for human visual performance – but some people cannot see anything at all, others may have blurred vision, and for those who see in sharp detail there may still be issues such as colour blindness affecting their vision. Some differences between people are innate and last a lifetime, some may come and go, whereas some may develop slowly over time. Whatever the reason, differences between individuals must be accounted for in any design, and this includes ITS.

Whilst human variability is vast in scale, there are certain key areas that are likely to influence ITS practitioners in their work.

Differences between People

The vast majority of quantifiable human attributes (especially physical characteristics) follow what is known as the ‘normal’ distribution. This is a distribution seen throughout nature and is represented in the figure below. It shows that the average value within a population (for a criteria such as height) will be the most common, with more extreme (large or small) values being progressively less common. There is no such thing as an average person as there is almost certainly nobody alive that is exactly average in every conceivable parameter. Instead the population is comprised of individuals who may be higher up the distribution on some parameters and lower down the distribution on others.

Natural variability in the population

Age-Related Differences

Social and Cultural Differences

Advice for Practitioners

Four high-level principles help guide those working with ITS:

Design for Worst-Case Scenario

Design for All

Understand Your User Population

Practical Examples of Human Variability

Human Performance

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. (See Coordinated Vehicle-Highway Systems)

Errors

Impairments

Arousal

Human performance varies depending on arousal (excitation level). Individuals can be under-aroused (sleepy, dis-engaged) or over-aroused (excitable, anxious). Individuals perform at their best when at neither extreme.

Arousal/Performance curve

Motivation

Undertaking Single and Multiple Tasks

Use of Physical and Cognitive Resources

Training and Practice

Advice to Practitioners

Expect and allow for variability between people and for a variation in one person’s performance/ability at different times and in different circumstances. The variability may be obvious (such as age, size, physical disability) or may not be. Where possible, design for the least able and most endangered. (See Diversity of and user groups)

People make mistakes, so it is essential that ITS is designed so that systems and processes minimise the possibility of errors and provide opportunities to recover from them. (See  Automation and Human Factors). Task and error analysis may be helpful. (See Human Tasks and Errors). Particular care needs to be taken when an individual’s mistake could have safety consequences for themselves or other road users.

Road Users (drivers, PTW riders, cyclists, pedestrians)

ITS Infrastructure Design – Promoting Performance

Public Transport Users

Control Room Design and Operations

Maintenance and Emergency Response Workers

Motivation and Decision Making

The “user friendliness” of the road network depends on a complex interaction between the technical systems – such as traveller information, route guidance and traffic control – and the road network users. Ultimately, people are individuals and will make their own decisions, but there are many theories and models that can help us to understand individual motivation and the effect this has on behaviour.

By taking account of human motivation and decision making, Road Network Operators should be better placed to understand how people behave both individually and in groups – and how best to influence that behaviour in order to manage the road network.

Human Motivation, Decision Making and Behaviour

The psychologist, Maslow proposed that humans have needs that influence their behaviour, which can be arranged in a hierarchy. Once a need is satisfied, then behaviour is influence by the next (unsatisfied) need in the hierarchy. The most basic are physiological needs (such as food and sleep). Once these are satisfied, safety needs take over and so on.

Hierarchy of Needs

Expectancy Theory

Expectancy theory says that choice or behaviour is motivated by the desirability of outcomes. In general people prefer to avoid negative consequences more than increase positive consequences – for example, to arrive at 08.45am for a 9.00am appointment is of minimal benefit but arriving late may be of considerable dis-benefit.

Theory of Planned Behaviour

According to the theory of planned behaviour, an intention to behave in a certain way is influenced by three things: the expected outcome (positive or negative), how others will perceive the behaviour and a judgement about one’s capability to carry out the behaviour. It seems that there are “boundaries” within which people feel they can and should act and areas where they feel they cannot. In part, this depends on having “permission” to act in a certain way – whether this is permission one gives oneself or whether it is permission granted by others. For example peer pressure can have a profound effect on young male drivers’ behaviour and their willingness to comply with traffic laws.

Planned behaviour

Incentives and Positive Reinforcement

Incentives and positive reinforcement make a behaviour more likely in the future. Benefits that appear certain and immediate are generally preferred to those that are less certain and more distant. This is called the saliency of benefit.

Information

People have an innate drive to be self-determined – they mostly prefer to be in control and will seek information in order to make decisions. This can be used to advantage in Road Network Operations by providing advice to road users and other travellers. Their trust in information (its credibility to them) depends on many factors including:

• the context
• whether the source is trusted
• fitting with previous knowledge
• confirmation and consistency
• the way it is presented
• other peoples’ reaction to the information

In general, people have a poor appreciation of risk (consequences and probabilities), and especially of very small risks. Events that can be more easily brought to mind or imagined are judged to be more likely than events that cannot easily be imagined. This is called the availability bias. Press reports, for example, tend to favour Bad News stories, which promote negative expectations. The managers of Traffic Control Centre operations will be acutely aware of this.

People do not always make choices that are in their best long-term interest. Sometimes “wants” are satisfied before “needs”. So, people are not always economically rational even when all necessary and consistent information is presented. The road users’ response to information messages may differ from what is intended by the Road Operator.

Few individuals constantly seek new experiences. For most there is a tendency to keep doing things in the same way. This is called inertia (an analogy to mechanics). So, people either do not undertake some new activity or continue to do the activity in the same way. To a large extent, these habits are a coping mechanism for the plethora of choices in everyday life.

Decision making also depends on the user’s willingness to seek out all required information (if it is even available). So, a typical approach in many situations is “satisficing” - seeking solutions that are not necessarily optimal but are “good enough”.

One theory proposes that people aim to reduce dissonance (degree of discomfort) between their view of the world and their actions. This can lead to “post-hoc” (after the event) justification of a decision made.

Related to this is a tendency for people to display confirmation bias – a tendency to seek out information (and to preferentially trust that information) that confirms an existing belief, rather than new evidence that may contradict that belief.

Decision Making and Behaviour in the Driving Context

In the driving context, Intelligent Transport Systems (ITS) can provide information and assistance to drivers and can play a part in their decision making. Research has led to various models – one model describes driving decisions at three levels:

• strategic level (such as planning route)
• tactical level (such as lane choice, headway)
• control level (rapid and fine adjustments such as accelerator/brake)

An extension to this model considers driving decisions at four levels with feedback and interaction between them.

The Extended Control Model (reproduced with permission from http://erikhollnagel.com/ideas/ecom.html)

Individual drivers exhibit a range of driving behaviour and styles of driving. Driving can also be considered as a social activity. Interactions between vehicles and between vehicles and other road users are largely interactions between people. An aggressive driving style, particularly in a cooperative driving culture, may be highly offensive. The term “road rage” has been coined to describe extreme feelings or behaviours aggravated by, for example, other road users’ behaviour or driving situations such as congestion.

ITS can provide much helpful information and assistance to drivers. It can also introduce potential problems. Attention to in-vehicle information and communication systems can detract from driving performance and decision making. Although ITS can provide assistance to reduce the drivers’ workload, it is known from research that a sustained low workload (underload) can lead to boredom, loss of situation awareness and reduced alertness. It has been observed that the greater the number of support-system functions which have become available through ITS, the higher the risk of drivers losing competence, which can sometimes be combined with their reliance on ITS functionalities. (See Driver Support)

Advice to Practitioners

Road users typically believe they have an implicit contract with the road network operator. This (in their mind) might include keeping the traffic flowing, maintaining the cycleway, and providing safe and adequate public transport. As a minimum, road users’ basic needs should be considered – such as food and toilet facilities and rest stops for longer journeys.

Anger and frustration can arise if the service quality falls below road users’ expectations. ITS can help to manage expectation – for example by providing information about service quality and frequency. This information needs to be available to road users before their journey (for example on the internet, or printed information), and during their journey (for example on signs, notices, mobile devices). ITS, and communication channels more generally, might also be employed to counteract “Bad Press” stories about the road network.

Dynamic ITS Information to Change Behaviour

Crowd and Group Behaviour

HMI Technologies

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” (recognisable 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

In fact people have others senses as well, including: vestibular (balance and movement), kinaesthetic (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.

There is a wide range of human machine interface components to support the interaction between road users and ITS.

Engagement with ITS – HMI components

Use of hardware (such as buttons and a display screen) allow road users to interact and to develop a dialogue with the ITS technology. The extent to which the dialogue is efficient and effective (and liked by the user) depends both on the detailed design and performance of the interface hardware and also the design structure of the dialogue.

The designer of the HMI has a very wide range of choices. For example, in hardware design, buttons can be “latching” (they maintain their state after being activated) or “non-latching” (momentary) with different sizes, shapes and clearances to other buttons, different levels of resistance and sensitivity. The hardware design may also take account of implicit associations and knowledge of users (such as a familiar shape or icon and colour – such as red for danger).

The design of the dialogue (its structure and management) is also very important to promote ease of use. Important issues include: length of “timeouts”, language used and menu structure.

Although the design of the HMI of vehicles is the domain of the automotive manufacturer, in-vehicle HMI is often supplemented by drivers with the addition of mobile communications and information systems. These may or may not be designed for use while driving and their use can have a significant effect on drivers.

Advice to Practitioners

Choice of HMI is a specialist area, and advice from human factors professionals is recommended. The HMI should be based on:

• the intended user group (See Diversity of User Groups)
• the context of use (See Context of ITS Use)
• the tasks to be completed and consequences or errors (See Human Tasks and Error Analysis)
• recognising that what works well when the HMI can be used as a single focus of attention may not work well in the “dual task paradigm” (See Context of ITS Use)

There may be a trade-off between ease of learning and ease of use.

Try it with new users – what is their experience? (See Piloting, Feedback and Monitoring)

Human Factors and Road Signage

Vehicle and Driver-Related

Engaging Users through ITS in Data Collection

Context of ITS Use

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 b 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.

Any measurements of usability (user-friendliness) should be carried out in an appropriate context and include a detailed description of that context.

User Context

Task Context

Technological Context

Organisational Context

Social Context

Physical Environmental Context

The 5W+H Checklist

Advice to Practitioners

Always investigate and document the context of use when designing how users interact with Intelligent Transport Systems as ITS need to be designed for specific contexts.

The following five steps are recommended in specifying the context of use for an ITS (product or service):

• describe the Intelligent Transport System and service
• identify the users and other stakeholders
• describe the context of use
• identify important factors affecting the usability of the ITS and concentrate on the “worst case” context rather than benign situations
• decide on requirements or test conditions

Use Checklists and Diagrams

Checklists can be helpful in describing the context of use. Diagrams can also be helpful. The example in the figure below concerns a driver’s use of an in-vehicle ITS.

Context of ITS use within a vehicle by a driver

Try it in Practice

Restrict Context of Use as Necessary

Support to Users

ITS can support users with information and warnings, and can provide various levels of assistance and automation depending on the service.

The human factors issues associated with these different “levels” of interaction are very different and these may have safety implications. Appreciating the key differences and understanding these issues can help the Road Operator to purchase, design and implement appropriate ITS.

The manner in which ITS services are implemented impacts on their ease of use. This greatly affects user acceptance and the degree of behaviour adaptation, as well as overall safety.

One characteristic of ITS is the level of support provided to the user. Using a five-fold classification, example ITS services are shown here:

• information (about a vehicle or the transport system) – for example, a road map or bus timetable
• advice (specific timely information which does not require an immediate time-critical response from the user) – such as an alternate route that avoids congestion
• warning (specific warnings which do require an immediate time-critical response from the user) – such as lane departure warning or vehicle approaching too close to workzone
• assistance (service to automate part of the user’s task under supervision from the user) – such as Adaptive Cruise Control and VMS plan generation
• vehicle control and automation – including collision mitigation, automated platoon driving, automated lane opening/closure

Levels of Automation in Vehicles

Implications for Human Factors

The human factors and safety issues are different for each different level of interaction or level of automation. The design of the HMI must be different for the different levels – in order to best support the user and promote safety in the transport environment.

The figure below provides a summary of the levels of support and HMI implications in the context of vehicles and driving. For further information see Driver Support

Levels of ITS support to the driver

Advice to Practitioners

It is important to identify the level of support that ITS is providing to users. Task and error analysis may be useful. (See Human Tasks and Errors)

Secondly, it should be appreciated that the human factors and safety issues are different for each different level of support – so the design of the human machine interaction (HMI) must be different for the different levels, to best support the user and promote safety in the transport environment. (See Road Safety)

Information and Advice

Warnings

Assistance and Automation

Automation and Human Factors

In the modern world, many processes are automated by machines. Whereas people would previously have been responsible for completing each individual process, the role of the person is typically now limited more to monitoring the machines that undertake those processes. The idea is that machines are employed to do the simple, repetitive tasks at great speed – and a person is on hand to sort out any problems that might occur. In theory this plays to the strengths of both machines and people. The (so called) “irony of automation” is that the human takes on the role of system monitor – and that this role is far from suitable for human attributes.

Why Automate?

People and machines are good and bad at different tasks and roles. The figure below highlights some of the key distinctions:

Roles Suited to Humans and Machines

In ITS the role of automation is often to remove from the user responsibility for tasks that people generally find difficult or mundane – so they can concentrate better on tasks which either cannot be automated or cannot be automated efficiently and effectively.

Problems with Automation

Advice for Practitioners

Automation can have negative consequences and designers will need to consider the possible implications of automation before introducing it into any design. Correct use of automation can prove extremely useful to the operator and to overall system performance. Transport systems and networks are often highly complex and ITS offers the potential to use technology to simplify aspects of these systems from the perspective of the user. Automation can be a useful means of reducing the overall complexity of the system so that individuals are able to focus more clearly on the most important processes. The key requirements in order to be able to do this effectively and safely are effective task allocation and the avoidance of overload or under-load.

effective task allocation

Transport Systems Context

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 endeavour (or activity) with the correct amounts of its necessary components at the time and at the 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 travellers. They engage in trip planning 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 organise 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.

Advice to Practitioners

When technical systems such as ITS are put into a societal context, complexity emerges. The systems have to be designed in a cost-effective, efficient, safe and environmentally acceptable way. These objectives require design methods which make it possible to cope with system complexity.

ITS usually involves several human decision makers – and all the decision-making processes which require information about the ITS environment must be considered. Integration of network operations, transport processes and stakeholder perspectives is necessary. Analysis, design and evaluation of this complexity, and its impact on modern solutions for transport services, must be performed adequately.

Activities (or processes) in society which make use of a technical infrastructure and communications networks will be influenced by a large number of decision-makers and stakeholders. They are often geographically dispersed, have contradictory goals and act with different time horizons. In consequence, description and analysis of the interaction between technology and people in a specific class of systems can become so complex that specialist tools and techniques may be required. Expert help should be sought where necessary.

Three highly interrelated perspectives - networks, processes and stakeholders - can be usefully identified and, if combined in an operational way, can be helpful to the analysis, design and evaluation of ITS solutions.

Network perspective

process perspective

stakeholder perspective

Why Involve Users?

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. (See Diversity of Users)

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.

Advice to Practitioners

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.

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. (See Human Performance)

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.

User Centred Design

User centred design (UCD) is a well-tried methodology that puts users at the heart of the design process, and is highly recommended for developing ITS products and services that must be simple and straightforward to use. It is a multi-stage problem-solving process whereby designers of ITS analyse how users are likely to use a product or service – but also tests their assumptions through analysing actual user behaviour in the real world.

A key part of UCD is the identification and analysis of users’ needs. These have to be completely and clearly identified (even if they are conflicting) in order to help identify the trade-offs that often need to happen in the design process.

User-centred design (UCD) aims to optimise a product or service around how users can, want, or need to use the product or service – rather than forcing users to change their behaviour in order to meet their needs.

The ISO 9241-210 (2010) standard describes six key principles of UCD:

• the design is based upon an explicit understanding of users, tasks and environments
• users are involved throughout design and development
• the design is driven and refined by user-centred evaluation
• the process is iterative
• the design addresses the whole user experience
• the design team includes multidisciplinary skills and perspectives

As shown in the figure below the main, but iterative, steps in UCD are Plan, Research, Design, Adapt, and Measure.

Steps in User Centred Design

A key part of the research stage for UCD is collecting and analysing user needs. Quality models such as ISO/IEC 25010 provide a framework for this activity.

Users include the following:

• primary users who interact with the ITS to achieve the primary goals
• secondary users who provide support (for example data providers and system managers or administrators)
• indirect users who are affected by the ITS

Some important questions related to user needs are:

• who are the users?
• what are the users’ tasks and goals?
• what functions do the users need?
• what are the users’ experience levels with similar systems?
• what information might the users need, and in what form do they need it?
• how do users think the system should work?
• what are the extreme environments?
• is the user multitasking?
• does the user have particular requirements of the interface?

User needs can also be defined according to the following list of attributes for an ITS:

• effectiveness
• efficiency
• satisfaction (usefulness, trust, pleasure, comfort)
• freedom from risk (safety, health, environmental, economic)
• reliability
• security
• coverage of a range of contexts (coverage, flexibility)
• learnability
• accessibility

Advice to Practitioners

The main advice is to adopt a user-centred design (UCD) process that begins with collecting and analysing user needs. The design of the ITS product or service can then be undertaken making use of all the advice and guidance provided below. The product or service should then be trialled and developed with actual users, taking account of their feedback. (See Piloting, feedback and monitoring)

Techniques for Collecting User Needs

Undertaking User Needs Analysis

Human Tasks and Errors

Analysis of tasks and errors is a hugely important activity for anyone seeking to understand how users interact with ITS or wishing to create the environment in which the interaction will take place – between users or between a user and an object/activity. Task analysis requires understanding and documenting all aspects of an activity in order to create or understand processes that are effective, practical and useful. Typically a task analysis is used to identify gaps in the knowledge or understanding of a process. Alternatively it may be used to highlight inefficiencies or safety-critical elements. In both cases the task analysis provides a tool with which to perform a secondary function – usually design-related. Error analysis is a specific extension of a task analysis and is about probing the activities identified by the task analysis – to determine how and why a user might make an error, so that the potential error can be designed out or the consequences can be mitigated.

Task analysis

The person conducting a task analysis first has to identify the overall task or activity to be analysed, and then to define the scope of the analysis. For example, it may be that they wish to examine the tasks performed by an operator at a monitoring station, but are only interested in what the operator does when they are seated at an active station. This would be the defined scope of the analysis.

Within this overall activity all the key subtasks that make up the overall activity must be identified. It is up to the person undertaking the analysis to decide what represents a useful and meaningful division of subtasks. This is something that comes partly from experience of performing such analyses and partly from understanding of the activity being analysed. Crucially, each subtask should have a definable start and end point.

With the subtasks created, the investigator then defines a series of rules and conditions which govern how each subtask is performed. For example, it may be that the monitoring station operator has at their workstation a series of monitoring systems (subtasks) where each subtask is distinct and separate – and it may be that the operator must perform the subtasks in a pre-defined sequence. The investigator must specify the rules governing how each subtask relates to the others. For example: “perform subtasks A and B alternately. At any time, perform subtask C – as and when required”.

The investigator would then look at each subtask in turn and perform a similar process to the process described above. The subtasks that make up subtask A would be identified and the rules governing their commission defined. This process of hierarchical subdivision continues until either there is no more meaningful division of tasks that can be performed – or the investigator has reached a level of understanding useful enough to inform the design.

Purpose of analysis

Advice for Practitioners

Before conducting a task or error analysis it is important to define what the output of the analysis is to be used for, as this will influence how the analysis is performed. For example, it may be that the investigator is only be interested in particular subtasks and activities – or that a particular level of detail is required, below which the analysis is useless and beyond which it is simply a waste of time and effort. Knowing the level of detail required is a key parameter as without this cut-off point, the analysis could go on almost indefinitely. A basic task analysis is a useful way for anyone to gain a clearer picture of any working environment. For more detailed analyses or situations where the task analysis is to provide the foundation for a larger set of activities, it is advisable to acquire the services of experienced practitioners.

task analysis

complimentary error analysis

Piloting, Feedback and Monitoring

Before introducing ITS or any new technology, or undertaking extensive field trials, it is invariably beneficial to pilot the system or service with a small group of users before more widespread deployment. This approach is part of User Centred Design (See User Centred Design) and allows any problems to be addressed, avoiding embarrassing and expensive mistakes.

Encouraging feedback from users and providing suitable mechanisms for monitoring use of ITS allows those responsible for its operation to better understand the experience of both occasional and frequent users. This may show how use of the ITS is changing over time (because of changes in other parts of the transport system or the environment) and provides advanced information about necessary modifications, including possibly re-design of the ITS (See Evaluation)

Piloting

Monitoring

Feedback

Measuring Human Performance

Overall evaluation of ITS products and services is an important activity because the performance of the road user will depend crucially on the usability of the ITS. A benefit of improving the ease and efficiency of ITS technology, is increased user satisfaction. This can provide business advantages, particularly when users have a choice of ITS products or services. Poor usability of ITS, such as a poor user interface, or inadequate and misleading dynamic signage, may have safety implications in the road environment. Good usability will help to manage and predict road user behaviour and so help increase road network performance. For all these reasons, the performance of ITS in terms of its usability needs to be measured. (See Evaluation)

Measurement of Usability

Usability measurement requires assessment of the effectiveness, efficiency and satisfaction with which representative users carry out representative tasks in representative environments. This requires decisions to be made on the following key points:

• what environment (context of use) is relevant
• which metrics (measures) will be taken
• what tools are required – such as stop-watch, questionnaire, driving simulator
• what method will be used to make the measurements

Steps in performance measurement:

• define the ITS to be tested (this may be a system in-use or a prototype/pilot)
• decide what type of user will be considered (first time/infrequent or experienced user)
• define other aspects of the typical context of use (See Context of Use)
• decide on the particular functions or aspects of the ITS to be evaluated and the context for the evaluation
• decide on the usability goals to be tested and their relative importance
• prepare a plan for measuring a set of metrics (that assess the usability goals)
• carry out the user tests
• analyse the test data to derive and interpret the metrics
• record the results and draw conclusions

The process of measuring human performance when the driver is interacting with ITS (particularly when using information and communication devices) can yield safety benefits – although there are challenges with this form of human performance measurement in this context.

Safety of Drivers’ ITS Interaction

Deciding on Goals and Metrics

Conducting Performance Testing

Data Analysis and Conclusions

Design of ITS for Vehicles

With the growth in deployment of ITS and the information and communication options available to drivers, the modern car has been described as ‘a SmartPhone on wheels’. Information may be presented both in-vehicle and externally and needs to be relevant, timely, consistent and useful. The challenge for designers – supported by standards and guidelines – is to provide the information and services demanded by drivers that are usable without causing unsafe distraction and overload. In-vehicle human factors have a number of important consequences for Road Network Operations, in particular:

• when a Traffic Control Centre exchanges information with vehicles and drivers through Cooperative ITS
• if the network operations include vehicle fleets equipped with information and communication systems, such as mobile safety patrols
• to promote safer travel on their roads
• when the objective is to achieve greater compliance with traffic laws

As well as information and entertainment, in-vehicle sensor, communications and processing technology can assist drivers by providing advice and warnings concerning the vehicle’s immediate environment. These warnings have to be perceived, understood as relevant, and acted upon appropriately if they are to be effective. Guidelines in this area are now emerging.

Driver error is consistently identified as a contributory factor in over 90% of vehicle crashes. Better design of the driver interface has the potential to keep the driver “in-the-loop” whilst increasing safety. Additionally, many vehicles now include ITS that provide automation of specific elements of the driving task. Systems can even be designed to intervene in vehicle control to avoid or mitigate an impending collision. Nevertheless, usability issues around how the vehicle ‘feels’ and responds, and how control is partitioned between the vehicle and the driver, are crucial to achieving driver trust, acceptance and adoption. The RESPONSE Code of Practice provides at least some guidelines in this emerging area and further research is underway. 

It is good practice for new ITS vehicle applications or in-vehicle information and communication products to be simulated and trialled with users to understand better the interaction between them and any consequences

There are many international regulations on vehicle design and many standards and guidelines relating to information and communication systems (ICT) and warning and assistance systems.

Vehicle Regulations

information and communication systems

Warning and Assistance Systems

Warning Guidelines

Guidelines on establishing requirements for high-priority warning signals have been under development for more than five years by the UNECE/WP29/ITS Informal Group (Warning Guidelines 2011). There has also been work in standardisation groups to identify how to prioritise warnings when multiple messages need to be presented – and one ‘Technical specification’ (TS) has been produced:

• ISO/TS 16951: Road Vehicles – Ergonomic aspects of transport information and control systems – Procedures for determining priority of on-board messages presented to drivers

In addition, two Technical Reports are relevant that contain a mixture of general guidance information (where supported by technical consensus) and discussion of areas for further research:

• ISO/PDTR 16352: Road Vehicles – Ergonomic aspects of transport information and control systems – MMI of warning systems in vehicles
• ISO/PDTR 12204: Road Vehicles – Ergonomic aspects of transport information and control systems – Introduction to integrating safety critical and time critical warning signals

Guidelines for Driver Assistance Systems

To help promote driver acceptance of Advanced Driver Assistance Systems (ADAS), a key issue is ensuring controllability. This has been addressed through guidelines. Controllability is determined by:

• the possibility, and the driver’s capability, to perceive the criticality of a situation
• the driver’s capability to decide on appropriate countermeasures (such as overriding or switching off the system)
• the driver’s ability to perform any chosen countermeasures (taking account of the driver’s reaction time, sensory-motor speed and accuracy)

Drivers will expect controllability to exist in all their interactions with assistance systems:

• during normal use within system limits
• at and beyond system limits
• during and after system failures

The European project RESPONSE, has developed a Code of Practice for defining, designing and validating ADAS. The Code (outlined in the figure below)  describes current procedures used by the vehicle industry to develop safe ADAS with particular emphasis on the human factors requirements for ‘controllability’.

Overview of the RESPONSE code of practice for design of in-vehicle information and assistance systems

Another European project, ADVISORS has tried to integrate the RESPONSE Code within a wider framework of user-centred design taking account of the usability of information, warning and assistance systems. The Intelligent Transport Systems (IHRA-ITS) Working Group of the International Harmonized Research Activities – is developing a set of high-level principles for the design of driver assistance systems (IHRA-ITS 2012).

Infrastructure

Human factors standards affect the design of ITS road infrastructure. Signage potentially has a significant impact, particularly on drivers, and there is a broad range of new and developing signage systems involving ITS. The most widely deployed signs, called Dynamic Message Signs (DMS), also known as Variable Message Signs (VMS) and Changeable Message Signs, (CMS) have developed in terms of technology. Experience of their use has been distilled into guidelines on their design and operation.

Two other areas where Road Operators may be involved in close consideration of human factors are the design of tunnels and control rooms. Both pose important safety and human factors issues for which human factors guidelines have been developed.

ITS Signage

Tunnels

Traffic Control Centre

Vulnerable Road Users

Vulnerable road users (VRU) are those users who are at great risk because of insufficient physical protection or because of relative high speed difference with potential conflicting modes (Vulnerable road users diagnose of design and operational safety problems and potential countermeasures, PIARC, 2016).

Through this definition a specific attention is given to four main categories of road users, i.e:

• pedestrians
• cyclists
• riders of powered two-wheelers
• light duty farm vehicles or animal drawn vehicles

Although there are few standards and guidelines concerning human factors of ITS for these groups of people, vulnerable road users are likely to benefit from a range of safety-enhancing ITS and supporting standards and guidelines on their design and implementation. (See Road Safety)

Advice for Practitioners

Disabled Road Users

Older Road Users

Pedestrians and Cyclists

Powered Two Wheelers and Similar Vehicles