Bringing Systems Integration to Rolling Stock

The Challenges of Rolling Stock Projects

Rolling stock are complex integrated systems within the railway system. When they require enhancement, other than maintenance and painting, this can result in complex programmes of work. As well as the on-board systems including doors, traction/braking, on-board communications systems, toilets and air-conditioning, rolling stock requires interoperation with infrastructure systems such as signalling, platform systems and network communications systems. All these systems have a level of safety integrity that should be considered, designed for and tested accordingly. This level of complexity requires effective programme management to ensure the expected benefits are realised, safety is maintained and interoperability with the whole railway system is retained. For introduction, refurbishment or replacement programmes, the unique qualities of rolling stock bring added complexities:

• The railway system remains operational. When an infrastructure renewal or enhancement is required, a possession is often required, resulting in a temporary service reduction or even suspension. Rolling stock vehicles can be taken out of service whilst retaining a service level. However, this results in a compromise needing to be reached between the available trains for service, the timescales to roll-out across the fleet and the efficiency of the production line facilities.
  
  
• Interoperation of new and previous rolling stock fleets. Due to this roll-out programme, as soon as the first vehicle is converted, the railway must temporarily operate with two rolling stock configurations until all vehicles are converted. This migration phase duration can be up to several years, having a significant impact on operations, maintenance and the passenger, all of which require appropriate mitigation. 
  
  
• Multiple rolling stock configurations. A single rolling stock fleet can have driving motor vehicles (with a driving cab and propulsion equipment), non-driving motor vehicles and trailing vehicles, as well as wheelchair-accessible, first class and catering vehicles. Indeed, there can be variations even within a configuration: build tolerances across a fleet, depending on how/when they were manufactured, can be found not to conform to drawing. For each vehicle, a different design may be required, each of which need verification and validation. Overlaying different systems results in several permutations of design and can require a significant level of configuration control.
  
  
• Significant testing requirements. The new rolling stock requires testing in two stages: testing against an infrastructure reference as required by standards, and then on the operational railway to validate against its specific qualities (gradients, gauging, horizontal and vertical curves, power supply, electromagnetic context) and interoperate with the existing systems: signalling, platform based doors/gates, correct-side door opening and more. The complexity of validating these interfaces makes it cost effective to produce and test a first-off train before commencing series production, bringing about challenges in the production line and supply chain. On top of this are the inevitable modification and/or fixes for things that do not work properly. These design modifications and software updates require verification and validation before further roll-out, adding cost, delay and additional configuration control.
  
  
• Complex array of interfaces. Rolling stock systems are varied in their function, their required integrity level and the medium or method of controlling functionality. Systems can function using data, hard wire control, pneumatics, and mechanical methods; they can have safety critical functions, like braking and door closure, or less critical functions like displaying the destination. These systems often interoperate requiring detailed physical and functional interface management to ensure correct operation.

The resulting complexity means that managing the integration of rolling stock projects into an existing railway system is critical. The resultant risks can be effectively mitigated through introduction of systems engineering techniques such as requirements management, interface management, configuration control, engineering change control processes, programme level technical risk management. These techniques were used effectively at Transport for London (TfL) in the following Central Line case study. Zoë Dobell discusses her experience as a systems engineer within TfL prior to joining WSP, conducting the integration of the Central Line Improvement Programme. She discusses the complexity of the programme and the most pertinent systems integration techniques—outlining the benefits they provided for the railway system—and concludes with a look at how WSP’s SI:D³ can be used across other rolling stock programmes.

Case Study: Central Line Improvement Programme

The Central Line Improvement Programme (CLIP) is a rolling stock enhancement programme to improve various rolling stock systems on the 85-train fleet. The programme consists of six projects affecting the following train-borne systems:

• AC traction – to remove the existing DC traction system, most of which is underframe mounted and replace with an AC traction system (eight traction packages and 32 motors per train) 
  
  

• Data Transmission System (DTS) – to replace the existing train management system known as DTS. This involved cab and saloon equipment, with substantial saloon car wiring and some underframe wiring. This project re-used the existing train backbone wiring and improved connectivity between train-borne systems by providing a vehicle-level ethernet network, maintaining the interface with the equipment it controls and/or monitors.
  
  

• Passenger Information System (PIS) – to replace existing audio-only PIS and replace this and the cab front display with the addition of saloon displays. This system has a significant interface with the DTS. 
  
  

• Saloon CCTV – the introduction of a saloon CCTV system. This system has interfaces with DTS and PIS.
  
  

• LED lighting – to remove the existing fluorescent lighting system and introduce a new LED lighting system.
  
  

• Saloon Design – to re-design saloon panelling, bracketry and fittings to install all cab and saloon systems, as well as provide wheelchair spaces, improved flooring and repair floor corrosion

Due to the complexity of the interfaces between the systems, many of these changes needed to be conducted concurrently in order to function, e.g. the new PIS would not interoperate with the old DTS.

Each project had its own defined goals, but the complex array of interfaces and the requirement for all systems to be installed at the same time, pulled these projects into a programme with overarching goals of improved reliability, accessibility, and passenger security and safety.

Each project had a project team, and a programme management structure to bring cohesion between the projects. A systems engineer was recruited into the operator’s project office for this programme to deliver the integration of these six systems/projects/contracts. The systems engineering included integration of the six systems with each other, of each system with the existing rolling stock and with ongoing maintenance activities / projects. The systems engineer introduced multiple systems engineering processes to manage the complexities of this programme.

CONFIGURATION MANAGEMENT

Prior to CLIP, the Central line rolling stock had four configurations of vehicle: motor car with cab (type A), a motor car (C) which is similar to an A car but with shunting controls in lieu of a cab, both of which are permanently coupled to a non-driving motor car (B). Some C cars have equipment for de-icing the conductor rails (D). CLIP introduced a fifth: a B car with wheelchair space. Each configuration required its own design, resulting in additional complexity to the interface management.

On top of this, some of the new systems could not interoperate with their predecessor system. Where systems were limited to communications within a single car, this had minimal impact but where communications required connection into the train-level communications system, this had the result that modified cars could only be coupled into a train of modified cars, and the same for unmodified cars.

By developing an architecture description, the development of the designs and the interfaces was monitored not only on a system-by-system basis, but a configuration-by-configuration basis. In early design stages, suppliers would simplify the architecture by broadly referring to two car types (motor (A car) and non-driving motor (B car)). Monitoring of the configuration developments and interface management performed by the systems engineer encouraged suppliers to develop designs for the five configurations in an earlier stage and mitigate risks that would have otherwise been realised at prototyping (for example, by trying to fit a piece of equipment in a place where de-icing equipment is already mounted).

The architecture description was made up of five sheets (one for each car configuration) and depicted the design development of each, by bringing together submitted design documentation from each of the suppliers. As well as showing how the designs were being developed, and how space was being allocated on the cars, this also highlighted how design maturity differed between the systems, which was critical for understanding the risk associated with design changes.

The development and maintenance of an architecture description allowed for effective configuration management throughout the design and prototyping phases. Effective management of this phase saves cost; failure to do so causes the programme to be extended leading to significant extra cost.

INTERFACE MANAGEMENT

Each replacement train-borne system has interfaces that fall into three categories:

1. Interfaces with existing and unchanged systems
2. Interfaces with replacement systems
3. New interfaces with new functionality

For example, amongst others, the PIS has the following three interfaces:

1. Passenger Emergency Alarms – this interfacing system is unchanged and so can be specified and designed against in order to retain existing functionality
2. DTS – this interfacing system is being replaced, so the PIS and DTS interface specifications and designs are developed in parallel by the respective suppliers, such that existing functionality is retained
3. Saloon CCTV – this interfacing system is new, so the specifications and designs are developed in parallel by the respective suppliers, but new functionality also needs to be specified

A snapshot of the interfaces that required management are shown in the following context diagram.

Each system was subjected to a thorough interface management process that involved detailed interface identification, definition and verification. By far the most complex interfaces that required management were those with other systems being replaced due to the parallel design development of these systems. To enable this, the systems engineer ran interface meetings that facilitated technical issue resolution. As part of this process, Agreed Interface Definition Documents (AIDDs) were written to agree interface definitions at appropriate stages. Due to the differences in schedules between suppliers, the development and agreement of these AIDDs ran in parallel but independently from each suppliers’ design reviews whilst remaining a contractual document. The systems engineer ran this process, allowing for agreed interface development and definition whilst also understanding the contractual obligations and schedule constraints of all parties.

VEHICLE PROTOTYPE TESTING

The six projects had six different schedules, contractual obligations, and design and development approaches. Development of the verification and validation of the systems required development of a programme-wide integration strategy that considered the programme’s and each project’s risks.

To accommodate the six differing schedules from suppliers, the systems engineer defined multiple vehicle configurations for the prototyping phase. Configuration 1 contained the AC traction system and DTS. Configuration 2 contained the DTS, PIS, Saloon CCTV, LED lighting and the relevant parts of Saloon Design. And Configuration 3 contained the remainder of the Saloon Design modifications. Before the final design could be approved, TfL required that all systems be tested on the same train (the final configuration).

To accommodate the varying contractual arrangements of the six projects, a risk-based approach was agreed upon that allowed for contractual design approval following the first stage of prototyping. Higher risk interfaces were validated within one of the first-stage configurations such that the suppliers could demonstrate compliance to customer requirements. Lower risk interfaces that could not be validated in one of the first stage configurations were validated in the second-stage final configuration without the suppliers present. Following contract approval, the suppliers could commence manufacture of the fleet’s equipment whilst the second stage of prototyping was undertaken. This approach balanced the schedule risk and still allowed for any required design changes to be incorporated following the discovery of issues.

Systems Approach for Rolling Stock Programmes

The systems approach that was employed in CLIP allowed for risk-based decisions to be made throughout the programme lifecycle to enable delivery of a reliable, accessible rolling stock, cutting across contractual boundaries. The systems engineer's development of outcomes and requirements resulted in programme-level requirements being included into the project-level contracts. The systems engineer then commenced effective interface management with the suppliers, mitigating the risk of additional cost to change contractual scope or of design changes at prototyping. The systems engineer planned and owned the logical prototyping sequence, which was mandated on all suppliers. This sequence minimised design issues throughout roll-out of the final design, reducing the overall cost of the programme.

This systems approach allowed for effective management of the complexities of a rolling stock programme: the abundance and varieties of interfaces, the testing requirements of multiple suppliers, the realisation of several benefits whilst also meeting safety obligations—all whilst the rolling stock continues to operate and serve passengers.

Applying WSP’s SI:D³ to Rolling Stock

The successful implementation of systems thinking and systems principles on CLIP shows the benefit that can be realised by rolling stock companies and within rolling stock programmes. WSP’s SI:D³ is a field-proven approach to provide clarity in complex programmes such as these. It has been successfully used on complex programmes across the industry, including the Victoria Line Upgrade and Deep Tube Upgrade Programme within Transport for London. The approach taken on CLIP has used similar principles, demonstrating the impact this approach has to successful rolling stock programmes.

SI:D³ is split into three groups:

• Develop the Strategy

• Define the System

• Deliver Integration

The processes within each group can be implemented individually or with other processes according to the complexity, risk and lifecycle stage of the particular programme. As such, it can also be tailored to complement existing organisational governance and / or project lifecycles.

Developing a rolling stock introduction / upgrade / refurbishment strategy requires strategic goal definition, capability definition and subsequently management planning. SI:D³ tools help organisations define the goal—for example, procuring a new fleet of rolling stock, through developing a clear understanding of the benefits, the business case and key expected outcomes from stakeholders. The next step is defining the capability of the end-state system, linking key capabilities with the benefits and the business case. SI:D³ tools support high-level management planning through development of a road map to benefits realisation.

Defining the system through system architecture development allows further planning development, through the migration states definition processes. SI:D³ enables the development of a procurement strategy, providing contract alignment between the numerous suppliers and ensuring interfaces are appropriately specified. Requirements analysis also ensures that solutions delivered internally, or from external suppliers, will ultimately deliver the identified benefits within the strategy.

Once the programme is set up, tranches of work have requirements documented and contracts are in place. We then deliver integration through the design and delivery stages. An integrated schedule that includes all the tranches is critical in understanding the schedule dependencies and the overall programme critical path. Interface management between the tranches or contracts needs to be active to ensure the interfaces are developed in line with the design processes taking place within each tranche—neglecting interface management results in sub-standard interface solutions which can fail to deliver key system benefits. Configuration management ensures an understood and functioning design configuration at all times. Holistic decision management and risk/issues management (within RADIO) ensures that decisions are taken considering the overall impact and make objective compromises between work tranches or contracts. SI:D³ tools facilitate system validation for both the ‘internal’ system, i.e. the rolling stock, and the wider railway system, ensuring the programme leaps this last hurdle before delivery and benefits realisation.

The SI:D³ approach mitigates those risks present later on in design and in delivery, where the cost of change is high, resulting in elongated timescales and inflated budgets, all too often seen with major programmes. SI:D³ brings integration activities forward to reduce the magnitude of change late in the programme—and ultimately protect the business case and deliver the intended benefits.

To explore WSP’s systems integration (SI) approach, continue to the SI hub page.