PLC configuration for use with HPP
Abstract
The client’s PLCs require slight modifications in order to be able to operate the wastewater treatment plant/sewer network by setpoints retrieved from the selected features hosted in the cloud solutions Hubgrade Wastewater Plant Performance and the Hubgrade Sewer Performance modules (hereinafter Hubgrade).
- The modifications comprise:
Tag name matching between the PLCs at the wastewater treatment plant/sewer network and the Hubgrade features, in order to exchange input/output signals.
Implementation of a watchdog strategy in the local PLCs to operate either by optimised setpoints from Hubgrade or basic setpoints from SCADA.
Enabling the execution of any setpoints from Hubgrade by the local PLCs.
Introduction
This technical description describes how a wastewater treatment plant/sewer network should configure its PLCs for optimal integration with the Hubgrade Performance, Plant module (hereinafter Hubgrade) software service.
Hubgrade is a cloud based service that receives operational data from wastewater treatment plants and sewer networks and on basis of these calculate optimised setpoints for the actuators regulating the plant operations. Hubgrade optimises the processes and the flows at the plant and/or in the sewer network in order to minimise the electricity costs, the chemical dosing, etc., and/or to increase the hydraulic and biological capacity, the energy production, etc., while ensuring stable operation and compliance with quality objectives for the wastewater systems.
The measurements come from sensors that measure ammonium, nitrate, phosphate, sludge blanket, flows, etc., and actuators are typically blowers, mixers, pumps, weirs, and dosage equipment. All sensors are connected to the local PLCs which communicate with Hubgrade and all actuators are ultimately controlled by the local PLCs which receive optimised setpoints from Hubgrade.
- This document provides:
A conceptual view on the connectivity between a plant/sewer network’s PLCs and Hubgrade.
A description of the software’s I/O tag syntax, i.e. the naming convention that are being used by Hubgrade for its input and output data elements.
A description of the configuration of the local PLCs with functionality (watchdogs) for enabling and disabling the use of the optimised setpoints calculated by Hubgrade.
A description of PLC modification necessary for the execution of any setpoints from Hubgrade.
An example of how to program a PLC controlling the actuators at the plant/sewer network.
Connectivity
The connectivity between the PLCs at the plant/sewer network and Hubgrade is based on the OPC UA protocol - Hubgrade has a built-in OPC UA server in the cloud that the PLCs at the plant/sewer network connects to when sending measurements and when requesting updated setpoints.
At the plant/sewer network the connection to Hubgrade’s OPC UA server can be established in a number of different ways. These are described in the Technical Description “Standard Practice - secure implementation of Hubgrade”. Suffice here to say that the connection links an existing or a new OPC server at the plant/sewer network with Hubgrade’s built-in OPC UA server.
PLC modifications for tag name matching between Hubgrade and a local PLC
Hubgrade exchanges data with the plant/sewer network through OPC tag matching.
All data that are being connected to the OPC system at the plant/sewer network are identified via a unique tag name. Only a small part of these are relevant to Hubgrade and which depends on the selected Hubgrade features.
Similarly, all input and output data on which Hubgrade operates are identified via Hubgrade’s unique tag names.
Connecting the plant/sewer network to Hubgrade involves matching those tag names which are relevant for the selected features of Hubgrade.
- Important: On the PLC level any data type is applicable, i.e:
Data from PLCs to Hubgrade: Any PLC data type can be used and will be automatically converted to 64 bit floating point by the OPC Bridge.
Data from Hubgrade to PLCs: The OPC Bridge may convert 64 bit floating point data as appropriate to match the data type in the PLCs.
If the data type in the PLC is changed by the PLC programmer, the OPC Bridge must be restarted.
- Hubgrade tag names follow a unitOperation.subUnitOperation.type.subType nomenclature where:
unitOperation identifies the operational area in which the data is captured or being applied. Examples include BIOLOGY and PRIMARY as referring respectively to the biological treatment stage and primary treatment stage in the wastewater treatment plant.
subUnitOperation identifies the location within the operational area where the data is captured or being applied. Examples include LINE 1 and LINE 2 TANK 1
Type identifies the data type and covers items like NH4 (ammonium), SS (suspended solids), etc.
- subType - provides a further identification of the data. This could for example be one or more of the following:
SETPOINT - a setpoint value from Hubgrade to a local PLC
STATE - an operational state (on/off): 0 = inactive/not ready and 1 = active/ready
ERROR - a measurement error of a sensor: 0 = error and 1 = ready/OK (OBS: might be in contradiction to conventionally used practice where 0 often equals “no errors”)
COUNTER - a counter value, e.g. accumulated flow, m3
MIN
MAX
WD - watchdog, please refer to section 4
Tag table
- Feature by feature a table will be provided for the tag matching. Hubgrade operates with a unit standard. If the local unit standard deviates from Hubgrade unit standard, as expressed in the unit column, cf. below, the PLC must make a conversion, so that Hubgrade receives input in Hubgrade unit standard and the actuators receive setpoints in local unit standard. As examples:
If a local sensor operates in l/s, whereas Hubgrade operates in m3/h, the PLC must make the conversion in an extra tag before sending the measurement to Hubgrade.
If a setpoint is retrieved from Hubgrade in m3/h and a local actuator operates in l/s, the PLC must make the conversion before sending the setpoint to the actuator.
In the tag table inputs to Hubgrade are marked with an up-arrow ↑ (measurement UP to Cloud). Outputs from Hubgrade are marked with a down-arrow ↓ (setpoint DOWN from Cloud)
Example of a tag table:
Item |
Tag name |
Unit |
|
↑ |
Input/Measurement:
Sludge blanket in settler line x, settler tank y, one in each settler
|
SECONDARYSETTLER.LINE x TANK y.SLB
(substitute x with line No. and y with the tank No.)
|
m from bottom of tank |
↓ |
Output/Setpoint:
Return activated sludge flow from each settler
|
SECONDARYSETTLER.LINE x TANK y RETURNSLUDGE.Q.SETPOINT
(substitute x with line No. and y with the tank No.)
|
m3/h |
For a plant with sludge blanket measurements in secondary settler line 1, tank 2, 4 and 6, this results in 3 inputs, as follows:
SECONDARYSETTLER.LINE 1 TANK 2.SLBL SECONDARYSETTLER.LINE 1 TANK 4.SLBL SECONDARYSETTLER.LINE 1 TANK 6.SLBL
- There can be up to 6 different types of tag tables. For each project the relevant tag tables and specific I/Os will be provided:
Measurements (need to have) Inputs required for optimisation computations. Example: The Return Activated Sludge feature uses flow measurement and either MLSS measurement or sludge blanket measurement to compute the setpoint for the return activated sludge flow.
Measurements (nice to have) Inputs which can: #. Support that Hubgrade can reach its maximum optimization level when multiple measurements are available for the calculations. Example: The Return Activated Sludge feature setpoint will be improved if both MLSS and sludge blanket measurements are available. #. Improve Hubgrade’s multiple control level strategy, which ensures optimisation, however at a lower level, in case the most preferred measurements are not available. Example: The Return Activated Sludge feature can use flow measurements from various locations in the plant. If more measurements are available Hubgrade will define which one is the preferred for the computations. If the preferred measurement is not valid Hubgrade will use another valid measurement for the computations. #. Provide the operator with an improved overview of the process performance, and hence an opportunity to make decisions for the optimal performance. Example: Return activated sludge measurements will improve the operator’s ability to evaluate the execution of setpoints from Hubgrade.
Measurements, Additional Benefits (need to have) Inputs required for optimisation computations related to any Additional Benefits of a feature. Additional Benefits will be activated automatically provided required sensor inputs are available. Example: Sludge blanket measurements in each settler will automatically activate the Additional Benefit called Flow Distribution of the Return Activated Sludge feature.
Measurements, Additional Benefits (nice to have) Cf. item 2 above for types of improvements of Additional Benefits.
Setpoints - one or more, depending on the plant actuators and the basic SCADA control Optimized setpoints computed by the algorithms of Hubgrade for the PLCs to execute in the actuators. Example: The Return Activated Sludge feature of Hubgrade provides a setpoint in m3/h for the return activated sludge flow at the plant, preferably one flow for each settler, alternatively one common flow for each settler line.
Watchdog / keep-alive signals. Cf. section 4 and section 6 (example) below.
PLC modifications for Hubgrade watchdog strategy
A watchdog strategy in the local PLCs allows the plant/sewer network to operate either by optimised setpoints from Hubgrade or basic setpoints from SCADA. The watchdog strategy implies that: the operator can enable/disable individually the features of Hubgrade, i.e. some features can be disabled while others are kept enabled
The data communication is monitored
In case features are disabled or communication issues occur, the PLCs must be programmed to implement a fall-back to the basic SCADA control.
A watchdog strategy must be implemented to each actuator which rely on Hubgrade setpoints to a PLC. Hubgrade features which provide overview (e.g. SewerView), forecast (e.g. Stormwater Forecast) or acts through other features (e.g. Stormwater Mode) will not have watchdogs.
- The watchdog strategy comprises the following:
Hubgrade watchdogs inform the PLCs whether the optimised Hubgrade setpoints are valid for the PLCs to control the actuators. A Hubgrade user with the appropriate user rights might disable an Hubgrade feature from the Hubgrade user interface or Hubgrade might decide that incoming data to a feature are of poor quality and decide to disable a PLC’s use of the optimised setpoints calculated by that feature. In both cases Hubgrade will use an Hubgrade watchdog to inform the PLC that it shall disregard Hubgrade calculated setpoints from that feature.
Keep-alive signal from Hubgrade to the PLCs - i.e. a way for the PLCs to be ensured that the communication with Hubgrade is online and ‘fresh’ setpoints are transferred to the PLCs.
Keep-alive signal from the PLCs to Hubgrade - i.e. a way for Hubgrade to be ensured that the communication with the PLCs is online.
The figure below illustrates the watchdog strategy and section 4.1 and 4.2 give further details:
Note: For connectivity and security please refer to the Technical Description “Standard Practice - secure implementation of Hubgrade”. The above is for illustration of the logical flow related to the watchdog strategy only.
Hubgrade watchdog
Hubgrade defines one Hubgrade watchdog for each feature (if a feature is repeated in more lines each line must have a watchdog). Each of these watchdogs are implemented as an output element that are being communicated from Hubgrade to the PLCs.
Example: SECONDARYSETTLER.LINE 1.SETPOINTWD.SETPOINT RETURNSLUDGE is the name of the watchdog used by the Return Activated Sludge feature that has been deployed at the settling line 1 at the wastewater treatment plant.
- Hubgrade sets the Hubgrade watchdog value to either 0 or 2.
When Hubgrade sets the value to 2 it is a signal to the PLC controlling the related actuator that it should use the setpoint coming from Hubgrade.
When Hubgrade sets the value to 0 it signals that the PLC controlling the related actuator should not use the Hubgrade generated setpoint.
Communication validation by using keep-alive signal
Hubgrade provides a keep alive signal with the tag name TIME.MINUTES OF DAY SETPOINT which gives the minute of the day. Each PLC must retrieve this signal in order to ensure the communication from Hubgrade is online to this PLC.
In case the PLC has not retrieved an updated value of the keep-alive signal within a specified period of time, the PLC shall assume that the connection between Hubgrade and the PLC is down. In this case the PLC in question shall disregard Hubgrade setpoints and revert to basic SCADA control until the PLC registers the keep-alive signal is updating again.
The specified period of time should typically be set to 10 minutes in the PLC.
To validate the connection from the PLC to Hubgrade, the PLC must send a counter value to the Hubgrade tag name TIME.MINUTES OF DAY SCADA. For example, a counter value could have the format “minute of day”. If the counter value received by Hubgrade does not change, Hubgrade will know that the communication from the PLC or the PLCs to Hubgrade is inactive. In case of multiple PLCs the main PLC must produce a keep-alive signal representing the communication state of the relevant PLC environment.
PLC modifications for execution of Hubgrade setpoints
This section describes the PLC modifications and testing that has to take place when Hubgrade is deployed at a plant/sewer network in order for the PLCs to execute the optimised setpoints from Hubgrade.
Control of the client’s actuators (pumps, blowers, dosing equipment, etc) is always done by the PLCs, and often just by using the same PLC control program with addition of the watchdog strategy, whether setpoints are retrieved from Hubgrade or from the SCADA.
- Important: The PLCs must ensure that any actuators are not operated outside the operating range for which the actuator is designed, even if Hubgrade should provide set points that are outside the actuator’s operating range. Consequently the PLCs shall validate the received Hubgrade setpoints and ensure they are valid and are within the safety range for the related actuator. Examples could be e.g.:
If any equipment can be damaged, e.g. at too frequent starts and stops, the PLC must make sure that it cannot be done.
If a setpoint from Hubgrade implies that an actuator shall operate at a lower frequency than it is designed for, the PLC must ensure that the actuator’s minimum frequency is respected.
