Impossible to base the Future on the past

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! see our app note what to look after

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 and new os to interface to it.

      • Host managed RTU applications – reducing the need for unique site logic/programs
      • Breaking vendor ‘lock in’ using open protocols

Can my existing RTUs with 10 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 10-15 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!

Share it with your freinds

Share on facebook
Share on twitter
Share on linkedin
Share on email
Overview - RTU protocols and driver setup
Your RTU application may simply be an 'end point' and only need to interface with a SCADA host or other master device - or it may need to 'sing and dance'...
1- Select what you need
The RTU Configuration Tool allows selection of protocols and hardware.
2 - Create a project in WorkSuite
Then define IO points, create some logic and additional variables eg. this waste water pump station controller accumulates pump statistics and computes derived flow totals from change in wet well volume.
3 - Setup DNP3 slave for this example
Use the Fieldbus Configurator to add the DNP3 slave protocol, create a channel (how to communicate), create a 'session' (who to communicate with), then set application layer parameters (messaging rules).
4 - 'Variables of interest'
Variables (data points in the RTU database) can be 'exposed' to one or more protocols, by referencing them in either the fieldbus editor (simple protocols like Modbus), or including them in a 'profile' (advanced protocols like IEC61850 and DNP3). For DNP3 slave, the variables of interest are dragged in to the DNP3S profile, where they can be associated to object types, given a point address, event class, reporting limits etc.
5 - Prove it works
Connect the RTU to the SCADA host and prove the data values are transferred correctly. If you need to troubleshoot the message contents - use the RTU web interface utility to capture network data packets for viewing in Wireshark to quickly resolve issues.
6 - Make it smarter!
The WorkSuite logic tools allow you to interact with the RTU communications tasks, to enhance the monitoring and control of your data transfer processes. This example DNP3 slave RTU is monitoring the unread events buffers and is able to manipulate point object properties (event class, reporting thresholds etc) and network interface properties (IP address of the host and peer slaves that it may be communicating with).
Conclusion - enjoy having a 'future proof' RTU...
Your RTU requirements will evolve over time, so when you need more I/O, comm ports, protocols or RTU functionality - know it can be easily implemented in a Brodersen RTU.
Previous
Next