The importance of using Final Mile Architecture in an IoT Pilot IoT pilots must be based on the architecture required for full-scale deployments
The importance of using Final Mile Architecture in an IoT Pilot IoT pilots must be based on the architecture required for full-scale deployments
Andy Mulholland is Vice President and Principal Analyst focusing on cloud business models. Formerly the Global Chief Technology Officer for the Capgemini Group from 2001 to 2011, Mulholland successfully led the organization through a period of mass disruption. Mulholland brings this experience to Constellation’s clients seeking to understand how Digital Business models will be built and deployed in conjunction with existing IT systems. Coverage Areas Consumerization of IT & The New C-Suite: BYOD, Internet of Things, IoT, technology and business use Previous experience: Mulholland co authored four major books that chronicled the change and its impact on Enterprises starting in 2006 with the well-recognised book ‘Mashup Corporations’ with Chris Thomas of Intel. This was followed in…...
Read moreRecently IT vendors seem to have been focused on delivering business benefits from better data analysis, rather than the ‘real-time’ Read and Respond capabilities of IoT. The acquisition of Jasper Technologies by Cisco for $1.4bn is a reminder that the functionality and role of IoT device connections is equally important. Its just as easy to over look that between the connection and the data analysis aspects there a further important group of functions controlling the extraction, collation and flow management of data.
Deploying a limited number of IoT sensors in a pilot is both easy and quick, unfortunately it will not illustrate the architectural requirements of a full-scale enterprise deployment. As the entire business value of IoT is based on the right data, at the right time, from events being made available for processing the so-called ‘Final Mile’ Architecture is critical to successful deployments.
The term ‘final mile’ was coined way back to explain a similar challenge of connecting massive numbers of individual telephone connections into the sophisticated telephony Service model. The physical connection required a whole architecture to integrate and control a wide variety of functions that make up the sophisticated telephony systems with their many Services in use today. Linking the connections between IoT Devices and Business Services, or Outcomes, is easy enough in directly connected pilots, but with the scale of hundreds rising to thousands of networked IoT Devices and associated Services additional functions must be accommodated in an architectural approach.
Technology architectures are usually defined by a diagram, (see a preceding piece on IoT-A architecture), but all of these seem to work from the better understood direction of IT systems. The definition and requirements of the Final Mile seem to have been over looked, perhaps because there is a lack of experience in larger scale IoT deployments. Illustrating the functional elements and their roles in outline through two use cases might be a better way to address the issues facing large IoT deployments; The first a large office block deploying IoT for Building Management; and the second IoT tracking of large engineering spares stored in the open on a remote site.
Predictions for IoT all point to the huge numbers of sensors that will be deployed, with manufacturers of many items building sensors into their products the result will be in an office facility, or an open storage area, containing hundreds of IoT sensed Devices. The sheer numbers of networked IoT devices deployed to gain and communicate valuable data is the issue that Final Mile architecture must solve.
Ponder on how valuable would the Internet connected Web be without search engines to find and align content at the time of a requirement? The Internet of Things faces a not dissimilar challenge in delivering the necessary aligned data when required.
In the first use case the illustration below of one floor of an Office block makes clear just how many building sensing points there are per floor in a modern office facility. Everything from CCTV cameras and fire detectors, to the embedded intelligence in air conditioners, photocopiers, even the lift controller, make-up the Building Management IoT network. Taken together the building itself is transformed into an intelligent domain capable of ‘respond and react’ semi autonomous regulation of many aspects. Think of the building continually rebalancing its use of heating, or air conditioning, against the detection of temperatures and impactful events such as a window left open.
The term Smart Building applies to these kinds of ‘reflex’ interactions that occur locally, around small simplistic data interactions that don’t require the processing capacity of remote Cloud service centers. This is not the same challenge as IT folks see in using IoT in a Big Data manner with analyzing the longer-term trends using periodic forwarding of the consolidated data. The case and methods for analyzing ‘big data’ of this type is well known, but IoT introduces two new functions to support successful enablement.
Even for the simple task of analyzing the effectiveness of heating or cooling in the building using the data from several hundred IoT sensing devices through out the building is difficult without knowing the location of individual sensing devices with the correlation to data on the air conditioning and heating systems.
For a pilot the limited number of locations can be individually mapped into a representative screen based GUI and the data will be handled through one on one direct connection. In real life operational deployments even at numbers as low as one hundred IoT sensing devices the Final Mile Architecture requires inclusion of the functionality for providing a location for each device plus a collated pack of contextually significant data.
In the case of the Air conditioning units, or heating units, the contextual data for individual units would be details such as make, model, capacity, power consumed, etc., plus operating history. By adding location and context the simple temperature reading data can be ‘mapped’, or modeled, onto a building to show airflows with resulting temperatures and a link made to the operational efficiency of various air conditioners and heaters.
Big Data from IoT sensing devices is difficult, perhaps even impossible, to meaningfully analysis without knowing location and relevant circumstances. Increasing the numbers of IoT devices to increase data coverage and accuracy results in an increasing challenge to provide context for all individual IoT sensing data sources.
Using IoT sensing for predictive, or responsive, facilities maintenance reinforces this point as well as adding a further requirement to the IoT Architecture capability. Improving productivity and response times by means of a ‘Fix’ on the first visit means providing the engineer with all the relevant data to achieve this. Location, key holders, make and model, previous service history and other details are critical to ensuring that attendance is made quickly and with the right skills, tools and spares, to the malfunctioning unit.
A final mile IoT Device architecture needs to include single, or multiple, Asset Data and Mapping Engines where this data is held for each sensing device ready to be appended to the event data and forwarded for further processing. Additionally a Data Flow Engine is required to preprocess the in-building events, and make forwarding decisions as to where the event with appended asset data should be sent. As a simple example the air conditioning units Service Contract may be held by a different company than that Servicing the heating units, the Data Flow Engine must determine what type of event should be sent to which company. Data Flow Engines work in tandem with Asset Data and Mapping engines in ensuring that actionable outcomes are made possible from the stream of IoT sensing event data.
Asset Data and Mapping engines and Data Flow Engines are both critical elements to the successful use of scaled up IOT device deployments; yet, as they are also a new emerging technology capability/product their role is often overlooked when planning an IoT project, or pilot.
The second use case shares the need for similar functionality to be provide in the IoT Architecture though the it is a less complex situation in many respects. The storage yard contains a finite number of large pieces of engineering spares stored in an un-serviced open-air environment. Cellular 3 or 4G connected IoT sensors are often used for this type of ‘mobile’ connection with their ability to provide reasonable accuracy of location via cellular triangulation. Cellular connectivity services for mobile assets work in storage, in transit, and field installation linking the location with the data, or event, streams. Cellular connected IoT architecture places more emphasis on the need to manage the connection and its wider range of services, (see Cisco acquisition Jasper Technologies video). The architecture will still need to include an Asset Data and Mapping Engine to assign the contextual data to the individual engineering spare.
Sensor selection dominates a pilot, but rarely to selection criteria include aspects that will be important in full-scale deployment IoT architecture. It is important that pilots reflect this, and include Asset and Data Flow engines to be really representative of the experiences that a pilot should provide in advance of a successful full-scale rollout.
New C-Suite
