The best way to deal with a leaky pipe

At the heart of the IBM Smarter Water product is the water information hub (WIH), can be viewed as a system, where the whole is greater than the sum of the parts. In a previous post I talked about how we can create intelligent apps on top of the WIH using IBM Smarter Water SDK, where these apps can then collaborate together to optimizing the water network by exploiting feedback loops in the system. In this post we will examine another feature of the system, that is the ability for the WIH to learn new stuff.

Usually, when we architect and design applications we store the data in a database. Databases are very good at storing and querying data but one drawback is that all of the data has to known at design time. For example, when we are building a database for a metering system we need to know everything about the metering system at design time. The problem with a dynamic system like the WIH, where the whole is greater than the sum of the parts, is that by definition the 'whole' know more than the 'parts'. In other words we can not possibly know all of the information contained in the 'whole' at design time. 

An example will help illustrate this. Lets return to the water balance application we previously built using IBM Smarter Water SDK. The water balance app measures the amount of water in and out of the system. In a water distribution system, the network is typically divided into a number of pressure zones. In the diagram bellow we can see five separate pressure zones. The water balance application reads data from the water information hub, which is connected at the backend to the sensors and meters in the network, and reports a standard measure of water (IWA) moving in and out of the network. The water balance application provides us with a baseline from which we can start to optimize the water network. By running a minimum night flow analysis, the water balance application can determine which pressure zone is the most 'leaky' in the water network (1). The problem here is, if we we architected the WIH with a database, the concept and corresponding database construct, for 'leakiness', may not have been considered at design time since we could not have foreseen all the apps that could be built on top of WIH at design time.

A water distribution with five separate pressure zones

The WIH bypasses this problem by using a semantic technology, rather than a database technology to represent the water network. I will go into the details of the semantic technology in a later posting but suffice to say that by using a semantic technology we can now add new data at runtime that was not thought about at design time.

Now, once the water balance app runs the minimum night flow analysis and categories the pressure zones by 'leakiness' it can write this information back to the WIH (2). The pressure management app can then use this new information (3) to prioritize which pressure zones it needs to optimize first.

This is just one example of where a water app that processes data from the water information hub has enhanced our understanding of the water system and can then make that new information available to other applications. This is because the semantic technology, that the water information hub is based on, is dynamic enough to allows us to make these changes at runtime. There are lots of other examples of applications that can enhance our understanding of the water network, and we will be looking at others in a future postings.