Origins of the Pollution Guardian Startup

We have now completed the first quarter of the Pollution Guardian project part funded by Innovate UK and it seemed a good time to reflect on where this whole thing came from in the first place.

It all started from a growing awareness, through many stories in the press, about the negative health effects of air pollution. Furthermore this pollution, unlike the ‘pea-souper’ of the 1950s and 1960s was largely invisible. However its immediate term effects were not invisible to the large numbers of people suffering from various respiratory illnesses such as asthma. It seemed there should be a demand to ‘shine a light’ on this pollution.

When starting a business idea it is important not only to understand customer needs but also the business’s capability to do something about it. At All about the Product we are veterans from the mobile phone industry and are steeped in both technical and commercial experience to bring highly sophisticated consumer electronic communications products to market. Any solution we were going to build would therefore be an ‘Internet of Things’ solution.

As many people have told us, for a good product idea it is not only important to know whether there are high levels of pollution present but also there needs to be something to do about it. We therefore became interested in the effects of pollution inside vehicles where there was an opportunity to control this enclosed space more than the entire atmosphere of a city. On further investigation we found articles which showed that very often the level of pollutants inside a car exceed those at the road-side [1] – we had our application focus.

We wanted a product within economic reach of the majority of the population and therefore a low cost consumer internet of things product for use in cars and other vehicles was born.

As this idea developed, we spoke to many stakeholder organisations such as health charities, workers unions, academia and local government. What we learnt from these discussions underlined the fact that there was this invisible problem there and many felt powerless to combat it. Our motivation to do something only grew.

We put our engineering hats and did a quick study to show that producing such a product was feasible. However when we looked at the skills needed to pull this product off, we quickly realised we lacked knowledge about urban pollution and the experience of pollution measurement. Fortuitously our local University – the University of Surrey has a very strong department in this field, so we contacted Professor Kumar at the Global Centre for Clean Air Research (GCARE) and set up a meeting. It quickly emerged that our skills complemented those of the university in making this product investigation happen. We agreed to join forces in making a bid for one of Innovate UK’s competitions and after a couple of attempts we won one! Thus the Pollution Guardian Project was born.

[1] Cepeda et al :Lancet Public Health 2017; 2:e23-34

https://allabouttheproduct.com/

https://www.surrey.ac.uk/global-centre-clean-air-research

Sensing the Air Quality

In our home page, we mentioned that within product incubation, we were working on our own solution activities. The area of interest is within the internet of things (IoT) and is targeted at low cost air pollution/air quality (AQ) solutions at this time. Thus we were pleased to participate in the 46^th Intelligent sensing program, organised by the UK knowledge transfer network.

What were the main learnings from the event?

Big concerns on the level of small particulates, specifically PM2.5 and below.
EU AQ measurement standardisation is scoping “informative” sensing solutions.
Growing interest in AQ sensor networks.
UK government desire to leverage crowdsourced pollution data.
Key sensor criteria & findings from low cost sensing components.
Urban & journey pollution mapping.

Particulates

Can we meet the EU reduction targets for PM_2.5 particulates by 2020? Should we be counting the number of particles rather than particle mass/m^3? Just one PM10 particle weighs as much as 1000 PM1 particles.

AQ sensor networks

Presentations from Alphasense and AirMonitors Ltd. pointed to the additional value coming from “lower than reference” quality sensors connected up as a network e.g. the ability to dis-aggregate pollution sources.

Crowdsourcing, sensor criteria and findings

The UK Environment Agency are looking to identify how they can better leverage crowdsource AQ data as a larger monitoring network than their existing 150 reference stations across the UK. However, the main concern is over the quality of this data. This then leads us to think about the air quality sensor and sensor system criteria:

Sensitivity: enough for the purpose e.g. movements within the general background outdoor AQ level
Specificity: responding to a specific gas pollutant and not being easily spoofed by the presence of other gases
Stability: the sensor performance remains predictable enough, compared to a reference over its intended lifespan

A couple of presentations mentioned using low cost sensors based upon existing metal oxide technology – the learning here being that the sensor system stability is a challenging issue to manage. Mitigation seems so far to have been to adopt electrochemical type sensors but which can be significantly higher cost.

Hamamatsu was one supplier at the event claiming good individual gas detection capability using light absorption sensing e.g. a sensor set to the band gap of a specific gas. This looks an interesting avenue to explore further.

Overall, the sensor selection is one of the most significant factors for us to consider in our low cost AQ sensing solution.

Urban & air pollution monitoring from vehicles

A couple of interesting talks measuring pollution across journeys.

Motorway driving is quite bad for particulates exposure due to vehicle pollution “plumes”.
Air re-recirculation in cars provides quite some benefit to exposure levels, as long as the CO2 levels & humidity levels in the cabin don’t build up too much.
Urban NO₂ hotspots experienced by cyclists on pathways, not only near road junctions but also when passing by industrial areas.
AQ pollution hotspots can move position dependent on the wind direction e.g. crossing over to the opposite side of the road. So, dynamic measurements or models are important.

Internet of Things (IoT) niches drive radio specialisation

In a previous blog article looking at radio technologies, we suggested that the winners in the race were likely to be based around Bluetooth, Zigbee and the emergent 5G technologies. Unsurprisingly, it turns out that life is more complicated than this, and there is a lot more going on within selected niches as well as elsewhere outside of the UK.

Whilst collaborating with a smart home energy saving business, OpenTRV, one of the things that becomes obvious is that it is super important in the home environment for devices requiring remote control to be able to communicate with a central/controller hub. There are number of ways of tackling this:

Plug all the devices in, use Wi-Fi and hope that all devices can reach the home Wi-Fi hub
Plug all the devices in, use Wi-Fi with range extender units e.g. using powerline technology
Go battery powered and use a low power “mesh network” of devices based on Bluetooth or Zigbee technology and hope that this will help solve all nodes reaching the hub
Go battery powered and use a low power wireless technology that has a better range in the first place e.g. sub-GHz radio based at 433MHz or 868MHz

There are different likelihoods of success and a number of pros and cons with each of these approaches: installation/wiring of sensors to an electricity supply, cost of extra connectivity units, battery replacement costs, data throughput, design margin/certainty of connections etc. In the home environment, product businesses have often tended to pick the last approach for the out of box certainty of connection and are big users of the sub-GHz radio technologies e.g. Lightwave & Mi|Home products.

Now “sub-GHz” wireless technologies may not be that familiar to people who know Bluetooth and Wi-Fi from their mobile phones, but they turn out to be surprisingly well supported by silicon vendors with a wide set of chipset offerings e.g. Texas Instruments CC1310, ST Microelectronics S2-LP, Nordic nRF-905, Silicon Labs EZR32WG, NXP MKW01Z128, Renesas RL78/G1H etc.

Silicon Labs sub-GHz evaluation board

Whilst the sub-GHz radio solutions for home sensors enjoy longer range e.g. 100m with low power, they do have the disadvantage of being unable to natively communicate with mobile phones or the internet. To do this, they need a compatible receiver box which has to be connected to the home router or Wi-Fi hub. This in itself is not a major issue as all home solutions currently rely on a physical “box” for providing the control element of the solution.

But could this box disappear into the cloud in the future? Certainly, but consumers may become worried if increasing numbers of their critical home systems lack the backup of local controls and they become totally dependent on both their broadband provider AND their home automation service’s cloud operation.

Evolutionary crisis in smartphones?

For ten years now the mobile phone business has been dominated by similar looking device offerings with large touch screens and similar user experiences centred on a responsive touch interface; is this going to continue, how is the market going to evolve?

Competition as a supplier in the mobile phone business is not straightforward -the rules of the game change from time to time. The mobile phone industry has seen a number of such change cycles since the establishment of the first digital mobile phones around 1990, with different players exiting and entering the market according to their ability to compete profitably within the cycle. During each cycle, different business factors become critical within the different phases:

The impact on a supplier’s product portfolio through the change cycle is a gradual increase in the in the lifecycle of individual products, which leads in turn to a widening of the number of products offered and ultimately to a much more consumer segmented product offer.

The voice era

The first change period in the digital era was purely the ability to produce a digital mobile phone at all – leading to the development of proprietary chipsets and software. The first digital products were too large and battery life was terrible, so the following consolidation phase was one of miniaturisation and power optimisation over a period in excess of five years. As the technology reached a point where acceptable size and power consumption was available there followed a plateau period for roughly 3 years when branding, segmentation and physical cosmetics was to the fore.

The multimedia era

The next change period came in 2002 with the advent of camera phones and programmable operating systems in GSM world markets. This heralded a period of multimedia convergence in the mobile devices as music players, video players appeared alongside the ever-present camera. A further complexity was incorporated over the following 2 years as 3G WCDMA became established as a fundamental requirement of a multimedia device. It can be argued that this change cycle was still in its consolidation period when it was disrupted by the next change period in 2007 when the Apple iPhone brought fundamental innovation in the user interface and later in the software application model. For a short period of less than two years products from both cycles were active and successful in the market – it should be noted that always after a change event there is a similar period, but the Apple iPhone product paradigm became the clear winner.

The Smartphone era

Since 2008 there has been a consolidation period in what became the smartphone space with ever better cameras, better quality displays and improved computing performance to deliver a high quality experience. Today the consolidation is reaching a point where the experience difference between high end smartphones and low cost smartphones has never been smaller. The smartphone based on the iPhone of 2007 has made it through its period of consolidation without being fundamentally disrupted.

So today, the smartphone business is in a plateau period- with supplier profitability tied closely to branding and logistical excellence fighting against the gravitational pull of commoditisation.

By retaining its own proprietary platform Apple has maintained differentiation while the rest of the market shares the Android platform and has therefore experienced greater pressures. Since the chipset business in the Android space has also been horizontalised- there is pressure from Qualcomm, Samsung and the like to adopt the very latest generations of their chipsets, however these are not delivering the big improvements in user experience seen in earlier years. Product differentiation is increasingly hard and the mode of the business is moving much more to a fast moving consumer goods model – as it did in the 1998-2002 period. The greater challenge now is that the smartphone form factor does not lend itself to easy cosmetic differentiation since the front face is over 90% glass.

So unless some breakthrough innovation is made, the winners in the smartphone market will be those who possess a good brand and marketing with the operational excellence necessary to deliver really good value to the end user.

Nokia – a good time to make a come back?

After largely disappearing from the mobile phone market following its acquisition by Microsoft, 2017 will see the re-emergence of the Nokia brand with products managed by HMD Global in partnership with FIH Mobile (part of Hon Hai Precision) and brand licensed from Nokia. As someone deeply involved with portfolio management at Nokia during the growth and glory days, I would like to take the opportunity to explore whether this is a good time for them to make a comeback?
In a previous blog I analysed the dynamics of the mobile phone market in terms of what facets of the overall business need to be optimised at a given point in time. In brief, my view is that the smart phone market has moved into a plateauing phase where the key strengths needed are brand, distribution and cost efficiency. So the question is whether this new Nokia set-up is well placed for this challenge?
First of all where is the Nokia brand today? Ten years ago Nokia was the leading mobile phone brand across the world except in North America, South Korea and Japan. This position had been built on fifteen years of growth – how much can this legacy be drawn on now? At its zenith Nokia stood for a perhaps contradictory combination of high technology and reliability – you could expect to get the very latest from Nokia and the products would be really tough in real life. The challenges of the 2008-2013 period largely stripped Nokia of the high technology association but today you still hear stories of how good and tough my Nokia was. The UK press has been full of stories about the resurrection for the 3310 over the last week, all very positive. So if I was to describe the Nokia brand today from a European perspective I would use words like: honest, tough and sentimental.
Distribution is the next major part of competing in today’s market scenario as with any fast moving goods business. Here HMD take responsibility for sales and FIH Mobile for manufacturing and logistics. This has the promise of being a good combination with a lot of personnel coming over from Microsoft devices business while FIH are of course a well-established world class manufacturer. Access to market in countries where operator distribution is critical will depend on the right deals being made but there is no obvious reason why this may not be the case. While a split company setup may struggle in a period where the market is changing fast with product innovation at the fore, since this is not the case at the moment there is no reason to believe this cannot succeed well.
Cost efficiency is the key to offering the value for money proposition essential in a plateauing market and in this case to compete against mainly Chinese companies which offer very keen price points. Clearly the advantage of the resonance of the Nokia brand will give the new venture an edge but as a challenger there can be no expectation of premium pricing at the beginning of sales. With the mobile phone chipset business dominated by only a few suppliers, the size of FIH/Hon Hai as a manufacturer will be important to get good pricing as well as the potential of Nokia branded goods making even a fraction of historical volumes.
So in a nutshell it would appear that the timing for a comeback looks good. Leaving re-entry any later would see the continuing in the decline of Nokia as a consumer brand – furthermore the operational mode of separate sales and manufacturing companies in partnership can work when product innovation is not the main route to success.

London Tech Expo 2017, IoT products and enablers

This is a modified version of an article originally published on LinkedIn here.

I made a worthwhile trip to the IoT London event (23-24^th Jan) recently to test the pulse of IoT and find out about some new and upcoming IoT product companies.

In general, I would say it felt like the scale and activity around IoT seems to have increased with a large number of participants and presentations on offer. With so much to see and businesses to talk to, it would have been useful to have a few more chairs to sit down and catch one’s breath…

Having said that, it is appropriate that this is called the Tech Expo as I could see a lot of product innovation, but also some challenges for businesses in finding their best channels for growth. Notwithstanding, I will mention here a few of the physical product companies that captured my interest..

Nanolike is a French company taking advantage of nanotechnology to create a tiny force sensor which uses a fraction of the power of existing sensing technologies. These size and power advantages mean that there is a wide scope of deployment opportunities, perhaps new products in the quantified self area that become feasible?

BeanIoT is based in Cambridge, UK and has created a range of small autonomous “bean” sensors which can connect to and through mobile phones and other low power bluetooth based devices. The beans have batteries and can be charged wirelessly, with the battery life depending on the number and rate of measurements requested by the bean. There is a quite a wide range of sensing available in the beans: accelerometer (step counter), temperature, pressure, air quality, humidity etc. It is interesting to see such a “Swiss army knife” type proposition being brought forward, as opposed to a more single purpose accessory like a fitness tracker or a wireless weather station. The team is integrating their own cloud storage and ‘bean’ data visualisation platform so as to provide an out of box solution and broaden its appeal toward business.

OpenTRV is a UK company aiming to make a big dent in the costs of domestic heating to cash constrained consumers along with the UK’s CO2 emissions. Their products are a connected and a standalone smart radiator valve that detect presence/occupancy in a room and learn when to turn on and off the radiator. Now existing thermostatic radiator valves can be bought for about £5, but many do not work particularly well nor do they offer the same heat saving potential, with up to 30% saving being claimed. The company is looking at the most affordable product options in order to make a 1 year repayment case to also appeal to people in rental accommodation. The connected option of the valve is more expensive, but can offer “telemetry data” on energy savings e.g. for large scale housing landlords.

The last company I mention is Neurofox, a German company with a product dedicated to helping stressed people achieve a state of mental relaxation in minimum time. The product comprises a headband with 5 brain activity sensors feeding into a controller unit with a headphone audio output and a wireless connection to a pc. The idea is to use the audio feedback path to help train the users to fall into a relaxed state. Over a period of time, through personalised hints and customised feedback, the solution gets better – but how this is achieved i.e. the IoT feedback path is not quite clear yet.

In summary, the show offered an interesting mix of product innovation along with end-end IoT solution companies, data visualisation offerings, multi and wide-area sensor connectivity and connectivity management solutions. Bearing in mind that google search does not generate a uniform distribution of winners, then for those interested in IoT companies, the list of exhibitors can be found here.

Life and death in the internet of everything…

The Internet of Things (IoT) or Internet of everything, hereafter IoE, is an incredibly hyped phenomenon at present viz IoT/IoE at the peak of the hype cycle. Source: Gartner 2014, 2015.

Nevertheless, within the massively wide scope of IoE, there have been clear opportunities within selected verticals. Businesses have been deploying IoE like solutions to optimise their process and realise significant cost savings. The example I like best is “Enevo”, a Finnish company involved in waste management, often described as the “internet of shit”, which has helped waste collection companies save huge costs, circa 40% by optimising the frequency and routing of collections.

There are a wide range of industry sectors looking at IoE, but can we say that the offers and solutions really belong to the same stable, or are they so custom they should be viewed within their own silo? Right now, this situation reminds me somewhat of the “bowling alley phase” from Michael Moore’s book, “Inside the tornado” (successor book to “Crossing the chasm”). In this phase, solutions are highly customised around individual businesses’ needs and there is not a vanilla platform offer suitable for all. Happy to hear other opinions on this.

Switching tack to the consumer product angle, what potential product categories do we see where people are going to pay out for an IoE augmented experience? It is happening here:

Personal monitoring/fitness e.g. fitbit, nike fuel,
Home automation/optimization e.g. Mihome, Smartthings, Nest, Hive
Personal heathcare/independence e.g. Kinetik, Acticheck

Of course there is then the catch all of the “closed loop” internet experience, embedded into part of an existing product category/product experience:

Providing a basic service e.g. music/video/other digital goods delivery & consumption
Providing feedback to the vendor or service provider of the product usage patterns and product maintenance/wear and tear e.g. Aviva drive car driving style, General motors Onstar

From a technical architecture point of view, when you consider the IoE across most of the categories, you are left with some common elements:

A sensor for gathering data. Most often wireless for convenience & background operation.
An aggregation point to bring together different sensor data streams and send to the internet. This could be a mobile phone or a home automation control hub.
A Cloud platform for the capture, processing and provision of service for the system e.g. visualisation of data, providing recommendations, remote activation/update etc.

To this end, at All about the Product, we have decided to take a look at a few contemporary solutions for elements of the system, to build a solution and then get a sense of the different strengths of the various options for the system elements.

We will be posting more information about our IoE product and voyage in the coming weeks.

IoT use cases & initial AWS IoT platform experience

In our initial internet of things (IoT) opening post, we said that many of the existing IoT solutions shared a common architecture. This post looks at the challenges in using one of those pieces of the architecture – the ease of use of an “off-shelf” cloud compute platform.

The essentials of an IoT system comprise of a few basic epics/user stories:

As a system owner, I want to be able to give my individual IoT endpoints their own unique identities so I can discriminate between them.
As a system owner, I want to be able to secure & restrict access to my IoT system to the endpoints that belong to me (and vice-versa).
As a system owner, I want to be able to define both individual and bulk policies for what IoT endpoints are allowed to do with their data when they connect.
As a system owner, I want to be able to define on both an individual and bulk basis what actions are to be taken as a result of IoT endpoint data transactions.
As a system owner, I want to be able to remotely “maintain” all of my IoT endpoints in terms of configurations and software versions.

In this initial approach to the AWS IoT platform, I concentrated on topics 1-3 and left aside the practical deployment issues for the present.

In summary, I would say that I like the Amazon approach to addressing these issues, as in a way they are the table stakes, with the main IoT value creation around what is being measured/monitored and how the data obtained is being intelligently used and combined to provide benefits.

My experience of the Amazon IoT system has focused on the IoT SDK and backend, specifically the python and embedded C versions and trialling the basic data publish/subscription over MQTT. In terms of positives & negatives:

No special setup required to start using AWS IoT, provided you already have an AWS account. It is also free to use (at present), provided you don’t go crazy and start using millions of messages per month.
Good initial impression of the documentation & code samples, but this soured slightly over time as a LOT of the examples & setup are tailored for the AWS IoT button as opposed to e.g. linux desktop for doing a quick test drive.
Bit of confusion over which “C” SDK to use for the desktop test drive. It seems it should be a separate download of linux_mqttmbedtls2.1.1.tar, which is a shame as I only found this out after downloading the embedded C SDK and discovering it within the readme file.
Very easy to “create” a new IoT device as well as certificates and keys to associate with the device to enable authenticated access to system.
Less great in terms of specifying precisely what to use in the header files for the code samples for the device ID and access points for pub/sub testing versus e.g. long identity string for the device shadow.
Not too well explained IoT policy concept i.e. [3] in the user stories. It is absolutely mandatory to create one of these and associate it with the certificate in order even to get connected to the IoT server.
IoT policies are poorly documented. I had to create a very permissive policy to enable the basic publish and subscribe examples to work: with ANY of my devices I can connect / publish/ subscribe to anything.
Calling out on the policies:
- The documentation on identifying *which* specific IoT node in the policy is somewhat lacking. I am not able to make restrictions adequately without affecting something else.
- Also the documentation on *what/where* the IoT device can publish/subscribe to is also lacking. There needs to be a better definition of the vocabulary & syntax for the policy statement.

AWS IoT console

Other than these initial problems, probably due as much to my own specific knowledge base, the AWS offering looks good in terms of getting started fast and providing the basic plumbing for an IoT system. Ian Massingham gave a good presentation on AWS IoT at Hardware pioneers in October.

Naturally AWS are looking to monetise IoT through use of their other cloud assets, storage, processing, machine learning and it will be interesting to compare in another blog against Windows Azure IoT which requires a chargeable server reservation for the right to use IoT.

Jan 2017 – update

I can now take back some of what I said earlier about the difficulty of finding the allowable policy definitions for IoT devices interacting with AWS’s backend. They were there in the documentation if you looked for them.

Excluding the “shadow” (Amazon’s virtual copy of the IoT device to use when e2e connections are broken), there are 4 fundamental actions and 3 different types of resource to query the action against.

Action	Resource query
Iot: Connect (enable basic connection from iot device to backend)	Client ID ARN e.g. to enable iot device “clientid1” to connect. arn:aws:iot:us-east-1:123456789012:client/clientid1
Iot: Receive (permission checked for messages to be sent to the device, essential to enable subscription)	Topic ID ARN e.g. for receiving from foo/bar arn:aws:iot:us-east-1:123456789012:topic/foo/bar
Iot: Publish (enables the device to send data to a topic, and/or filter allowable topics)	Topic ID ARN e.g. for publishing to foo/bar arn:aws:iot:us-east-1:123456789012:topic/foo/bar
Iot: Subscribe (restricts allowable topics for iot devices to subscribe to)	Topic filter ID ARN e.g. for subscribing to foo/bar arn:aws:iot:us-east-1:123456789012:topicfilter/foo/bar

In summary of the policies:

We can restrict connections according to the IoT device ID.
We can prevent messages being sent to the IoT device(s) or limit them to certain topic groups.
In a combined policy statement with connect, we can limit the IoT devices able to receive messages from certain topic groups.
We can limit the topics where IoT devices are able to publish to.
In a combined policy with connect, we can link the device id-topic pair publishing combination e.g. a destination specific to each client.
Ditto for subscriptions.

And there seem to be plenty more policy resource query variations in the documentation available using “variables” for some more advanced use cases.

Experience with AWS IoT platform, part 2

This is the second blog in a series looking at the complexity of using well known cloud compute platforms for building solutions for the Internet of Things.

Summary

The IoT “rules” and “actions” within AWS IoT are what allow you to bring your IoT data to life within the cloud through associated AWS services.

My first observations about setting these up gave me the sense that this was going to be quite tricky- using the AWS command line interface to craft new roles and policies to be able to use different AWS services.

However, this setup work is now starting to get a whole lot easier, with the introduction of a set of guided UI steps in the IoT suite which make it easier to accomplish the end goal. I was able, with relatively little effort, to setup publishing using an IoT program on a client to create IoT data files in the AWS storage cloud and make these publically visible on the web.

Whilst saying this, I experienced a few odd quirks from the platform e.g. when trying to configure IoT automated actions. Whilst I can’t claim strong knowledge of the platform, the reasons for the issues were far from clear and it may well be that there is just one way of doing things.

My feeling is however, that it would be a small step from here to have the client program running on a reasonable scale embedded platform e.g. one with Wi-Fi/IP stack. Indeed, the AWS IoT button is a good example and AWS themselves reference a number of other suitable hardware platforms.

AWS have a number of services to connect with the IoT platform e.g. database and simple notification services which are bundled under a somewhat “vertical” navigation scheme; it is a shame that the service “worked examples” are rather spread around the AWS documentation, meaning that the problem you are trying to solve may have an answer, but you can’t always see it from your current silo.

AWS IoT platform rules & actions

In a previous blog, I looked at the basic epics and user stories for an IoT system and cross referenced the experience with the AWS IoT platform. This previous blog only touched on the basic connection experience with AWS IoT: configuring end-points with identity certificates, setting up the target internet access point and enabling the basic data publish policy on the cloud end. These are represented by the greyed out boxes in the initial block picture.

This piece is an initial look at the next step operations possible with the AWS IoT system:

Defining a rule to filter all the published IoT topic data
Creating an action related to the rule e.g. data file/database update

Note: As a company looking to make a solution with a number of real “autonomous” IoT end points, quite a number of other tasks remain beyond what I have mentioned in the blogs so far e.g. visualisation, endpoint update, non-functional performance, alternate wireless connectivity (BT, LoRa) etc.

Initial thoughts

The rules and actions seem to be the most quirky part of the IoT system so far: I noticed that one of my new rules/actions stored in the cloud seems to have disappeared/deleted itself and then re-instated itself on the following day. Strange.

From my experience in trying to use AWS IoT rules and actions, it is best to follow AWS’ precise recommendations.

Setup an account with AWS (account “owner” – access all areas including billing)
Set up an administrator account under AWS IAM (all areas w/out billing)
Make/configure everything else whilst logged in as administrator i.e. all AWS IoT, “thing”/ device names, certificates & access policies.
- After creating devices/certificates as the account owner, and other items as the admin, I had some odd behaviour with rules/actions not being executed and files being created yet not being visible to me as “administrator”.

The picture shows some of the SQL syntax used for specifying the topic of interest to work with and a SQL “WHERE” condition can provide further filtering on the topic data content – it is typically looking for key-value pairs with more details in the IoT developer guide.

The next stage in the dialogue, the selection of an action to result from an IoT rule is shown in the picture above e.g. creating files in S3 storage.

The selected action must be configured and the above picture shows the s3 action configuration. The first boxes are to specify or create the S3 bucket where the IoT data will be written along with the sub-directory/key. If a new bucket is needed then an s3 management console is opened to enable this.

The lower box enables the selection of a “role” with an appropriate associated permissions policy to execute the action. Interestingly the “create a new role” most often did not work for me i.e. fails to load the IAM management console. To work around, I used an existing role which had the s3PutObject policy, and used the “update role” button to add the new s3 bucket/subdirectory to the role permission – see the picture below.

This odd behaviour is an example of there is perhaps just one way of doing things at present i.e. when using the rule wizard, it appears to prefer to re-use existing roles with s3 access as opposed to creating additional roles.

Having been through the setup experience, it is clear to me that to get most value from AWS IoT rule and action deployment, you need to get to know the rest of AWS’ solution offering e.g.

Identity access and management (IAM) as an enabler
Simple storage service (s3) for storing data
Lambda (“serverless” execution) for manipulating data
Simple notification service for messaging and alarm notifications

This should not be surprising as most of these solutions are also “chargeable services” in their own right, with the IoT providing the on ramp for customers. This familiarisation process is going to involve a certain amount of time investment, but the payback potential is evident and the examples within each service silo are generally good and worthwhile to try out.

A future blog will contrast our experiences with Microsoft Azure IoT with those of AWS IoT.

Radio technologies for the internet of things

This article reviews the issues when considering the choice of radio technologies when building Internet of Things systems. Our previous article proposed there were two radio technology selections to be made:

An ultra-low power technology to connect sensor nodes with gateway nodes to enable battery powering for ultra small devices.
A longer range technology to connect gateway nodes with the internet.

Ultra low power radio technologies

Given that a typical sensor node will be battery powered without re-charge over a period of the order of years, there is massive requirement for an extremely low power solution. Several radio technologies have been developed with this application in mind – of particular note Bluetooth Low Energy and Zigbee/Thread.

The case for Bluetooth is built on the universal availability of this standard in smart phones so allowing these devices to act as either gateways to cloud application, control points for the IoT system or data aggregation/display nodes for non-cloud connected cases.

The case for Zigbee and its Thread variant is built on their optimised design for connecting sensors and particularly their ability to create a mesh network which potentially extends the effective operating range of a gateway node.

Bluetooth SIG is aiming to close these functional gaps in the Bluetooth 5 release which is due late 2016 early 2017, promising in addition to mesh networking increased range. Timing is often critical for the process of choosing winning technical standards, but in this case it seems the whole IoT market has been dormant in a state of great expectation already for a number of years and therefore not a critical issue for Bluetooth.

Ultimately the winning radio standard in this case is likely to be decided by the role of the smart phone in the IoT ecosystem – if it plays an important role then Bluetooth solutions will dominate, if not then it is likely there will be less consolidation into a single radio type.

Longer range radio technologies

For the RF connection between the gateway node and the ‘internet’, the availability of a local WLAN network has typically between the key factor driving choices as a Wi-Fi signal will usually mean lower costs and power consumption than using cellular. Indeed, Ericsson has estimated that nearly 90% of IoT devices will NOT be connected over cellular. However 5G is being designed with IoT in mind and therefore it may offer a more cost effective and robust communication solution than today’s cellular solutions, yet expectations are that this technology will not be widely available until after 2020*.

Long range IoT is currently dominated by a number of proprietary solutions such as SigFox and LoRa which have emerged to fill a gap of combining long range and low power. The price of this combination is to really cutback on data rates offered to a single node, which suits a lot of the contemporary machine to machine applications. Because of the very low bandwidth per node and their relatively long range, these solutions can be made to be a very economic solution for many applications.

Looking at past experience with mobile telephony, standardised radio solutions drive opportunities to create economies of scale and if operators create economic packages of IoT users then it is likely 5G will dominate in the long term.

*Verizon in the USA is aggressively driving 5G wireless trials and targets some early commercial deployments in 2017 for fixed site application i.e. fibre/cable replacement role, not mobility and not necessarily the scope of 5G required for lowest power IoT.

Segmenting the IoT Market, autonomous versus powered

In a previous blog, we looked at the one of the issues of using off the shelf modules for IoT endpoints. The linked commercial question is what is the volume and value of the opportunities for autonomous (battery) versus powered IoT endpoints?

Hypothesis

Given that there are going to be over 1 billion new mobile phones coming to market every year and that the majority of these will support BT smart (BT LE etc.), it is a reasonable bet that there will be a healthy market for autonomous IoT devices that are capable of interacting with these phones. The autonomous endpoints are battery powered and using the lowest energy connectivity possible. This is the IoT mobile driven market assumption.

What wisdom exists on the internet?

There are a wealth of IoT market papers and surveys out on the web and I am going to sample a couple of them, to try and make sense of the question above. Good source for different studies and forecasts:

http://www.postscapes.com/internet-of-things-market-size/

Whilst acknowledging there are discrepancies between them, what do these reports tell us?

The volume of connected devices will be about 20-30 Billion by the end of 2020 which is a growth rate of 20-25%.
Most of the “value” created, with varying definitions of economic value add, will be in the business sector (2/3) as opposed to the consumer sector (1/3).
However, most of the end-point deployments (2/3) are in the consumer segment i.e. 13.3-20Bn and the rest in business, 6.7-10Bn.
The investment in device/software/integration will be a small chunk of the overall economic value created (~10%).
Only 10% of devices will be connected over cellular, 90% non-cellular
Average cost for a consumer endpoint is $100 and this is flat to 2020; By contrast the business average is $400 falling to $250-300 by 2020.
- Likely to be considerable variation as some end points are already <£10
Opinions differ on the share of the device vs. system cost and reflect perhaps different expectations in business environments compared to consumer and scenarios where different systems are becoming interconnected.

Guesswork.. and plenty of assumptions

If we are interested in device based business cases then the volume is in the consumer segment. Within *consumer there can be home, personal transport and personal technology.

Home: home hub, lighting, remote thermostats, remote controls, radiator valves, RC sockets, fire/smoke detectors, movement detectors, video surveillance, energy usage monitoring, humidity sensors, smart bed etc.
Transport: car/motorbike charge point, bicycle light charging
Personal technology: PC, tablets, game console, game controllers, smart phones, smart watches, smart clothing (generic), smart health (BP/glucose monitoring) etc.

Next, some guesswork and assumptions…

Environment	Consumer segment share	Autonomous share in segment
Home	50%	35%
Transport	10%	5%
Personal	40%	80%

In the assumptions in the table above, “autonomous” refers to devices which are designed to operate from battery over the main course of their operation/use cases. This can refer to low interaction devices e.g. humidity sensor, temp monitor/controller as well as high rate ones e.g. a game controller.

Plugging this table of our assumptions on top of the forecasts and assumptions of others, we have 50% share for autonomous IoT devices in the consumer segment i.e. 6-7Bn devices in 2020 and value at $6-700Bn.

Conclusion: autonomous IoT devices look attractive enough to consider.

*I note that some reports consider devices with a “human data input” interface not to be part of IoT, but part of general internet evolution i.e. PCs, tablets and the primary usage mode of smartphones.

In many ways, I like this definition, but given the fast pace of technology evolution it seems too binary to be sustained. For example, consider a simple autonomous sensor but with a button to enable voice interaction. I believe that the voice interface will have a hugely disruptive impact on the design of and our perception of the capabilities of simple autonomous sensing devices.

Here is the link to Amazon’s Alexa offering which is available to be integrated into 3rd party devices, offering natural language parsing and the possibility to define a custom set of actions (skills kit) according to the spoken phrase. Talking toothbrush anyone?

Internet of Things: Challenges using standard hardware modules

There is a huge amount of hype related to the internet of things as we have already explored in a previous blog.

However in its current state the IoT market consists primarily of a myriad of proprietary solutions optimised for a given application; with these conditions it does not seem likely that IoT will deliver on the hype around it. If that situation changed and standardised radio interfaces were used along with general purpose hardware modules which could be purposed for application by software alone then the market could explode.

In order to make the internet of things realise its potential it is imperative that the creation of networks is both straight-forward and low cost.

The availability of wireless enabled computing elements such as the Raspberry Pi or ultra-low power elements such as the Nordic nRF52 promise to enable the creation of Internet of Things systems with very low cost and great configurability. However the reality of creating such systems is more complex than it might be.

Raspberry pi 3 with built-in wireless capability

Types of wireless compute elements

There are fundamentally two types of autonomous compute elements in IoT networks:

Battery powered without frequent re-charging. The over-arching design objective is minimise energy and power consumption (to use primary cells or perhaps solar charging) which prevents the use of current WLAN technologies and drives a demand to minimise processing on-board. The relevant RF communications candidates for these devices are Bluetooth and ZigBee/Thread. Generally speaking these elements require an intermediate gateway to connect to the internet. These elements will be referred to as sensor nodes.
Mains powered or battery with frequent re-charges. In this category ultra-low power is not a driver, RF link technologies such as standard Wi-Fi, proprietary (e.g. SigFox) or cellular are most appropriate to connect to the internet. Included in this category potentially are smart phones. These devices may either gather data themselves or else harvest it from the ultra-low power devices detailed above; in which case as well as possessing radio technology to connect to the internet, they must also contain radio technologies such as Bluetooth or ZigBee. These elements will be referred to as gateway nodes.

Connecting up

For a typical IoT application in addition to the elements detailed above the following are required:

A wireless router or a cellular base station connected to the internet.
A cloud application to aggregate, analyse and display data. In addition this application can also monitor and control the nodes in the network.

For this system to work in a ‘fully horizontal’ manner the interfaces between each element should be well defined and published and could therefore be connected like ‘lego’. However there are certain challenges which need to be overcome. The key questions which need to be initially addressed are:

Choice of radio technology to connect the nodes.
Choice of higher level communications protocol to gather/deliver information between the nodes and the internet based cloud application.

These two questions will be addressed in further blog posts appearing here.