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 right 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?