As we all know it, IoT (Internet of Things) has been a hot topic for some time by now. The following is a practical high-level description of the use of Geolocation while developing IoT solutions. Our intention is, of course, to help to those who are approaching this technology mix, by sharing our own experience.
When we first started working on IoT we wanted to order our own boards, which we felt they should be custom-made to fit the needs of some of our clients. In our Lab by then, we had already built many Geolocation solutions oriented to dispatching and field data collection, using our mobile apps and cloud architecture. This data is very important for operations because otherwise they’d have to rely on manual communication (Emails, SMS, voice or Office Docs (MS/Google’s)).
Years later, we’ve felt strongly attracted by the possibility of adding one more option to our Field Data Collection activities: Reading from IoT devices. This way, data would come from humans and devices together, and everything would be included in the same algorithm that runs the workflow (In some of our products, a set of algorithms is aimed to learn and predict potential issues). This was done besides the usual, which is alerting our Clients or reporting on actual occurrences. IoT then is providing us with the possibility of customizing a board to fulfill, and therefore build a device, a single direct objective: Broadcast data to a larger system (or change the device configuration based on instructions from the same larger system).
The greatest thing about IoT boards is that they have Sensors (and now there is a large quantity of them to read lots of things useful to all of us). Thus, our boards would be tailored to read qualified data from the Sensors, using GSM (we partner with some carriers) it would connect to a cloud service, and using secured protocols it would store information in a strategic place. Our own bots would then scan for any new data constantly and trigger event notifications that end up in browsers, smartphones or even other devices. UI/UX would get in the mix to deploy usable and easy-to-read analytics when monitoring was necessary. This way we can deploy end-to-end cloud enterprise solutions capable of data extraction/broadcast, using IoT and Geo, with cool interfaces, all applied to practical purposes in today’s businesses.
We then run into some obstacles when ordering our own boards. Things like minimum quantity, extensive timelines and an arduous cycle of coordination to get things the way we needed (I was sure that thing could get better with bigger budgets but still the speed wasn’t quite there for us). We put that option on a backburner and examined ready-to-go boards like Raspberry Pi (https://www.raspberrypi.org/), Linkit (http://www.seeedstudio.com/depot/LinkIt-ONE-p-2017.html), Banana Pi (http://www.bananapi.org/) and others. We’ve spent a good amount of time examining the pros and cons on each. We’ve decided that each of them would be a good fit, depending of the actual final need. For example Raspberry Pi was robust and well made but we couldn’t use too much for mobile solutions. LinkIt was good with Sensors but not as good for enterprise solutions. Banana Pi was a great fit for mobile solutions but its core technology needed us to do a lot of work at the OS layer.
All in all, our big benefit was that we were able to understand lots of details and possibilities on how to properly, securely and quickly turn this set of technologies into enterprise solutions that do the job at a very low cost and with huge level of scalability.
The scalability came from configuring and deploying AWS services as brokers at each critical step of the workflow and using the full potential of native cloud services. This way a considerable transaction volume increase (communication is extremely light) would just trigger a cloud auto-scale feature to grow itself while it remains high.
With all this experience, we’re now helping our clients to include field data in their mission-critical processes using devices like the one in the cover picture (one of our first ones). We’re also noticing that the traditional concept of “Field” is transforming itself with today’s trends. It’s going from just people traveling outside the office from place to place to do a certain job, to a larger group in the organization. One major reason is remote work (employees/contractors contributing directly/indirectly to this large data feed using/not using their location). Another reason is the evolution of mobility, it’s easier now to stick IoT devices to your physical infrastructure (vehicles, ships, equipment and others).
I hope this information was helpful to you, if you’d like to know more details about it, feel free to email me at firstname.lastname@example.org