Advanced IIoT
Application Note:
Building Advanced IIoT Applications - by combining Remote I/O and SCADA Concepts
Using intermediate controllers between the SCADA host and remote I/O devices
There are many applications that require a combination of remote monitoring and supervisory control, as shown in the SCADA subsystem here that manages remote borefields and interacts with a corporate SCADA system. Recent growth in the deployment and market acceptance of Industrial Internet of Things (IIoT) devices allows cost savings in many remote monitoring applications, but when the system must also include supervisory control then an additional ’layer’ of intermediate controllers is often required. Brodersen M Series modular hardware includes functionality that can be easily setup to create intermediate controllers using a mix of I/O, logic, data logging and HMI that enhance the management and use of IIoT devices.
The most important consideration for any control system – the cost of down time!
When looking at how a control system should be setup or deployed there are many requirements and factors to be considered, but before trying to determine what the cost of implementation might be – don’t forget to look at what the costs might be if the system fails or has problems ie. the down time costs.
In plant type applications, down time costs are usually assessed as the loss of revenue caused by failure of all/parts of the control system. However, there are also some additional costs that need to be considered – particularly when systems are in a remote location. These costs quickly escalate if the system is complex (requires ’expert’ outside assistance), does not have ’fault tolerant’ capabilities, lacks local/remote diagnostics or does not have both local and remote auto/manual operation functionality ie. can the various parts of the system still be operated via local HMI style interfaces if the overall primary/host system is not available/connected…
Functionality you didn’t think you would need!
Most control system design starts with a ’mud map’ style overview sketch of the various parts of a system. In the example shown here with a tank and 3x water bores the physical layout of the site, the capacity of the bores, the operations philosophy and user requirements need to be understood before the control system design can be started.
If the user requirements are basic and the system capacity is small then likely that a low cost IIoT style solution might be appropriate. The basic set of user requirements will get a ’tick in the box’ and the overall system cost will be reduced by using IIoT style field devices connected to a cloud based server when compared to traditional hard wired control systems that typically use PLCs. The system may even be deployed and work just as intended…
However, in many cases there are unforseen user requirements that did not seem relevant at first, but soon appear either within the initial system, or later when the system is expanded, or when the concept is replicated for the next borefield. For example, individual bores may not all produce similar quantities of water, some bores may require additional instrumentation (use of VFDs, dual pump sets, pressure and flow monitoring etc), some bores can only be run for a fixed duration and need a ’rest’ between operations, power supply restrictions were not considered (cost of power at peak times, or availabilty of power in solar pumping applications), some bores may need to be used for injection (return of excess production etc).
When systems like borefields are ’scaled up’ – what worked in a small system may not work in a larger system. Small systems may have low cost flow meters (per bore, or a single meter), but large systems may benefit from using ’inferred’ flow measurement eg. run ’proving’ cycles where each individual bore is run in turn and changes in the local tank level are used to compute the flow rate using volume/time to find initial flowrate and decayed flowrate after extended operation. Interaction between the various system parts within a system will often require logic to manage/arbitrate operation of monitoring and control devices (including setpoints, interlocks, user authority levels, failasafe operation etc) and may also require use of additional ’device protocols’ to allow the devices to interact eg. industry standard device protocols such as Modbus, Profinet, Ethernet/IP, DNP3, IEC61850 etc.
If the system has the bores distributed over long distances, then local/wide area communications using the IIoT device communications interfaces may not work reliably, or at all and additional network interfaces may be required eg. data radios, 4G modems, fibre modems etc.
Communications protocols have very different delivery and reliability concepts
Many IIoT applications have reliability issues when trying to include control of devices and equipment, rather than simple monitoring. This is typically because of the way messages are managed by default in IIoT applications and that the IIoT devices interacting with each other have limited logic and message management capabilities. It is wrong to asume that the different communications protocols found in PLCs, RTUs, HMIs, field instruments (eg. flow meters), VSDs (eg. variable speed drives attached to pumps) and IIoT devices offer the same functionality , or that only their formats/contents differ.
IIoT uses MQTT – the message format primarily used in
IIoT applications is the Message Queing Telemetry Transport (MQTT)
protocol. MQTT provides a lightweight
publish/subscribe interface suitable for use on low power microcontrollers to
optimise network bandwith by using compact messages. In a typical IIoT system, the field devices
publish their data to a broker (as clients that push ’changes’ to the
broker). The users register interest
with the broker of various data ’topics’ so the broker knows to send updates to
the user when the data changes (broker acts as a server to update the user
clients when they connect).
As shown above, the MQTT broker creates a ’disconnect’ between the field device (the publisher) and the user (the subscriber). The MQTT broker allows the field device to offload the responsibility of delivering messages to the subscribers. This concept is beneficial to the low power IIoT field device as it can power up, ’chirp’ a short message to the broker, then resume low power monitoring mode without having find multiple subscribers, manage retries or even be concerned if messages are not read by recipents/subscribers.
Field devices use simple protocols like Modbus – communication between field devices in plant automation type applications use simple protocols like Modbus. These protocols use ’polling’ by a master device of one or more slave devices to request various data values. Output values can be written routinely or on change. These protocols are considered ’query/response’ (send a message and wait for the response before sending another message), they do not include routing information (a Modbus message only includes a destination address so cannot be easily transported outside of the local area) and have simple static content (no dynamic content such as changed data events, data quality or device quality).
SCADA systems use protocols like DNP3 – communications in wide area SCADA systems use sophisticated protocols such as DNP3 that include advanaced message management functionality to allow priortising of message delivery, buffering of unread events, routable messages, unsolicited messaging (messages initiated by the slave device), peer to peer messaging (slaves can interact with each other) and dynamic message content (messages include data values, time stamped events/changes, data quality, device quality, message sequence information etc).
