RTU Architecture

Application Note: Doc 13011, May 2020

Application Note: The ‘game has changed’ – can your RTUs do this?

There are many ways of adding functionality, or getting around problems…

The RTU32M architecture provides more benefits than simply modular hardware!

Introduction

Building scalable solutions that meet user requirements has always been demanding for RTU vendors, but managing RTU applications has become increasingly challenging for SCADA managers.

Brodersen have been manufacturing products for use in remote monitoring and control solutions for more than 50 years. Our customer base is global and our products are used in a diverse range of applications that include energy management systems, water and waste water SCADA, infrastructure monitoring, building automation and airport management systems.

This Application Note provides an overview of significant changes to the architecture of the latest RTU32 Series products and discusses how SCADA system requirements have evolved and why it is important to think about future requirements when selecting RTUs.

Your ageing RTUs might meet requirements now – but what about in 15 years?

A capable systems engineer will usually find a way around most functionality issues/problems using their experience and skills.  However, work arounds become unmanageable and over time new requirements can only be met with a large step change in the base technology.  Think about mobile phone lifetime – RTUs use the same technology!

If your RTU vendor is trying to convince you that their ageing products meet your immediate needs and more functionality can be squeezed into their old CPU technologies if your requirements change – don’t believe it!  Technology is changing rapidly. You will soon need encryption, user authentication and web technologies and smart communications interfaces like 4G modems – this requires latest generation hardware.

The old way – a unique setup and logic program for each RTU

Most RTU applications have evolved from being managed by a program/set of software tools that ‘wrapped up’ the RTU configuration in to two components – the RTU setup/personality and the RTU logic. The RTU firmware and hardware were designed around proprietary methods of allowing embedded processors to provide RTU functionality. The objective was to allow a SCADA host to access data representing the current (and recent) state of field devices.

Host managed RTU applications – reducing the need for unique site logic/programs

Over the last 10-20 years, most large utility companies have moved to having their RTU applications managed from the SCADA host. As communications networks evolved with higher speeds and sufficient bandwidth to allow for both data transfer and transfer of configuration files, open protocols such as DNP3 became dominant because of support for ‘described’ data (message response includes the data format and data value – making it easier to ‘line up the ducks’), data priority, time stamped events and file transfer. As noted earlier, the old way of managing RTU applications meant each site would have a different logic application, primarily because parameters such as alarm limits and site functionality were managed within the logic programs. Managing logic programs requires use of logic editors and code compilers that are expensive and require a high level of technical expertise.

Utility SCADA systems also evolved to include object based site configurations that improve replication and management of site types. For example, a data model of a two pump waste water station ‘type’ that includes point data and associated graphics, alarms, trends etc can be easily cloned to manage hundreds of similar remote sites as site ‘instances’. In many cases the only difference between the multiple instances of a site type would be its site address – but in more complex systems some sites had multiple functions and unique parameters for alarming and control, in both the SCADA host and in the RTU site configuration.

To achieve host managed RTU applications, the unique requirements of each remote site / RTU is managed by site setup and site parameters files, rather than with unique logic programs. 

The logic programs contain generic ‘snippets’ of functionality such as pump control, flow metering and alarm limit processing that can be referenced by the site files to define how the RTU application operates. The creation and editing of the textual or binary format site files can be managed by the SCADA host (eg. using SQL tools to extract relevant site information from the SCADA host database), or external to the SCADA host using editors such as EXCEL.

A simplified overview of RTU functionality to meet the objective of host managed RTU applications

Breaking vendor ‘lock in’ using open protocols

The benefits of managing the RTU applications from the host vary, but if open protocols such as DNP3 and WITS-DNP3 are used, the ability for vendors to ‘lock in’ customers to using a single source for RTUs is broken.  Other benefits include improved version control of site applications (particularly if local configuration access is inhibited at the RTU level), a reduction in the number of licensed RTU configuration tools (third party software tools to generate logic programs) and improved security if using latest generation RTUs with advanced security capabilities.

Future requirements cannot be met with old RTU architectures

Do SCADA system managers ever experience that ‘mission accomplished’ feeling of contentment – everything has been deployed, is fully operational and all users are happy?  If so, it does not last long, or may never occur because the operational requirements of SCADA systems continually evolve and change for many reasons.

In the previous sections, functionality to achieve host managed RTU applications was described. Brodersen RTUs have had such functionality for many years within the message and data handling sections of the RTU firmware that is shown here in more detail.

Just as SCADA system requirements continually change, so do RTU functionality requirements. With mobile phone technology influencing the availability of embbeded device hardware and their operating systems, RTU developers need to carefully choose hardware platforms and firmware architectures that provide both longevity and capability.

While component reliability has improved and the life expectancy of RTU hardware may be >20 years, the availability and support for CPU architectures (the brains of the RTU) is now 10-15 years. ie. a RTU released in 2010 is likely obsolete well before 2025…

 RTU32M – a revolution!

Innovation requires ‘revolution’, not just evolution.

The recently released Brodersen RTU32M is a compact, modular product solution featuring hot swap, distributed smart I/O, redundancy and more. The 200-900MHz CPU runs an embedded Linux kernel using a chipset with guaranteed availability past 2035.

Flexible – add what you need, now or later

Start with a CPU and power supply, then add I/O and communications modules to meet site requirements.

RTU32M – the latest generation Brodersen hardware

Modern RTU Applications – need a flexible RTU hardware architecture

When describing host managed RTU applications earlier, the focus was on how the site configuration parameters and program logic necessary to monitor and control a remote site were defined to provide integration with a modern SCADA host.

Until recently, when considering RTU selection most users and vendors were encouraged to take a ‘one size fits all’ approach using a ‘brick’ style RTU with a mix of 20-30 I/O and 2-3 communication ports. The ‘rule of thumb’ was buy enough of these RTUs and they will get cheaper. What about the smaller or larger sites?

When the game changes so do the rules – future proof RTU architecture is the new ‘rule of thumb’

[R][T][U][3][2][M] modular hardware provides a lower cost, ‘future proof’, easy to maintain and flexible solution – pay for what you need now, or add it later if your requirements change.

I/O – as needed

The RTU32M modular hardware makes it very easy to create small to large RTUs to suit a wide range of I/O requirements. Start with a CPU and Power Supply then add I/O.

Distributed I/O

In some applications the I/O may need to be distributed to suit equipment and cabinet layouts. The RTU32M supports up to 80 modules with a 40m total bus length.

Ethernet, serial ports, or 4G NB1/CAT1 modem

Communications ports are just as important as I/O. The CPU module includes 2x 10/100 Ethernet ports, but if you need more ports, choose one or more of the comms modules. ET04A adds 4x Ethernet, SP04A adds 4x serial (3x RS232, 1x RS232/485), CM02A adds 1x Ethernet and 1x serial. The IM51 LTE modem is available in two formats to suit low speed NB1/IOT and high speed CAT1. All modules are managed by the RTU firmware and allow more than simply connection to a SCADA host eg. allow protocol gateways, message brokers and data concentrators.

Redundancy – you may not need it now…

In some high priority applications, the RTU may be required to have increased availability. The RTU32M can be used in SIL2 (Safety and Integrity Level) environments where increased availability is achieved using redundant hardware. Simply add comms, CPU, power supply and I/O modules as required to meet the desired high availability objectives.

Modern RTU Applications – need a modern CPU and firmware architecture

There is a limit to how far you can go with squeezing more features out of old CPU technologies. The RTU32M has a configurable CPU architecture that uses software license options to select CPU speeds of 200, 500 or 900MHz and RAM size of 128 or 256MB. Like the I/O hardware, you add/enable the level of CPU performance that you need, but most important is the capability of the embedded Linux kernel and the underlying firmware architecture that enables functionality that previous generation RTUs just cannot achieve. 

Can my existing RTUs with 15 year old CPU architecture meet my future requirements?

If we started a conversation about mobile phone evolution and discussed the capabilities of the models produced 15-20 years back to those produced now – it is difficult to do an ‘apples with apples’ comparison, because the old phones did not have the capability to do what users expect now. RTUs are no different – if you expect (and need) to have secure data, secure user interfaces and advanced processing capabilities you need to have a latest generation RTU, otherwise it is not future proof!

Smart Modules – report status/health, hours run, s/no and more

Every module is intelligent and able to report status information that can directly interface with asset management systems. I/O modules have parameters for each channel including AI range and scaling, DI debounce and state inversion, DO fail state (Hold, ON, OFF) and AO range, scaling and fail mode (Hold, or preset value).

User Interfaces – the $0 HMI generated by the RTU

The Brodersen WorkSuite software used to create RTU logic applications includes graphic generation tools that allow user displays to be published as html pages that the RTUs web server can present to local and remote users on their web browsers. This is a no cost option that allows operations data, trends, reports and diagnostic information to be viewed on PCs, tablets and smart phones. Use a low cost industrial Android tablet if a local HMI is needed – no setup required, displays are managed by the RTU!

Security – latest generation RTUs feature advanced security

All utility companies are needing to conform with government policies regarding security of critical infrastructure. IEC62443 specifies cyber security capabilities for control systems. Read more about RTU security – LDAP (user authentication), Encrypted Storage, Firewall,VPN, HTTPS, SSH, SSL, SFTP and signed applications in our RTU Security App Note.  

Signed Updates – apps and f/w use encrypted key signatures

The RTU supports secure updates of ‘signed’ user applications, firmware and I/O module firmware via file transfer / logic. Secure future proofing!

Getting Connected – SCADA protocols and secure interfaces

Your project requirements may initially be focused on the protocol used to transfer data to the SCADA host. Brodersen RTU SCADA protocols include DNP3, WITS-DNP3, IEC60870 and IEC61850 that are well proven at doing this – use VPN if additional link security is required. But a modern RTU needs to also allow secure connection to its setup (SSH), web server (HTTPS) and file system (SFTP and DNP File Transfer). It may also need to interact with corporate IT systems (SNMP and SYSLOG) or interface with other local devices (MODBUS, ProfiNet, Ethernet/IP) or IOT devices and IOT Networks (MQTT Client and Broker/Server).

Multi-tasking – the RTU can run up to 4x different tasks (it’s like having 4 RTUs instead of one)

Large applications can benefit from being split in to multiple tasks   eg. task 1 may handle I/O processing and interface to the SCADA host, task 2 may handle the site logic application, task 3 may handle the unique requirements of a particular site. ‘Public’ variables can be shared between tasks.

Modern RTU Applications – also need latest generation software tools

Having discussed host managed RTU applications and the reasons for using a future proof RTU architecture, the software tools used for management of a modern RTU should also be considered. For many years ISaGRAF was used by a lot of RTU vendors to provide their RTU logic ‘engine’, but as it has not been updated for almost 10 years, most have moved to other third party platforms, including CODESYS and straton. What did the original developers of ISaGRAF do next – they developed straton, a modern IEC61131-3 logic platform.

WorkSuite

Brodersen WorkSuite is a powerful set of software tools built around the straton logic platform. WorkSuite does more than manage logic programs, it allows setup of local and remote I/O, communications interfaces, data storage and transfer and creation of user interfaces / HMI. Program in ladder logic, function block diagram or structured text – each has its merits, but best of all you can convert from one format to the other.

Click here to find out more about the WorkSuite software tools functionality.

Embedded SCADA running in the RTU allows even more functionality – is this the future?

Earlier we showed the RTU as a slave to the SCADA host. In the near future it is likely that this concept may be ‘turned upside down’ ie. more of the data processing, analysis and data presentation (displays, trends, reports etc) may be undertaken by the RTU. Interested users and SCADA hosts will subscribe to ‘data of interest’ that resides in the RTU. The example shown here is an ‘instance’ of the same DNP3 pump station template that can be used in the SCADA host, but it is running in the RTU, allowing local and remote users to connect from a secure iPhone or Android client ‘app’ using their smart phone/tablet.

Embedded SCADA – logic, graphics, trends, alarms, historian…

Conclusion – make sure you choose a future proof RTU!

The latest generation of Brodersen RTUs have all of the functionality described above because of their flexible hardware architecture, modern firmware and software tools.  Can your RTUs do this?