Enterprise IoT

The title of this book is Enterprise IoT because we focus on a specific subset of enterprise solutions within the larger realm of the Internet of Things. It is not our intention to invent yet another category, as there are already enough in this area – including Cisco’s Internet of Everything, GE’s Industrial Internet, and the German government’s Industry 4.0. However, for a book such as this, we believe that it is helpful to have a clearly defined scope and give it an explicit name. In this section, we will explain the origins of Enterprise IoT and provide a definition.

From M2M Towards the IoT

The idea of connecting devices and applications is not new. Specialized telematics solutions have been around for a long time. Over the last decade, M2M (Machine-to-Machine) communication became widely established, a development driven by players such as telecommunications companies looking for new ways to leverage their existing mobile networks. So what is the difference between M2M and IoT? There is no black-and-white answer to this question.

The following excerpt from [MR13] summarizes what we feel to be the most important points:

Applications: M2M applications are about connecting devices and their associated applications – for instance, a smart meter and a smart metering application. IoT applications are potentially far more complex. They are characterized by complex event processing and data analysis and offer higher-level services.

Flexibility: While an M2M application is typically functionally specialized (dedicated) and quite inflexible, an IoT application needs to be more flexible in terms of its potential to evolve over time.

Architecture: Many M2M applications are deployed with a relatively rigid and unchanging solution architecture, while IoT applications are characterized by their need for distributed and federated processing, storage, and querying. In essence, when an M2M application is deployed, software engineers have a pretty good idea of what processing will need to take place over the entire lifetime of the solution. Conversely, since the range of IoT applications is ever-expanding and individual applications are often divorced from the underlying data feeds, different aspects of different IoT applications that may leverage the same data feeds might most efficiently be located in different places.

Speed: It is worth emphasizing the point about speed, by which we mean potentially minimizing transmission and processing delays to better support data analysis. “Speed” can be designed into an M2M solution as needed, and applications are capable of supporting the necessary “speed” requirements from Day 1. In an IoT environment, however, the need for speed in the delivery and processing of different data feeds may evolve and change over time.

Verticals: The discussion up to now highlights a related difference between M2M and IoT: M2M applications should be considered in the context of industry verticals and functional niches, whereas IoT applications have the potential to transcend these limitations to become cross-industry and cross-function applications.

Context: To support the flexibility of environment noted above, it is necessary for IoT applications to be semantically rich and for associated contexts and ontologies to be clear. This is not the case for M2M applications, where data generated by an application only needs to be meaningful in the context of that specific application and within the boundaries of a known systems environment.

Structure: This leads to a wider point about the structure of data. In M2M, data is highly structured (and well documented). In an IoT environment, a developer may want to include CCTV feeds in an application, or crowdsourced information, or information derived from the Twittersphere. These information sources are at best semi-structured and at worst completely unstructured (depending to a great extent on the kind of information that the developer is trying to extract).

Growth: A related difference is the speed of growth that can be expected in M2M and IoT environments. In the case of an M2M application, growth is far more predictable. Typically, an M2M solution is designed for a specific market, or set of assets, and can be deployed in that addressable market in a relatively predictable way. Data generated by M2M solutions would typically grow linearly with device count. The growth in data volumes, transaction volumes, and applications in an IoT environment is driven by network effects between a diverse range of data sources. Accordingly, growth in the IoT space (on any measure) can be expected to be more exponential, rather than the more linear and predictable growth that characterizes the M2M space.

Data ownership: Lastly, it’s worth touching on the topic of data ownership. While data ownership in the case of M2M connected solutions can often be unclear, the concept of data ownership in an IoT environment is far more complex. Fundamentally, in the case of M2M, the privacy of data can be considered within a known landscape of application, user, and regulatory requirements. In the case of IoT applications, however, data could potentially be used for contemporaneously unforeseen applications in unforeseen locations and for unforeseen beneficiaries. This is one of the major aspects of the IoT that large companies will have to deal with effectively if they do not want to lose their customers’ trust.

Subnets of Things

Building on all of the above points, [MR14] introduces the useful concept of “Subnets of Things” (SoTs) as a necessary step in the evolution from M2M to the IoT. M2M solutions can almost be regarded as “Intranets of Things”: closed environments with little connectivity outside of the device estate or solution in question. The natural next step for integrating these solutions into the “outside world” is to consider how these Intranets of Things could be integrated with what could be regarded as “adjacent” products, services and, of course, (other) Intranets of Things.

We believe that this stage of development will be driven by common ownership of data sources or common cause among data owners. An example might be a utility that builds connections between its smart metering solution and its field force solution. The utility can do this because it owns the smart meters, the field force capability, and the applications that support these capabilities, as well as the data that the applications generate. In short, the systems, the connected devices, and  the IT environment within an enterprise can be regarded as a potential Subnet of Things.

The key point to consider in relation to these Subnets of Things is their unique ability to develop far more quickly than a full-scale Internet of Things. This is due both to the fact that stakeholders are more willing to share data and to the technical feasibility of sharing between applications.

A logical next step is to extend the concept to data communities, which we define as a community of devices, data sources, and data owners that could potentially give rise to a Subnet of Things. An example might be a group of intelligent building providers that come together to form a common platform.

It is clear that SoTs are a significant and critical step on the path to any future IoT. We believe it should be relatively easy to convince a defined group of people with similar motivations to standardize in order to create an SoT. However, it is likely to be far more difficult to take the next step to the IoT, i.e. to convince all those in IT and related industries to standardize sufficiently to allow the emergence of an SoT.

Focus of this Book

Simply put, Enterprise IoT focuses on the space that includes both advanced M2M solutions and Subnets of Things (with the exception of highly advanced SoTs). This is indicated in the figure below.

Typically, an Enterprise IoT solution would focus on a single class of assets, but would often have multiple devices from different vendors deployed on this asset class. Enterprise IoT solutions will often have higher semantic richness than simple M2M solutions.

In this book, the scope of a typical Enterprise IoT solution is explicitly limited to a single enterprise that controls this solution, but that might collaborate with other partners for the backend in order to provide a complete solution. In this regard, Enterprise IoT is more limited than the full IoT vision, in which essentially every device can connect to any other device, either directly or through the cloud. This was a deliberate decision, as we feel that many enterprises will focus on these more tightly controlled, single-enterprise type of IoT solutions in the next couple of years.

Domain Focus

Some people in the IoT community differentiate between the Industrial IoT (connected vehicles, machines, and other industrial equipment) and the Consumer IoT (smart wearables, connected dishwashers, etc.) [OR14]. However, it would be too simplistic to say that Enterprise IoT only focuses on the Industrial IoT. While it is true that most of the application domains and use cases in Part II of the book primarily deal with industrial examples, we believe that the key point of this book is its focus on solutions that are typically controlled by a single enterprise and that follow certain architectural patterns, which are described in more detail in the following. Both of these criteria are fulfilled by numerous examples from the Consumer IoT as well. Take, for instance, the eCall service or the car-sharing facilities discussed in the previous section.

As you will see in Part II, our analysis to date has mainly focused on manufacturing and industry, connected vehicles, smart energy, and smart cities. The lessons learned from these domains provide the current basis for the Ignite | IoT Methodology. In version 1.0 of this book, at least, we didn’t have time to include a case study on smart wearables. However, we would be curious to find out if this would be another suitable candidate for Enterprise IoT. Possibly something for the next version…

Definitions of Key Terms in IoT

In order to help make Enterprise IoT concepts more concrete, we have included a number of helpful definitions below. Perhaps one of the most important decisions we made in devising our nomenclature was to drop the term “thing” – which sounds paradoxical, since the IoT is supposed to be all about connecting “things.” However, in our experience, people in an enterprise rarely talk about “things.” We have therefore opted for the terms “asset” and “device,” as they are more commonly used.

The above figure provides an overview of the key elements of an Enterprise IoT solution scenario, which are defined as follows:

• (1) Asset: In business terminology, we refer to numerous physical “things” as “assets” in order to emphasize their significance. An asset is a property or piece of equipment that is produced, operated, or managed in order to generate revenue or to help to improve a company’s operations; for example, vehicles, facilities, machines, or power tools. Assets are generally a key part of an enterprise’s business model. Note that the asset itself is not generally considered to be part of the IoT solution (at least not in the Enterprise IoT context), whereas a device (see below) might well be part of the IoT solution.
• (2) Device: Devices are another important type of “thing.” Typically, devices are economically less significant and physically much finer grained than assets. Devices in the IoT mainly include sensors (for heat, temperature, pressure, flow, etc.) and actuators (such as electric motors or hydraulic components). In our Enterprise IoT scenarios, devices are typically deployed on the assets.
• (3) Enterprise: “Enterprise” refers to the organizational scope of the entity that is operating the Enterprise IoT solution. In many cases, this is the same enterprise as the one operating the assets – for example, a fleet manager, a manufacturer, etc. In some cases – like the eCall service – the enterprise operates the backend service only. Enterprises are increasingly adopting IoT solutions to support their core business processes as a means of establishing new business models and creating lasting relationships with their customers. An enterprise may use the IoT either to operate its own assets or to deliver a service for assets belonging to another organization.
• (4) Enterprise IoT Solution: An IT system that connects assets and their devices with backend application services.
  • (4a) Backend Services: The backend services of an IoT solution usually enable remote monitoring and control of devices and assets, gather device-related data, and are integrated with other enterprise applications (5).
  • (4b) Backend UI: The backend services generally provide web or mobile interfaces to enable users to interact with the services, for example a visual dashboard with an overview of the current operational status of all assets.
  • (4c) Remote Communication: The communication mechanism between the asset and the backend service, for instance via mobile network, satellite, etc.
  • (4d) On-Asset HW+SW (Hardware + Software): The hardware and software components of the solution that are to be deployed on the asset. Often, the on-asset hardware is a form of gateway that enables local and remote communication, while the on-asset software acts as a local agent enabling local integration and remote messaging. For example, the gateway might use an industrial bus to integrate with local sensors, and a GSM module to communicate remotely with the backend. In many cases, the gateway/agent also performs translation and mapping services to create a bridge between the protocols used locally by the different devices and the formats supported by the backend system. Note that (4d) only refers to solution-specific HW+SW: many assets already have existing on-board HW+SW that enables local business logic but is not part of the solution.
  • (4e) Solution HMI: Some IoT solutions also include a solution-specific Human-Machine Interface (HMI), such as the on-board display of a car-sharing service.
• (5) Enterprise Applications and (6) Partner Systems: Most IoT solutions have to integrate with a number of internal and external (i.e. partner) applications such as ERP, MES, PLM, CRM, legacy applications, etc. In many cases, these applications also contain some data related to the assets. For example, an ERP system might contain vehicle configuration data, a CRM system will contain the vehicle owners’ contact data, and the backend will contain data on remote vehicle condition. Only by integrating all of these different data sources can a holistic view of the asset be obtained.

The figure below provides a concrete example of an Enterprise IoT solution. The solution is an eCall service that can detect and deal with emergency situations. The managed assets are cars. The enterprise is the eCall operator, in this case Bosch Security Technology. The solution contains an on-board Telematics Control Unit (TCU), which has an integrated acceleration sensor. In addition, the TCU is integrated with the car’s airbag via the CAN bus. Communication with the backend is based on GSM. The main backend service is the call center application. This application must integrate with the local telephony management solution, the vehicle database managed by the car manufacturer, and the Public-Safety Answering Point (PSAP), which is connected to the police station, fire department, or ambulance service closest to the scene of the accident.

We hope that these definitions and examples are helpful. They will be used throughout the book. In particular, you will see that they have been incorporated into one of our key architectural concepts, the Asset Integration Architecture (AIA). This concept is used to analyze most of the use cases and will be formally introduced in Part II (see “IoT Architecture Blueprints“).