IoT Ecosystem Game

Internet of Things is changing the world. Not by what we do, but how we do things. This affects individuals, organizations and business ecosystems.

Until now, we have seen ecosystems dominated by a single companies. Let's take Apple as an example. In specific consumer product segments, Apple has ruled the whole value chain from hardware via software to markets and distribution channel. With the model Apple has succeeded to collect 80% of profits of smart phone industry, with only 18% market share.

IoT however is way too diverse for any single company to dominate. Applications vary from hen houses to connected cars, from thermostats to medical instruments. Just like technical architectures are changed from M2M verticals to horizontal layers of IoT, are businesses forced to co-operate with partners and competitors.

M2M vs IOT architecture.

Connected devices is nothing new, M2M has existed from 10 to 20 years already. However, M2M  tends to be like vertical silos, application specific end-to-end solution with limited expandability. IoT as opposite is more like Internet architecture in general, horizontal layers without predefined purpose for any specific function.

Changes in connectivity architectures reflects to ecosystems. A healthy IoT ecosystem has different players for different horizontal players, and preferably many of them. A good example of IoT ecosystem is build around ARM and IBM. ARM provides technology for Things and  IBM for Internet, making it Internet of Things.

ARM embed and IBM cloud offering are really a winning combo. ARM has the strongest ecosystem of silicon vendors. IBM with it's new cloud offering and partnership with Apple, ARM, Semtech, and many more has really gained reputation. This heterogeneous and loosely linked ecosystem has no single point of failure.

There is no ring to rule them all, and there is always room for new trials. That's the only way how the technology can go further in large scale, the law of natural selection applies in technolofy as well.

Just recently Intel announced a new IoT platform, partnering with Accenture, Capgemini, HCL, NTT Data, Tata Consultancy and Wipro. Basically, that's a single silicon vendor with bunch of consultants. Doesn't sounds like a healthy ecosystem. I expressed my thoughts  about the Intel Edison/Quark technology already a year ago. The technology is the basis of this new alliance, which really doesn't convince me.

Node-RED for Home Automation

Node-RED is a great tool for creating graphical data stream integration and processing flows. Now Node-RED is even better suitable for home automation, as support for multiple different wireless sensors is added via Tellstick Duo.

Yesterday I started to prepare a demonstration for a local Node.js meetup in Helsinki. Node-RED is built a top of Node.js, thus it is natural topic for a presentation in the meet-up. Meanwhile preparing the demonstration, I ended up creating an input node into Node-RED for Tellstick Duo. It is now contributed to the project.

The node is available in npm and github with name node-red-contrib-tellstick.
More detailed information is available on my web site: http://ala-paavola.fi/Node-RED

Node-RED with tellstick input node.

Tellstick Duo is USB-connected 433MHz RF transmitter and receiver from Telldus Technologies in Sweden. It supports wide range of commercially available sensors and devices from different vendors.

Node-RED was initially created by IBM Emerging Technologies at IBM Hursley lab, Winchester UK. It was released as an open source project and is still actively maintained and supported by IBM. It's one of the key assets in IBM Bluemix portfolio.

Couple of weeks ago I met one of the initial creators of the software, Dave Conway-Jones (@ceejay). His answer to my question why did they released it as open source in the first place was something like: "We tough it's so cool that it would be a crime against humanity not to publish it to the whole world." Well, perhaps Dave didn't expressed it exactly like that, but that's how I feel it.

Node-RED is really gaining momentum at the moment. More and more manufacturers are including it in their products, Multitech Conduit IoT Gateway as an example.

More and more devices are supported by Node-RED, Philips Hue for example.
A friend of mine, a system operator, created a build health status indicator with help of Node-Red and Hue. He integrated Node-RED into their company continuous integration tool chain, and now everybody in the office see what's the status of the build. If someone breaks the build, server room neighbourhood is immediately glowing red...

LoRa in constructed environment

Suddenly LoRa has became one of the hottest technologies in the Internet of Things domain. The number of new customer cases we see in our company is increasing on a daily basis. But where's the beef?

There are two main use cases where LoRa is strong:
- Wide area wireless sensor network (W-WSN)
- Factory (or any facility) area netwok (FAN)

In W-WSN applications, individual diameter of individual LoRa cells may vary from 2 to 20 kilometers. This makes it possible to collect data from many sensors into single gateway for upstream via wired or wireless connections (3G/4G data mode). This is the modem killer scenario explained in previous posting.

Factory area network with star-topology.

FAN is perhaps more common use case for LoRa. Facility can be anything including factory, refinery, warehouse, seaport, shopping center, or office block, and all other cases where mainstream technologies like WiFi, Bluetooth, Zigbee, and other 2.4 GHz RF can't do the job without unreasonable number of access points or complex multi-hop routing algorithms and routing node.

LoRa modulation has certain characteristics which make it suitable for difficult constructed environments like a factory.

Aa a rule of thumb: the lower the frequence the longer the distance, or better peneration. Reduction from 2.4 GHz to Sub-GHz frequencies alone gives significant improvement. The CSS modulation of LoRa makes it possible to detect signals 20dB below the noise floor, yet giving improvement over traditional narrow-band Sub-GHz radios.

Multipath propagation

Multipath fading is a common problem in constructed environment. Signal may travel via multiple different routes due to reflections from different surfaces. It's like echo on a railway station making it very difficult to understand announcements given by loudspeakers. In radio technology, multipath propagation may cause signal amplification or attenuation with short displacement of the receiver.

Up-chirp, increasing frequency sweep in time domain.

Different frequencies have different reflection signature. Chirp Spread Spectrum (CSS) uses frequency sweeps to carry information. During the sweep, some frequency may attenuate, whereas some other frequency may be amplified. All in all, detection of signal in receiver side is very reliable. Consider the railway station example. If audio frequency sweeps - chirps - are broadcasted from loudspeakers, human can easily recognize whether the individual sweep is going from low to high (up-chirp) or from high to low (down-chirp), even if significant echo takes place.

Frequency also affects signal penetration. Due to various reasons, certain frequencies may penetrate better than others. By spreading the signal to wider bandwidth, we increase the probability that some signal gets through. According to our experiments, LoRa has been the only commonly available IoT RF technology, which can deliver data from inside a closed metallic storage container to outside world.

LoRa - the modem killer?

Internet of Things is at the top Gartner's hype curve of the year. But how to get the Things into the Internet? - That is the question.

When designing a IoT system, device connectivity is often among the biggest headaches. In case of consumer products, it is usually possible to rely on existing infrastructure, either Wifi Access point or Bluetooth/Smart connectivity of mobile phone. When considering city-wide installation of wireless sensors network or intending to cover a whole industrial plant, those consumer technologies are simply not feasible.

In practice, individual sensors are Today often having a cellular data modem with them, which is totally overkill. Reading a single sensor value every now and then does not need the bandwidth which is good for streaming video. Modem by itself as a component is usually more expensive than rest of the sensor electronics, and it ruins your power budget. Finally but not least, management of SIM subscriptions in global context is a nightmare.

Why there are so many cellular data modems then? Because there has been no other real options available. Low power 2.4 GHz radios like 802.15.4 can only do about 100 meters in open space. Wifi can be extended to some 500 meters, but then power consumption is over battery budget.

Sub-GHz radios can address the range issues. Narrowband RF like in TI portfolio are proven to have good performance in distance. A interesting new alternative is Semtech Lora.

Freescale FRDM-KL25Z Cortex-M0 evalution board with
ARM mbed-supported LoRa Shield from Semtech.

LoRA is a long range sub-GHz spread spectrum radio technology from Semtech. LoRa uses proprietary chirp spread spectrum  (CSS) modulation, which is rather unusual solution for data communication. CSS is more commonly known in radars and that sort of applications. In sensor node communication, added value of CSS is rather good distance measurement, which is far more accurate than traditional RSSI estimation.

BOM cost of Sub-GHz RF subsystem is less than 5€, which fits into the price range of most IoT sensors. However, having the radio in the sensor node only is not good enough. Also infrastructure is needed. In building-wide installations one can assume a gateway or two to be easily installed and maintained. In case of metropolitan area network the situation is different. Some one must build and operate the network infrastructure.

There are some indications that traditional telecom operators may be interested in introducing IoT networks. It may be considered as direct competitor with existing M2M cellular data business, which may hinder operators interest. However, if operators don't do that by themselves, some one else will do it, and then operators are only loosing.

FastNet in South Africa is the first public reference of a telecom operator investing in LoRa-infrastructure to provide IoT communication services. However, the playground is not reserved for traditional operators only, but new players like energy or transportation companies may invest into network infrastructure of their own and start selling capacity to other players as well.

Is Java dead?

While studying in the university at the turn of the millennium, Java was described as the programming solution to pretty much everything, and Java processors running bytecode in hardware were the future promise of embedded systems. 

Well,  Java processors never really made their way into mainstream, and nowadays you never hear anything of them. In the context of embedded systems, Java by itself is now performing similar act of dissappearance.

Last week I attended Embedded Conference Scandinavia as a speaker and exhibitor. ECS is the leading embedded event in the Nordics. Good for making contacts; compact and very well focused.

This year at ECS, I didn't heard anyone talking about Java or presenting any Java-based solutions. In the context of embedded systems, Java simply doesn't exists anymore - If it ever really existed? Last year I wrote about my toughs on java: Java for embedded - does it really make sense? (Sept. 2013). This year I'm even more convinced it really doesn't make sense, and other people are more and more thinking alike.

Snapshot of Freescale presentation slide at ECS.
MQTT, Node-RED, Node-JS, Bluemix and mbed promoted.

At ECS, I gave presentation about issues like MQTT, Node-RED, Node.js and Bluemix, and how to utilize them when creating embedded solutions. Just like I have done in numerous previous postings in this blog series. I was delighted to see I'm not alone with my message, companies like Freescale and Multitech also openly promoted the very same technologies and gave presentations at ECS.

If not Java, what then? ARM mbed platform is really gaining momentum now, and the ecosystem is growing with increasing acceleration. Freescale, IBM, Multitech, they all promote and support mbed Today. My first experiences with mbed are reported in Internet of Things with help of ARM (Aug. 2013).

Death of Java is not a tragedy. Instead it gives more space for proper programming technologies like mbed, Node.js and Node-RED. Think of world with Java never invented - all the millions of man years of wasted effort used for something useful...

IoT rocks

IBM Insight 2014 in Las Vegas is over now, here are some remarks.

Mobile first, Cloud and Watson are the big things of the day. IoT is a rising trend, but a bit curiosity among IT people. IBM is still refining it's IoT strategy, but the importance is well recognized. Bluemix is one the key enablers of the new era.

In the main session at Tuesday morning, even a live IoT-demo with Bluemix and Node-RED was presented. I felt that so familiar. Some readers may remember my Bluemix-journey starting from the IOTcoop with very much the same technologies.

MQTT plays essential role how devices are connected. Actually, meanwhile IBM people had their event, OASIS organization officially approved new version 3.1.1 of MQTT standard. I'm a member in the Technical Comittee.

Presentation slide of John Thompson.

I had my priviledge to attend a Business and Industry Leadership Executive Luncheon, hosted by the Vice President, Internet of Things Strategy, John Thompson. John gave an awesome speech about Internet of Things. He really knows what he is talking about, and well recognized all the challenges which well known by Embedded Systems and IoT players like my company.

John stated 70% of technology is the same in traditional IT and IoT, but 30% is different and that's why it is hard for traditional IT players to succeed in any IoT project. The snapshot from his attachment highlights the key differentiating factors. It's interesting to notice that it's not only about technology, but people as well. In IoT, your partners are different to tradional IT.

Companies like Espotel are the rising stars of the new IoT era.

Cloud on cloud

Where do you do your cloud development, in the cloud perhaps while flying high?

One important aspect to add in to my previous Bluemix testimonial. As it is a cloud service, it's omnipresent. No matter whether you're in the office, at home, or traveling, you can control and develop your cloud app, at any place any any time.

Wifi is getting more widely available in airplanes nowadays. It was really cool Yesterday when I was flying to Las Vegas for IBM Insight conference. I did literally cloud programming by modifying the Bluemix app while up in the clouds, or above. 

Before I departed, I told to the business partner that I'll be away for couple of weeks in total, but don't worry, I'll keep my commitments and your progress is not endangered at any time. I can do my part of the job while being away, thanks to the decision to select the cloud as the common integration point.

Cheers from Vegas! I'm looking forward for 5 interesting days among IBM technology and people. Watson for Analytics will be my topic of special interest here. I hope I can soon tell more about that.

Watson logo.

Bluemix for real business

Last week at IBM Business Connect I talked about Bluemix accelerating to market. This week I made it reality.

Usually I don't talk about customer projects here, and usually I don't implement software in customer projects by myself either. So this is a double exception.

Recently we started a new project where my company is supposed to deliver an IoT solution for a retail domain, another vendor provides ERP system, and we do integration together. So this is a multi-vendor case. All the vendors - 4 in total - are separate legal entities having separate premises and information infrastructure.

Traditional way of co-development would cause need to cross-install software components into each others development environment, an/or creating VPN-connections or other holes to firewalls and stuff. This time I decided to make it differently: for the duration of development, I created the integration point in Bluemix.

Node-RED screenshot as illustration. Picture taken from nodered.org web site.

There are clear benefits we gained immediately at the beginning of the project:

Rapid development
First of all, thanks to PaaS, the base system with selected components was up and running just in minutes. I decided to use Node-RED to implement my part of the integration. Node-RED is semi-graphical programming language built a top of Node.JS. Roughly within an our from beginning, I had the first application specific functionality implemented and in service.

Shared access
All parties involved in the development have access to the cloud, no-one needs to compromise corporate security by implementing any changes in the existing IT configurations. Connections are encrypted by TLS/SSL, which makes it secure enough especially as no real business data is involved in the system during development time.

Instant deployment
As this is a R&D project for a new innovation, no readily available specifications exists. Documentation is written parallel to the development, in agile manner. Changes occur multiple times per day, and it's crucial to deploy them fast. With Node-RED, the development actually occurs in Bluemix with web user interfaces. Performing deployment only requires single click of Deploy-button, and changes are in production (in developer zone) in a second.

Fail fast
As said, no specs exists a priori. Some ideas are good, some others not so much. The three things mentioned above make it easy to test new ideas quickly - and fail fast. Already during the very first day of joint development, we found some basic assumptions wrong, and changed some design fundamentals immediately. Without all help of this, it would may have taken weeks to recognize the root problem. Think of all the wasted effort by re-writing the code then!

DevOps
I'm not an operator. I can install a Linux desktop by myself, but installing a production server with high security and SLA sounds like a nightmare. With help of Bluemix PaaS, I do not need to care about the platform. I only need to focus on my own code which brings the added value to the customer.

It's not just hype, the benefits are evident, and experienced in real-life commercial business. Someone is paying for all that, and I believe the one is happy for the benefits gained in terms of savings in time to market and development costs.

PaaS security considerations

Security is the first concern which arise when talking about cloud services. Let's take a closer look.

Cloud services are usually categorized as SAAS, PAAS, and IAAS. What comes to security, I personally trust PaaS most.

Infrastructure as a Service (IaaS):
Computing resource, typically a virtual machine or sometimes physical computer, is provided to customer. Customer installs platform, middleware services and application software. Security is more or less up to the customer's competence. Example service providers: Amazon EC2, IBM Softlayer.

Platform as a Service (PaaS):
OS platform, execution environment, data storage and services are provided by service provider. This environment is more limited simultaneously more protected than IaaS. Example service providers: Microsoft Azure, IBM Bluemix.

Software as a Service (SaaS):
Customer pay for use of certain domain specific application and has very limited capability to affect the behavior of the software. Usually SaaS providers do not disclose their security measures, thus one can not evaluate the level of security. Example services: Salesforce, Basecamp.

Summary: IAAS - You're on your own. PAAS - Limited but protected. SAAS - You just got to trust.

PaaS security mechanisms

Let's dig into some details of security mechanisms of PaaS service. I'm using IBM Bluemix as an example here.

Control of external communication
Only HTTP/S and WebSocket/S connections are allowed. All other connection attempts are discarded. All external connections go through external appliance for improved security.

API isolation
Only selected set of application programming interfaces are provided to developer. Even if the application is behaving badly, it can not do much harm. Vulnerabilities like Shellshock are eliminated as the platform does not provide access to such services as command line.

Data protection
Data is proven to be available to given application only. However, several instances may share the same data store, if configured so.

Platform instantiation
Each application runs in its own container that has specific resource limits for processor, memory, and disk.

The week point of a PaaS-based cloud service is the application itself. No security measure can protect the application from it's own stupidity. However, the developer can focus all attention to application design, without need to worry for underlain services. This may eventually reduce the amount of stupidity in application design and leads to better overall security.

Value proposition of PaaS

It's simple: Bring your own code. What makes it so special then?

Have you ever had a new business idea but hesitate to try it out due to the risk related to the initial investment? If your business is related to internet services, maybe PaaS can help you. 

Perhaps the biggest promise of the Platform as a Service (PaaS) is the user's ability to try new things out with minimum risk. Just take an instance, deploy your code, and pay per use. If it's aint working as a business, then just quit it, and you didn't lost much.

Snapshot of Bluemix service configuration panel.

Let's take a closer look to some key aspects:

Pay per use

Do you know how many users you'll have on your new service? Seldom one can predict that, and it makes ROI calculation difficult. How about having your costs proportional to your user count. That means fixed production cost per production volume.

Modern PaaS services like Bluemix offer innovative payment models. The base charging unit of Bluemix is Gigabytehour (GBh), somewhat similar to kiloWatthours (kWh) you're paing for the electricity. The analogy is obvious: pay per use.

Focus on your code

You do not need to care about hardware, connectivity, or the software platform. Just select the necessary middleware services you need, and put all your energy on your application, which is the one who brings all the added value after all. It's the service provided by your application which matters to your customers, not the underlain infrastructure.

In traditional IaaS approach, you need someone capable of putting it all together and setting it up, and someone to maintain it and keep things rolling. With PaaS, it's all taken care on behalf of you. You only need to understand your application details.

Instantly in service

Just a few clicks to select components and services you need, and you're ready to deploy you code to production use. How about development then? Just use the same PaaS, but developed on your own sandbox. Once it's ready to publish, just deploy it to production by simple mouse click.

Maintenance free

If something is advertised as maintenance free, it usually means you can't fix it. In case of PaaS, you do not need to fix it, as someone is already doing that, and without you even notice it. 

IBM wrote about my thoughts in their blog at Sept. 23rd, 2014 (in Finnish):  Playground for developer - Early birds experiences

One can't avoid discussing about internet services without someone asking for security. That will topic for a next postings.