In 2017 two Parasyn teams began the design and replacement of two of Aurizon’s SCADA systems.
The first of these is the Remote Monitoring System (RMS for short). The RMS is used for the management of Level Crossing and Environmental sites. Aurizon’s RMS has been operational since 1989. Originally designed as a level crossing monitor, the system was modified to include environmental monitoring of such things as rail temperature, rainfall, rock slips and flood levels near rail bridges. The purpose of the system is to centrally collect alarms and maintenance information from remotely located equipment and to present the data to the appropriate operational and maintenance personnel. The RMS also interfaces to the Train Control System (TCS) to share alarm and status information. The previous system used software which was not based on traditional industrial automation products.
The second, more critical system is the Traction Power Supervisory Control System (TPSCS). Aurizon operates and manages the Central Queensland Coal Network (CQCN) which consists of approximately 2,670km of heavy haul rail infrastructure. The Goonyella Rail System in Central Queensland services coal mines in the northern Bowen Basin. The Blackwater Rail System connects mines west of Rockhampton to coal loading ports at Gladstone. The 24/7 Network Control Centre based at Rockhampton controls the TPSCS system for the Blackwater and Goonyella rail networks and the Network Control Disaster Recovery Centre is based in Mackay.
The SCADA component of the Aurizon TPSCS monitors and controls equipment at high voltage feeder stations, track sectioning cabins, track coupler units, autotransformer sites and motorised isolator sites. Equipment under control includes circuit breakers, protection relays, isolators, transformers and fault locators. Power load, quality and regeneration are monitored. The SCADA component consists a production system, disaster recovery system, development system and operator training system.
The SCADA enables Electrical Control Officers (ECOs) to monitor and control the distribution of power across the rail network. It interfaces with Powerlink for power system information sharing. The TPSCS is not a train control system.
Parasyn’s scope for both systems includes design, Safety in Design (for TPSCS), concept testing, configuration, software development, transition planning, integration, testing, training, staging and support.
The TPSCS project led the way in terms of architectural design. This was an important engineering saving for Aurizon in terms of total life-cycle cost. The architectural design including IT servers and network interfacing was virtually replicated for the RMS system even though the finer details and user configuration is completely different. There was consideration for having both systems hosted in the single enterprise SCADA environment, however the RMS system is not managed as a “critical” operational system even though its integrity is still essential to how Aurizon operates it assets safely. Thus, today the RMS and TPSCS remain physically and functionally independent. The ability to decouple the maintenance of RMS SCADA and trackside equipment from the Traction Power System is a long-term maintenance saving for Aurizon. This makes a strong case for critical infrastructure asset managers to consider how systems are managed beyond the convenience of single enterprise software footprints. It is simple to lump SCADA systems into one environment and there are strong reasons for standards to be managed in one integrated development environment (and we have had to do that before), however, the procurement of the IT infrastructure including software cannot be the only criteria that determines the final system architecture. A wider perspective including the role of both IT and OT support, the risk profile of the systems, and the operational integrity are paramount to a successful long-term workable solution.
The new systems are a massive uplift in features. Operators reported events management, status information, management of alarms and historical trends were “so much better!”
A large component of the design included provision for transitioning to the new systems. How would operators switch from one system to the other. The change management approach to reduce the impact of operators using a new system, was to build a training environment complete with a simulator. The simulator was used to create test scenarios for certifying new operators. After the training environment and simulator was built, the trainers were trained, who would in turn train the operators. They watched on as Parasyn trainers did the base load of the training. Training was also provided for how to configure the simulator “test scenarios”. In a much simpler environment, new scenarios can now be added by the trainers as the system changes throughout its life.
Operators were certified onto the new system before going live. The new system was activated in parallel with the old system. Technical complexities included catering for fully redundant old and new systems, and redundant interfaces to Powerlink using the Inter-Control Center Communications Protocol (ICCP) (IEC 60870-6/TASE.2). The ICCP interface needed to remain active during the transition activities. The ICCP interface driver was also a new and secure version which neither organisation has used before. Server Transition Planning workshops were held starting in the design stage and completed prior to the commencement of Go Live activities. The transition planning ensured the design catered for how the system would be managed and provided confidence at Go Live that everything had been considered.
The technical transition of the system was hidden to the operators except for having two systems in the control rooms. The plan was to have operators able to use both systems for several months. Due to benefits of the new system, the ease of use and the change management approach taken by the combined project teams, the operators had almost forgotten the old systems after only a month of using the new systems.
The standardisation of design is an obvious direct engineering and maintenance benefit. The silent partner in this was the unification of data behind the scenes. The independent SCADA systems were unified in terms of data in an industrial data-lake. The eDNA Enterprise Historian provides the bridge between both SCADA systems. Though operators may use independent SCADA systems for maintenance and alert management, the wider business can access information from a centralised perspective, using the data historian. With little to no training in some cases, data is accessible to stakeholders who would find access to SCADA data otherwise prohibitive. How was this possible?
The enterprise historian provides a number of interface points for data to be consumed, including native historian client tools for analysis, a business connector and APIs. Native connections to the SCADA systems provide the benefit of a unified and standardised configuration that traverses into the historian. This means one convention throughout the software platforms. Defined data elements (tags or points) correctly defined at the start, based on stakeholder requirements, means better outcomes for the business as point “translation” is never required.
The enterprise historian also provides another asset hierarchy application to map information via a new context (abstraction). His allows searchable data definitions to meet other business requirements such as Asset Management, and in particular if the existing SCADA conventions do not meet the requirements set by future software systems deployed by the business.
The asset hierarchy enables a multiple view concept. To name a few, data can be organised by asset type, geographical location, zone or other aspects that enhance the way data is viewed for reporting back in the native Historian Client Tools. No matter how the data is organised and viewed, it does not impact the integrity of the front-end SCADA systems.
Front end design has provided safe and secure back end unified data access. The SCADA is safe, no matter what happens in the corporate domain.
In 2017 two Parasyn teams began the design and replacement of two of Aurizon’s SCADA systems.
The first of these is the Remote Monitoring System (RMS for short). The RMS is used for the management of Level Crossing and Environmental sites. Aurizon’s RMS has been operational since 1989. Originally designed as a level crossing monitor, the system was modified to include environmental monitoring of such things as rail temperature, rainfall, rock slips and flood levels near rail bridges. The purpose of the system is to centrally collect alarms and maintenance information from remotely located equipment and to present the data to the appropriate operational and maintenance personnel. The RMS also interfaces to the Train Control System (TCS) to share alarm and status information. The previous system used software which was not based on traditional industrial automation products.
The second, more critical system is the Traction Power Supervisory Control System (TPSCS). Aurizon operates and manages the Central Queensland Coal Network (CQCN) which consists of approximately 2,670km of heavy haul rail infrastructure. The Goonyella Rail System in Central Queensland services coal mines in the northern Bowen Basin. The Blackwater Rail System connects mines west of Rockhampton to coal loading ports at Gladstone. The 24/7 Network Control Centre based at Rockhampton controls the TPSCS system for the Blackwater and Goonyella rail networks and the Network Control Disaster Recovery Centre is based in Mackay.
The SCADA component of the Aurizon TPSCS monitors and controls equipment at high voltage feeder stations, track sectioning cabins, track coupler units, autotransformer sites and motorised isolator sites. Equipment under control includes circuit breakers, protection relays, isolators, transformers and fault locators. Power load, quality and regeneration are monitored. The SCADA component consists a production system, disaster recovery system, development system and operator training system.
The SCADA enables Electrical Control Officers (ECOs) to monitor and control the distribution of power across the rail network. It interfaces with Powerlink for power system information sharing. The TPSCS is not a train control system.
Parasyn’s scope for both systems includes design, Safety in Design (for TPSCS), concept testing, configuration, software development, transition planning, integration, testing, training, staging and support.
The TPSCS project led the way in terms of architectural design. This was an important engineering saving for Aurizon in terms of total life-cycle cost. The architectural design including IT servers and network interfacing was virtually replicated for the RMS system even though the finer details and user configuration is completely different. There was consideration for having both systems hosted in the single enterprise SCADA environment, however the RMS system is not managed as a “critical” operational system even though its integrity is still essential to how Aurizon operates it assets safely. Thus, today the RMS and TPSCS remain physically and functionally independent.
The ability to decouple the maintenance of RMS SCADA and trackside equipment from the Traction Power System is a long-term maintenance saving for Aurizon. This makes a strong case for critical infrastructure asset managers to consider how systems are managed beyond the convenience of single enterprise software footprints. It is simple to lump SCADA systems into one environment and there are strong reasons for standards to be managed in one integrated development environment (and we have had to do that before), however, the procurement of the IT infrastructure including software cannot be the only criteria that determines the final system architecture. A wider perspective including the role of both IT and OT support, the risk profile of the systems, and the operational integrity are paramount to a successful long-term workable solution.
The new systems are a massive uplift in features. Operators reported events management, status information, management of alarms and historical trends were “so much better!”
A large component of the design included provision for transitioning to the new systems. How would operators switch from one system to the other. The change management approach to reduce the impact of operators using a new system, was to build a training environment complete with a simulator. The simulator was used to create test scenarios for certifying new operators. After the training environment and simulator was built, the trainers were trained, who would in turn train the operators. They watched on as Parasyn trainers did the base load of the training. Training was also provided for how to configure the simulator “test scenarios”. In a much simpler environment, new scenarios can now be added by the trainers as the system changes throughout its life.
Operators were certified onto the new system before going live. The new system was activated in parallel with the old system. Technical complexities included catering for fully redundant old and new systems, and redundant interfaces to Powerlink using the Inter-Control Center Communications Protocol (ICCP) (IEC 60870-6/TASE.2). The ICCP interface needed to remain active during the transition activities. The ICCP interface driver was also a new and secure version which neither organisation has used before. Server Transition Planning workshops were held starting in the design stage and completed prior to the commencement of Go Live activities. The transition planning ensured the design catered for how the system would be managed and provided confidence at Go Live that everything had been considered.
The technical transition of the system was hidden to the operators except for having two systems in the control rooms. The plan was to have operators able to use both systems for several months. Due to benefits of the new system, the ease of use and the change management approach taken by the combined project teams, the operators had almost forgotten the old systems after only a month of using the new systems.
The standardisation of design is an obvious direct engineering and maintenance benefit. The silent partner in this was the unification of data behind the scenes. The independent SCADA systems were unified in terms of data in an industrial data-lake. The eDNA Enterprise Historian provides the bridge between both SCADA systems. Though operators may use independent SCADA systems for maintenance and alert management, the wider business can access information from a centralised perspective, using the data historian. With little to no training in some cases, data is accessible to stakeholders who would find access to SCADA data otherwise prohibitive. How was this possible?
The enterprise historian provides a number of interface points for data to be consumed, including native historian client tools for analysis, a business connector and APIs. Native connections to the SCADA systems provide the benefit of a unified and standardised configuration that traverses into the historian. This means one convention throughout the software platforms. Defined data elements (tags or points) correctly defined at the start, based on stakeholder requirements, means better outcomes for the business as point “translation” is never required.
The enterprise historian also provides another asset hierarchy application to map information via a new context (abstraction). His allows searchable data definitions to meet other business requirements such as Asset Management, and in particular if the existing SCADA conventions do not meet the requirements set by future software systems deployed by the business.
The asset hierarchy enables a multiple view concept. To name a few, data can be organised by asset type, geographical location, zone or other aspects that enhance the way data is viewed for reporting back in the native Historian Client Tools. No matter how the data is organised and viewed, it does not impact the integrity of the front-end SCADA systems.
Front end design has provided safe and secure back end unified data access. The SCADA is safe, no matter what happens in the corporate domain.