Distributed and Remote I/O
Application Note: Doc 13021, September 2020
Video – Distributed and Remote I/O
Application Note: RTU32M – Plant Applications
Management of Distributed and Remote I/O
Plant applications require lots of I/O – but not all in one place as shown here…
Introduction
The latest generation modular Brodersen RTUs not only improve the functionality available for our traditional small-medium sized remote site applications, but they also meet the requirements of plant style applications. Our previous generation of brick style RTUs have always supported I/O expansion and allowed for creation of distributed I/O solutions, but their physical size, power requirements and limited functionality of the I/O modules meant that such solutions did not meet expectations, or match capabilities of large PLCs.
This application note describes how the RTU32M series I/O modules can be used in plant applications where I/O is both distributed within a cabinet and located remotely around the plant on an Ethernet LAN.
RTU32M – with advanced PLC functionality suitable for plant applications:
- Secure local and remote access to configuration and diagnostics
- Small footprint, high density modular I/O
- Failsafe, hot swap, smart I/O
- Online logic changes (including application restart with outputs held)
- Distributed I/O (segmented bus)
- Remote I/O (serial and LAN based I/O – remote CPUs have no logic app or options)
- Redundancy options (multiple power supplies, CPUs, I/O, LANs etc)
- Global variable ‘binding’ allows fast setup of a single plant wide logic application
- Future proof (option to include logic/smarts in the remote RTUs, when needs change)
- Modern platform, ensuring longevity and continued development of functionality (including new module types).
Most RTUs are well suited for remote site applications (typically <200 I/O)
In the past – when asked to highlight the differences and benefits of using an RTU versus a PLC, the benefits of using RTUs focused on I/O isolation and SCADA protocols that are not well supported by PLCs, such as IEC60870, IEC61850 and DNP3. These protocols allow for prioritisation of data, logging of time stamped events, inclusion of data quality and described data formats, hence they are well suited for wide area SCADA systems with geographically dispersed remote sites. As the majority of the remote sites had <200 I/O, physical size and management of distributed I/O did not need to be considered – so the I/O isolation and protocol functionality was enough to make the RTU the best choice.
Not all RTUs suit plant applications (typically >200 distributed/remote I/O)
Plant applications have large amounts of I/O that need to be distributed remotely because of the various separated areas that form the plant. The physical size of the I/O is important, but the remote I/O must also be managed by the primary/central PLC/RTU ie. as an extension of its own physical I/O.
Online RTU Configurator – Design what you need!
Our RTU Configurator allows creation of different RTU setups. Add power supplies, CPU, I/O and comms modules to create appropriate RTU layouts.
It’s a bit different to a ‘stacking bricks’ TETRIS game, but still fun!
Large RTUs and Distributed I/O (expansion I/O using the RTU IO Bus)
Each RTU32M supports up to 60 I/O modules. The overall backplane bus length can be up to 40m (assuming that appropriate bus cables are used).
Plant solutions need local and remote I/O to be managed in a single application
Most plant applications have a combination of distributed and remote I/O. An important consideration is management of the remote I/O. It is much easier to manage the plant automation in a single/central logic application if the remote I/O is ‘connected’ by a background process that ensures remote I/O is referenced in the same way as local I/O. This also avoids needing logic applications in the remote I/O sites.
Build it and they will come …
It is very tempting to completely fill a test rack with hundreds of RTU modules – just because we can!
Instead, we loaded it with four RTUs to represent the main plant and 3x remote area locations of the example plant application shown below.
Objective – prove one logic application can manage all I/O!
WorkSuite – managing the setup of multiple I/O locations
The Brodersen WorkSuite software makes it easy to setup and manage the sites. Each site has a ‘project’ that is listed in a common Workspace area as shown below eg. ‘IO Boxes 1-3’ and the ‘IO Box Master’.
The Global Binding Editor – mapping tables make association of remote I/O easy…
The Global Binding Editor allows the association of tags from the various projects in the Workspace to be made by dragging variables in to a table.
Communications between sites then occurs if any of the producer data values change (without needing to setup logic or comms tasks to send/poll data).
An initial ‘proof of concept’ setup example.
Before creating a more complex solution, first look at the simple example below. Here a few input points from each location are ‘produced’ and sent on change to remote consumer output points.
Note: this simple example is moving ‘physical I/O’ ie. AI and DI values from one site to AO and DO values at another site.
In most plant applications the primary function of the binding protocol is to allow the master to have an image of all remote variables (updates to input images are received from the remote site – writing to an output image sends an update to the remote site). The variables associated to/from the remote sites can be any variable type (not just physical I/O).
The Global Binding Editor – link and point information, tag debounce/hysteresis
Each communications link reports its connection status and each point has additional status fields that include error status and date and time stamps. Each point also has a hysteresis option to manage debounce and significant change (minimises excessive event reporting).
Back to the example plant application…
The Master RTU has ~90 of its local I/O variables and ~130 remote I/O variables (‘tags of interest’) mapped from/to the remote sites. The logic application interacts with the master list of variables (local/remote I/O).
Note: the master has an additional 98 local I/O tags associated to its own physical I/O.
Plant Application – the Binding Editor maps variables from/to the remote sites
The Binding Editor adds a column for each site. The first column holds producer variables. In the example plant application, each remote site produces its physical inputs, as listed below.
In the example plant application, the master produces its images of the remote physical outputs, as listed below.
Plant Application – proving that it works
A selection of local and remote I/O variables have been mapped to a simple pump controller application to demonstrate/prove the concept.
Get on the Brodersen Bus – local and remote I/O solutions!
Very remote I/O – far far away in Melbourne Australia…
Watch our 10m video to find out if the test application worked.
