A smarter water app development ecosystem

In previous blog posts I have detailed how enterprise apps can be developed today using the IBM Smarter Water Platform. From this a whole enterprise based app development ecosystem can be built up to help address real worlds problems for the water industry such as water conservation and non revenue water (NRW). These apps follow a pattern of; leveraging information from various sources such as the citizen as a sensor and the Internet of Things (IoT) of smart water sensors and meters, analyzing the information with advance analytics, and visualizing the information and analysis in a contextual and situational aware environment. This pattern can yield powerful insights into the water network. In this blog i want to examine this ecosystem more with a story about how multiple players can collaborate around this smarter water ecosystem.

Below is the diagram outlining the development of a smarter water app development ecosystem. The App Store in the diagram below can be realized by our IBM Cloud try and buy offering. We will now look at a non revenue water story that could be realized by this ecosystem.

A Non Revenue Water story (A Smarter Cities ecosystem)

1. A Water Balance App is  developed on the Platform by a App Developer in collaboration with a Domain Expert (an example of a water domain expert would be a water engineering consultancy company). The Water Balance App could then be published to a Smarter Cities App Store (such as IBM Water Usage Analysis app at the IBM’s try and buy site). A domain expert can then consult with the Water Balance App and use it to help find leaking zones in a water system
2. A Domain Expert can then consult with a Pressure Management App (from the Smarter Cities App Store) to help reduce the pressure in the water network and therefore reduce the amount of leaks. The domain expert can extend the app with their domain knowledge (KPI, regulatory reports, SOPs). The Domain Expert can use the Water Balance App to quantify how effective the Pressure Management App has been in terms of leaks reduction in the water network. 
3. An Asset Vendor (an example would be a sonic sensor manufacturer ) can then work with an App Developer to create a Sonic Leak Detection App for their sonic sensors. This app would again be published in the Smarter Cities App Store. A Domain Expert would then consult with the Sonic Leak Detection App to detect a leak down to a particular pipe. The Domain Expert can again use the Water Balance App to quantify how effective the Sonic Leak Detection App has been in terms of leak reduction in the water network.

Here the roles are defined more clearly

• Platform Provider - IBM would be the smarter water platform provider 
• App developer - An app developer would use the platform services and programming model (SDK) to develop apps on the platform, these apps could then be deployed to the Smarter Cities App Store. 
• Domain expert - Domain experts will use the platform as well at the apps from the Smarter Cities App store in their consultancy to give them a competitive advantage. They will typically augment these app with domain specific content (e.g KPI, reports, SoPs).
• Asset Vendor/Content Expert - Asset Vendors provide hardware solutions such as sensor and meter vendors. As cloud hosted solutions become more common, our platform and SDK will become an attractive solution of developing apps to access their hardware that are connected. 

This ecosystem will enable multiple parties to collaborate together to allow them consume and use water resources smarter. The  IBM Smarter Water Platform therefore allows us to build advance analytics based apps with data consumed from the enterprise, the Internet of Things, and the citizen as a sensor thereby opening up a new ecosystems for collaborative smarter planet app development: an enterprise app store. This combined with the latest announcement of a joint collaboration between IBM and Apple makes this a very exciting time.

http://lnkd.in/d_-6WZF

View Eoin Lane's profile

Water and the internet of things

Over the past year on this blog I have been talking about a number of concepts around how we can become smarter about how the world uses water. I thought it would be good for this posting to take a breath and put it all together to give new and existing readers an overview of where the IBM Intelligent Water Platform (IOW) is now and its technical capabilities.

At the heart of IBM Intelligent Water Platform (IOW) is the water information hub (WIH) which provides a system view of the internet of things as related to a water or grid utilities network. This network is built up from elemental data sources such as sensors, meters, enterprise asset management systems, CRM systems, ERP systems and GIS systems. This systems view allows the user to view the water network as a whole, where the whole is greater than the sum of the parts. The water information hub is modeled using a flexible semantic technology that allows the modeling of real world water networks and can manage change dynamically. 

Smarter water enterprise applications can then be build on-top of the water information hub using a software development kit (SDK). The SDK provides a number of core services for the application developer:

• A interface into the water information hub (WIH), 
• A interface into the advanced analytics engines of the platform, 
• A rendering service that allow the application developer to display result to the end user

Using these core interfaces, the platforms eventing model, and an integration with social media services an application developer can develop advanced analytical water application such as pressure management and pump energy optimization and deploy these applications into the IOW platform.

The enterprise application development pattern separates function from content using the concept of a content pack. in a model, view controller pattern. This allows an application developer and business partner to collaborate together to solve a diverse range of global water problems. In the Smarter Water SDK, the application’s content comes in the form of a content pack. We can think of a content pack as a container that holds lots of different types of content, content that can be both consumed and produced by the application, such as KPI, SOPs, and custom reports.

An organizing principle is then used to categorize and classify the applications. This classification is by vertical (e.g. Water sourcing and distribution, waste water, etc), by role (executive, planner, operator) and by business responsibility. This classification allows for multiple application to be installed and configured, as part of the application development lifecycle, into the IOW platform.

All of the services of the IOW SDK interfaces are built and offered as cloud services to allow for remote development and deployment of enterprise applications. All of the enterprise analytical applications can in turn expose and be offered as business services. These applications can then collaborate and cooperate together using their business services to help solve real world water problems such as a leaking pipe.

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.

Cooperating applications for self optimizing water systems

People often ask me what is the importance of the water information hub (WIH)? The WIH provides a system view of the water network, where the whole is greater than the sum of the parts. In other words is not just  an elemental view of the water meters, or the sensor (pressure, flow, turbidity etc), or the assets (pipes, manholes, value, pumps, etc) in the system, it shows how all these elements, and many more, interrelate with each other. We can now treat the WIH as a system and like all other systems it exhibits certain characteristic of a system such as feedback loops. A simple example of a system with a feedback look is a house with thermostat. A thermostat works with a furnace and you set the thermostat to a certain temperature and the furnace works with the thermostat, blowing on and off, to keep the house at that set temperature. Here there is a feedback look between the thermostat and the furnace. For a great book on understand more about systems and systems behaviors, including feedback loops, see the book: Thinking in Systems: A Primer.

The very same can be done for a water distribution network where we have water flowing into and out of the network from the tap, or from from leaks, or from fire hydrants. Water lost from the systems that is not billed through a meter is called non revenue water (NRW). We can create similar feedback loop for the WIH by measuring the amount of water in and out of the system and then optimizing that via some feedback loop mechanism to help minimise the amount of NRW. The example we will look at is very similar to the thermostat example above in that is there are also two applications cooperating together: a water balance application that measures the amount of water in/out of a network and a pressure management application that will optimize the pressure in the network. Both of these application can be build using the IBM's Smarter Water SDK

Water Balance Table

In any system it is always important to get the beat of the system. In a water distribution network this is how much water is flowing through the network and were the water is going to. A measure of a beat of a water network can be provided by a water balance table. In a water distribution network, the network is typically divided into pressure zones, as this makes it easier for a water authority to manage the pressure across a large network and allows for a sub section of pipes to be kept at a constant pressure independent of the rest of the water network. A water balance application built using the SDK could read in the pipe network data and the associated meter readings from the pipe network, and then calculate and display the water balance. The figure above shows a standard water balance report that the water balance application might produce. One of the things a water balance application can do, is run a minimum night flow analysis, which runs the water balance at 3.00 AM, when water usage is at it's lowest, and all of the losses of water in the system at that time are largely due to leaks. By comparing pressures zone, using a minimum night flow analysis, we can then determine which pressure zones are having the most leaks.

Multiple pressure zones and a minimum night flow analysis chat

A pressure management application works on the principle, that within a pressure zone, pressure in usually kept high to ensure that there is adequate positive pressure on the tap side.  Keeping the water network at high pressure all the time has a detrimental effect on the pipe network, particularly in an aging pipe network, which is the case in most western european cities. The constant high pressure tends to corrode the pipes and also exasperates any existing leaks. A pressure management application, built using SDK, will read off the pipe network and then iterate through the pipe network and read off the pressure reading at pressure critical point and then take that data and process it through an optimization algorithm. The output of the optimization algorithm will then give the optimized pressure readings for that pressure zone. The application could then write out to the pressure reducing values, in that pressure zone. using an OPC interface and set the optimized pressure value for the network.

Feedback loop between the water balance and the pressure management applications 

These two applications, the water balance application and the pressure management application can be set up in a feedback loop very similar to how the thermostat and the furnace feedback on each other. This kind of collaboration between the two application can be done simply with a pub/sub interface on the applications. The water balance application alerts, the pressure management application, that a particular pressure zone is very leaky. The pressure management application optimize the pressure in that pressure zone. Once the pressure management application runs and optimizes the pressure in the pressure reducing values and then in turn alerts the water balance application that the pressure has been optimized. The water balance application would then run the minimum night flow analysis again, the following night, and find by how much the leaks have been reduced.

Rain to drain water network

In this feedback loop between the water balance application and the pressure management application, the water balance application may tell the pressure management application to use a different optimization algorithm and test the effectiveness of one algorithm against another. There are many more of these feedback loops that you can find in the water network, such as the rain to drain picture above in Peter Williams paper, and we challenge you find more and build collaborating applications around those.