The systems needed to manage and operate a motorway are complex. When a new motorway includes construction of a tunnel, the requirements for ventilation, lighting, and incident management systems increase this complexity. Add to this mix a fully electronic, multi-lane, free-flow tolling system, and we are presented with a significant systems engineering undertaking.

PB played an integral role in theelectronic tolling design process for the concession holders of Sydney's newest tunnel project-the $800 million CrossCity Tunnel. Opened in August 2005, this tunnel is expected to remove 90,000 vehicles per day from the crowded streets of Sydney's central business district. As with all electronic tolling in Australia, it is based on the use of portable radio transponders (also known as tags).

The System-of-Systems Approach

A popular topic within systems engineering is the concept of system-of-systems (SoS), where a system can be viewed in two ways:

• As an integration of smaller subsystems
• As the system itself being a subsystem requiring integration with external interfaces in order to provide its intended functionality.

SoS problems are a collection of transdomain networks of heterogeneous systems that are likely to exhibit operational and managerial independence.¹

The CrossCity Tunnel project offered the opportunity to implement a sound system integration methodology based on the SoS concept. From the perspective of the tolling system being an integration of smaller subsystems, it comprised:

• Dedicated short-range communication-based tolling equipment
• Laser detection and classification systems
• Infrared camera systems delivering automatic license plate recognition and optical character recognition
• Image review modules
• Account management systems.

From the perspective of the tolling system being a subsystem of a larger system, it required integration with:

• Interoperable tag issuers and electronic tollways
• Operations management and control systems
• Enforcement agencies
• Air quality monitoring systems
• Interactive voice response systems
• Financial service providers
• External call centres
• Off-the-shelf accounting systems.

System Integration Activities

Internal and external interfaces are treated separately within the system integration function. The activities for each are essentially the same, however, and are outlined below:

• Obtain the system hierarchy.
• Define the interfacing components.
• Ascertain the functional and physical interfaces for the system.
• Organise an interface control document.
• Define the functional and physical interfaces for the system.
• Conduct interface working groups with the stakeholders responsible for each side of the interface and the customer.
• Review test procedures and test plans to verify the interfaces.
• Audit design interfaces.
• Ensure interface changes are incorporated into system specifications.

Figure 1: System hierachy showing major subsystems that combine to deliver the complete tolling systemt.

We developed a simplified system hierarchy that was used (and refined during further stages) to display the required interfaces between systems. These interfaces are shown in Figure 1 as connecting lines.

The interfaces identified in this diagram were listed in a light-
weight ICD which, for this project, was a table documenting the essential data relating to each interface and referencing the external document that fully described the interface (Table 1). It describes:

• The two systems involved in the interface by name and owner
• A general description of the function the interface performs
• The party responsible for driving the definition of the interface. (The ownership of the interface resides with the suppliers of the two integrating systems and both parties had input into the definition. Responsibility could change during the definition process.)
• Basic high-level technical data describing the interface
• The status of the interface definition
• Reference to external documents that completely described the interface, or indication that the technical details of the interface were proprietary.

The ICD should represent the complete set of interfaces required for the solution. It must be noted that on this project some interfaces were between systems that were supplied by the same party, and there were instances where information relating to these interfaces was proprietary and was not disclosed. These situations must be identified and, in the absence of the interface definition, appropriate verification needs to be included in the test plans.

Table 1: An example of a light weight interface control document.

Conclusion

The level of integration between disparate systems was identified early in the project as a significant risk. The implementation of the defined integration methodology was proposed as a mitigation strategy and represented sound systems engineering. While many of the required interfaces were developed specifically for this project, the use of a defined methodology gave consistency to the process and confidence to all parties that the target was achievable. Further, by viewing the overall projects from an SoS perspective and following the prescribed system integration activities, we created a set of deliverables that ensured that the design, development, delivery and verification requirements were met in an auditable manner. The systems involved in the CrossCity Tunnel were technology based; however, this process does not need to be restricted to integration between technology-based systems. A system can be broadly defined as an integrated set of elements that accomplish a defined objective. This generality ensures that a system engineering approach is applicable to wider engineering disciplines.