RUMM is a spin-off company from a project based at the University of Glamorgan in South Wales, UK.

Working with their customers, RUMM provides a full energy/utility service customised to the clients needs ranging from fuel purchasing, meter installation, advanced monitoring and targeting to the project management of engineering and IT solutions. Our focus is to reduce utility costs. We provide our customers with customised on-line utility information and work with them to reduce their costs and ensure they remain low.

Initially the project had already created a utility management web application to view meter information online using vb.net v1.1 and the .netCharting component to graphically represent the data to the user.

Our first steps to taking on this project were to rationalise the requirements of the RUMM project and create a development process based around those needs. We identified the following projects/requirements:

• 3 .net projects were required to allow a modular approach to the development of the project as a whole: a “front end” project for main RUMM public facing web site, a “manager” project to allow RUMM customers to log into the site and view their meter data, and finally a “data administration” project to allow RUMM staff to manage the large scale data importing, processing and exporting to the manager project (typically one meter can hold thousands of rows of data per month with each company averaging 20 meters each). This approach allowed us to work on one module without having to take down any other services while we were developing new services or modules.
  
  
• We installed a 3-tier release process to ensure any development of any of the modules first went through a process of quality assurance before reaching the live web server. All development was carried on a local development web server. Once the developers had created and tested their code on the development server, it was released to a staging server where the new additions, bug fixes and changes underwent regression testing by different staff members. Once testing had been passed, the code was then released to the live web server where it be used by RUMM’s clients. We also used the same approach when processing data, using a development, staging and live Microsoft SQL Servers.
  
  
• Due to the complexity of the service, primarily with the administration and manager projects, we used Visual SourceSafe and a release label structure to record all changes made so that we can track and trace all changes made to the code and rollback to a previous version if required. Each big fix or new addition was given a release number, whenever a file was checked out by a developer, when the work was completed; it was checked back in using the specified release number.

The Manager Project

This was the most mature project available at the time Web fibre / Netsmade4u started at RUMM. It was already serving data to one client using .netCharting but was still very much a work in progress project.

During our consultation with RUMM, we decided the best approach was the take the core data processing features out of the existing project and using our development methodologies explained above, re-coded the manager project from ground up taking more advantage of the features found in .net v1.1 while also making each segment of the manager project more modular to assist in the maintenance of the application.

Keeping the existing design of the original manager, we added very few new visual features, but we did redesign the GUI (Graphical User Interface) to make it easier for customers to drill down to find information.

Chose utility type to open area, choose area to open meters for chosen utility for the chosen area.

Once the user had selected the meter they wanted to view, the data is grabbed from the database using a stored procedure based in the default or user specified time frame. This data is then “shaped” for processing by the .netCharting component.

Each bar in the chart is clickable allowing the user to drill down to the next level of data. By clicking on a month, the chart would update to show the data for that month. The user is able to drill down to half hourly intervals.

The user can also step through years, months and days, deepening at what level they have drilled down to on the chart, by clicking the next and previous buttons.

Depending on what drill down level you are on, the controls change
to allow you to step backwards and forwards in time

One problem area we found drilling down with the chart, when the user clicked on one of the bars, instead of doing a typical .net postback, the .netCharting component actually performed a redirect back to the same page thus losing all variable state. At first we looked at storing the user state as Session or Cookies variables, but we found due to the way the clients used the site, the back and forward buttons were utilised and this caused the browser history to be out of sync with the last Session state.

The most flexible solution we found was to store all user state as ViewState data in the page itself and as the amount of user data stored was minimal, the performance impact of using the ViewState was minimal and the benefits large as it allowed the user the freedom of using the back and forward buttons in the browser.

We still had the problem of the chart losing its state after a drill down event due to the redirected self post back it performed. As with the original project, the best solution was to pad out the query string with the data required to regenerate the chart (and some user data) upon the redirection, mimicking the original developer’s solution. To ensure the chart was rendered correctly upon the redirect, we created a validation module that took all the data from the query string, checked it, recreated the user state and chart state, then displayed the information to the user.

The Manager application also allows the user to select multiple meters (even of different types) and compare them side by side.

The Data Administration Project

The biggest selling point for the RUMM project is its data and the accuracy of it. The data is recorded locally at the meter source on a half hourly basis and recorded in a storage device which then delivers the data remotely to centrally located machine at RUMM using an Application called MeterRing developed by ElComponent Ltd.

All the meter data is stored in an Access database which is MeterRing’s preferred storage medium. However, for RUMM, the storage option needed a different approach as we had to consider multiple users accessing the same storage medium, the efficiency of the data stored and speed at which it could be accessed. Our choice was to regularly take the data from the Access database and reshape it into a table in Microsoft SQL Server.

MeterRing regularly dials out to all the remote meters on its lists and fetches the data. To keep the live web site up to date, we created a small application to query the Access database every half hour and move any new data to the live database server. During the transfer process, the data need to be reprocessed and reshaped to fit the needs of the Manager project.

Processing requirements:

Tariff charges – each meter or group of meters for gas, water or electricity have their own tariffs. To calculate the cost of every unit used by the meter, we would process the unit’s cost based on the meter’s tariff and add that the SQL Database’s table column.
Other charges – any other charges associated to that meter, such as a standing charge, was also calculated and added to a table column.
Usage - every recorded half hour unit was compared to the previous reading and the different added to a table column. This value is used to show the amount of units used in a period.

Data Reshaping:

The structure of the Access database in the current version of MeterRing at use at RUMM did not allow for a set up of multiple clients or meter types, however, a solution was found to incorporate more than one client and associate meters to them.

Along with the different clients, meters came in different types and the data recorded in different columns. This created a complex and potential problematic area to manage. To make the RUMM version of the data as flexible as possible, we created a module to reshape the data in the Access database to a more easily manageable and scaleable format in SQL Server. Our fear was that a newer version of MeterRing able to support multiple companies would force us to redevelop the data manipulation features from the RUMM stored data, more so if we had kept to exactly the same format as the Access database used. With our approach to creating a data shaping module, we are able to control the flow of data from the Access database to the SQL Server thus allowing us to easily change the shaping module to accommodate any changes made to newer versions of MeterRing.

The end result was one table holding all the data for all meters for all clients, identified by ID’s for client, meter type and so on, whereas the Access database held multiple tables for each meter. A simple SQL query using the SQL Server version of the data quickly brought back all relevant data from one table. We used other tables to ensure a relationship existed between Utility types, Meter types, Client settings and so on.

In some cases it was necessary for RUMM to go back in history and recalculate data on per client, per utility, per meter basis. The data administration application was able to cope with this by allowing the administrator to select the time range, meters and new values to reprocess. It would then automatically upload the changes to the live database server.

Tariffs can also change and the administrator allows you to select the meters and enter new tariff details to be processed from that point forward. The previous tariff was never deleted as it was needed as record of the previous cost and would be required again if data from that tariff’s period needed to be recalculated.

RUMM continues to improve and add new features to its service and as such our relationship with them continues.