IoT SCADA Dashboard with UWP
In February 2016 we embarked on an experiment — can a team of three developers straight out of university deliver a SCADA system in three months? Turns out, they can!
So, wtf is SCADA? It’s the name for Industrial IoT that’s older the feudalism, the one industry used before IoT was conjured up by some marketing department. That experiment has set us on the path of IoT and that’s how the Quickbird IoT Dashboard app was born.
Originally Quickbird had nothing to do with IoT. As described in other articles on this blog, we wanted to address terrible state of software in agriculture and bring together data from drones, satellites, etc.
While presenting at Malvern Festival of Innovation and met a fellow startup, Saturn Bioponics. They produce hydroponic vertical farming system for greenhouses, which are much more efficient than traditional greenhouses. (you can read about them here). We learnt that they have a same issue as the rest of agriculture— control system on the market was terrible AND expensive. We thought we could help, but there was a catch — we would have to build the sensor hardware as well as software, and, as is often the case with startups, the budget was tiny.
After much deliberation we took on the project. Neither we nor our client have dealt with contract software development before. Hell, we didn’t even sign a contract because we felt uncomfortable asking the customer to do that.
However we did know that screwing up requirements is the number one reason why software projects fail. We made sure that if we fail, at least it would be for a different reason. We agreed on three month timeline for some modest goals:
- Put together a hardware sensor system for monitoring conditions in a greenhouse: Temperature, Humidity, Water consumption, Ph, EC..
- Create an app to collect these readings and save them to a database
- Make a nice UI to access this data from a wall-mounted touchscreen
During the project, we’d meet every Monday to review progress and refine requirements. This was also when we’d have the struggle that’s pervasive in all software projects “could you add in feature X”. It’s difficult to get this part right — requirements always have gaps, and you are suppose to listen to your customer and refine them, so that you can deliver a decent product. Some of it made sense -> we agreed to do C, and for C to work you logically had to have B.
On the other hand if you let the client keep adding to the project, not only are you being taken for a ride, they could also cause the whole project to fail if you can’t complete it on time.
So you have to both listen to the customer and argue your position vigorously. Whatever the outcome, we would update the spec and email over the new version. Rapid feedback loop was very helpful, as both we were both new to it and every week were getting a better understanding of where we are trying to drive the project. Also having the PDF from last week was invaluable for next week’s meeting, as we had a written agreement to fall back on.
At the time we were kindly hosted by Entrepreneurial Spark Birmingham, which is a startup accelerator hosted in a NatWest bank building. So we had a nice premiere location to impress our clients. On the other hand, with our electronics, soldering, water pumps, etc. we made a terrible mess at the office and I an still surprised they tolerated us as kindly as they did.
We found the weekly meetings to be quite a lot of pressure, and it was frustrating that the office was closed on weekends. I mean, have you seen successful entrepreneurs? All of them have a story about slaving away 100 hours a week. Looking back I think that was actually good for us — I find that I can work >10 hours in a day and that works fine, but I really need a day’s break for un-rushed thinking, perspective and general sanity.
The build
We decided to build a Windows 10 UWP application, and oh boy, how I did not realise what we signed up for. The framework was really raw at the time and severely restricted our options, be that in error logging, deployment , or whatever
- The code ended up a bit of spaghetti from all the changes
- The UI was built for specifically Full HD screens and would not scale to anything else
- The app only dealt with one arduno device
Our client managed to convince us to venture into a whole new area — controlling pumps around the hydroponic greenhouse. These pumps add water, regulate the flow of nutrients, acidic and basic regulators for PH.
This freaked me out a lot, it means our system could be responsible for killing £100,000 worth of crops due to a software glitch. But we did it anyway.
Results
We’ve never actually built hardware before, so we didn’t know what to expect or how long it would take. We gave ourselves 3 months, which was pretty ambitious at the time. The reliability requirement that scared me the most. I mean, who makes industrial systems out of Arduinos and expects them to work, right? Wrong.
Turns out, even without prior experience, making an Arduino run reliably for years is a piece of cake. What we delivered was a mish-mash of stackable Arduino shields, mostly from DfRobot.
The system was delivered to Saturn and they tested it for a week, and packaged it up into a waterproof enclosure. The system was installed in a greenhouse where it happily worked for a season.
Meanwhile we were negotiating a commercial relationship to develop a cooler, cloud-connected system that would manage multiple devices remotely. Unfortunately we couldn’t come to a commercial agreement that made sense — Saturn could not, at the time, afford to pay for development on a contract basis. We suggested to take on app development as a generic app for control and automation, and make Saturn our first customer. Saturn’s unique IP is not the app itself, but their know-how and equipment for vertical farming. However Saturn insisted on exclusive ownership of the app. We went back and forth on the argument several times, but just couldn’t square the circle.
Demonic Possession
We decided to build a product-grade version of the system and try our hand at selling it as a generic solution
Unfortunately we got possessed by the idea and kept pouring in resources past the point where it made sence. Too much time was spent on development and too little was spent on sales. Eventually we canned the project. Regardless, we tested two approaches.
Embedded Linux version
A version of the system that runs on Intel Edison and communicates with a single Arduino through serial. The user accesses it through a web-dashboard on the local area network. The system was build on NodeJS and MongoDB.
UWP App Version
We built a new UWP application from scratch to avoid any issues with copyright — after all we did sell the original app. It should have been piece of cake— we only had to add a server for cloud synchronisation and the server code was straight forward. Turns out we were wrong.
While the server code was straight forward, the application became a lot more complex. Instead of simply saving telemetry from an Arduino it had to deal with synchronisation, conflicts and remote commands in real-time. We didn’t have prior experience with websocket communication and that was a can of worms by itself.
That doesn’t mean the app became hugely complex, but our original hopes of building version 2 in a month were dashed — instead it took four months, and consumed non-trivial amount of money.
Lessons learnt
After building the application we never managed to find another customer for such automation.
Building the second version of the app was a mistake — we should have found a second customer fist by showing them the original application as a demo. Then we would have had a clear objective for the system we are building and much more focused development. Instead we had long debates about how the app should work, and what if the user wants that and what if the user wants this. This made any decision into difficult deliberation and morale was low because it wasn’t clear why we were building the thing.
