12th January 2016

Developing Sensing SEC

A fair chunk of my 2015 was spent heading up the Sensing SEC project, so I thought I may write a debrief/reflection on the process – which at times was frustrating and challenging – but the end result is a set of tools and visualisations that ViseR and the university stakeholders can be proud of.

Sensor tag mind map

Creating a mind map of the SEC sensors in coggle started out as a great idea but soon turned into a behemoth.

Some of the largest hurdles came at the start of the project. Merely getting our head around the complexities of the building’s data sensors and schematics was a project in itself. Thankfully QUT’s Facilities Management team were on hand throughout the project to guide us through, and  I daresay even they probably learnt a bit more about some of the systems themselves! Probably the biggest hurdle to overcome was trying to integrate a system provided by a 3rd party partnership. The software was supposed to save us time by providing the solution we required, however with no documentation or support and weeks delving through DLL explorers the decision was made that it would be in the best interests to break this partnership and develop our own solution.

And thus began the system architecture and planning for a RESTful API service for the building data. Acting as a middle ground, hooking into both sensor data through an OPC proxy and also providing historical data through SQL and Splunk based loggers.

sensingsec-network

Network diagram of the Sensing SEC systems.

The system uses a variety of technologies: the BMS (building management system) provides data for the building sensors, including the tri-generator, the HVAC, weather station and vibration sensors. The other part of this is the EMS (electronics management system) which collates access to the energy and resources of the building such as gas, water, lights and power. These 2 systems both feed live sensor data via an OPC Proxy, which the API can then tap into. This allows us to separate and group sensors from different systems and present in a more human readable and discover-able way. The next element of this is enabling the historical data. We achieve this via a few different methods again, from hooking into the SQL log databases for the EMS and BMS, to creating custom logs to store the data into Splunk (PV, CCTV and Touch data are wired this way). We had a few teething issues with Splunk (a few remain on-going), and we

One pleasant surprise coming out of the project was the ease of the .Net Web API 2 + MVC. My last foray into the creation of a RESTful API service was years ago, when the concept was just beginning to gain traction and the whole thing was a very laborious process. This time around however I was delighted with how easy it was to set up the relationships between repositories/models/controllers and the routes. Automatic documentation generation from the method stubs is icing on the cake.

The Sensing SEC Homepage

Another plus for me in developing this project was the use of SVGs with CSS animation. The homepage was originally designed to just be static, but the decicsion to include animation really helps to bring the sections to life and re-iterate the idea of a ‘Sensing’ building, as can be seen in the short video capture above. I had used both SVG animation and CSS animations before, but never together. The ease to export an svg from the Illustrator designs and then create transitions / keyframe animations within the familiar CSS meant I could quickly prototype and tweak animations as I went.

Given the target audience of the web application was students and researchers ranging anywhere between Post Grad and primary, we decided it would be beneficial for a lower level way access to the data rather than the REST calls and documentation, and so the API explorer was born.

Touch REST service visualisation example

The API Explorer, seen here with the Touch Explore, allowing users to see the touch data of Zone 1 over time

This proved to be a great tool, not just to provide a quick query builder, but to visualise and test the data returned.

Looking to the future, there still remains some goals Viser would like to see achieved: these included a public launch, student workshops, Nagios alerts, older IE support and 3d representations of the data.

- Ben Kleverlaan

Leave a Reply

Your email address will not be published. Required fields are marked *