QR Type Approval for Kingfisher RTUs for Traction Power

This article delves into the essential framework and practical application of type approval, a mandated process for ensuring the operational suitability of new or modified rail equipment. It outlines the standard five-step procedure—from the initial application and technical review to rigorous testing, reporting, and final certification by the governing authority.

A case study involving Queensland Rail (QR) upgrading their Remote Terminal Unit (RTU) CPUs illustrates the complexity of this process, revealing that even seemingly simple “plug and play” replacements require extensive validation of all software configurations due to subtle compatibility issues and the zero margin for error when managing high-voltage traction power. Furthermore, the discussion highlights that type approval involves establishing specific operational boundaries and accepting documented functional deficiencies that will be managed via formal staff training.

• Why is type approval important?
• What are the basic steps for getting type approval?
• The back story
• How did it go?

Why is type approval important?

Type approval is critical to industry as it provides a standardised, formal process to ensure the safety, reliability, and interoperability of all new or modified equipment. It serves as a vital risk management tool by mandating rigorous testing and evaluation of components for signalling systems, traction power, and rolling stock, thereby preventing accidents and operational failures. A consistent Type Approval framework produces outcomes where performance is baselined, and operational certainty is safety assured. Without this process, the industry would face significant safety risks, increased costs, and barriers to innovation and technological advancement as mistakes and poor performance would litter the technology landscape.

What are the basic steps for getting type approval?

The basic steps for type approval are as follows.

Application: A supplier submits a comprehensive package of technical documents, designs, certifications, and safety analyses for the new product to a governing body that will verify the process is in order.

Technical Review: The rail authority’s engineers review the documentation to ensure the design meets all required safety and operational standards.

Testing and Trials: The product is rigorously tested in a lab and often in field trials on the railway network to prove it performs safely and correctly under real-world conditions.

Report: Following completion of testing and any related trial, a report is provided detailing the process and outcomes. This report is an input for the certification.

Certification: If all tests are successful, the authority issues type approval, sometimes in the form of 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 mandated type approval. The replacement of the CPUs to next generation meant the IO module footprint could be retained as they were physically and electrically compatible. The concept of “plug and play” was sound but not without caveats. During type testing it was discovered that a combination of older generation IO modules though physically compatible, in the solution design were not. Specific modules were more economical to replace, than to refurbish the onboard firmware after transporting back to the factory.

Plug and play in this context is wildly inappropriate given the risks around operating HV equipment used to manage the traction power network. Operators (ECO’s – Electrical Control Operators) must have total confidence when they use SCADA, that the OT software systems, IEDs, and RTUs used to manage remote devices, are monitoring and executing their commands 100% of the time. There are no margins for error. How can this even be reasonable?

When migrating software from one platform to another, legacy functions and methods of configuration may not be supported on the newer target platform. New designs are developed to adjust for these constraints. The challenge is some of the constraints are not obvious at inception. In addition, compatibility between subsystem operating systems and compiled applications (via Instruction List (IL), Structured Text (ST), Function Block Diagram (FBD), Ladder Diagram (LD), and Sequential Function Chart (SFC) generated code) may yet to be established and are now “first time” use.

Every effort is made by developers to port code between platforms before shipping equipment to customers for use, however, the number of unique customised applications is endless, therefore consumers must make themselves aware and must act to remove the risk of unforeseen use. In our story here, the consumer (QR as a rail operator) took the responsibility to ensure the safe use of the equipment inside the configuration of their own system design. This implies rigorous testing of all configuration combinations in use for the existing system design and its foreseeable future use. This also means that a general statement of “fit for use in the power industry” has little to do with type approval and more closely aligned with electrical specifications and suitable functional capabilities on branding documents.

Type approval establishes credibility and assurance. Often different organisations share the burden or borrow type approval status from one another, however application of such should be treated cautiously especially for configurable devices like RTUs which are complex and can be configured to fail using standard programming functions. It the use was standardised and exactly the same this sharing and borrowing would be of no concern.

As simple as the 5-step process reads, the detailed design and formal testing is far more complex and onerous than standard systems or test harness testing. For example, when a test fails and firmware or a compiled application is subsequently updated, impact assessment is carried out to determine what regression testing is then required. In some cases that can mean repeating every test previously done. This is because the baseline operating systems have changed. Repeating testing has commercial implications which cannot constrain the validation process as that defeats the purpose of type testing. Commercial constraints are more likely to put a halt to the program in its entirety.

Software type testing with multiple layers of operating systems relies on experts taking the time to consider all permutations and operational use. A deviation of the operational envelope implies the type testing approval is no longer valid and this is another reason the entire type testing process may be required to recommence from the beginning. To reduce the impacts of likely restarts, the design and testing records should be well structured and include clear transcripts including the sequence of activities. This forward planning can greatly reduce the impact of significant regression testing. High risk areas like platform or core functions which other functions rely on, should be prioritised to create a good base upon what to build. Doing the easy tests first is unlikely the best test strategy.

For QR, significant operational risk and cost saving occurred because the rewiring of control cabinets and marshalling panels was virtually eliminated. Despite this, all software configurations needed to be validated before operational trials would be permitted. Provisional approval was granted prior to operational trials and then operational trials followed in tightly controlled pockets of the traction power network.

Another aspect of type approval is setting or adjusting the operational boundaries. This means placing restrictions on how the equipment is to be used so that it operates as intended. This methodology provides a framework to isolate known product deficiencies in specific scenarios. In this Type Testing example, functional deficiencies were determined and subsequently accepted on the basis that they would not be used. The issues were documented for awareness and for future consideration. This awareness was integrated in the formal training of staff so they were fully aware of the necessary restrictions.

How did it go?

Restarting testing after weeks of work, new firmware introduced by necessity, change of functional designs due to no longer supported legacy functions, updated configurations to cater for “same functions” not being the same, replacement of specific hardware to avoid particular scenarios, it was all there, and mission accomplished. The power network now includes the latest Kingfisher RTU CPUs, type approved.

Type testing complex configurable devices is not for the faint hearted.

SCADA, Control Systems and Services, PLC & RTU Solutions Pacific National SCADA Software and Critical RTUs replaced Modernising Traction Power without downtime