RTU Type Approval for Power Systems
This article looks at the framework and practical application of type approval, a mandated process for confirming the operational suitability of new or modified rail equipment. It walks through the standard five-step procedure, from initial application and technical review through to rigorous testing, reporting, and final certification by the governing authority.
A case study involving Queensland Rail (QR) upgrading its Remote Terminal Unit (RTU) CPUs illustrates how complex this process can be, even a seemingly simple “plug and play” replacement requires extensive validation across every software configuration, because of subtle compatibility issues and the zero margin for error that comes with managing high-voltage traction power. The discussion also shows how type approval involves setting specific operational boundaries and formally accepting documented functional deficiencies, managed afterward through staff training.
Why Type Approval Matters
Type approval gives the industry a standardised, formal process for confirming the safety, reliability, and interoperability of new or modified equipment. It's a risk management tool that mandates rigorous testing and evaluation of components for signalling systems, traction power, and rolling stock, and it's what prevents accidents and operational failures. A consistent type approval framework baselines performance and gives operators safety-assured certainty. Without it, the industry would carry far more safety risk, higher costs, and real barriers to innovation, as mistakes and poor performance would litter the technology landscape.
The Basic Steps for Getting Type Approval
The process runs through five stages:
- Application: a supplier submits a comprehensive package of technical documents, designs, certifications, and safety analyses to the governing body for verification.
- Technical review: the rail authority's engineers review the documentation against required safety and operational standards.
- Testing and trials: the product is rigorously tested in a lab, and often trialled in the field, to prove it performs safely under real-world conditions.
- Report: a report detailing the process and outcomes is produced, feeding directly into certification.
- Certification: if every test succeeds, the authority issues type approval, sometimes as a certificate from a head of discipline, formally approving the product for use on the network.
The Back Story
Having elected to upgrade existing Kingfisher RTU CPUs to the latest generation, QR's replacement program required type approval. Replacing the CPUs while retaining the existing IO module footprint, since the modules were physically and electrically compatible, made “plug and play” sound straightforward. It wasn't, without caveats. Type testing revealed that some older-generation IO modules, while physically compatible, weren't compatible in the solution design itself. Specific modules turned out cheaper to replace outright than to refurbish onboard firmware after shipping them back to the factory.
“Plug and play” is a misleading phrase in this context, given the risk of operating high-voltage equipment that manages the traction power network. Electrical Control Operators need total confidence that the OT software, IEDs, and RTUs managing remote devices are monitoring and executing commands without exception. There's no margin for error.
Migrating software between platforms can leave legacy functions and configuration methods unsupported on the new target platform, so new designs have to compensate, and not every constraint is obvious at the outset. Compatibility between subsystem operating systems and compiled applications, generated via Instruction List, Structured Text, Function Block Diagram, Ladder Diagram, or Sequential Function Chart code, may genuinely be untested in this exact combination for the first time. Developers make every effort to port code between platforms before equipment ships, but the number of unique customised applications in the field is effectively endless, so the end customer has to take responsibility for validating their own configuration. In this case, QR, as the rail operator, took on that responsibility directly, which meant rigorously testing every configuration combination in current and reasonably foreseeable use. A general “fit for use in the power industry” statement has little bearing on type approval, that's a matter of electrical specification and functional capability, not certified suitability.
Type approval builds credibility and assurance. Organisations sometimes share or borrow type approval status from one another, but that should be treated with caution, particularly for configurable devices like RTUs, which are complex enough to be configured into failure even using standard programming functions. If use were standardised and identical across the board, sharing approval this way would carry little risk, but it rarely is.
The five steps read simply, but the detailed design and formal testing involved is far more complex than standard systems or test-harness testing. When a test fails and firmware or a compiled application is updated, an impact assessment determines what regression testing is required, sometimes repeating every test done previously, because the baseline operating environment has changed. Repeat testing carries real commercial cost, but the validation process can't be constrained by that cost without defeating its own purpose; commercial pressure is more likely to halt a program outright than to safely shortcut it.
Testing software across multiple layers of operating systems relies on experts taking the time to consider every permutation and operational use case. Any deviation from the tested operational envelope invalidates the type approval, which is another reason the entire process may need to restart from the beginning. Well-structured design and testing records, with a clear transcript of the sequence of activities, reduce the impact of a restart considerably. High-risk areas, particularly platform or core functions that other functions depend on, should be prioritised first, since testing the easy items first is rarely the right strategy.
For QR, the program delivered real operational and cost benefits, largely eliminating the need to rewire control cabinets and marshalling panels. Even so, every software configuration had to be validated before operational trials were permitted. Provisional approval came first, followed by operational trials in tightly controlled sections of the traction power network.
Type approval also means setting or adjusting operational boundaries, restricting how equipment is used so it operates as intended. That gives the program a framework for isolating known product deficiencies in specific scenarios. In this case, functional deficiencies were identified and accepted on the basis that those specific uses would be avoided. The issues were documented for awareness and folded directly into formal staff training, so operators understood the restrictions involved.
How Did It Go?
Restarting testing after weeks of work, introducing new firmware out of necessity, redesigning functions no longer supported on the legacy platform, updating configurations where “same function” no longer behaved the same way, and replacing specific hardware to avoid particular failure scenarios, all of it happened, and the program succeeded. The power network now runs the latest Kingfisher RTU CPUs, fully type approved. Type testing complex configurable devices is not for the faint hearted.
A consistent type approval framework produces outcomes where performance is baselined and operational certainty is safety assured.