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.