Design

The Design phase covers all aspects of the detailed technical design and how the system will be embedded in the organization. At the end of the Design phase, all technical issues should be fully determined. A reasonable estimate of implementation and ongoing costs should have been made and approved. It is quite possible that the initial Functional Requirements will be revised as the design process increases the understanding of what can be achieved, or in light of the emerging cost estimates. The Guidance presents 7 steps in the Design phase:

What Technology will it need?
What Platform will it need?
What Data will it need?
What other resources will it need?
What else can the technology, data and resources be used for?
How will the business processes need to change to take full advantage?
What will be the total cost?

At the end of the Design phase, the ITS project should be ready to go to procurement. This may still require a final corporate decision to proceed with the proposed project and/or approval of the associated funding.

6 What technology will it need?

Themes: On-vehicle; In stations; On highway; Back-office; Communications

The Technology Concept will have determined the broad approach. The next step is to determine the specific technology solution. This includes the systems to be used; the device types; where they are located; the distribution of function and intelligence; and how the various elements communicate with each other. The output from this step is selection and a detailed description of the ITS technologies to be deployed.

For most entities implementing ITS, especially those doing so for the first time, identifying the needed/suitable technology will draw heavily on current practices within the industry. While some adaptation will always be required, it is normal to identify what other successful Operators or Authorities are using, and to take this as a reference point. This is a safe approach if steps 1 to 5 have already been taken and if there are resulting well-developed Functional Requirements and Technology concept based on an analysis of goals and needs. The technologies to be used need to be considered from four perspectives:

System/sub-system: The functions performed by the ITS system, e.g. Operations Management, Fare Collection, Surveillance, Precision Docking
Location: Where the technology is located, e.g. on vehicles, at the control centre, at bus-stops
Technology type: The nature of the device, e.g. customer-facing equipment, sensors, data processor, communications device, data storage units
Role: Generate data (e.g. sensor), process data (e. g. card reader), display (e.g. at-stop information display), analyze data (e.g. dispatch support), optimize resources (e.g. scheduling)

Many devices have multiple embedded components and they may perform multiple functions. For example, a suitable GPS-enabled mobile phone may now be sufficient to support AVM functions, where previously it would have required a radio, a GPS unit, a driver interface/console and an integrating processor. Similarly, individual devices may now perform multiple functions, or a suitable combination of two devices and shared processing may eliminate the need for a third device.

7 What platform will it need?

Themes: System Architecture; Communications

An ITS System consists of many interconnected devices, software and information. At a minimum, they need to be able to connect to each other and exchange information. The ITS systems and sub-systems may need to be able to perform tasks together. In many cases, the new ITS systems will need to interface with the existing or legacy systems of the transport entities, or interface with external systems such as the traffic control centre.

Correct interfacing of systems can only occur if it has been properly planned for. This is one of the most underestimated aspects of ITS systems. It is all-too-often ignored or given minimal attention until procurement or even operation is well advanced, and then problems start to emerge (e.g. during installation). By this stage, it can be very costly and/or time-consuming to resolve. Sometimes, fixing the problems (or even admitting to them) is considered so much trouble that the consequences are left to someone else to solve later and the problems are lived with until they can no longer be ignored.

Examples of avoidable problems (which are often encountered in ITS deployments) are:

Problems with wiring and installation of different ITS equipment on buses, due to a lack of a comprehensive wiring and communication diagram
Inability to connect new devices to existing ones because there are not enough physical connector points, and/or the software in the existing devices cannot recognize the new ones
Inability to interface different ITS systems because the data elements are defined differently and use different coding. A comprehensive data model would have avoided this.

The main ITS “platform” concept elements are:

The System Architecture, which provides a ‘blueprint’ of all the ITS systems and how they relate to each other
The Communications Architecture, which defines both how the systems and devices talk to each other, and the content of the information to be exchanged
The Data Model, which provides a consistent definition of all data to be used in the transport entity, so that each (sub-)system describes the same things in the same way
Interfaces, which define the physical connectivity between devices and the protocols used for information exchange
Standards, which ensure that both Vendors and Clients develop hardware and software in a common way, usually based on international industry consensus

The ITS deployment team will determine the appropriate platform elements. Ideally, they will select international norms that reflect industry practice, and they will select relevant elements of such norms. This can lead to significant benefits in terms of robustness of design, and ability to source different vendors for different ITS (sub-) systems without compromising the ability to interface the (sub-) systems.

It should always be remembered that all reputable suppliers are used to working with international norms and to interfacing with the equipment of other suppliers. It is usually no additional burden for suppliers to conform with standards or to work with other suppliers. In most cases, it only becomes a problem when the Client fails to provide a common framework within which to work, or favours one supplier over the others.

8 What data will it need?

Themes: Data from technology; Existing MIS data; Other data sources

Having defined the platform, it is necessary to define the specific data requirements associated with the ITS systems. The application software of ITS systems is highly dependent on data. It is also the task of many ITS applications to generate, collect, store or transfer data. The data requirements will come into a number of broad categories:

Support data which the ITS system needs to carry out its functions (background data, configuration data, daily assignment data)
Real-time or event/transaction-specific data which the ITS requires when it is performing a specific function. It may generate this data itself, or receive it from another device or system
Data which the ITS system should pass to devices, both for immediate and downstream use

This is a technical task that requires expertise and experience. There is considerable scope for transferring and re-using materials from industry good practice and from other successful ITS systems. Nonetheless, it is very important that any such replication is carefully adapted to the needs of the deployment site, and is fully compatible with the Functional Specifications and the site Technical Design.

9 What other resources will it need?

Themes: Infrastructure; Back-office; Human resource

Occasionally, an ITS system may be free-standing or can be plugged into existing ITS systems without any other requirements. However, most ITS systems are not independent and they require supporting infrastructure and back-office support. Three particular aspects need to be considered:

The ITS system may need to share some of the IT platform of the host organization (e.g. servers, communications, operating systems). Platform capacity may need to be increased and additional user licenses purchased.
The ITS system may need to interface with the existing administrative and/or management IT systems. System software amendments may be needed.
The ITS systems may also need non-ITS supporting technology including communications, servers, back-office PCs, printers, office software and security software.

These requirements need to be identified, specified and budgeted for as part of the ITS system design and planning.

10 What else can the technology, data and resources be used for?

Themes: Technical concepts; Options analysis; Budget setting

ITS systems, and the data they generate, almost always have the potential to deliver more than they were originally designed to do. It is very important for organizations implementing ITS to be aware of this and to learn how to exploit the opportunities that arise.

Opportunities tend to arise at specific phases - during the design, after implementation, and when new devices or more advanced technologies (e.g., distributed processing) are added. Quite often, the greatest benefit can be gained by other departments of the transport operator, which perhaps did not really understand the ITS at the beginning or whose needs were not included in the analysis. This is why it is essential to include representatives from all parts of the organization in the design phase.

It is advisable to establish a culture of continuous development, which seeks to advance the usefulness, efficiency and productivity of the ITS investments. Many enhancements require only modest investment, and others can actually make cost savings within the organizations. In cases where an enhancement would be expensive or difficult to implement as a stand-alone action, it could be included in a later general upgrade or renewal of the ITS.

11 How will the business processes need to change to take full advantage?

Themes: Functional identification; Business processes review; Implementation plan

The most effective ITS deployment occurs when organizational change, business process change, and ITS deployment are designed together. In these cases, the organizational change leads, and the ITS is designed as a core enabler of the new processes. In other cases, gradual organizational and process changes occur after the ITS deployment, as the possibilities are understood.

Experience in a number of cities has shown that this can be an evolutionary process. At the time of the first ITS implementation, many transport entities are not able to fully envision or appreciate the potential of the ITS or they do not know how to harness it. Following a learning period, the potential can be exploited in subsequent deployments or when they are renewing older systems. The case studies of Zurich, Prince William County and Dublin illustrate this developmental path.

Change to organizations inevitably occurs when ITS systems are implemented. The greatest advantage is achieved when ITS is implemented because the organization seeks to change – and hence the organizational change actually drives the process – compared to some organizations where change is a reaction to a new technology.

12 What will be the total cost?

Themes: ITS application; Support technology; Other resources; Operating costs

The cost of the ITS system needs to be estimated at various stages in the specification and design process. The initial estimate is usually an order of magnitude costing, based on typical costs in the industry. As the design becomes more specific to the host environment, a more accurate estimate of costs can be made. The costs should be considered from three perspectives:

Initial investment, including both equipment costs and the cost of installation/deployment
Ongoing operating costs
“Whole of life” costs, including upgrades and added functionality It is important to make an accurate assessment of these costs.

Failure to do so could lead to serious problems at the procurement stage if the price of the most suitable bids turn out to be well in excess of the available budget. This could lead to cancellation of the project, a major downgrading of the functionality, or a reduced number of locations where ITS devices are deployed.

The three most common causes of cost escalation are:

Software development turns out to be far more complex (and hence more costly) than originally expected
“Mission creep” as more and more functions and devices get added to the ITS project
Fascination with technology (on the part of the leaders or of the technologists), so that more advanced and costly equipment is specified than was really needed to do the job

It is not necessarily a problem if the actual project becomes more expensive than the original estimate, especially as the added-value may also increase. The important point is that any cost escalation is known to the decision-makers, can be justified, and the extra cost is provided for. A useful source of published information on costs for ITS is published by the RITA (Research and Innovative Technology Administration) unit at the US Department of Transportation. Information on public transport is mostly contained in the Transit Management section. The website contains both full examples and unit costs, as well as relevant contextual information for the detailed cases. In some instances, information is also given for implementation and lifecycle costs.