Author Archives: Robert Alfonsi

Update on our first prototype & air pollution on BBC news again

BBC London ran a recent story on air pollution exposure during commuting:

It now seems a long while since our last blog post, but air pollution is barely out of the news with the latest BBC story about air pollution exposure during commuting. This topic is fairly close to our hearts with the pollution guardian activity inspired by the fact that air pollution exposure is highest within motor vehicles.

Earlier on this year, we put together our first prototype pollution sensor containing a particulate sensor for PM2.5 measurement and a Nitrogen Dioxide (NO2 ) gas sensor. PM2.5 refers to the measurement of very small particles, less than 0.0025mm in diameter which can go deep into the lungs and containing a variety of payloads e.g. road, brake or tyre dust or chemical compounds from combustion. Nitrogen Dioxide gas can exacerbate respiratory conditions and at street level is mainly produced by diesel vehicles.

How does out first prototype look?

Close up photo of our first protoype unit

Why did we make this first prototype?

  • to create a self-contained sensor unit with its own internal power supply to enable easier bench and field (car) testing
  • to shrink the volume of air trapped within the unit in order to keep the unit responsive to the current air conditions
  • to enable experimentation with parameters to find the best balance of sensitivity versus stability

We will write a bit more about the “infrastructure” of the prototype and surrounding app and cloud solution in later blogs, but the main question we had when we put the hardware unit together was does it work?

Well, the good news was that the prototype actually worked as expected across a range of functional areas with only one bug with battery charging which was solved by a simple hardware modification to the units.

How well did the units work compared to our initial cardboard prototypes? Pretty good in practice:

  • having “always on” internal power meant that the sensors could be ready to start work within a couple of seconds; previously the sensors could require several hours from being powered up to being ready to measure
  • fast responsiveness to Nitrogen Dioxide gas e.g. able to pick out smelly vehicles passing by

NO2 measurement against time

And where does that spike of air pollution correspond to? A smelly van on the southbound slip road of the M25/A3 junction…

Map of NO2 air pollution hotspot on M25/A3 southbound sliproad

 

Pollution Guardian: Measuring air pollution with cereal packet prototypes

As mentioned in the previous blog, we put in a lot of preparation work over summer 2018 in order to be able to quickly start work on the Pollution Guardian project and de-risk certain areas. One of the first items to be actioned was the creation of a custom circuit board to explore the performance of our selected, affordable Nitrogen Dioxide (NO2) gas sensors and the type of electronics needed to setup, amplify and filter the output of these sensors. We called it our “bench test” circuit board as we thought it would only get used indoors on the bench..

Bench test circuit board

With the bench test board, we designed a couple of options for the electronics solution:

  • to provide a backup option, in case the one circuit failed to perform
  • provide us alternate options based on relative performance
  • to enable optimisation of the bill of materials cost

Designing & making the circuits went relatively smoothly,  but it is not until you receive circuits that you can really see what is going on. Some mistakes we discovered quickly, whilst others took a period to debug. Mostly our mistakes were due to the misinterpretation of and assumptions on the component specifications; our first solutions to these issues actually went on to compound our problems.

After a period of investigation and debugging, we were finally able to identify and solve the underlying issue. As part of this work, we lashed these prototype circuits together with an off-shelf development board (TI cc2640R2) all contained in a cereal packet wrap for protection. We called our first units  Dougal & Zebedee and took them out of the lab and into the car:

Dougal and zebedee prototypes

What we found when we started testing out the units was that whilst our units appeared quite sensitive to temperature change, they were actually capable of detecting low levels of NO2 inside the car.

The picture below shows a trace of NO2 measurements whilst traversing the one way gyratory system in the centre of Guildford – note that a decreasing level on the graph trace implies a higher NO2 concentration:

Air pollution on Guildford gyratory system

 

So, at the conclusion of our cardboard proto work, we knew we had the right potential sensitivity toward NO2 which we could work with on the next prototype to calibrate and try to get consistent between test units.

 

 

 

Pollution Guardian: From competition win to prototyping

BBC cartoon programme Magic Roundabout characters

Magic Roundabout characters

Feasibility projects like the Pollution Guardian imply a certain level of risk and it was critical for our business to secure some grant support from Innovate UK to help us mitigate those risks.

Looking back, it seems a long time since we made our application for funding, but considering the risks ahead, we prepared ourselves in order to get started quickly in case of a positive outcome of our bid:

  • Working on the system architecture, driving decisions on the hardware and software platforms to use within development
  • Further research on the key components
  • Talking to collaborators and contractors to re-check availability
  • Re-planning the market research

Now, many academic papers point to the difficulty in using affordable sensors e.g. around variability, stability and accuracy, so one of our biggest challenges in the project is to put together an affordable solution based on these sensors. Our approach was to tackle this issue head on, building a very early prototype and using a minimum “data gathering platform” around it to understand the pitfalls & performance issues.

This early work cut across several disciplines:

  1. Electronics, designing a custom circuit to best interface with affordable gas sensors
  2. Firmware, building on a development platform to gather and share sensor data over wireless
  3. Mobile app, customised to gather the local sensor data & upload it to a data store
  4. Mobile backend, a real time database to capture the data streams and tools to help explore the data
  5. Mechanics, how to wrap this early prototype for real world use
  6. Early system testing & validation approach

We will be adding a few blogs to the site to cover progress on the above items; suffice to say the first mechanical housing for the unit followed the “breakfast cereal box” approach. After wrapping up the first sensor unit, its looks gave us the name for our prototype, Dougal, after the dog character from the programme, “The Magic Roundabout”.

Dougal, the Pollution Guardian cereal box prototype

Sensing the Air Quality

Venue for sensing the air quality and emissions program

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 46th 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 PM2.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 NO2 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

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.

London Tech Expo 2017, IoT products and enablers

London Olympia, site of IoT Tech Expo 2017This is a modified version of an article originally published on LinkedIn here.

I made a worthwhile trip to the IoT London event (23-24th 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…

Time progression of hype cycle for IoT/IoE

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:

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.

Basic Iot use cases

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

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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 showing certificates and policies

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.

Amazon Web Services Internet of Things (IoT) setup and configuration block diagramSummary

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”.

Amazon web services Internet of Things (IoT) creation of a rule for processing IoT data

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.

Amazon Web Services Internet of Things (IoT) creation of an action on IoT data

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.

AWS Internet of Things (IoT) configuration of an action on IoT data

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.

AWS Internet of Things (Iot) workaround for role definition for IoT actions

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.

Segmenting the IoT Market, autonomous versus powered

Consumer versus business IoT deployments

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?