Simplified, more sustainable water treatment

Currently, EVS Water operates only in Amazon Web Services (AWS) infrastructure, as it is tightly coupled to AWS capabilities for machine learning and data science. There are some possibilities for hosting some data locally, but these are highly dependent on specific project requirements, would be considered and would need to be discussed with our data management team.

We plan for the system to be up and running between 1-2 months. The calibrated deterministic model ensures a stable baseline for machine learning predictions. This has a strong benefit over machine learning only approaches which can require years of data to train properly.

EVS Water uses recurrent neural networks (RNN) powered by TensorFlow and Keras to calibrate models around a deterministic baseline. These tools have been chosen as they are widely accepted frameworks for applying RNN to challenges requiring identification of patterns in complex data sets. These frameworks are production-focused and integrated into the source code to enable accurate forecasts for EVS Water applications and allow for relatively rapid implementation and processing times. Input features to the RNN may include Feed/Coagulation pH, DOC, UV254, Temperature, Feed/Lamella Overflow Turbidity and coagulant dose, using both existing and a vendor installed instruments.

Sorption Capacity used in the deterministic model is also further calibrated by this RNN model to site specific conditions. The detailed design of the RNN models is developed as a result of close engagement with the customer and site personnel and depends on the design of the plant and available monitoring data.

We use a procedure for forecasting time series data based on an additive model where non-linear trends are fit with yearly, weekly, and daily seasonality, plus holiday effects. It works best with time series that have strong seasonal effects and several seasons of historical data. It is also robust to missing data and shifts in the trend, and typically handles outliers well.

Although technically feasible to connect with DCS/SCADA systems ​​​it is recommended that data for Plant Optimiser are obtained from the data historian rather than the DCS/SCADA system. Latency between DCS/SCADA systems is not typically of concern in applications of this type, which require approximately hourly resolution in data.

Further DCS/SCADA connected applications are typically associated with much longer timeframes associated with permissions and policies related to accessing the data stored there. Data historians (e.g. PI) are designed to interact with a wide variety of stakeholders including 3rd party vendors and we are confident that one of our three preferred methods for data management (code to Envirosuite’s API, ftp transfer to a WSD site, or ftp transfer to an Envirosuite site) will be accepted. Alternatives to this design will require a variation to the scope of work in this proposal.

PIDs, PFDs, monitoring points, representative monitoring data, dosing locations, equipment datasheets will be required to be shared at the start of the project. Data for nominated monitoring points will need to be shared at least daily during the operational phase of the project with protocols agreed at the start of the project.

To facilitate an evaluation of financial benefits, average unit cost of chemicals, electricity consumption, solid waste disposal and labour cost for the plant will be requested at the start of the project.