Who owns the Machine Generated Data in IoT – Men or Machine?

The other day we were discussing and debating on a solution to be designed to meet the sensing needs for access, temperature, and humidity for some devices which form part of a networking infrastructure ecosystem. The idea was to build an IoT based system for monitoring and control.

The design discussions veered around the ability to collect data from the sensors and the types of short range communication protocols which could be deployed.Questions and clarifications were raised if we were compliant to use short range communication protocols in sensitive areas as customer Data Centres which are like owned and that they may be custodians of data of their end customers.

The hidden perils of data acquisition and data ownership reared its head which needed to be addressed as we moved forward.

The data which is acquired by sensors is essentially Machine Generated Data (MGD).This post will  dwell on the subject of data ownership of MGD as follows :

  1. Sensors ( Data Acquisition and Communication )
  2. Machine Generated Data
  3. The Lifecycle of the MGD and the Ownership Paradigm
  4. Who should be the owner of the MGD?

Sensors (Data Acquisition and Communication):

In the IoT ecosystem, the physical computing frontier is managed by the Sensors .Sensors essentially include three fundamental functions:

  • The act of sensing and acquiring the data
  • Communication of the data through appropriate protocols to communicate their readings to internet cloud services for further aggregation and trend analysis
  • The activity is energized by power supply,

The additional functions would include processing/system management and user interface.

The Digital Computing part comprises the IoT application. This is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device.

When making physical measurements such as temperature, strain, or pressure, we need a sensor to convert the physical properties into an electrical signal, usually voltage. Then, the signal must be converted to the proper amplitude and filtered for noise before being digitized, displayed, stored, or used to make a decision. Data-acquisition systems use ADCs (analog-to-digital converters) to digitize the signals with adequate signal conditioning.

Sensor data communication to the cloud can be done in multiple ways from wireline to wireless communication of various complexities. While wire line communication has some important benefits (such as reliability, privacy, and power delivery over the same wires), wireless communication is the technology that is the key catalyst in the majority of IoT applications that were not previously practical with wired systems. Reliability, channel security, long range, low power consumption, ease of use, and low cost are now reaching new levels, previously thought infeasible

Some examples of recently popular IoT wireless communication types: Wi-Fi, Bluetooth Low Energy (aka Smart), Zigbee (and other mesh 802.15.4 variants), cellular, LPWA (Low-Power, Wide-Area network variants: Ingenu, LoRaWAN, Sigfox, NB-LTE, Weightless), and Iridium satellite.

  1. Machine Generated Data (MGD)  :

Sensor data is the integral component of the increasing reality of the Internet of Things (IoT) environment. With IpV6, anything can be outfitted with a unique IP address with the capacity to transfer data over a network. Sensor data is essentially Machine Generated Data. MGD is that is produced entirely by devices/machines though an event or observation.

Here we would define human-generated data, what is recorded is the direct result of human choices. Examples are buying on the web, making an inquiry, filling in a form, making payments with corresponding updates on the database. We would not consider the ownership of this data in the post and would be limiting our post to MGD.

  1. The journey of the MCD and the Ownership Paradigm:

The different phases exist in the typical  journey of Machine Generated Data .

Capture and Acquisition of Data– This is a machine or a device based function through signal reception.

Processing and Synthesis of the Data – This is a function which ensures enrichment and integration of Data

Publication of the Data – This is done by expert systems and analysts who work on exception management , triggers and trends .

Usage of Data – The action which need to be taken on the processed and reported information is used by the end user .

Archival and Purging of Data – This function is essentially done by the data maintenance team with supervision.

Now let us dwell on the Ownership Paradigms.They range from the origination of data , adding value to the data through make over , monetising of data through insights generated. Interestingly, let us explore if there is any conclusive method for determining how ownership should be assigned. A number of players may be involved in the journey of the data (e.g. the user, hardware manufacturer, application developer, provider of database architecture and the purchaser of data, each having an equal lay of the claim in different stages of this journey )

  1. Who should be the owner of MGD :

Let me share the multiple and conflicting views  :

The owner of the device which records Data .In essence, the owner of machine-generated data(MGD), is the entity who holds title to the device that records the data. In other words, the entity that owns the IoT device also owns the data produced by that device.

But there could be a  lack of clarity if the device is leased rather than owned.. When real-world constructs such as lease holdings of (say servers) come into play, it indeed gets complex and even murky

The owner is the user of the Data :The other dimension is data may be owned by one party and controlled by another. Possession of data does not necessarily equate to title. Through possession there is control. Title is ownership. Referred to as usage rights, each time data sets are copied, recopied and transmitted, control of the data follows it. There could be cases where the owner of the device could be the user of the data.

 The maker of the Database who essentially invests in aggregating, processing and making the data usable is the owner of the Data :This has a number of buyers of this paradigm . The owner of a smart thermostat does not, for example, own the data about how he uses it. The only thing that is ‘ownable’ is an aggregation or collection of such data provided there has been a relevant investment in carrying out that aggregation or collection (the individual user is very unlikely to have made that investment). The owner here could be the Home automation company. The value which could be generated though this investment could be producing market intelligence, exploiting the insights form data to build market presence and differentiation,

The purchaser of Data could be the owner of the Data: An auto insurance company could buy the  vehicle generated data ( from the makers of automobiles )  and could design a product for  targeted offerings to specific market segments based on say driving behaviour patterns  and  demographics  .This may not be as easy as this seems – refer the url  :  http://joebarkai.com/who-owns-car-data/ which states that the owner of the vehicle and not the maker of the car owns the data collected from the electronic data recorder.

The value chain of who owns the data can be a complex one with multiple claimants. As one aggregates more sources it just gets more complicated. A good example is in the making of smart cities. The sources of data can be from multiple layers and operational areas . City authorities would be making the effort to make use of the data in areas of waste management , traffic congestion , air pollution etc . So does the city authority own the data?

My personal take is , if someone in the MGD value chain is making the data usable  for  a larger good , and  in the process may monetize the data to cover the investments , that entity deserves to  be the owner of the data  as that is where value is generated .


The Integrity and Intrigue of IoT Platforms


The last count on the number of IoT Platforms which are jostling for space in the crowded IoT market place is 460 . There are analyst reports galore which explain the features and benefits of these platforms.

For an IoT platform to be called as a comprehensive, mature and end to end it has to have the 8 components with reasonable feature and technology depth which make an IoT platform.

To know what these 4 layers are which constitute 8 components. Let us get down to the basics of a typical IoT platform.

Hardware ( Device )  Layer :

  1. This is where data is produced.
  2. This includes the physical devices with their in-built microprocessors, sensors, actuators and communication hardware.
  3. This layer makes the devices “smart”.
  4. The 2 components which go with this layer are :
    1. Connectivity and Normalisation
    2. Device Management

Communication Layer :

  1. This is where data gets transported.
  2. This part of the technology infrastructure ensures the hardware is connected to the network, via proprietary or open-source communication protocols.
  3. This layer gives the data from devices the “expression”
  4. The 2 components which go with this layer are :
    1. Networks/ Infrastructure
    2. Communication Services

Software Backend Layer ( Cloud Services Layer )   :

  1. This is where the data is managed.
  2. It manages the  connected devices and networks while  providing  the necessary  the interface to systems in the eco-system  (e.g., ERP-system).
  3. This layer provides the “knowledge”
  4. The 2 components which go with this layer are :
    1. Database ( RDBMS and noSQL ) for storage and orchestration
    2. Processing , Rules Engine and Events Management

Applications Layer :

  1. This is where data is turned into value.
  2. In the application layer, IoT use cases get presented to the user (B2C or B2B).
  3. This layer is responsible for the “actions” to be taken.
  4. The 2 components here are
    1. Data Visualization and Analytics
    2. External Interfaces( APIs) to third-party systems ( like ERP )

The cross layer is Security layer which cuts across the 4 layers as mentioned.

The nub of the issue is ,  companies just providing cloud storage  or data security or running a CRM software or connectivity management claim to be an IoT platform .

75 % of the IoT platforms which are currently in the market provide connectivity management pretty well which is essentially the communication layer.

This is borne by the figures which are as below:

  1. IoT platforms themselves will not be revenue earners , but they can definitely facilitate revenue growth when they are put in a business context .The total revenue generated through IoT platforms in 2015 is $ 330 Mill and is expected to grow to $ 1.168 Bill in year 2017 ( as per reports from IoT-Analytics ) . Of the 460 platforms which are there only 7 % of the platforms generate $ 10 Mill or above .
  2. McKinsey report says that $11 Trillion is the business value which can be generated through the implementation of IoT programs and that would mean through productivity gains, efficiency of operations and the like .
  3. The fact that 12.5 bill things would be connected by 2020 also makes communication layer with connectivity the strongest contributor to the IoT platform companies.

So what are the parameters one should look at when accepting an IoT platform as a platform in the truest sense of the word (with integrity)?

The assessment of a platform could be considered to fall in two broad areas .They would be:

  1. Depth across the Layers for a Horizontal IoT Platform
  2. Vertical User Specific Industry Focus ( B2C or B2B )

The Depth Across the Layers for a Horizontal IoT Platform would cover:

  • Application Enablement
  • Device Management
  • Cloud Storage
  • Analytics Platforms
  • Connectivity

Currently 75 % of the platforms are in Connectivity layer ( as per IoT-Analytics report )

Vertical User Specific Industry Focus ( B2C or B2B focus )

  • Consumer – Home, Lifestyle , Health , Mobility
  • Business – Retail, health , Energy ,Smart Cities , Manufacturing , Supply Chain , Public Services

The leader here are Energy and Manufacturing (falling under IIoT ).

Next time one comes across an “IoT Platform” one needs to be suitably  intrigued to check the integrity of that claim!!



Top 5 reasons why “Internet” in Internet of Things could be a misnomer!!

Let me pose a quiz question –

“What is common between Paris’s Port Neuf & Internet of Things?

———————-(Both are misnomers!!)————————-


Port Neuf is the oldest bridge in the city, but its name still means “new bridge.” It was completed in 1607 .

Now let me mention the phrase Internet of Things .Ever wondered how this name was coined?

The term “The Internet of Things” (IoT) was coined by Kevin Ashton in a presentation to Proctor & Gamble in 1999. Ashton is a co-founder of MIT’s Auto-ID Lab. He pioneered RFID use in supply-chain management.


The world caught on to this; and I believe with Cisco’s announcement in the later part of the first decade of 21st century, Internet of Everything legitimised this as the phrase.

There were feeble attempts to offer synonyms like “ambient computing”, ubiquitous computing, “M2M computing” “ and the like but nothing stuck on like IoT  .

One of the influential Tech bloggers Daniel Miessler also tossed a few alternatives like Universal daemonization, universal object interaction etc.

If one breaks the phrase into its components it does not tell what is expected to tell. I will explain this later in the document.

My premise is the phrase is not doing an honest job of explaining what exactly Internet of Things , as we now know it is.

Let us take a step back and take a view the traditional internet and how it was built  and compare that with the world of  IoT

  1. End Systems – The end systems in traditional internet would be PCs, laptops, hand- held devices, servers, routers (both manned and unmanned). In the IoT architecture the scope and the breadth of the end systems or devices to be connected is expected to run into billions, and these devices would be “small, dumb, cheap and copious.”. These end devices do not have processors, memory and hard drives which are needed to run a protocol stack.
  2. Flow of Data – The flow of data in traditional internet is bidirectional and is fast given the bandwidth available and high fidelity. In the IoT world the data flow is generally and individually insignificant but in an aggregated manner it would be meaningful and is unidirectional from the device to the server or cloud. Here the communication would be machine to machine and in tiny snatches of data and working in possibly lossy networks. In the traditional internet, the data networks are essentially over-provisioned by design, built with more capacity than is typically required to provide a best effort based service. Protocols like TCP/IP are based on mostly reliable connection between sender and receiver.
  3. Number of Devices and their Management – Numerous reports mention about how humongous the breadth and scope of IoT would be. The end systems or devices would vastly outnumber human beings on the planet – the network so created would be varied and unprecedented. Imagine the moisture sensors being linked to thermostats and occupancy sensors linked to surveillance systems and the like. With the count of devices exploding in the world of IoT, the panacea is thought to be provided by IPv6 as the IP addresses required to manage them would be solved by IPv6 (with its unlimited capacity to churn IP addresses). Providing address is one thing but their management is another.The estimated 700 billion IoT devices cannot be individually managed, they must self-manage. Self-addressing, self-classification and possibly self-healing will be the order of the day in addition the IP addresses.
  4. Human Involvement – The traditional internet is primarily human-to-machine oriented. There is a human at the end of the session. Applications like email, web surfing and video streaming consist of chunky data flowing through high bandwidth pipes to be consumed by humans per session and is bi directional in flow. In the world of IoT this is just the opposite – data is clipped (or terse, yet purposeful) , mostly meaningless when seen individually but making sense in an aggregated manner and the data flow is .unidirectional. The meaningful amount of data individually could be insignificant and random but when aggregated could be important and give a meaningful update. For example, a temperature sensor may generate only few hundred bytes of data when temperature crosses the threshold, otherwise it would be in sleep mode.
  5. Adaptation to Network – Traditional Internet is extremely reliable. There is a significant overprovisioning of bandwidth and redundancy which is built in, at the design and the deployment phase. This provides a high level of services to the internet users, the human beings.

In the world of IoT most of the devices or end systems reside on the extreme edges of the network and the connection may be inconsistent and intermittent. Devices may not  be needed to be kept switched off to conserve power ( as they consume low or no power ) , they must share wireless connections among them. Individual lost messages may not mean much and they could manage well in lossy networks.

Now you may ask- why not TCP/IP for IoT? These protocols which form the heart of traditional Internet, are ill suited for devices geared for IoT. The inherent robustness of these protocols makes them too heavy duty and overhead rich. It may sound odd, but sometimes being capable and reliable may not be something needed in the “awkward world” of IoT.

Internet of Things is an expression which has firmly got entrenched, when essentially it says that devices would be connected and this contentedness makes them behave as computers and hence the things transform into “thinking things”.

Let us all be like Parisians and retain the much acclaimed word “Internet of Things” not withstanding it could be a misnomer !!