|Team 1: connected cars.
Team one discussed deploying an Apache Kafka cluster on AWS to handle data processing. A light blog that didn't really add much to the understanding of what's actually going on. They've since published a final blog[^] that summarises what they accomplished. What it comes to is an application that shows a map with other drivers in the vicinity. The key feature is a "driver score" that alerts the user to the crazy factor of other drivers. Lots of dramatic music.
Frankly: I don't get it. The entire project could have - and frankly should have - been a simple smartphone application. Smartphones have GPS, accelerometers, data connections and standards libraries, APIs and massive programming support. The inclusion of an arduino unit and Dell Wyse was not adequately explained.
What I would have liked to see: a smartphone app to handle the communication and UI. The arduino connected directly to the OBD port of the car to get driving dynamics, which would then communication with the phone via bluetooth. At least a sketch of what it would take to have the application ultimately apply the brakes in case of an impending accident. What we saw was basically Waze without driving directions.
Team 2: DIY Smarthomes for Aging-in-Place
We're at the point where the teams are mow pulling it all together and Team 2 have given us a rundown of how their system would work. This is split between nicely technical disucssions on using Clojure on the Edison (thank you guys!) and general comments about coordinating wearable and sensor data through a local gateway. To me this seems like they are simply creating another HomeKit or Brillo. The addition of Edison based bridges to route bluetooth sensor data to the main gateway is an excellent idea. However, I'm still looking for the meat. Where's the backend services and algorithms that will take this data and, using machine learning, translate this into real-time Alerts of Impending Doom?
Ultimately Team 2 did not achieve their goals. What they did achieve is a great contribution to the developer community in their form of their work on Iotivity. However, this again underlines the issues with IoT: there are no standards. We're still fighting the tools.
Team 3: Cognitive Healthcare System for Rural Areas
Team 3 has also wrapped up their project and demonstrated their remote patient diagnostic application. It's basic - 4 lead ECG instead of 12 lead, a slightly questionable body temperature probe placement (probably to keep it kid-friendly) and nothing adventurous such as blood work included. It is a prototype, after all. Someone may need to see a doctor, though, because blood pressure of 102/85 is a little low.
The sensors are all controlled and their data collected by the main application. Communication is via WiFi, and data is then processed manually (lots of Python scripts) to detect anomalies. Two main thinks are apparent
The data acquisition is way too coarse. A cardiologist could never read an ECG of that form. ECGs are subtle and require a hell of a lot of training to read. Machine learning can certainly do the job, but only if the data is very, very good. They need to use some decent screen casting software. It was very hard to see what was happening on the screen in the demos.Overall the ssytem seems reaonably complete. The risk of mis-diagnosis is extremely high with their current setup but it's about the concept, not the actual data and hardware at this point. Again, I probably would have considered a smartphone app more appropriate given that power and WiFi in remote communities may be harder to come by than a simple cell tower. WiFi, bluetooth and a ton of processing power is in your hand.
Team 4 - Proximity carts
Team 4 have gone all out in the video[^] department with a fully animated video explaining their system. Unfortunately their video showed a slightly cumbersome UI turning on and turning off LEDs. I have no idea how this relates to. Frankly I'm lost
Team 5 - remote agriculture health sensing
Team 5 have been granted an extension due to shopping dalays. Before that they had a couple of posts about using Matlab for porcessing and the BeetleBot (sans laser beams, unfortunately). At this point there's no final solution that's been demoed. Hopefully by this time next week.
Security wasn't addressed
These challenges are meant to stretch the imagination and coding skills while showcasing the technology available. The Intel IoT kits are maturing rapidly and the availability of APIs, SDKs and toolkits is astounding. There's still lots and lots of work to do, though, and frankly fewer, more comprehensive options would help the community rather than more. I'm sad to see not a single .NET entry.
What was also not mentioned, apart from a brief note by Team 3, was security.Is data from sensors being encrypted or passed through secure channels? Are data files with personal data (health monitoring data, car sensor dara, home sensor data) being stored in plain text or encrypted? What scope is their for the data between sensors and the processing system to be hijacked? Could the accident prevention system be hijacked from within the car easily? What about another driver hijacking the signals from surrounding cars? Given that the remote health app was on a laptop, could personal health data be accessed by other apps on that laptop? Were remote webservices protected with authentication? Was all communication handled over SSL?
I saw a lot of time spent fighting tools. I saw essentially zero time spent protecting systems (and people) from harm.
In my mind the IoT challenge isn't the software or hardware. It's the data. Specifically, it's protecting the data.