Water System Monitoring

Thousands have lived without love, not one without water
~W.H. Auden

In Washington State there are two types of public water systems as defined by the department of health. Group A systems are the largest and consist of any system with more than 14 connections (or serve 25 or more individuals for 60 or more days per year). Group B water systems serve fewer than 15 connections and 25 people per day. As you can imagine there are large disparities in these water systems in the category for Class A systems. Large Class A water systems run by municipalities and counties have the resources and customer base to properly monitor and service these systems, while neighborhood community Class B systems lack the expertise and resources to properly monitor and service the equipment. Most of these smaller water systems rely on third party management companies who lack the expertise and training that maintaining a water system requires. I know this because I live in a community with a water system that we own and have dealt first-hand with the issues (and unfortunately the results of losing water for multiple days on end). With four kids this was a terrible state to be in!

Some of the issues that we faced were a direct result of poor monitoring. The first issue was that all monitoring was analog and local to the pump house. Our first line of defense was a mechanical float that gave us tank level but required constant monitoring (walking by the tank to ensure the level was not drawn down). Typically, neighbors up the street would notice a loss of water pressure and subsequently a walk to the tank would show that the tank was depleted. The issues over the years ranged from blocked filters on the well pumps to actual pump failures. However, the only means of finding flow issues were to take readings at the mechanical flow meter using a stopwatch to determine actual flow out of the ground. This was difficult as the pump was not always running and required timing to determine how much the well was producing. As a controls engineer who is fascinated by connecting sensors and devices at the edge to the cloud, this was an ample opportunity to build a robust monitoring system that would alert on failure and give the community an opportunity to address issues before we lost our water. My first approach was to fix the tank level issue. Not having real time visibility to the tank level and generating an alarm when it reached below a threshold was paramount to fixing imminent loss of water. If we had an alarm prior to water loss we could implement mitigation strategies:

1. Conservation to ride through short term issues and at least keep minimal water for critical tasks (flushing toilets, cooking and washing dishes)
2. Provide an opportunity to bring temporary water (prior to loss) to the tank in case of larger mechanical and electrical failures.

Once the real time monitoring was in place for tank level the next task was to build robust monitoring for well production and water flow to the neighborhood. By having flow in and out of the system we could not only monitor long term health (mechanical issues, obstructions, etc.) but also start predicting possible leaks in the system or out in the neighborhood. This is when having the data aggregated in the cloud provides meaningful analytics and ability to effectively manage the system.

As I started to do the analysis of what sensors and monitoring solution to put in place there were a few constraints to work around. First, we needed to work within a reasonable cost that the neighborhood of 15 homes could afford. For our use case we needed to keep this within a budget that was manageable for a small neighborhood of 15 homes to afford. We set a threshold budget of less than $5,000 USD.

The second constraint was the location of our water supply. The water tank was located outside about 25 feet from the pump house. This means that anything needing remote power (120V or low voltage) would require wire to be run which is expensive and difficult in the elements of the pacific northwest. In addition, the well house did not have internet or service available so if we wanted to remotely monitor I would most likely need to choose some sort of wireless solution. With this in mind, I started researching wireless level sensors that were rated for outdoor conditions. During my research I found a company, National Control Devices, that produced a line of long range wireless sensors (up to 2 miles). NCD leverages a protocol called DigiMesh®, which is a secure wireless protocol in the 900 MHz frequency approved for our North American application. NCD also builds AWS and Azure gateway products, which allowed us to create a mesh network of the devices and did not require additional compute and code. We simply needed to install the sensors and create IoT certs from AWS for the secure connection to the cloud. The level sensor transceiver worked with lithium ion batteries negating the requirement to run low voltage cabling out to the sensor. The only thing we needed was an outdoor rated enclosure to house the transmitter that was mounted on top of the tank.

Since my long term goal was to build a robust monitoring system that also predicted water usage and maintenance cycles I still needed to determine how I would get flow. Luckily, the incoming and outgoing pipes to the system were in the pump house so finding a flow sensor was a bit easier (and cheaper). I found this company, Micronics, that builds ultrasonic flow meters. Since the meters were installed in the well house I did not need outdoor rated or wall mounted meters. My options were to use Modbus or a 4-20mA signal for real time flow. I elected on the 4-20mA as it is easier to troubleshoot and I was able to find a dual channel transceiver from NCD to collect both flow meters and push it to the cloud via the AWS cloud gateway. These are the main components I used for the project:

Given my experience with AWS this was an easy choice and was also fairly easy to use serverless monitoring solutions with industrial grade hardware. I decided I wanted canned dashboards and didn’t want to fuss with managing a server. I elected to use AWS SiteWise as I could connect it directly to the AWS IoT data I was receiving from my sensors. I also needed to build some custom lambdas using python to format the data and pipe it to SiteWise. In addition, I needed to build a custom alarming engine using lambdas since AWS IoT events did not satisfy my use case. Ultimately, the general architecture looked like this:

The best part of leveraging AWS is the cost. I setup two SiteWise users (most months we only use 1 and are billed for one). Also, the Lambda and IoT monthly costs are in free tier so we don’t pay for the actions and innvocations. Our largest cost is the SiteWise subscription, which is $10 per month per user. Total cost with taxes is typically $11 per month. Here are a few pictures of the install. In the next post I plan on doing a deep dive of the AWS architecture service requirements.