What type of ITS application?


Themes: Technical concepts; Options analysis; Budget setting; Pre-feasibility

Developing the technical approach for the ITS    

As a broad generalisation, the concept and framework of the ITS system emerges in one of the following ways:

  • An ITS concept, or range of concepts, is developed in response to a formal analysis of requirements
  • The organisation already has some ITS, and develops new ITS applications and services around the original system(s)
  • The organisational already has some ITS but, following a detailed assessment, decides to migrate to a new concept or framework for the future expansion
  • A decision is taken to implement a specific ITS solution (or set of solutions) without prior analysis, e.g. based on a site visit to another location, awareness that it is industry good practice, or in response to promotions by ITS system vendors

Each of the first three scenarios is a safe way to proceed. The project proposer has carried out an analysis of user requirements and has derived (outline) functional specifications, and may also have prior experience of specifying, deploying and using ITS.

Dangers of proceeding to ITS design without sufficient analysis of requirements

By contrast, the last scenario - implementation with insufficient analysis – carries high risks for the organisation. It is strongly recommended not to proceed further with design or procurement until a sufficient user requirements and functional specification process has been undertaken.

The ‘less bad’ risk is that the products do not meet their expectations and that they merely waste money and time. The more serious risk is that the transport organisations adjust their processes, staffing levels, procedures etc. in anticipation of the new system(s), and then find either that it does not perform as they require or that the technology/organisation interface is problematic. This may lead to level/quality of service worse than when they started, and reduced capacity to deliver or correct the services manually.

This scenario is highlighted because it is surprisingly common in the urban passenger transport sector. It should be stressed that the intention to implement ITS may well be correct, and indeed the broad ITS concept may also be reasonable. It is the process (or more precisely, the lack thereof) that is unsound.

More often, the failure occurs because (a) the role and specific requirements of the ITS has not been thought through; (b) the interface between the technology and the organisation/operating procedures has not been well considered; (c) too much reliance has been placed on “the technology will solve all things”; (d) insufficient attention has been given to whether/how the ITS systems can get the information they need to perform; or (e) perfectly suitable technology options have been eliminated too early (e.g. building the specifications around a particular vendor’s products).

With this warning clearly made, from this point onward the Guidelines are directed to users who have carried out a reasonable level of analysis of user requirements and functional specifications.  

Developing a Technical Concept for the ITS project

Development of Technical Concepts will almost certainly be an iterative process linked to the stages described below.

The most important advice at this stage is to keep an open mind, and to avoid predetermining the outcome – e.g. due to personal preferences, the intent to use specific vendors or products, determination to use legacy systems, etc. There should not be inherent preference (overt or implied) for specific solutions or vendors. There may be legitimate reasons to prefer local vendors or to retain legacy systems, but these should be explicit criteria in the selection process, and should not bias the option generation phase.

The Technical Concept phase should generate a number of options.

It should begin with an open, creative exercise to explore a wide range of options, and should be wiling to consider new technology approaches. The willingness to explore is important because of:

  • the rapid pace of change in technologies and emergence of new/enhanced devices and applications
  • the constant change in costs and processing capacity of components, which open new possibilities
  • the very wide range of solutions that are not known in the passenger transport sector but are widely deployed and proven in other sectors
  • the advantage in resolving different viewpoints at this early stage

This activity needs to involve the main stakeholders, and to involve people from different disciplines – business management, operations management, dispatchers, drivers, customer service, technologists, IT/administration. On one hand, this represents the different perspectives of the organisation. On the other, it helps each ‘specialist’ layer to understand the needs and strengths of the other. Probably most importantly, it allows the management and operational layers to better understand the technologies (of which they may have little prior experience), and the technologists to better understand the passenger transport world, the tasks to be performed, and the real-world challenges.

Factors influencing the options for ITS Technical Concept

Development of the Technology Concept options should be strongly driven by the User Requirements and Functional Specification (all participants should be fully briefed on these). While the process should be creative, the creativity must be directed to achieving the requirements at optimal budget and optimal risk, not to technical innovation for its own sake.

The Technology Concepts are likely to be based on:

  • Current practice in the urban passenger transport sector. This provides a wide range of working models, from which performance, cost, and risk information are readily available
  • ITS and communication vendor proposals
  • The degree of disaggregation within the operator sector (e.g. number of operating companies, number of locations)
  • The number of installation locations for devices (vehicles, bus stops, conductors, terminals, …)
  • The available means of communication and data transfer
  • Available internal and background (e.g. GIS/mapping) data
  • Available IT support
  • Investment costs
  • Operational costs (communications, maintenance, …)
  • Concept risk
  • Operational, performance risk
  • Future requirements for expansion (in function, scale or geographic area) and for integration

High-level ITS Technical Concept Options

At the generic level, there are a number of fundamental concept options (which in turn have many variants):

  • “Infrastructure heavy” using dedicated support platforms. This would typically involve a significant degree of in-vehicle equipment, a significant amount of off-vehicle equipment, dedicated communications infrastructure and extensive sector-specific software and applications
  • “Infrastructure heavy” using generic or open support platforms. This would typically involve a significant degree of in-vehicle and off-vehicles equipment, use 3rd party communications infrastructure (e.g. GSM/GPRS), utilise public/3rd party facilities where possible (e.g. GIS/mapping, internet, general payment and clearing services), and utilise sector-specific software and applications only where necessary
  • “Infrastructure light” with extensive exploitation of data. This would typically involve a moderate level of in-vehicle equipment (e.g. location device and voice/data communication), moderate/low level of off-vehicle equipment, software and applications which utilise the data for real-time and post-event analysis and integrate with off-the-shelf IT packages.
  • “Infrastructure minimal”. This would typically involve inexpensive in-vehicle equipment (GPS-enabled mobile phones), public communications channels (GSM, GPRS), and use inexpensive software (e.g. "Apps") to provide practical operations and administration functions. Although a minimalist technology approach, it may still support creative and pragmatic functionality

The generic options considered are likely to reflect prior experience with ITS, organisational and societal IT culture and capacity, the corporate level and concentration of the Operators, and financing capacity.

The generic options (possibly with variants) will make an initial identification of the type of devices, their location, functionality, and interaction/integration. It will provide an initial identification of the principal applications and analytical functions, the means of communication and main information exchanges, the data generators and stores, etc.

Analysis of Technical Concept Options

A typical Options Analysis would consist of at least two phases, the first of which fits within this concept phase, the second occurring after a further phase of developing detailed technology options and some initial design:

  • Analysis of Technology Concept Options: This deals with the generic level (see options above), and sets the broad direction to be taken. It provides the roadmap for the ITS development, provides a coherent reference framework for the more detailed design of the individual system/sub-system elements, and for this level of individual design gives an indication of the other equipment, applications and data that can be availed of (or not, as the case may be). It facilitates initial costings and budget.
  • Analysis of Detailed Technology Options: This occurs at a later stage, and following more detailed investigation and outline design or preparation of initial technical specifications. It should be possible to separately analyse options of individual systems or subsystems, devices and/or applications, since they will work within the reference framework. Nonetheless, the integration and interface of the various elements must always be checked and assured.

In exceptional cases, it may be necessary to revisit the Technology Concept decision following the more detailed design. For example, despite reasonable initial investigation, it may emerge that a fundamental enabling technology or platform will not be available or suitable, or that the costs of the equipment and/or software will exceed available budget.

In such cases, it is better to revisit the Concept options rather than press ahead with a design that cannot be implemented.  That said, it is worth exploring whether there are other technical means to achieve most of the objectives without sacrificing too any of the essential functionality of the ITS system.

Options Analysis - a multi-step process

The Option Analysis would normally be performed in a multi-step process, which would include:

  • Develop the Options to be assessed
  • Develop the assessment framework, criteria and their relative weighs, with clear separation of objective and subjective measures.
  • The framework is likely to include criteria such as:
    • Functionality
    • Expected functional and technical performance
    • Additive effects and integration
    • Cost (initial and ongoing, lifecycle)
    • Ability to build on existing infrastructures, devices, applications, internal capacity, …
    • Technical/capacity constraints to implementation
    • Expandability, in terms of functions, scale and geographic area
    • Future integration and interoperability requirements
    • Deployment/migration path
    • Constraints
  • Ranking of the options and/or their variants
  • Risk assessment
  • Finalisation of the choice of Technology Concept.

One analysis outcome could be to commence at one level, with indicative migration path to a higher level later - e.g.

  • following some years of ITS experience and better understanding of how to exploit ITS systems
  • when a new enabling technology becomes available (GSM coverage, GIS/mapping for the area)
  • when affordability thresholds are  passed (reduced capital or operating cost, increased industry financing capacity)
  • when a specified critical mass of applications is implemented (e.g. migration to smart card ticketing)

Preliminary Budget estimation for the ITS project

At this stage, a preliminary Budget Setting activity can be performed. This should identify, by system/sub-system:

  • In-vehicle device capital costs
  • Terminal, bus-stop and operational location device capital costs
  • Control centre, depot and other central capital costs
  • Communications infrastructure capital costs (wireless, landline, fibre optic)
  • Data and IT platform capital costs
  • Procurement costs
  • Installation and deployment costs, including training
  • Operations costs of the ITS system
  • Ongoing costs of communications
  • Device spare parts and maintenance costs
  • Data, ITS applications and IT applications operation, support and maintenance, including licence costs

Ongoing costs of the ITS, including management of AVL Control Centre, Dispatching, traveller information, can be done either by:

  • Total costing, based on foreseen cost items and estimated unit costs
  • Marginal costing, comparing the new operational scenario to the existing one

Order of magnitude costing is sufficient at this stage, since the primary purposes are to:

  • Identify the scale of initial and ongoing funding required
  • Seek outline approval, at least to proceed with project design
  • Identify where the costs arise, and who must bear them
  • Identify areas where the detailed design should seek opportunities to reduce cost, either in the individual system/subsystem design, or through synergies
  • Identify items which may need to deferred to a later stage, due to funding availability

Discuss the scope and cost of the ITS project with key Stakeholders

It is strongly recommended that at this stage the scope, functionality, expected benefits and preliminary costs are shared with the relevant stakeholders. Consensus needs to be formed on both the direction of the design, and the scale of the funding to be committed.

There is little point in proceeding to design ITS schemes that will not be approved because key stakeholders do not support it or cannot see sufficient benefit to justify the management effort, implementation disruption, or required budget.

If the desired ITS scheme cannot be fully funded, it is essential to identify it at this stage. It is far better and safer to devise a less costly ITS approach that has been explicitly designed for future enhancement / upscaling, than to try to scale back higher functionality devices and / or applications when insufficient budget is available.

You are here Guidance Planning What type of ITS application?