Systems Engineering Programme

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.

Component

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.

Communications

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.

The first two steps – “Service Descriptions” and “ITS Architecture” – shown on the left-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 right-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 left 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?)

Verification and Validation

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 left 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 left-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 left-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 services that are to be provided, with no more than a short single sentence description of each one
• Who will benefit from the introduction of the services with a brief outline of what those benefits are expected to be
• The date(s) when it is proposed that the services will be introduced
• Who are the stakeholders and why they are promoting this implementation of ITS

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.

Video:Professor Brian Collins on Systems Engineering