Putting a product on the IoT

The Internet of things (IoT) is the interconnection of electronic devices or ‘things’ which are used together as part of a network. This reference study addresses the questions ‘Should I put my product on the IoT?’ and ‘How do I put my product on the IoT?’

Go to the profile of Kurt Morgan
Sep 21, 2017
0
0
Upvote 0 Comment

Author(s): Kurt Morgan

Abstract

This study is aimed at engineers who are familiar with product development and their own application area, but are new to adding IoT connectivity to their products. It includes examples of real-life IoT applications, for engineers to compare with their products, to give ideas of the benefits of the IoT. It lists current technologies that can be used to put products on the IoT and gives criteria for evaluating them. It includes two case studies of real products (mains powered hospital decontamination equipment and a battery powered wireless sensor), showing which criteria have been considered. The IoT trend has provided lots of tools and technologies that can be applied now to give real benefits to customers and this reference study is intended to inspire engineer to use them.

Introduction

The Internet of things (IoT) is the interconnection of electronic devices or ‘things’ which are used together as part of a network. That is, making devices with sensors talk to devices with actuators. Wireless technologies and the public Internet have facilitated the IoT – but the term applies equally to wired sensors and local application specific networks. Researchers were using the Internet to keep tabs on their coffee machine [1] before domestic consumers were able to access the Internet [2]. The IoT promises to enable new applications by: connected devices working together automatically and allowing customers to solve their own problems by connecting devices together [3,4]. Interest in the IoT means that there are lots of tools that enable engineers to provide new features to products and new services to clients.

This reference is intended to answer the questions: ‘Should I put my product on the IoT?’ and ‘How do I put my product on the IoT?’ The final answers to these questions depend on specific commercial circumstances. You can put your product on the IoT if someone is willing to pay for the benefit it provides and the amount that they are willing to pay will determine your options. This paper gives use cases which you can compare with your circumstances and options to address the key technical hurdles.

Should I put my product on the IoT?

Although the IoT is applied to many applications, the actual use cases for devices are a combination of the following:

  • Sensing: Some devices are sensors, reporting physical properties such as temperature or position, as well as logical inputs such as selections on a screen. Other devices contain sensors as part of their function. The devices report the sensor values over the IoT.
  • Performance monitoring: Devices have varying degrees of autonomy. Devices that have some degree of autonomy monitor their own performance and can report their operating status over the IoT.
  • Control: Devices can be actuated, operated or configured directly over the IoT.

According to Fujitsu’s IoT Delivery Solutions Lead, Karl Verhulst, speaking at Agri-tech East’s REAP Conference 2016, the ‘secret sauce’ that turns successful remote control or remote sensing into a successful IoT application is the algorithm that connects devices. Algorithms may use rules created using expert knowledge or machine learning. The IoT is effective when the algorithm makes control decisions that would not otherwise be possible. The following (in Table 1)  are a list of application areas with examples of devices, functions and algorithms that might be used.

Application area

Example

Devices (‘things’)

Functions

Algorithm

Key benefit

personal care

telemedicine

pacemaker, in home gateway [5]

sensors for heart activity, sensors for battery, monitoring of pacemaker performance

detection of events defined by doctor

Doctor notified when unexpected events happen – problems detected before patient reports them at routine monitoring [28]. The IoT aspect is read only – no direct control function, presumably because of security fears [5].

fitness equipment

scales, fitness watch, phone (gateway for watch)

scales – sense weight, fitness watch – sense location and movement, report notifications to user

detection and recording of activity (by watch – edge computing). reporting and tracking of fitness plans

The results of all the devices are reported in an online dashboard [29]. This can direct users through fitness plans, this turns the activity into a game (gamification) and uses social media to encourage competition between friends.

transport

taxi service [6]

autonomous cars normal cars

autonomous car is fully autonomous – status reported, controlled with pickup/drop off destinations. Normal cars controlled manually, but ordered and paid for in the same way by customers

system schedules pickup and drop off of cars

The cars can be ordered conveniently using an app, the ETA of the car monitored and payment made (or shared with friends) using the app [7]. In current implementation, the autonomous car does have a driver in a supervisory capacity.

patient flow control [8]

phone, Bluetooth beacons, signage, doctor/admin computer

administrator – enters appointment. Phone – directs patient automatically using beacons. Signs – display appointment slots. Doctor – reports patient seen

system monitors location of patients/doctors in real time, updates digital signage and patients directions

Hospitals are a maze. Patients need to visit multiple specialists and facilities as part of an appointment. This system directs patients through the hospital, from one part of the appointment to the next automatically.

smart homes

smart thermostat

boiler, thermostat, smoke/carbon monoxide alarm, security cameras, oven etc.

thermostat – senses room temperature and occupancy, boiler – controlled by thermostat, alarm – senses smoke/CO, cameras – detect occupancy

principal algorithm monitors: schedules; remote commands and if people are present to turn heating and compatible appliances on/off. Additional features such as security alerts on unexpected entry

The principal application is as a smart thermostat. This works autonomously and wirelessly to control the boiler – but can report and be controlled using IoT functionality. An IoT interface is provided for other manufacturers to connect their devices.

smart cities

recycling bins [9]

recycling bins

bins – report available space

system updates the routes for bin collection

This was facilitated by a lower cost (£10 s), low-power (years on AA batteries) modules, lowering the cost of ownership to the point that it can be used on low-value items such as bins.

parking spaces [10]

parking space sensors in Tarmac

sensors – sense if car present

system creates a map of space occupancy

Drivers can access the location of available spaces using detailed mapping.

smart farms

poultry farm [11]

feed storage bins, feed stations, cameras, temperature sensors

level sensing in storage bins and feed stations. Cameras output images. HVAC reports

calculation of bird weights, mortality rates and consumption of food/water per bird

Poultry farms are already highly automated. This calculated per-bird food uptake information and trends, which were not previously available. It added automatic notification when bird health parameters were out of acceptable ranges.

smart factories

industry 4.0 assembly line work station [12]

equipment, terminal operator-tag

equipment – reports status, terminal – senses operator presence, scans barcode of work item, displays work orders with instructions

central database, not just of orders and stock, but all work orders and the status of operations in progress

The whole factory is managed by a central system, so it is possible to manufacture small batches of customised products without confusion.

industry 4.0 machine [13]

machine, personal device (phone, tablet etc.)

machine – reports status, device – shows status (and designs and operation history and service history)

central database, with all details of equipment design and configuration to hand

information about the equipment (such as faults, or the need for routine maintenance) is provided in a vendor neutral way, allowing factory workers and machine service workers to understand and fix problems quickly

Table 1: Example IoT applications

Range

Example

miles

LoRA, Sigfox, Weightless, Cellular (GSM/UTMS/LTE), Wired (DSL)

local

Zigbee, Z-Wave, Thread, WiFi, X10, Lifi, Wired (Ethernet, MODBUS, CAN)

near

Bluetooth, intrared, RF identification, NFC, Wired (USB)

Table 2: Examples of IoT connectivity technology

How can I put my product on the IoT?

Connect physically

As the IoT develops, there will be many wired and wireless ways of connecting devices (Table 2) [14]. They can be evaluated against the following list of criteria.

Cost: The total cost of ownership of the system – including development costs, unit costs, ancillary hardware costs (gateways, personal devices) and ongoing costs (standing- and usage-based connectivity charges, licences, maintenance and batteries).

Size: How much size the communications will add to the system. The frequency of wireless devices sets the antenna size which can be a limiting factor.

Geographic availability: Connectivity methods are not available in all geographies: spectrum or intellectual property (IP) licencing, or infrastructure may prevent (or increase the cost of) deployment in some places.

Licencing and compliance: Radio equipment is subject to the Radio Equipment Directive in Europe and Federal Communications Commission Rules and Regulations in the United States. Many products comply with regulations in their target market by using pre-approved radio modules which comply with international standards and which may be explicitly registered with the authorities in particular markets. Adding wireless modules as directed by their manufacturers does not add a large compliance burden to products. The regulatory bodies in target markets provide simple guidelines on compliance.

Weight: Important for mobile devices.

Power: For devices without a wired power supply, power consumption is likely to be critical. If even possible, the cost or inconvenience of battery replacement might be prohibitive. Many connectivity options trade-off bandwidth (lower-frequency devices often use less power) and latency (sleeping devices use little power) and use sophisticated network gateways (to schedule the sleeping and offload the high-power communications to a wired device) to reduce power consumption. Power can be managed at an application level too, turning off transceivers when not in use, or using power harvesting (wind/solar/heat/motion) technology on a device.

Range: Where devices are deployed in a building, or vehicle, there may have a local wired or wireless connectivity option. Connecting to this network might be an efficient solution, where this is not possible (for security, for physically remote devices, or just where the local network is not owned by the deployer of the device for instance), installing a local gateway, careful alignment of a directional antenna, or using a long-range option may be required. Radio range is a function of radio frequency (low frequency radio waves tend to get attenuated less by the environment), output power, bandwidth used, physical orientation, attenuation of obstructions, antenna directionality and the radio protocols used; so depends very much on a particular application or even installation.

Latency: To save power, some devices switch off. This means that they will not receive messages immediately. It may also mean that they have to wait for a specific time for the network (of sleepy routers) to be ready to transmit. The time to transmit a message depends on the bandwidth and amount of data in addition to any routing and turning on delays.

Security: Some communications hardware provides secure communication (guarantees of who is talking to whom and that no-one else can receive or tamper with the messages). This will also require consideration at an application level.

Resilience/availability: There is always a risk that components of a system will fail. In the event of a failure, it will take time to repair the system. IoT systems appear resilient, if one ‘thing’ fails, only a subset of features associated with the thing should become unavailable. In practise, IoT features which appear to only involve interactions between two battery powered things in the same room may rely on: a mains powered gateway, long-distance communications networks and remote servers. The failure of any one of which might stop the apparently simple interaction working. A cost/risk analysis is required. Costs could include safety and reputation. To improve reliability it might be necessary to consider the system architecture, to do processing locally (perhaps in edge nodes, or a gateway rather than the Internet), to use a multi-point communications system with redundancy built in and a messaging protocol that handles failure. The costs can be reduced by keeping customers well informed as issues emerge through backup communications channels [15]. There may also be contractual and business model considerations.

Interoperability: Part of the application may be integration with other devices. Being compatible may be a way of selling a device. It might also make an application affordable, if some development or infrastructure is paid for by someone else. This can be achieved by direct physical connection, directly via the Internet or using a gateway server.

Long-term availability: The IoT is a developing field. Some components are available from single vendors or rely on networks which are just rolling out. Some companies will fold and leave customers without products and services. Customers may be unwilling to take the risk of buying something that becomes obsolete. If customers are buying a service, what are the risks and costs of part of the system being unavailable and what can be done to mitigate this (lifetime buy of spares, owning any infrastructure, contracts backed by a large reputable company, using a more stable technology)?

Make the ‘Thing’ compatible

For devices to be connected together in an IoT application, they have to be able to find one another, know where to send their messages and speak the same language. This is the job of network protocols. Ecosystems of products exist around network protocols, for instance the Nest [16] smart thermostat defines a protocol for other smart home devices. There are many other products marketed as Nest compatible. Alternatively, a device can talk with other devices via a server (middleware) that connects them to other products (or suites of products). For instance, the Wemo Smart Socket [17] can be used to switch off appliances using a vendor supplied app – but the Wemo web service can also be configured to respond to events from a Nest thermostat and the IFFT web service can control Wemo Sockets. These integrations use the Nest and IFFT branding and are easy for consumers to use.

There are general purpose protocols for connecting IoT products which are designed to be transported over internet protocol (IP), including: MQTT, CoAPP, DDS, AMQP and XMPP. IoT devices also use the normal hypertext transfer protocol (HTTP) which is used to submit forms on webpages. It is possible for devices to communicate with an application specific server (possibly in the cloud) or to use a server and middleware provided as a service. Amazon [18], Microsoft [19] and IBM [20] all provide IoT services supporting MQTT and HTTP. Google [21] use their own protocol. Where low-power devices are connected to a local gateway, the gateway could connect the devices using a general purpose protocol. Clear documentation and examples will enable other people to make products that are compatible with your device. Once IoT devices are connected to a server, they may be accessible through an application programming interface (API) using other protocols. Things to consider in choosing an IoT protocol (and associated server) include:

Compatibility: What devices need to work together? If particular connections are required, does the protocol support them directly or will additional software development be needed? Do these devices use predefined application specific messages?

Reliability: What happens when the messages are sent over an unreliable channel? Will they be resent or stored for later resending, what notification will there be to the application?

Scalability: Will the protocol work with large numbers of devices? How will this impact cost and performance? Will it be possible to improve these with more/better hardware?

Speed (encoding, latency, bandwidth): The physical connection will limit the available message size and bandwidth. Are the application specific messages small enough to be sent when encoded using the protocol? If devices are being used to control other devices, is the protocol and associated server fast enough?

Security: Conduct a security threat assessment, what security is required? Is the protocol field tested and information on previous attacks understood? The physical communication layer may provide some security features. Does the protocol provide the rest? How does security affect the commissioning of the system? Are the algorithms sufficiently fast (particularly if they are not supported by hardware or the device has few resources)? What physical security does the device require? What steps could be taken to secure the rest of the nodes if the security of one was compromised?

Availability: Is the protocol widely used and likely to be supported for the life of the devices? Is it possible to switch servers or protocols during the life of device (especially if they are managed by customers or not physically accessible)?

Provisioning: Devices may need to be configured with a serial number and a security key. They may also need to be associated with a user, or location, and other devices that they connect to directly. They may have a limited user interface for setting this, requiring a configuration mode, button, labelling or an extra hardware interface especially for configuration. Some of these steps could take place during manufacture or be done by consumers. Has this complicated use case been considered to minimise cost and human error?

Upgrading: Will the protocol support various versions of a device in the field? Can devices be upgraded in the field using the protocol? If so, what would happen if an error occurred?

Development: Is there a reference design (hardware or software) that can be reused to design the system quickly and reliably? What features are provided for debugging (such as logging messages and events or reporting them live to a console)?

Cost: What are the total life costs of the solution (during development and operation)? How could these change in the future? Does the protocol enable charging for services (associating users with devices and usage)?

Branding: Is compatibility a selling point? Is additional cost, or development effort, required to be part of the sales channel for ‘compatible’ products? Is there another approach that provides similar benefits?

Using the data

As well as providing a specific application for customers, the IoT provides an insight into how devices are used. Online, customers know that their activity is tracked – by the presence of tailored pop up advertisements. They may be willing to accept this as the price for a free service, though in the EU websites are required to inform users if they are doing this. Similarly, customers may be grateful for calls from service technicians when their IoT devices break down, but this is an area where consumer opinion and the law are developing.

Data protection: Data collected from IoT devices can be personal data, according to the definition of the UK Data Protection Act [22]. How and where this information can be processed is controlled by law. Many devices are associated with an identifiable user. Some devices collect sensitive personal data to do with health. It may be possible to discern other sensitive information from records of usage, occupancy or direct location.

Consumer choice: In the same way that choice of electricity supplier [23] and provision of basic Internet services [24] are (currently) guaranteed by EU laws, as IoT services become more central to life, the ability to access services and to switch providers may come under greater scrutiny.

Useful data

The IoT enables data from devices to be analysed. IoT vendors supply dashboards, giving graphical summary views of data from devices. Machine learning can also be used to detect events from data.

How/how often/when customers use devices: Records of the messages sent to and from devices will give more quantitative information than ever before about how products are used. This will enable development effort to be focused on features that customers actually use and issues that cause customers the most trouble. It may also enable marketing to be more customised, advertising quantified benefits to customers for particular products or offering services at prices that match the level of benefit.

Handling problems: IoT devices can monitor their own status (the current in a motor coil of an autonomous car) or be used explicitly to detect a problem (a river level gauge). This may enable more efficient preventative maintenance and automatic diagnosis of current problems, enabling a quicker response. It will also give real statistics on the frequency of problems and trends of measurements across deployed devices as they age.

Monetising the IoT

As well as buying IoT-enabled devices. Consumers may use IoT-enabled services. They may also buy new features or services for products. How consumers are charged for these products and services is a commercial decision, but IoT technology may enable billing on a per usage basis; provisioning of new features through a software upgrade to existing hardware, where initial purchase costs are subsidised by services charges, or the cost of supplies, the IoT can conveniently enforce or monitor charging arrangements.

Hospital decontamination equipment case study

The equipment: The UltraV ultraviolet light decontamination system, manufactured by Hygiene Solutions in the UK (Fig 1). A mains powered decontamination unit houses strong UV lights that kill pathogens. The unit can be wheeled around hospitals to the rooms where it is needed. UV light monitors are connected wirelessly to monitor the dosage. A touch screen control panel is connected wirelessly to monitor the process and to authorise use, with an NFC (card with an electronic chip) pass. The decontamination unit reports usage to an IoT server, which sends usage reports to managers, texts operators when the process is complete as well as logging all communications and any issues.

Fig 1: UltraV ultraviolet light decontamination system

The system automatically reports successful decontamination cycles to managers. Operators enter the location of processes, which allows managers to confirm which rooms have been cleaned and manage proactive cleaning regimes. Using IoT features, the equipment reports measurements from during the cycle, confirming that the cleaning cycle has been carried out successfully and allowing maintenance to be efficiently scheduled. The time that hospital rooms are unavailable to patients will be reduced by automatically notifying operators when decontamination processes are about to complete and by further integrating the IoT data with existing process management software.

The touch screen, light monitor and unit are connected in a local network using WiFi. This allows the built-in WiFi capabilities of the embedded computers in the touch screen and unit to be used without additional cost. The light monitors are battery powered, but the batteries can be changed easily and the monitors turn themselves off when put away. The WiFi modules selected have good battery life, power and good range and offer a robust connection in indoor environment. WiFi hardware is available from many vendors and can be used without a licence in the countries where the equipment is on sale. Protocols based on HTTP and WebSockets are used over WiFi. This is tried and tested technology, reducing the risk of the development process and ensuring the reliability of the system.

The unit has a cellular modem to report usage. As the equipment can be used in many places and by many operators and owners, it may not always be possible to access other networks. Cellular coverage is available in most locations, using an IoT SIM card, which can roam across all networks in the UK and many worldwide. In buildings, reception is sometimes limited, so messages are stored and resent if they are not received. The MQTT protocol is used to report the message to a private cloud server. The messages were formatted using Javascript Object Notation, which is convenient to process and allows extra fields to be added without changing server software. This is a standard protocol, enabling existing software libraries to be used, with limited development. The system is secured using well-tested techniques and commercial encryption libraries. The units are commissioned during manufacture (using the NFC reader), reducing the training needs for customers. The private server gives stability and controlled costs. The fielded units must continue to work – it might not be possible to upgrade them.

Commenting on the use of IoT in their sector, Tautvydas Karitonas, Design Project Manager of Hygiene Solutions (who manufacture the equipment) said:

‘In the NHS, where efficiency is paramount, the difference that IoT makes to our technology is invaluable. The improved responsiveness and access to readily available data allows us to tailor our service to the specific needs of the client and ultimately allow them to give better quality of care to patients. With IoT technology only set to improve, we will absolutely be looking at new ways of implementing it on future generations of our products. Keeping our clients informed and aware of our decontamination process promptly and accurately is what sets us apart from our competitors and the IoT one of the drivers behind this.’

Building monitor case study

The equipment: A wall-mounted sensor for temperature, humidity, light and sound levels. It is to be installed in buildings to enable heating and lighting to be optimised. It must last for 2 years once installed.

The data can be used to monitor conditions inside buildings. This can detect if the temperature or humidity goes outside of present thresholds, to ensure that the occupants of the building are comfortable (when occupancy if detected) and that the fabric of the building and the equipment in it are not damaged by cold and damp. In future, the IoT data can be used to confirm when heating and lighting systems are turned on and report failures. The set point of heating systems could be automatically updated to ensure that all areas of the building are maintained at the right conditions.

For commercial reasons, the Sigfox protocol was selected though the other low-power wide area network protocols would also have been technically applicable. Sigfox has a range of 40 km in open areas [25]. In practical tests, the units operated inside buildings over 22 km from a base-station with a PCB track antenna and a lithium D size battery. As the Sigfox network is being rolled out in the UK, coverage maps provided by network operators needed to be consulted to ensure operation at particular sites [26]. A power budget for the product showed that the majority of the energy would be used in transmissions. To achieve the 2 year target in practise, the unit could only transmit once per hour and the electronics and the transceiver [27] had to be physically turned off and the microcontroller put into a low-power mode. Only 10 bytes of application payload were available, so a very compact application specific message structure was required, encoding parameters with the minimum number of bits and not wasting space by aligning fields to the nearest whole byte size. No space was available to identify the message format, so the format had to be inferred by the device serial number (a unique number included in all transmissions). The sensors were commissioned during manufacture. The serial number needed to be read from the Sigfox transceiver and entered into the Sigfox Server using an extra serial interface added to the device. The Sigfox Server was configured to send messages to an application specific server using the HTTP protocol. The application specific server was simple to write using a reference design and well-tested open source libraries. The application specific server provided a visualisation of sensor readings. The Sigfox Server logged all transmissions, their timestamps and received power levels allowing the system to be debugged.

Conclusions

IoT technologies are currently being deployed across all sectors of industry, from health care to logistics. The devices themselves can act as sensors and actuators, but the most benefit comes where clever algorithms connect them together to do something that could not be done before. It is possible to imagine IoT functionality being added to many products. A range of wireless connectivity solutions are commercially available, but they have different properties and the options need to be evaluated to choose the right technology for the job. Being compatible with other IoT devices in the same market is a feature for IoT devices, which can be achieved by choosing the right physical connectivity or by making them available via the public Internet. As well as the immediate benefit to customers, the IoT provides accurate information about usage and equipment status to manufacturers which can be used to improve products and offer new services, provided that privacy and security are considered.

References

  1. ‘Trojan room coffee pot – Wikipedia article’, Available at https://www.en.wikipedia.org/wiki/Trojan_Room_coffee_pot, accessed 21 November 2016.
  2. ‘Internet in the United Kingdom – Wikipedia article’, Available at https://www.en.wikipedia.org/wiki/Internet_in_the_United_Kingdom, accessed 21 November 2016.
  3. ‘What is the Internet of things? – guardian article’, Available at https://www.theguardian.com/technology/2015/may/06/what-is-the-internet-of-things-google, accessed 21 November 2016.
  4. ‘The Internet of things is far bigger than anyone realizes – wired article’, Available at https://www.wired.com/insights/2014/11/the-internet-of-things-bigger/, accessed 21 November 2016.
  5. ‘MERLIN.NET™ PATIENT CARE NETWORK – FAQ’, Available at https://www.sjm.com/en/patients/arrhythmias/our-solutions/remote-monitoring/merlin-net-pcn/faq#tab, accessed 21 November 2016.
  6. ‘Uber riders to be able to hail self-driving cars for first time – guardian article’, Available at https://www.theguardian.com/technology/2016/aug/18/uber-riders-self-driving-cars, accessed 21 November 2016.
  7. ‘A Guide to Uber’, Available at https://help.uber.com/en-GB/h/5a9e5cd6-88f4-4597-b29a-4feb67d407c2, accessed 21 November 2016.
  8. ‘Patient flow management for clinics – Stanley Healthcare’, Available at http://www.stanleyhealthcare.com/solutions/health-systems/clinical-operations-workflow/patient-flow-clinics, accessed 21 November 2016.
  9. ‘MK:Smart – helping to deliver the Internet of things in Milton Keynes’, Available at http://www.mksmart.org/blog/2014/05/23/mksmart-helping-to-deliver-the-internet-of-things-in-milton-keynes/, accessed 21 November 2016.
  10. ‘Parking sensors to take pain out of finding a space – new scientist article’, Available at https://www.newscientist.com/article/mg21328506.100-parking-sensors-to-take-pain-out-of-finding-a-space, accessed 21 November 2016.
  11. ‘REAP conference 2016 speakers’, Available at http://www.agritech-east.co.uk/site/reap-2016-speakers/, accessed 21 November 2016.
  12. ‘First Industry 4.0 line on-stream in daily production’, Available at https://www.boschrexroth.com/en/xc/trends-and-topics/industry-4-0/best-practices/multi-product-line-demonstrator/homburg-assembly-line/homburg-line, accessed 21 November 2016.
  13. ‘Industry 4.0: real-life Impact’, Available at https://www.boschrexroth.com/en/xc/trends-and-topics/industry-4-0/best-practices/your-benefits-81, accessed 21 November 2016.
  14. ‘The complete list of wireless IoT network protocols’, Available at https://www.link-labs.com/complete-list-iot-network-protocols/, accessed 21 November 2016.
  15. ‘Amazon web services outage/Canary app’, ‘Unable to connect at this time’, Available at http://sss.status.canary.is/incidents/3tzkw5qdfw86, accessed March 2017 .
  16. ‘Works with Nest’, Available at https://www.nest.com/works-with-nest/, accessed 21 November 2016.
  17. ‘Wemo switch’, Available at http://www.belkin.com/uk/F7C027-Belkin/p/P-F7C027/, accessed 21 November 2016.
  18. ‘AWS (Amazon Web Services) IoT’, Available at https://aws.amazon.com/iot/, accessed 21 November 2016.
  19. ‘Azure IoT hub’, Available at https://www.azure.microsoft.com/en-gb/services/iot-hub/, accessed 21 November 2016.
  20. ‘Watsom IoT platform’, Available at http://www.ibm.com/internet-of-things/iot-solutions/watson-iot-platform/, accessed 21 November 2016.
  21. ‘Internet of things (IoT) solutions’, Available at https://www.cloud.google.com/solutions/iot/, accessed 21 November 2016.
  22. ‘Data protection act 1998’, Available at http://www.legislation.gov.uk/ukpga/1998/29/contents, accessed 21 November 2016.
  23. ‘Your Europe – energy supply’, Available at http://www.europa.eu/youreurope/citizens/consumers/energy-supply/index_en.htm, accessed 21 November 2016.
  24. ‘Your Europe – Internet access’, Available at http://www.europa.eu/youreurope/citizens/consumers/internet-services/internet-access/index_en.htm, accessed 21 November 2016.
  25. SIGFOX M2M network, Available at http://www.iotglobalnetwork.com/products/single/id/571/sigfox-m2m-network-access, accessed March 2017.
  26. Sigfox global coverage, Available at http://www.sigfox.com/en/coverage, accessed March 2017.
  27. ‘Ultra-low power Sigfox compliant transceiver IC’, Available at http://www.onsemi.com/pub/Collateral/AX-SFEU-D.PDF, accessed March 2017.
  28. ‘Yes, terrorists could have hacked Dick Cheney’s heart – Washington post Article’, Available at https://www.washingtonpost.com/news/the-switch/wp/2013/10/21/yes-terrorists-could-have-hacked-dick-cheneys-heart/, accessed 21 November 2016.
  29. ‘Fitbit Surge™ fitness super watch – dashboard&App’, Available at https://www.fitbit.com/uk/surge#dashboard, accessed 21 November 2016.

 

Go to the profile of Kurt Morgan

Kurt Morgan

Embedded systems engineer, Morgan Electronics Ltd

No comments yet.