No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Why Enterprise IoT Needs a New Architecture

Extravagant predictions abound about how machine-to-machine communications and the Internet of Things are going to change our lives, and there's some validity to them. But if you look beyond the IoT and M2M hype and start thinking about the long-term challenge, then what becomes clear is that this will never happen without brand-new IoT architecture.

This new architecture must be flexible enough to allow multiple device types, monitoring a variety of assets, to interact with each other and with a diverse range of applications and stakeholders. Without a new architecture, we'll never be able to realize the IoT vision given today's reality -- a plethora of inflexible, standalone automation islands.

This bold statement comes from conversations I've had with Eurotech, a global supplier of embedded technologies, products and systems. And while I don't have any guru-type pretensions, I've been thinking along similar lines.

Today's M2M solutions are based on a vertical, silo model and designed as point solutions. They monitor one issue, a physical parameter or the movement of a machine part, and transfer the data into a single enterprise application. This architecture prohibits applications from sharing data; there's no interaction, no interoperability, no resource sharing. Not only does this restrict the IoT's uptake but also makes fulfillment of the ultimate long-term, consumer-centric IoT vision -- that of zillions of small, simple, low-cost sensors all interacting with each other and the applications built upon them -- an impossibility.

Enterprises need similar functionality from the IoT architecture, but one that's based on the separation of data generation and data usage. Mainstream applications can access and share data that's been abstracted (virtualized) and converted into a common format.

Let's use a train's people-counting sensor as a simple example. In this case, multiple organizations can benefit from use of the sensor data. These include:

  • the train operating company monitoring passenger patterns
  • a maintenance organization moving to a usage-based scheduling system
  • a catering company delivering foodstuffs to the train
  • the station issuing warnings of approaching passenger loads
  • city or town authorities establishing transport strategies

  • the train operating company monitoring passenger patterns
  • a maintenance organization moving to a usage-based scheduling system
  • a catering company delivering foodstuffs to the train
  • the station issuing warnings of approaching passenger loads
  • city or town authorities establishing transport strategies
  • As you can see, what starts out as a simple app ends up as a mix of applications, including those of authorized third parties. That would not be possible in a solution based on the vertical, M2M silo model.

    A Virtual Architecture
    We need to forget entrenched silo-type thinking when adopting a networking paradigm based on a virtual architecture. Instead, consider the implications of employing event-driven IoT data similar to the way message-type data is communicated in Twitter. Hashtags define the topic and users don't need to know anything about device addresses or the communications architecture. They simply register their interest in receiving messages when the hashtag matches their criteria. The social network constantly generates new data and hashtags, but the underlying architecture doesn't change. There are no connectivity issues.

    The use of a topic-based IoT architecture would decouple data generation from data usage and allow the addition of new data flows (topics) at any time. Applications would register an interest in a topic that contains the data elements it needs, and subsequently receive relevant data as it is published. Subscribing applications would automatically receive new data flows. Scaling wouldn't be an issue.

    Click to the next page for Eurotech's approach to enterprise IoT virtual architecture and next steps

    Is It Doable?
    Yes -- in fact, Eurotech has done it. This architecture requires a middleware data aggregation layer, and must be able to adapt as new topics appear on the system. If a company wants to monitor a new type of asset as it moves into a market sector, for example, then the infrastructure, including any databases used for data archive, needs to be able to store data from new topics without the need for user intervention or reconfiguration. And new data should be immediately available for mining by applications such as analytics or dashboards.

    A typical enterprise network will have numerous "things" that communicate with a smart, multi-function gateway, which can accommodate hundreds or even thousands of individual inputs. This gateway also can serve as an application development environment, allowing developers to create and deploy their apps in the same environment where they will be used.

    In the future IoT sensors will get smarter, but right now we need a mechanism for acquiring sensor and device data and converting it for use within the new architecture. The multi-service edge gateway provides this vital link layer -- a common hardware and software platform onto which protocol agents and business logic are downloaded for integration with existing assets.

    What Eurotech Offers
    Eurotech's Everyware Device Cloud, shown below, serves the purposes I've described in this article. It functions as an M2M/IoT platform that enables integration within the cloud and between the cloud and enterprise, and it allows users to develop integration flows that connect applications residing in the cloud or on premises and then deploy them without installing or managing any hardware or middleware.

    portable

    Eurotech says its design focus is on integrating distributed systems into the enterprise IT world through standard protocols and application programming interfaces. This allows incorporation of a message-based "enterprise service bus (ESB) for machines" architecture, which in turn eases the integration of different device data systems and applications. The company built its ESB for machines on an established product designed for implementing communication between mutually interacting software applications in a service-oriented architecture.

    Next Steps
    But more is needed. Despite considerable success, as evidenced by the plethora of innovative M2M solutions for consumers, companies and society, the industry ignores a fundamental issue. Today's cellular networks aren't fit for purpose: They do not and cannot enable the optimum delivery of M2M and IoT traffic. Cellular networks are designed for voice and high-volume data traffic, while most M2M traffic has a payload of less than 30 bytes and only needs a throughput of 100 bits per second. Moreover, the communications overhead can be 500 bytes to 600 bytes, so the overhead is more than an order of magnitude higher.

    This has led to the development of lightweight communications protocols, such as IPv6 over Low power WPAN -- or 6LoWPAN -- that operate at Level 2, the data link layer. In addition, other networks use ultra-narrowband technology (read License-free Spectrum Goes Cellular).

    Enterprise IoT Architecture Takeaways

    • M2M employs stand-alone solutions based on a vertical, silo-type model
    • IoT employs multiple solutions based on a horizontal, integrated model
    • Enterprise IoT requires new methods and paradigms
    • The architecture requires separate data producers and data consumers
    • Databases should automatically adapt to new data topics and content
    • Infrastructure should be communications technology agnostic
    • Build systems on published, open protocols that are widely adopted within the community
    • Address user, device and application access together with other security issues like encryption
    • Abstract device hardware, and enable reuse of applications across a wide range of devices and industries
    • Implement gateway devices, both as interfaces to legacy equipment and to act as aggregation and control points

    • M2M employs stand-alone solutions based on a vertical, silo-type model
    • IoT employs multiple solutions based on a horizontal, integrated model
    • Enterprise IoT requires new methods and paradigms
    • The architecture requires separate data producers and data consumers
    • Databases should automatically adapt to new data topics and content
    • Infrastructure should be communications technology agnostic
    • Build systems on published, open protocols that are widely adopted within the community
    • Address user, device and application access together with other security issues like encryption
    • Abstract device hardware, and enable reuse of applications across a wide range of devices and industries
    • Implement gateway devices, both as interfaces to legacy equipment and to act as aggregation and control points

    MQTT, an M2M/IoT connectivity protocol, operates on top of TCP/IP -- in other words, above Level 3, or the network layer. It's considered ideal for use in constrained environments, where the network is expensive or when running on an embedded device with limited processor or memory resources, for example. MQTT also supports the exchange of instant messaging-type transmissions, which means that transportation is payload-agnostic. In addition MQTT has three quality-of-service levels.

    Eurotech and IBM co-authored the MQTT protocol, submitted it to the OASIS consortium as a standard for IoT communications and donated as open-source code through the Eclipse Foundation IoT working group.

    IoT is a great concept, but one that won't reach maturity without considerable effort... and a new architecture.