John Cranley, Expertise Leader - Rail & rail systems, shares his experiences and lessons learned from these often complex projects. It’s an area that’s been close to his heart in the past 20 years of his career.
My first real exposure to integrating control room functionality came about during my involvement in the Central Line Upgrade project being undertaken by London Underground (LUL) during the early 1990s.
A decision had been made by LUL operations staff to devolve the control of the DC1 circuit breakers from the power control centre at Long Acre and transfer them to the new line control centre at White City.
There were numerous technical, and operational issues surrounding this decision, one of which was that this was yet another disparate system for the new ‘swish’ control room and associated equipment room to house, with different operator workstations to the train control system and the line control systems, thus detracting from the clean ergonomic environment the engineers and architects were trying to create.
As engineers, we looked around for alternative options and that’s when I came upon integrating railway control room functionality. Sadly, the timeframes for the project did not permit proceeding with this developing technology. Therein lies one of the major concerns for the opponents of functional integration risk. It is key to make the decision to integrate early in a project to mitigate risk both to programme delivery and the budget.
From a control room hardware perspective, integrating control room functionality essentially means providing a common Human Machine Interface (HMI) to all operators in the control room, regardless of the tasks the operator is required to undertake. The functions required by the operators to perform their jobs then become available to them when they log on via an ‘Area of Responsibility’ (AoR).
There are then two ways the functions can be presented to the HMI:
Some of the immediate benefits of functional integration include:
Dependent on the rail authority, some of the functions available in the control room may have Safety Integrity Level (SIL) criteria associated with them.
For example, the operation of traction supply circuit breakers in a number of authorities is an SIL 2 function and other functions such as public address announcements to surface stations have no SIL requirements.
A concern with a single supplier system is that the customer may be paying for the additional software control measure which is required to be put in place for an SIL 2 system and will also need to be undertaken for the non-SIL functionality, i.e. an increased cost and possible increased project duration to the customer.
Likewise, for the multiple supplier solution, a concern is it introduces another level of complexity; and, therefore, risk -- with the only immediately perceived benefit a common ‘look and feel’ HMI for the operators.
There are other issues associated with both options above, which I have heard discussed over the years; and, essentially, they all revolve around the complexity of the software, which creates a greater risk to the delivery programme and the budget of these projects.
For example, decision support systems helping operators to analyse network problems quicker than what might be achieved manually. With all functions coming through one system, event associations can be pre-programmed into the system by maintenance and operations staff using ‘operator friendly’ interfaces.
Dependent on the filtering mechanisms, one or more solutions can be presented to the operator to resolve the network incident quickly. As confidence grows within the operations staff on the accuracy of the solutions presented, control sequences can be implemented on multiple control actions, further accelerating the resolution of the incident.
Clearly, the debate is likely to go on for many years to come on the pros and cons of functional integration of control rooms. One size does not fit all, and each authority needs to decide on the perceived benefits or disadvantages to their organisation.
What I have learnt over the years, though, is that if an integrated control room environment is not considered at an early enough phase of any project, then the decision is usually already made for the authority, with the risk to programme and costs being too high.
Like all good projects, the first step is a clear and agreed set of user requirements. From these user requirements, consideration should then be given as to whether integrated control room functionality best meets the client’s needs.
If this is done early enough in the project cycle, the integration risks can be mitigated, hopefully leading to the realisation of effective control room integration with the rail authority reaping the benefit for years to come.