Posts Tagged ‘IOT’
LoRaWAN™ defines the communication protocol and system architecture for the network while the LoRa® physical layer enables the long-range communication link. The protocol and network architecture have the most influence in determining the battery lifetime of a node, the network capacity, the quality of service, the security, and the variety of applications served by the network.
This post will give a quick overview of the ingredients into building a complete LoRaWAN-enabled application. The software development or rather the details of it on each ingredient are topics for another day.
4 Primary Ingredients
To get started on building solutions using LoRa/LoRaWAN this is what you going to need:
- Thing: A LoRa radio module that you can hook up with a sensor… the challenge, especially in the US, it’s not easy to get something like that. The easiest, I think, is to get a dev kit such as the one from Multi-tech (combine the mDot with the UDK). It has a Arduino shield socket making it easy to plug in sensors and play around. Of course if are serious about using LoRa to enable your IoT applications you will end up making sophisticated devices such as the ones from Decent Lab.
- Gateway or Concentrator: You will need a Gateway or a Concentrator that speaks LoRa to the sensors & devices, and IP Connectivity to the Cloud – that can be for example Wi-Fi, Ethernet or 3G. LoRa Alliance is making a concerted effort to get everybody to adopt LoRaWAN as the protocol. I say that because if you wanted to you could build your own like Link Labs has decided to. My primary point is that while one side of the LoRa Gateway speaks “LoRa” – the other side will connect to the Internet (over TCP/IP or UDP/IP). The piece of software that interfaces with the backend is typically referred to as the Packet Forwarder – and has been open sourced by Semtech. Once again the choices are limited but while I used the Multi-tech Gateway – you could also get the gateway from Link Labs.
- LoRaWAN Network Server or Backend: This is the entity that speaks LoRaWAN to the Gateway and gets you the data to your application. Semtech the company behind LoRa hosts a backend that you could leverage. Multi-tech runs a “network server” on the Gateway itself. Or you could connect to the The Things Network (TTN for short, open-source, crowd-funded backend). On that note TTN is also going to be delivering cheap gateways. I first used the Network Server running on the Gateway, then made changes to make use of the TTN Backend. And finally I hacked using a combination of several open source backends – and ran it with my application backend.
- Application or Application Backend: The actual IoT application – that does something useful with the Thing – is most likely running on a private or public cloud would interface with the LoRaWAN network server and do the application-specific processing. The interface between the LoRaWAN backend and the Application Server is driven by the LoRaWAN backend provider – that is not a standard. TTN uses MQTT to do that, so does Multi-tech. This one is the easy part because you could use your own PC or Mac to run it or use any of public clouds for it. (Or may be a Smartphone App).
Note that if you (for the prototype or production) end up using a Network Service Provider such as Senet then you could skip on the Gateway. This is because companies like Senet want to offer LoRa as a Network Service, akin to how AT&T or Verizon provide cellular (both voice and data) service, and they set up “gateways” to cover a certain area with the LoRaWAN network. You could use TTN – but either you will have to be within the coverage of a community-hosted TTN Gateway or buy your own and hook it up to the TTN backend.
Getting all the 4 ingredients in place will enable you to truly understand the details of LoRaWAN and guide you on how to build solutions that address use cases well-matched with the attributes of LoRaWAN.
This is how the device kit looks like – it has a BME280 (Pressure, Temperature, Humidity), Light Level and GPS sensor attached to it. Also attached an NFC tag reader that I use for provisioning.
Internet of Things or IoT has been a megatrend worldwide for the last decade or so. I have seen a frequently quoted number from Cisco that indicates the number of connected devices will be 50B by 2020. But what is the math behind the number? How did Cisco arrive at that number? How many analysts, companies, presentations, and blogs have used that number?
I read through, again, the Cisco IBSG report which was published in 2011, and here is how the number was computed:
- Cisco started with a report from Forrester (actually in the Cisco IBSG PDF Report – the reference is to a number quoted by George Colony of Forrester Research in a post published by InfoWorld – March 2003) that states there are 500m Connected Devices
- Next take the number of connected devices in 2003, and get the number of devices per person – 500 Million divided by 6.3 Billion – resulting in 0.079 Devices per person.
- Using data from US Census Bureau and their internal IBSG data for 2010 – the next step was to state the number of Connected Devices was 12.5 Billion, and dividing that by the world population (6.8 Billion) results in 1.84 devices per person. Please note that per Cisco the 12.5 Billion number includes Smartphones and Tablet PCs.
- Cisco then used the work done by a team of researchers in China that showed the size of the Internet doubles every 5.32 years. The reference in the report is to the following: Internet Growth Follows Moore’s Law Too
- Next step was very easy – multiply the number from 2010 every 5 years – you don’t even need a calculator now – you get 25 Billion for 2015 (double from 12.5 in 2010, and that leads to 50B in 2020.
The 50B number does not get into a bread down by categories on the devices. We cannot make out from this number the percentage of sophisticated devices such as Smartphones or the percentage or low-power, low-cost number.
This number probably (and anecdotally) is one of the most cited number to show the growth of IoT. The math behind it looks simple and abstract but it helped propel the market forward!
Chances are, if you are in the business of technology, you have come across the term “Full Stack”. It started few years back with the notion of a (software) developer being able to program all layers for web applications – you can find a great description from 2012 here: What is a Full Stack developer?. The momentum, and market for Full stack developers kept going up. And then it started being discussed at the level of a company or rather a startup – and I would attribute it to the VC firm A16Z to define it at this level. A16Z has dedicated a page on the Full Stack Startup as a part of their ‘trends‘ in investing. The ideal full stack company is Apple – they do everything top to bottom, providing the best user/consumer experience to their customers (readers may be familiar with the previous iteration of full stack – the Vertically Integrated Company – I’m not sure how it is different from the definition of Full Stack).
This got me thinking on what are the attributes, skills, expertise needed by a Full Stack IoT Company – a company that build a complete solution based on the benefits of IoT, and here they are:
1. Hardware design, development and manufacturing: This may or may not be part of a full stack IoT company but the reality is that the T in IoT stands for “Things” – physical things. And interfacing with them requires hardware. Full Stack IoT companies will own or control significant aspects of the hardware required in their solution. This implies the Full Stack IoT company needs skill around design, development of hardware. And as many delayed Kickstarter hardware projects prove – these companies would need expertise and experience in manufacturing, and supply chain. The hardware would involve both the sensor and the gateway being used.
2. Embedded / Firmware (resource-constrained) Programming: IoT has re-surfaced the lost art of an embedded programmer. Imagine the code running inside the wearables or sensors – it is all embedded code and in some cases running without any real operating system. Design, development and debugging is fundamentally different than cloud or mobility or application level programming.
3. Application-level & Middleware Programming: Programming on the IoT Gateway, Cloud and the distributed middleware to integrate all of the elements together
4. Cloud development, and operations: All IoT applications require a cloud component, you would need the cloud infrastructure (e.g. Amazon AWS), the IoT middleware portion running on the cloud and the IoT application which provides the functionality.
5. Management – of devices, of applications, of network (even though the network belongs to a third party): as the solution provider – managing devices, and apps – for version control, updates would be needed as a part of the integrated offer and solution. Once again – the Full Stack IoT company may license or integrate a third party solution but would own the responsibility.
6. Smartphone & Tablet Apps: Do I really need to justify this? You would need apps to both for management of the IoT application and also for consuming the experience provided by the application.
7. Analytics, Mining, Business Intelligence: ideally the company provides basic analytics with its solutions, and can be integrated with other products and solutions for advanced analytics. Full Stack IoT companies may leverage analytics solutions from other companies, but would still retain control of the data.
8. Integration with IT & other systems – to interface, and integrate with business applications in order to deliver the contextual value provided by the IoT system. Your IoT application may also need to integrate with other services to enhance your service – for example you may need to integrate with a Weather reporting web service if you are offering an application that controls/manages air conditioning (HVACs).
Bottom line – IoT applications are distributed across multiple systems and that is both a challenge and an opportunity! Whether your company is a “Full Stack” IoT company or not – if you building IoT applications – you cannot escape the 8 attributes described above. You will have to partner, build or integrate that help address all the 8 elements.
Full Stack Reading
There is no doubt that “Internet of Things” or IoT is the buzz word in technology – destined to change our future forever. And yes I do believe that IoT will change our future or rather the change has begun, and only accelerating. However another buzz word that marries IoT with Big Data – is Predictive Analytics. It is all about how all the sensor and machine data can help find patterns, and be beneficial for use cases like predicting equipment failure. IoT Analytics, I feel, at times is a bubble within a bubble.
Is Predictive Analytics important? Yes it is but not at the cost of how IoT can change the present – not just the future. I see the following steps before you can get into a predictive stage for the mass market (i.e. some use cases probably have crossed several of these steps):
1. Reliable connectivity of sensors, and reliable transfer of data – example did the temperature spike because it actually became hot or it was anomaly because of loose connections or software glitch?
2. If already connected in the world of instrumentation such as SCADA or other legacy proprietary protocols – migrating either the connectivity or the data from the sensors over to the world of IP & Cloud Computing
3. Making present, and the near present better than before: actions that can be taken without the need for predicting the future such as shut down the equipment right now because the temperature has actually spiked.
Predicting the future is one of the many benefits of IoT.
The Internet of Things (IoT) enables a new class of service – Product as a Service. A world where devices, things, appliances, objects become a service being offered. This had started at the high end of market many years ago even before IoT went mainstream and technology analysts forecasting numbers on the “billions” of devices that would be connected. A great example was that of Rolls Royce and its airplane engine division that even before 2009 was generating significant service revenue by monitoring the jet engines while in flight: Britain’s lonely high-flier.
Imagine a world where you don’t pay for the light bulbs or doors or HVACs upfront but you pay monthly – it sounds preposterous – doesn’t it? Take it a step further – home builders could bundle all these services – team up with a finance company and include it all in a single lease? It does sound preposterous but attempts of this nature are real. Consider what BMW & Solar City are doing – buy an EV from BMW, and you can have Solar Power included in your lease – it is the value being generated by connecting and controlling everything!
Last week I blogged to walk the talk, and getting on with IoT. I came across a blog post covering the AHR Expo – AHR is show focused on air conditioning, heating and refrigeration expo. Nest after being acquired by Google last year made HVAC, Thermostats and IoT popular. The acquisition was a major driver in throwing visibility on IoT. The reality, though, was that thermostats (and hence HVAC) were being enabled by IoT for quite sometime. But I digress…
Businesses of all sizes use HVAC, Refrigeration and Building Automation. And companies such as Honeywell, Schneider, Daiken, and Rheem have been enabling their products to be smart and connected. HVAC and Building Automation systems are installed & maintained, typically, by third parties. The third party integrators, contractors form the backbone of this business.
A sign of success is when contractors who install these “AHR” systems, and support them for repairs and maintenance – are benefitting from enabling smart connectivity on the systems. This leads to a win-win for both the contractors and the consumers or business owners. First step is to enable smart connectivity to their equipment, next step is to train and make the IoT-enabled tools available to the contractors.
Kevin Ashton, the father of IoT, has a simple advice for companies looking to leverage and benefit from IoT – “Begin”. In Why the Internet of Things isn’t like the Big Bang Kevin says, and I quote:
In what Ashton calls “the wild frontier of IoT,” the best advice he can give is “Begin.”
“There’s too much sitting around in meetings, staring at PowerPoints, waiting for someone to tell you the answer. When someone else knows the answer, you’ve already lost.”
But where to begin? Pick an internal project, and enable it with IoT. Roll it out to a limited set of customers, learn, tweak and update the solution. Analytics is supposed to be the big killer app – the data coming in from these sensors, and things that would unlock the potential of Big Data or Small Data. But to begin – collect the data. Or if you are already collecting the data (and many industrial companies have been doing “IoT” for a long time) – figure out a way of putting a wrapper around that system, and APIfy it.
That’s how to begin…