Quick summary
Narrative
A couple of weeks ago I went to Sensors Expo 2017 in San Jose. This topic is slightly outside my normal beat, but fits with my ongoing interest in "telcofuturism", especially around the intersection of IoT, networks and AI. It also dovetails well with recent writing I've done on edge computing (link & link), a webinar [this week] and paper on IoT+video for client Dialogic (link), and an upcoming report I'll be writing on LPWAN for my Future of the Network research stream at STL Partners (link).
First things first: listening to some of the conference speeches, and then walking around the show floor, made me realise just how little I actually knew about sensors, and how they fit into the rest of the IoT industry. I suspect a lot of people in telecoms - or more broadly in wireless networking and equipment - don't really understand the space that well either.
For a start, there's a bewildering array of sensor types and technologies - from tiny silicon accelerometers that can be built into a chip (based on MEMS - micro-electromechanical systems), right up to sensors woven into large-scale fabrics, that can be used to make tarpaulins or tents which know when someone tries to cut them. There's all manner of detectors for gases, proximity, light, pressure, force, airflow, air quality, humidity, torque, electrical current, vibration, magnetic fields, temperature, distance, and so forth.
Secondly, a lot of sensors have historically been part of "closed-loop" systems, without much in the way of "fully-connected" computing, permanent data collection, networking, cloud platforms or analysis.
An easy example to think about is an old-fashioned thermostat for a heating system. It senses temperature - and switches a boiler or radiator on or off accordingly - without "compute" or networking resource. This has been reinvented by Nest and others. Plenty of other sensors just interact with "real-time" systems - for example older cars' airbags, or motion-detection alarms which switch on lights.
In industry, a lot of sensors hook into the "real-time control" systems, whether that's for industrial production machinery, quality control, aircraft avionics or whatever. These often use fixed connectivity, with a bewildering array of network and interface types. It's not just TCP/IP or familiar wireless technologies. If you haven't come across things like Modbus or Profibus, or terms like RS485 physical connections, you perhaps don't realise the huge complexity and unfamiliarity of some of these systems. This is not telco territory.
This is important, as it brings in an entire new realm to think about. From a telco perspective, we're comfortable talking about the touch-points of networks and IT. We are don't often talk about OT or "operational technology". A lot of people seem to naively believe that we can hook up a sensor or a robot or a piece of industrial machinery straight to a 4G/5G/WiFi connection, then via Internet or VPN to a cloud application to control it, and that's all there is to it.
In fact, there may well be one, two or three layers of other technology involved first, notably PLC units (programmable logic controllers) as well as local gateways. A lot of this is the intranet-of-things, not the Internet-of-things - and may well not even be using IP as most people in networking and telecoms normally think about it.
In other words, there's a lot more optionality around ISO layers - there are a broad range of sector-specific or proporietary protocols, that control sensors or IoT devices over a particular "physical layer". That contrasts with most users' (and telco-world observers') day-to-day expectations of "IP everywhere" and using HTTP and TCP/IP and similar protocols over ethernet, WiFi, 4G or whatever. The sensor world is much more fragmented than that.
These are some of the specific themes I noted at the event:
- Sensor technology is complex, diverse, fascinating & fast-evolving.
- There are dozens of sensor types & technologies.
- Nobody believes the 20-50bn devices forecasts, especially if they are based on assumptions that 1 sensor = 1 device
- Some sensors improve the capabilities of already-connected devices, like phones or (increasingly) cars.
- Some sensors enable creation of new forms of connected device & application.
- Most sensors connect first via one or two tiers of local gateways, sub-systems or controllers, rather than directly connect to the Internet / cloud individually
- While the amount of sensor-generated data is growing hugely, not all of this needs real-time collection and analysis, and so network needs are less-extreme.
- Many industrial sensors use niche or unfamiliar forms of connectivity.
- Genuine real-time controls often need sensors linked to "closed-loop" systems, rather than using Internet connections / cloud.
- WiFi & short-range wireless technologies like Bluetooth & ZigBee are growing in importance. There is limited concern about using unlicensed spectrum
- LoRa radios (sometimes but not always with LoRaWAN protocols) are growing in importance rapidly
- Cellular connectivity is important for certain (especially standalone, remote/mobile & costly) sensor types, or sensor-rich complex objects like vehicles.
- The US seems more keen on LTE Cat-1 / Cat-M than NB-IoT for sensor-based standalone devices. Europe and Asia seem more oriented towards NB-IoT
- There are no obvious & practical sensor use-cases that need 5G, but it will likely improve the performance / economics / reach of some 4G applications.
- Camera / image sensors are becoming hugely important and diverse. These are increasingly linked to either AI systems (machine vision) or new forms of IoT-linked communication applications
- "Ordinary" video sensors/modules are being supplemented by 3D, depth-sensing, emotion-sensing, 360degs, infra-red, microscopy and other next-gen capabilities.
- AI and analytics will sometimes be performed on the sensor or controller/gateway itself, and sometimes in the cloud. This may reduce the need for realtime data transmission, but increase the need for batch transfer of larger files.
- Conclusion: sensors are central to IoT and evolving fast, but the impact on network connectivity - especially new cellular 4G and 5G variants - is diffuse and non-linear.
Narrative
A couple of weeks ago I went to Sensors Expo 2017 in San Jose. This topic is slightly outside my normal beat, but fits with my ongoing interest in "telcofuturism", especially around the intersection of IoT, networks and AI. It also dovetails well with recent writing I've done on edge computing (link & link), a webinar [this week] and paper on IoT+video for client Dialogic (link), and an upcoming report I'll be writing on LPWAN for my Future of the Network research stream at STL Partners (link).
First things first: listening to some of the conference speeches, and then walking around the show floor, made me realise just how little I actually knew about sensors, and how they fit into the rest of the IoT industry. I suspect a lot of people in telecoms - or more broadly in wireless networking and equipment - don't really understand the space that well either.
For a start, there's a bewildering array of sensor types and technologies - from tiny silicon accelerometers that can be built into a chip (based on MEMS - micro-electromechanical systems), right up to sensors woven into large-scale fabrics, that can be used to make tarpaulins or tents which know when someone tries to cut them. There's all manner of detectors for gases, proximity, light, pressure, force, airflow, air quality, humidity, torque, electrical current, vibration, magnetic fields, temperature, distance, and so forth.
Secondly, a lot of sensors have historically been part of "closed-loop" systems, without much in the way of "fully-connected" computing, permanent data collection, networking, cloud platforms or analysis.
An easy example to think about is an old-fashioned thermostat for a heating system. It senses temperature - and switches a boiler or radiator on or off accordingly - without "compute" or networking resource. This has been reinvented by Nest and others. Plenty of other sensors just interact with "real-time" systems - for example older cars' airbags, or motion-detection alarms which switch on lights.
In industry, a lot of sensors hook into the "real-time control" systems, whether that's for industrial production machinery, quality control, aircraft avionics or whatever. These often use fixed connectivity, with a bewildering array of network and interface types. It's not just TCP/IP or familiar wireless technologies. If you haven't come across things like Modbus or Profibus, or terms like RS485 physical connections, you perhaps don't realise the huge complexity and unfamiliarity of some of these systems. This is not telco territory.
This is important, as it brings in an entire new realm to think about. From a telco perspective, we're comfortable talking about the touch-points of networks and IT. We are don't often talk about OT or "operational technology". A lot of people seem to naively believe that we can hook up a sensor or a robot or a piece of industrial machinery straight to a 4G/5G/WiFi connection, then via Internet or VPN to a cloud application to control it, and that's all there is to it.
In fact, there may well be one, two or three layers of other technology involved first, notably PLC units (programmable logic controllers) as well as local gateways. A lot of this is the intranet-of-things, not the Internet-of-things - and may well not even be using IP as most people in networking and telecoms normally think about it.
In other words, there's a lot more optionality around ISO layers - there are a broad range of sector-specific or proporietary protocols, that control sensors or IoT devices over a particular "physical layer". That contrasts with most users' (and telco-world observers') day-to-day expectations of "IP everywhere" and using HTTP and TCP/IP and similar protocols over ethernet, WiFi, 4G or whatever. The sensor world is much more fragmented than that.
These are some of the specific themes I noted at the event:
- Despite the protocol zoo I've discussed, WiFi is everywhere nonetheless. Pretty much all the sensor types have WiFi connectivity options somewhere, unless they're ultra-low power. There's quite a bit of Bluetooth and ZigBee / other varieties of IEEE 802.15.4 for short-range access too.
- Almost nobody seems bothered about the vagaries of unlicensed spectrum, apart from a few seriously mission-critical, time-critical applications, in which case they'll probably use fixed connections if they can. Bear in mind that a lot of sensors are actually fairly time-insensitive so temporary interference or congestion doesn't matter much. Temperatures usually only change over seconds / minutes, not milliseconds, for example. Bear in mind though, that this is for sensing (ie gathering data) not actuating (doing stuff, eg controlling machines or robots).
- Most sensors send small bursts of data - either at set intervals, or when something changes. There are exceptions (notably camera / image sensors)
- I saw a fair amount of talk about 5G (and also 4G and NB-IoT) but comparatively little action. Unlike Europe, the US seems more interested in LTE Cat-1 and Cat-M rather than NB-IoT. Cat-M can support VoLTE, which makes it interesting for applications like elder/child-trackers, wearable and building security. NB-IoT seems fairly well-suited to things like parking meters, environmental sensors, energy metering etc. where each unit is comparatively standalone, and needs to link to cloud/external resources like payments.
- There's also lot of interest in LoRa, both as a public network service (Senet was prominently involved), and also as privately-owned infrastructure. I think we're going to see a lot of private LoRa embedded into medium-area sensor networks. Imagine 100 moisture sensors for a farm, connected back to a central gateway on top of the barn, and then on to a wide-area connection (fixed or mobile) and a cloud-based application. The 100 sensors don't need a wireless "service" - they'll be owned by the farmer, or else perhaps the connectivity will be offered as a part of a broader "managed irrigation service" by the software company.
- There's an interest in wireless connectivity to reduce regulatory burdens for some sensors. For example, to connect a temperature sensor in an area of an oil refinery with explosion risks, to a server in another building, requires all manner of paperwork and certification. The trenching, ducting and physical wire between them needs approval, inspection and so on. It's much simpler to do it with wireless transmitters and receivers.
- A lot of the extra sensors getting connected are going to be bundled with existing sensors. Rather than just a vibration sensor, the unit might also include temperature and pressure sensors in integrated form. That probably adds quite a lot to the IoT billions number-count, without needing separate network links.
- A lot of sensors will get built into already-connected objects. Cars and aircraft will continue to add cameras, material stress sensors, chemical analysis probes for exhaust gases, air/fluid flow sensors, battery sensors of numerous types, more accelerometers and so on. This means more data being collected, and perhaps more ways to justify always-on connections because of new use-cases - but it also means a greater need for onboard processing and "bulk" transfers of data in batches.
- Safety considerations often come ahead of security, and a long way ahead of performance. A factory robot needs sensors to avoid killing humans first. Production quality, data for machine learning and efficiency come further down the list. That means that connecting devices and sensors via wider-range networks might make theoretical or economic sense - but it'll need to be seen through a safety lens (and often sector-specific regulation) first. Taking things away from realtime connections and control systems, into a non-deterministic IP or wireless domain, will need careful review.
- Discussion of sensor security issues is multi-layer, and encouragingly pervasive. Plenty of discussions around data integrity, network protection, even device authenticity and counterfeiting.
- Imaging sensors (cameras and variants of them) are rapidly proliferating in terms of both capabilities and reach into new device categories. 3D depth-sensing cameras are expected on phones soon, for example for facial recognition. 360-degree video is rapidly growing, for example with drones. Vehicles will use cameras not just for awareness of surrounding, but also to identify drivers or check for attentiveness and concentration. Rooms or public-spaces will use cameras to count occupancy numbers or footfall data. New video endpoints will link into UC and collaboration systems "Sensed video" will need greater network capacity in many instances. [I am doing a webinar with Dialogic about IoT+video on July 13th - sign up here: link]
- Microphones are sensors too, and are also getting smarter and more capable. Expect future audio devices to be aware of directionality, correct for environmental issues such as wind noise, recognise audio events as triggers - and even do their own voice recognition in the sensor itself.
- Textile and fabric sensors are really cool - anything from smart tarpaulins for trucks to stop theft, through to bandages which can measure moisture and temperature changes, to signal a need for medical attention.
- There's a lot of modularity being built into sensors - they can work with multiple different network types depending on the use-case, and evolve over time. A vibration sensor module might be configurable to ship with WiFi, BLE, LoRa, NB-IoT, ZigBee and various combinations. I spoke to Advantech and Murata and TE Connectivity, among others, who talked about this.
- Not many people seemed to have thought about SIMs/eSIMs much, at a sensor level. The expectation is that they will be added by solution integrators, eg vehicle manufacturers or energy-meter suppliers, as needed.
- AI will have a range of impacts both positive and negative from a connectivity standpoint. The need for collecting and pooling large volumes of data from sensors will increase the need for network transport... but conversely, smarter endpoints might process the data locally more effectively, with just occasional bulk uploads to help train a central system.
No comments:
Post a Comment