How Parasyn Replaced Pacific National's Ageing OMCS

Pacific National (PN) is Australia's largest private rail freight operator, playing a crucial role in the country's logistics and supply chain. With a network spanning every state and territory, PN transports everything from bulk commodities like coal, grain, and steel to intermodal containers and specialised freight. Monitoring and managing rail assets safely is central to that operational efficiency, and the reliability of PN's Operations Management Control System (OMCS) is a critical part of maintaining its safety record. Parasyn used a Systems Engineering approach to safely replace that OMCS, including Geo SCADA Expert and Kingfisher RTUs.

Scope

The PN OMCS upgrade replaced the existing SCADA platform and RTUs outright, moving to Schneider Geo SCADA Expert and Ovarro Kingfisher RTUs. There's a stark difference between greenfield and brownfield replacement projects, further complicated when legacy products are no longer supported. PN acted early, and its legacy components weren't yet end of life, reducing project risk significantly.

Key Risks

The initial assessment and project planning phase identified a number of delivery risks: PN operators might not readily accept the new SCADA system; the existing system and site assets are ageing, and operations were understandably nervous about turning equipment off without confidence it could be turned back on; and an operational incident during cutover could cause extended, unplanned downtime.

These risks are specific to this project but far from unusual when transitioning legacy critical systems. On very old systems especially, turning equipment off carries real operational and commercial risk, justified by local experience, and it reinforces why operational staff on the ground need to be part of identifying hazards, assessing risk, developing control measures, and ultimately accepting the residual risk a new system introduces.

Program Management and Systems Engineering

Systems engineering is a crucial discipline for complex systems like rail networks, ensuring every component, from tracks and signals to trains and infrastructure, works together to deliver safe, efficient, reliable transport. The V-Model, a common systems engineering framework, illustrates the iterative process from system requirements through verification to validation.

The OMCS replacement followed a typical Systems Engineering project format, the waterfall approach. The project wasn't large in equipment footprint, but the operational impact was significant nonetheless, as it is with most automation technology projects. Notable elements of the delivery program included requirements definition, risk assessment, design workshops, Function Design Specification development, procurement, development, transition planning, implementation, and acceptance.

In a V-model project, verification of requirements happens progressively, followed by a final audit that's the green light for subsequent build or testing activity. Initial pre-design requirements mature as design workshops are held and further design inputs come in. As designs are verified against developed requirements, stakeholders build confidence that their needs-driven requirements are reflected in the program or design. The earlier and better this is done, the fewer surprises during user acceptance testing, with the ultimate goal being no surprises at acceptance, having tested all functionality thoroughly while focusing more on performance-based testing than re-litigating how the system is supposed to work.

Once requirements are verified against design, transition planning can begin, identifying how each requirement is validated, by inspection, demonstration, analysis, or testing. Test plans and procedures articulate that the chosen validation method has been adequately addressed. Testing at least twice, following an organised and approved program, lifts confidence in the eyes of those preparing to accept the new system, particularly when configurations have never specifically been tried before. The sheer volume of tests, even on a small to moderate project, demands continuity of approach as others join or share the workload. A rigorously applied testing framework creates a platform for regression testing, so a patch or workaround doesn't require starting again from scratch, arguably one of the most important reasons Systems Engineering matters for critical infrastructure projects: it takes the process and method out of daily discussion and keeps focus on meeting requirements and assessing the impact of whatever limitations get dynamically discovered along the way.

Wrap

Operator and maintainer training for this OMCS project was less formal, focused on operational changes from old to new. In other scenarios, system criticality and the safety argument might dictate a different, less simplistic approach. Here, since the new system wasn't planned as anything other than like-for-like, this approach carried appropriate weight.

The project concluded in November 2024. Feedback, somewhat ironically, included a note that more training would have helped. The lesson: systems engineering projects need balanced appreciation across the organisation, since projects always face budget constraints, and the tail end of a project needs enough funding to deliver customer fulfilment to the level actually planned at the outset, not just the level remaining once funds run low. Acceptance planning is an early and critical part of project design, not an afterthought.

Upgrade Opportunities Beyond Like-for-Like

A like-for-like-only philosophy would have missed a real opportunity on a legacy conversion like this. It's a conversion, not a version upgrade, a genuinely new lease of life on a different technology platform, which means considering new features and sometimes retiring well-loved ones that are no longer available.

True to form, the new software and hardware did need to match like-for-like as a baseline, and Parasyn's project methodology still imposed thorough testing throughout. As with many legacy systems, inputs and outputs get exercised for functions that haven't been used since the day they were installed decades earlier, and thorough retesting exposes wiring issues, inconsistent legacy coding, and drawing inconsistencies. This project rectified a number of these issues and established a new baseline of performance. New technologies bring new functionality, as Geo SCADA Expert and the new Kingfisher RTUs did here, and an uplift in system integrity and quality came along for the ride. Realised opportunities included:

RTUs:

• Latest CPU hardware compatible with legacy IO
• Coding using IEC 61131 languages
• A library-based configuration approach, ensuring consistency across sub-functions
• Modern functionality aligned with Visual Studio

SCADA:

• Improved operator interfaces (zoom, pan, navigation, alarm lists)
• Multiple Document Interface (MDI) functionality, letting operators reorder displays
• Adaptable to most common monitor sizes, suitable for use in the field
• Latest software version, well supported with monthly updates
• Increased cyber security through certificates and encrypted connectivity
• Stronger, more reliable redundancy