Systems engineering is an inter-disciplinary approach to the design and management of large and/or complex engineering projects throughout all stages of their life cycle from the very start to the very end. Usually the project begins with a "vision" describing in general terms what the project is expected to achieve and it ends when all the engineering tasks in the project have been completed and customer acceptance has been achieved. Sometimes a project is completed by an in-house team, in which case the end will be when what it has provided, has outlived its usefulness and been dismantled. It can be quite difficult to resolve when a large and/or complex engineering project is said to be complete. Using systems engineering mechanisms enables all of the issues to be identified and addressed in a logical – and usually timely manner.
Although there is some dispute about the reliability of published statistics on success and failure rates for IT projects, there is much evidence to suggest a significant number are not successful – with some that are failures, often leading to their cancellation. The definition of failure usually means that they either:
One way of defining ITS is to say that it is the application of Information and Communications Technology (ICT) to transport and – in the context of Road Network Operations – particularly to road transport. It is reasonable to suppose that the success rates of major projects that implement ITS are likely to be similar to that of IT projects unless appropriate measures are taken to minimise the risk of failure.
One of the key elements in the application of the systems engineering methodology is the involvement of all stakeholders so that they can feel part of the ITS implementation. This can be achieved through participation in activities such as defining the vision of the services that ITS will provide – and understanding how the provision of these services can be translated into something that can be implemented, that is created and deployed.
Systems engineering provides mechanisms that enable projects for ITS implementations to be delivered in a way that is:
Meeting each of these delivery targets will help each particular ITS project to reach a successful completion. An important outcome is that success will encourage existing and new stakeholders:
As with any methodology, the use of systems engineering does not provide a total solution. Other factors are the expertise, and creativity of key personnel, the situation knowledge and awareness of the stakeholders and the competence of those actually doing the ITS implementation.
The link below to a lecture by given by Professor Brian Collins, who is a world-class authority on systems engineering, provides a general introduction and overview of the subject and shows how a systems approach has been used to solve some well-known problems in transport. The video clip lasts about 50 minutes and if viewed in its entirety will provide some useful insights into various aspects of deployment that need to be considered when implementing ITS. In responding to questions Professor Collins underlines the importance of including both politicians and the media as stakeholders in ITS implementation.
The development of ITS in Road Network Operations (RNO) can be traced back to the simple systems used to control road traffic about 50 years ago. The control system collected data about traffic flow, processed it and from the results of this processing – output commands to vehicle drivers, as illustrated by the diagram below. The data were collected from sensors that detected the passing of road vehicles, and the output commands were the "red-amber-green" indications from traffic lights.
Figure 1: A very simple ITS implementation
Since those far off days, ITS has evolved to become much larger (supports a wider selection of services) and very much more complex (they needs more and different components). ITS may now:
The advent of cooperative systems (usually shorted to Cooperative-ITS (or C-ITS) and called "connected vehicles" in the USA) brings further complexity that involves sharing of both collected data and the results of data processing, in which vehicles play a more active part. The system shown in the diagram above has expanded to become something similar to that shown below.
Figure 2: A complex modern ITS implementation
This example is typical of many of those being deployed in many places around the world. As the demand for ITS grows, the complexity of each implementation will increase – both in the number of services it provides and the geographic areas that it covers.
System engineering provides mechanisms that help to ensure that ITS projects of this complexity can be successfully implemented. This means they will deliver the functions that stakeholders expect and do so within timescale and budget.
One of the principal mechanisms is the ability to manage project programmes. If the programme can be properly managed then it can be completed on time and within budget.
Systems engineering programmes show the technical or engineering steps that have to be taken from the start of work through to when it is completed. In very simple terms the programme will consist of the following four steps:
These four simple steps can be applied to almost every project that implements ITS, no matter how complex, or not, each project happens to be.
Although many terms are used in systems engineering, two are used more frequently than most of the others. They are system "component" and "communications" and it is important to understand how they are used in this context.
A system "component" is the name given to any constituent part of an ITS implementation created from one or more "bits" of hardware – or a combination of hardware and software – that can be provided as an individual item. Usually, an ITS component provides a particular function, so in many ways it is a "building block" from which ITS implementations are assembled. Sometimes a combined set of components will be called a "sub-system", but depending on what it is, this name could also be applied to a single component.
The term "communications" or sometimes "communications link" is the name given to the mechanism by which data and instructions are transferred between system components, or between a component and another system that is outside the ITS implementation. It can be one or more data transmission media such as physical cables, and/or other less tangible forms of links such as wireless, microwave or infrared. In this context “communications” do not include the means of communication with the people who are the system operators and end users (travellers, drivers and freight shipping managers). These will be provided by specialist system components, such as operator interfaces or variable message displays that provide information to travellers and/or drivers. (See Engagement with ITS)
In the modern world, although most projects to implement ITS follow the four steps highlighted above, each step has become more complex. This is an increasing trend as ITS evolves particularly now that new services which are dependent upon data sharing between them (Cooperative-ITS) are moving from the exclusive province of research and development efforts into actual implementation projects. The steps in the programmes for these projects need to be expanded from the four highlighted above. Use is often made of what is called the systems engineering "V" model. Various descriptions of this will be found in resources, such as systems engineering textbooks. Simplifying some of the terminology found in these resources produces the programme illustrated below.
Figure 3: Diagram of the systems engineering
The first two steps – “Service Descriptions” and “ITS Architecture” – shown on the -hand side of the "V" are considered here. (See What is ITS Architecture?)
More information about the remaining two steps on this side and "Component Design" is provided here. (See Technical or Engineering Development)
All the steps on the -hand side of the "V", which are about testing and integration, are discussed here. (See Integration and Testing)
Some versions of the "V" model include a step called a Concept of Operations, or ConOps. It usually appears in or near the Service Description or ITS Architecture Steps at the top of figure above . The work in both these Steps can provide input to the ConOps, and further detail about this work is covered here. (See What is ITS Architecture?)
In addition to the systems engineering "V" model, other methodologies are also available to manage ITS implementations. These include "Enterprise Architecture" and the Open Group Architecture Framework (TOGAF) which are discussed in the context of ITS architecture. (See What is ITS Architecture?)
As well as the logical progression from one step to the next, it is important to include "Verification" and "Validation" as links between some of the steps.
Verification: this is a process to test whether the system component meets all the design requirements and technical specifications at each stage. What is done in one step must be compatible with the results of the previous steps. So for example, the “sub-system design and communications procurement” step may show that some of the choices made in the previous step “component specifications and communications requirements” are difficult or impossible to achieve. In this instance the ITS Architecture would have to be reviewed to see if any changes are needed to solve the problem, which if they are, will lead to a revision of the component specifications or communications requirements and some of the other outputs produced from it. (See Next Steps?)
Validation: this is the process of testing whether what has been produced as the result of each step in the hand side of the "V" model achieves the desired result, and requires that test specifications are produced. Creating a test specification should be a part of each step on the -hand side of the "V" model. If it is impossible to test the result then how will anybody know if what has been produced is doing what it is supposed to do? In this situation it may be better to review the design to see what needs to be altered to make testing possible?
Progress from one step to the next down the -hand side of the "V" should not take place unless verification has been completed and the test specification has been produced and agreed.
Sometimes, and particularly if the ITS implementation will involve several stakeholders or there are several services to be provided, it is very useful to create a statement of the "vision" that the stakeholders have of what they want to achieve. It is produced in close consultation with the stakeholders (perhaps with one taking the lead) and provides an overall picture of the ITS implementation by highlighting the following:
The "vision" should be less than a page in length and designed to be read in not more than 5 minutes. If necessary, bulleted points and diagrams should be used in preference to using lots of text. In many ways it is a "selling" document to be read by senior decision makers such as those who allocate financial budgets. But it can also be used to encourage the participation of other and perhaps as yet undecided stakeholders. The other use it has is as the precursor to the more detailed service descriptions that the stakeholders will have to produce at the start of the steps in the "V" model where the ITS architecture will be created.
(See Formulating a Programme)
Many developing countries may have little or no existing ITS components or communications. Consequently the road users, travellers and those that move goods (end users) and road managers will have limited experience of using many of the services that ITS can provide and those providing the services will have little or no experience of the on-going management of what is required to provide them. This is an important factor in deciding the scope of at least the initial ITS implementation in order to build experience of ITS and manage expectations.
Creating the "vision" statement described in the previous section can and should generate much enthusiasm about the services that ITS can provide and the benefits that they will deliver to both travellers and those that move goods. It will be tempting to include all the possible services in the first ITS implementation. This will be a mistake, a likely consequence of which is that the implementation of at least some of them will fail and/or those that are implemented will not perform as expected and hence not deliver the anticipated benefits. ITS may get a "bad press" and make it difficult to gain support from stakeholders for implementing additional services – or in the worst case – fixing those already implemented that are not performing as expected. It can also result in the development of bad relations with suppliers and/or system integrators, who will probably be blamed for the under performance of the services.
Despite what it may say in the "vision" statement, a realistic scope must be set for the initial ITS implementation. For example:
the service providing a priority system for buses will not work until the road traffic management system it needs to operate has been implemented first and proven to actually manage traffic using the road network in the way that was expected.
a trip planning service will not perform very well unless the service that collects and collates traffic data has been operating for a sufficient length of time for reliable predictions to be available for journey times, something for which several months of operation will almost certainly be required.
The important point is to set a realistic scope for the initial ITS implementation in terms of the number of services it will support. This could be included in the "vision" statement but is perhaps better put into a separate "ITS implementation strategy" document. This document should also include details of a rolling programme for the introduction of further services over a period of time – that perhaps extends to years rather than weeks or months. (See Strategic Planning and Case Studies on Finnish ITS Strategy and Seattle ITS Strategic Plan 2010-2020 )
A "rolling programme" (or "rolling plan") produces a phased implementation of ITS services in stages instead of implementing all the services at once. Each stage starts after the previous one is completed and is operating successfully.. For example, before bus priority measures are developed, the traffic management service on which they depend will be up and running and delivering benefits. A rolling programme can be implemented over months or even years, depending on the number of services and their complexities. Training and management of personnel involved in the ITS implementation can be better managed this way. Using a core team of people who manage the implementation of successive services provides continuity of knowledge and experience.
The rolling plan should not be time dependent, but driven by the proven successful implementation of the previous set of services. Thus ITS will be implemented in a series of logical steps rather than a single "big bang". Another good reason for having a rolling plan is that it will help to create a good level of interest from prospective contractors because there is the prospect of further work when extra services are added in the future.
Media and publicity can be very important for the success of any ITS implementation. Information provided to the media (radio, television, newspapers, social media, the technical journals and other platforms) needs to be handled properly. If the implementation is proceeding according to plan and the services will deliver benefits that the travelling public and freight shippers want – there should be no problem. If either of these is not the case – for example, an ITS scheme that is very costly or unpopular – then the media can become hostile. Negative publicity is more likely when the implementation runs late, is over budget or the services do not perform as expected.
It can be useful to employ a media consultant or publicist who is experienced in ensuring that information about the ITS implementation is timely and correct and is not open to misinterpretation.
The USDOT ITS ePrimer Module 2: Systems Engineering includes a very useful list of reference sources of information to aid further study of this whole subject. The Module is authored by Bruce Eisenhart, Vice President of Operations, Consensus Systems Technologies (ConSysTec), Centreville, VA, USA and is available on-line at:
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 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:
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:
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.
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.
Obviously it is important to have the numbers of staff involved in the management of the ITS implementation. For the project management part of this work, there is nothing better than an experienced Project Manager (PM), preferably with some recognised professional qualifications in project management. Experience of working in ITS is not necessary, as the PM is primarily concerned with contractual and financial matters, but knowledge of local laws and customs will be advantageous. Ideally the PM should be appointed before the "procurement" stage of the ITS implementation starts. This enables them to be involved in the final contract negotiations and to take ownership of the agreed terms and conditions. It also means that they can produce or validate the project plan at an early stage, which will enable it to have the most beneficial impact on the project. The PM should also participate in the negotiations for any sub-contracts covering specialise activities, such as building works and installation of components at the roadside.
As noted above, the PM may come from a leading supplier, or the system integrator (if one has been employed), or a large and/or dominant stakeholder, or be a complete outsider. Once the ITS implementation has been completed they can move on to other work. But if the ITS implementation needs any upgrade or improvement work, then it will be of benefit to use the same PM again to take advantage of their previous experience and any relationships they have built up with any of those who will be involved.
Similar comments apply to the person managing the systems engineering programme, the "technical project manager" or "engineering manager", except that it will be a definite major advantage if they have some previous experience of working in ITS. They should be appointed as part of the "procurement" stage of the ITS implementation, perhaps as part of the contract with a supplier, communications provider, or system integrator.
The advantage of having a systems engineering programme manager who is employed by one of the main stakeholders is that person could also be retained for work on any upgrade or improvement work that the ITS implementation requires in the future, to take advantage of the knowledge of its complexities that will have been gained from the previous work. The resourcing of staff for individual component and communications development and testing will be a matter for the suppliers and providers involved, but should be expected that the person or people involved will have some relevant experience.
For developing economies, finding the people for the project management and systems engineering programme management roles may be difficult. If expertise in either of these roles is available locally, it is more likely to be that for project management. Employing a person with knowledge of local laws and customs will be a definite advantage.
Finding a suitable person locally for the engineering programme management role will probably be more difficult. This will be particularly true if there is no local expertise in ITS related technologies and communications.
There are several consultancy companies specialising in ITS implementation that will be able to provide engineering programme managers with suitable experience. These companies vary in size from large international organisations with offices in several parts of the world, to small single person organisations. The former are likely to have a broader range of experience of implementing ITS services than single person organisations, but this does not necessarily make them any better. It is best to do some research to find out what actual ITS implementations they are working on currently and have worked on in the past to assess their experience. Also communicating directly with their actual customers will almost always provide a much better idea of how good they are.
Ideally what is needed is an organisation that is prepared to set up a local office and to recruit and train local people in engineering programme management. This will have definite advantages in that the knowledge gained from a particular ITS implementation can be retained locally and be used in any future ITS related work.
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.
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.
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 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.
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.
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.
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.
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:
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
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 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.
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.
The testing of the components and communications that is carried out in order to integrate them will usually go through the following stages:
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.
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 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.
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.
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:
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.
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.
Once the ITS implementation is complete, the system components and communications links have to be operated and maintained. This will enable the services to be delivered as required by the stakeholders and for maintenance work to be carried out to ensure that of the services delivery can continue. Operations and maintenance does not just happen – plans must be put in place so that what needs to be done is understood and the appropriate resources are available to do it. (See System Maintenance)
The short video about the work of the Swedish Transport Administration provides some useful points for justifying the use of ITS, from one of the leading European implementers. It is not so much the technical solutions that are highlighted as the philosophy and the inclusion of tasks such as maintenance, which is highlighted for good reason.
Because ITS implementations are diverse it is not possible to describe one solution that will fit all of them but there are common issues that need to be considered so that solutions can be found for the individual circumstances. Establishing the areas of operational responsibility is best done by considering them under the three headings of managerial, geographic and technical.
Determining how much management will be needed to deliver the services that the ITS implementation is providing is best done by considering some of the following issues:
The need to consider some or all of these issues depends on the scope of the services being provided, but the above are examples of some of the more common issues that are likely to arise.
The assignment of responsibility within the management organisation depends on its structure, which will vary from one ITS implementation to another but must be agreed before ITS is implemented to avoid and potential embarrassing situations later. Sometimes the organisation will have been created specifically for the ITS implementation, but on other occasions responsibility for ITS will have been acquired in addition to its existing portfolio of responsibilities.
Some ITS implementations will be large enough to cover several geographic areas, such as the states or provinces within a nation, regions within a state, or districts of a city. The issue is whether management of the services will be centralised at national, state or city level, or distributed to smaller geographical units, within the state, region or city district.
If responsibility for service management is distributed then the relationships between these organisations will be important and must take account of local differences that may impact on ITS operations, such as:
How issues like the above are accommodated depends on the scope and content of the ITS services and the organisational structures both within each geographic area and at the higher (national, state or city) level. It is important to enable them to be discussed and procedures/actions agreed by all those who will be involved before the ITS implementation has been completed.
The allocation of technical responsibilities will be slightly different for system components and communications. If everything works correctly, then it does not matter too much. Only when a component or a communications link fails or performs in an unexpected way does it become important. Inevitably, this will occur at some point in the life cycle of any ITS implementation and it is important to consider in advance its likely impact.
The question of who has technical responsibility for any mal-performance of ITS lies in deciding where the "design responsibility” rests. This can be done by looking to see where the methodology and/or technology to be used in a component or communications link is defined and allocating the responsibility to whoever created that definition. The most common examples are:
It is best to ensure the "design responsibility" rests with the organisation that is most appropriate to carry it – the one that is most likely to have the capability to resolve any issues as and when they arise.
For system components design responsibility should be placed with the suppliers. For example, if the control centre terminals have to give users access to the ITS applications and also enable them to do office tasks (for example, word processing and answering e-mails), the component specification should state these requirements and say this must be included in the design of the terminals. The specification should not define the operating system, processor, memory and other features as this is in effect defining the design of the terminal and shifts responsibility for any problems to those that wrote the specification.
A similar approach is needed for the communications requirements. They should not say that a packet switched network operating at a particular speed must be used. Instead they should define parameters such as how much data is to be transmitted, how often, with what reliability, expected transmission duration, which parts of the links are on mobile devices, the level of security that is required and the resilience needed to combat unauthorised access. Such a specification will also be much easier to test, since these are verifiable parameters.
In addition to the scope and content of the services provided by the ITS implementation, the need for relationships with other organisations will depend on the environment in which the services will operate. The environment will be defined by the geographic coverage and by the number of organisations involved. (See Integrated Strategies)
Some ITS implementations will provide services in several geographic areas. If the services in each area are to be operated and managed by different organisations, then unless the areas are completely separate, meaning that the road traffic conditions in one area have no effect on those in other areas, relationships – such as operating agreements – will need to be established between them. The scope of these relationships will be based on such factors as whether the need to co-operate is a regular occurrence or only under particular circumstances. (See Planning and Reporting)
It is also possible that some of the services that are provided in the same geographic area will be operated and managed by different organisations. For example, services related to Public Transport and tolling will often be provided by their own organisations. In these instances, the way in which their operations can inter-act with each other and with other service providers needs to be defined and act as the basis for the relationships. It may be necessary to develop detailed operating agreements between the different organisations. So for example, how should the road network operator respond to requests for vehicle priority from the Public Transport organisation? Another classic example of the need for relationships between organisations is where the road network uses a lifting bridge to cross a waterway that is managed by a port authority – how is the need for the bridge to open for vessels and closed to vehicles to be managed?
Finally the issue of the participation of the Police and/or other law enforcement agencies in road network operations will need to be addressed. In some countries the two are distinct, whilst in others it is the Police Force (or sometimes a dedicated part of it) that operates and manages the road network. If the road network operation and the Police Force are separate organisations then the relationship needs to define what the co-operation will be and how it will be implemented. For example can the road network operator report traffic offences, or to what extent can some of the data from the traffic control centre (for example, CCTV images) be used as the basis for the successful prosecution of offenders? (See Policing / Enforcement)
In countries with very little experience of implementing ITS, it could be difficult to set up the "environment" to operate and deliver the services. The "environment" will be defined by the organisations involved and how the responsibilities are allocated between them. To some extent this depends on the structure of the existing organisations and the relationships they have with each other. It may be necessary to create one or more new organisations, structures and relationships for the ITS implementation. The important point is to create an organisational structure that avoids un-necessary conflicts between organisations, whilst ensuring proper management of their activities.
For example, in some geographic areas, it is the Police that provide whatever road traffic management is currently in place. The issue to be resolved is, should they continue to do this in the ITS implementation, and if not, when and how should they interact with the organisation that will be responsible for the traffic management service(s)? There is no one universally applicable mechanism that will resolve this issue, but whatever is put in place must be recorded so that once agreed, there is no further dispute about the role of each organisation and who is responsible for what, when and where.
The probable route to achieving what has been described above, is to buy-in external expertise either directly or through consultants. If this route is followed it will be advantageous to visit ITS implementations that have used the proposed source of expertise and/or consultants and to discuss how the organisational relationships work. It is also worth remembering that sometimes what works for one country or culture will not work for another.
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:
How these two totals are calculated will depend on a combination of the following nine factors:
Not all of these factors will be relevant to every ITS implementation – but those that are will determine the maximum staff requirements needed.
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:
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.
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:
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.
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.
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.
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.
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.
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.