Sierra Monitor Blog
One of this season’s best selling gifts is the Amazon Echo with Alexa. Plug it in and Echo / Alexa will run your house for you: turning on lights, locking / unlocking doors, catering to your family member’s unique climate comfort needs, and reducing your energy bill – all voice-activated and without any hard-core programming. If you haven’t tried it, you should. It’s cool. But if you are part of the Facility Management or Building Automation and Controls community, like I am, the Echo / Alexa will also make you and all members of our community feel old, unimaginative, and so last century. We are the dads that wear sweaters and “dad jeans” (although “dad hats” are a hit with the youth these days), and justify our lack of fashion sense by claiming that we are just being responsible.
Consider the venerable Building Management System (BMS). Perhaps only 20% of all the commercial real estate in the United States is managed by a BMS because the rest of the market is too small or unsophisticated to be able to handle a BMS. So a debate rages on as to how to bring the “power of the BMS” to the other 80%. And it’s not like the 20% that has a BMS is thanking their lucky stars either.
Adding new functions to a BMS isn’t easy. Opening up BMS access to system manufacturers and integrators, who legitimately need to have real-time access to their data that is locked in the BMS is difficult. Extracting the required data for analysis from the BMS is no picnic. Facility managers therefore complain about being held hostage by their BMS vendor. So in the midst of all this hand-wringing, let us pause for a second and consider my not specially talented 12 year-old nephew who set up his mother’s Alexa and essentially created his “home BMS” in less than an hour; making his home instantly more managed, controlled, safe, and energy-efficient than at least 80% of commercial real estate.
Folks – it’s time to stop being so entrenched in our beliefs about what a BMS is or should be. It’s time to learn from the group across the aisle – the consumer sector – that is out-innovating us.
A few key aspects stand out as lessons for me. Firstly, all the “smart things” in the home – locks, thermostats, motion sensors, washing machines, and lights have their own cloud point-of-presence and their own applications. That is, each of these things has a visible presence on the consumer’s smartphone through their own cloud and is individually controllable. Secondly, Amazon Echo / Alexa is able to orchestrate these smart things and as a result, scenarios such as “if the door is opened by a particular smartphone, turn on the lights and heat up a specific room in the house”, become easy to implement, with no programming required. How does this happen? Well, the Alexa cloud receives voice commands (doesn’t always have to be voice) indicating the desired scenario, goes out and establishes links to that user’s accounts in the lock cloud, the light cloud, the thermostat cloud, and so on, and invokes the right Application Programming Interface calls (APIs) to make the desired actions happen. Note that all “system integration” is happening in the cloud. It’s the device clouds that talk to each other; it’s not the devices in the house talking to each other.
How do these lessons apply to the building automation and control and facility management market?
Firstly, all devices installed in a building, such as boilers, chillers, generator sets, electric sub-meters, pumps, VAV controllers, fire panels, etc. should be smart and have their own individual cloud points-of-presence and applications, just as consumer devices do. Device and system manufacturers need to turn their electro-mechanical devices into smart devices with a cloud presence. Facility manager should insist that their vendors have this capability. Doing so, in effect, forcing every vendor to provide an app, is good not only for the facility manager, but for all the vendors as well, because it greatly improves the vendor’s ability to continue to add value to the facility manager with better service and operational insights.
For devices that are already installed and are pre-cloud, the facility manager should implement a common facility device cloud that automatically discovers all the automation and control devices in the facility, for example, all the BACnet-based devices in the building, and creates a virtual cloud instance for each device. Once all the devices and sub-systems (and their access and data) are represented in the cloud, the facility manager should develop their own Alexa-inspired BMS. An integrated point of control that is intuitive and fun to use. Will it be as easy as the home Alexa? Maybe not, but that should be the goal.
Sure, the naysayers will grumble first about lack of standard data models. I’d like to point out that the Echo / Alexa use case does not require standard data models – the RESTful APIs published by each device vendor – are good enough. The naysayers will talk about security. I would argue that securing a home with a new-born baby may be just as important as securing a facility – so let’s accept that security is a serious issue that must always be front and center, but it’s an issue that applies across sectors.
Am I going out on a limb to make a point? Of course. If that’s what it takes to get what I want for the New Year … having our community think about reinventing the BMS.
For those of us of a certain age, there is a difference between a “real product” and a “toy product”. Some years ago, I was meeting with a large vendor who makes thermostats amongst other things, when NEST was bought by Google for a princely amount. The executive I was with sniffed disparagingly and said “that’s a lot of money for a toy”. Ironically, Google paid more for this toy than what his company that makes “real products” was worth. All of us who work for or with companies in the Industrial Internet of Things (IIoT) space pride ourselves on the fact that we make real products that solve real problems, unlike all these toy IoT consumer gizmos. But that said, it is time that we in the IIoT space learn that these consumer IoT guys might have a thing or two to teach us.
In this blog piece, I want to highlight a lesson from the consumer IoT world that the companies that make IIoT products should appreciate and apply to their business. At a philosophical level, it is the difference between the pluralistic view of the world that the younger consumer companies and workers embrace versus the rigid command and control view that comes more easily to the established industrial companies. At a product vision level, it is the difference between ensuring that your product’s voice can be heard by you, versus being satisfied that your product’s voice is provided to other “supervisory systems”, leaving you none the wiser about your own product. At a technology level, it is about offering a “whole product” that consists of the device, the cloud, and an app; versus thinking of the product as just a piece of hardware. Let me elaborate some more:
Consider any consumer IoT product – whether it is a smart thermostat, a smart lock, a home security camera, a smart washer/dryer, or a smart wearable product. Almost all such products consist of the device itself, along with an app provided by the device vendor. The device vendor runs a cloud service that the devices register with, and provide their voice to. The apps work against the data in the cloud and make the devices real and interesting to the user. Yes, an individual home user might end up with ten apps on their phone to manage their ten devices from ten vendors – but ask that user if they’d prefer to do that or “integrate all that information into a comprehensive home management platform and have a single unified application interface”, and you’ll be asked if you are recently arrived from the ex-Soviet Union. In this world, a noisy, pluralistic approach is preferable to a structured supervisory approach. The device makers benefit from this approach as well, developing deep insights on their users, and continuously innovating and offering better gizmos and better services around their gadgets.
Now consider your typical IIoT device or controller in a facility. The facility is “governed” by a supervisory management system, typically called a SCADA system or a BMS/BAS. All devices or controllers in the facility are vassals or tributes, offering up their data and information to this all-seeing, all-powerful supervisory system. Once the IIoT device or controller maker has sold their product into their facility, they do not have any access or visibility to their products in use. Sure, the powerful supervisory system does – and that’s great news for the company that makes that supervisory system. But what about the twenty other companies that sold their products into this facility? They are blind and deaf to their own products, unless of course, the facility manager calls to complain that their product isn’t working.
So what should the IIoT device or controller vendors do? Don’t be satisfied with just being a cog in a larger wheel. Yes – your products have to tie into a larger hierarchical system – that’s just the nature of these facilities, and that will not change. But, aspire to be more. So what if you just make “flow meters” – just to pick one of a hundred devices or controllers used in facilities – that feed into a supervisory system? Think of your flow meter as a smart, cloud-connected product. Insist on offering your own apps to the customer. Insist on having your own cloud point-of-presence. Insist on staying connected with your products. Insist that you want to continue to hear your product’s voices even after they have been installed in the field. Now you will know how your products are being used. You’ll be able to provide proactive and predictive services. You will learn about real life usage and might identify the next cool feature your customer might pay more for. Now why would the customer, say the facility manager in this case, let you establish cloud-based connectivity to your products? It’s because they too would benefit from your ability to provide better support, better innovation, and possibly even a better business model, for example, offering your product as a service rather than as a piece of capital equipment.
Walk on the other side and bring that lesson over into your world. It may feel counterintuitive and uncomfortable, but as Mr. Mick Jagger once said, “But if you try sometimes you might find; you get what you need.”
Blog post was originally posted on IoT Today on March 1, 2016.
Sure, I am as interested as the next guy in how the IoT will transform customer lives. But selfishly I’m more interested in the impact that the IoT will have on the companies that design and make the things or smart connected products. We know that companies that make these smart connected products are able to provide superior maintenance and support ranging from prevention to prediction to prescription.
There are interesting cases of companies that offer their products as a service; for example, Michelin offering tires-as-as-service. Companies like Babolat sell smart tennis racquets that can measure player performance, perhaps along with a coaching service that can analyze and suggest improvements. The good folks at PTC/ThingWorx have a great use case of a mountain bike providing its data-in-use back to the bikes product designers, who can then get insights on the torque levels, skid and so on, and use that insight to design a better product.
Looking for Metaphors
All heart-warming stories, so why am I not feeling that holiday cheer? I sit with my customers or snoop in on my competitor’s webinars and all of them point to the golden age of innovation and amazing new optimization possibilities that are yet to come when some miraculous integration with other systems happens. And the cynic in me notes that enterprise integration and optimization is always Phase 4 of a four-phase evolution – for any problem. Might a different perspective help us look at this problem differently and produce better insights? To paraphrase Paul McCartney, “When I find myself in times of trouble, metaphors come to me, speaking words of wisdom.” In this case, the two metaphors that I’d like to share with you are product voice and voice curation. Let me discuss product voice in this blog piece and voice curation in the next one.
Product Voice: Enriching the Voice of the Customer
It’s kind of cool to think about smart connected products as having voice that they contribute and conversations that they engage in. Most of the cases I’ve described above collect and analyze this product voice to deliver new support services or offer products-as-a-service, or make product enhancements. However, many more interesting insights open up when you recognize that product voice is only one type of voice, and that it may be lacking in context when viewed in isolation.
That is, simple insights like “uh-oh, the steam pressure in the boiler is dropping and I think it’s going to fail” may be available based on just the product data without context, but more sophisticated insights relating to innovation need context. Remember the bike use case I described earlier where the product designers were monitoring bike usage? How would the designers know if a bike was being ridden by an outlier (like this one) or an average guy? Would average statistics even mean anything? A product designer would need context around the product voice to make good decisions and that context is not part of that product voice stream, or as us geeks would say, “It’s not in the metadata”. So what’s the solution?
Let’s stay with the voice metaphor. In the 90′s, a term called voice of the customer became popular. The notion was that organizations should collect customer voices to learn what their customer needs are and specific suggestions they might have. In addition to the traditional approach of product managers talking to customers or customer service folks being told by customers what they like or dislike about a product, companies use tools like Survey Monkey to solicit voice, or they crawl through social media sites to see what their customers are saying about them or on related topics. It is in combination with these other sources of voice that the true potential of product voice can be realized. That is, product voice must be considered as enriching or enhancing the voice of the customer. That means that product voice is just one type of customer voice, and the IoT should be viewed as a part of holistic customer experience management.
Metaphor Shows Need for a Two-Tier IoT Cloud Architecture
Let’s get back to nuts and bolts. The understanding that product voice by itself can deliver a set of benefits, but that it needs to be combined to with other voices to provide more elusive benefits leads to a two-tier cloud architecture. That is, there is a need for a Device Cloud that is distinct from the larger Analytics/Application cloud. The Device Cloud should be responsible for identifying, registering, and managing the smart connected products that are in the field and providing secure access to these products to authorized and authenticated users. The Device Cloud in conjunction with the smart connected products feeding into it collects and presents product voice. In some cases, this product voice may be presented directly to authorized users, such as the case where a user is notified that something seems awry and the user subsequently logs into the remote smart connected product in a secure manner to learn more.
This is in line with the remote support and maintenance use cases described earlier in the blog. In other cases, the product voice needs to be sent on to the Analytics/Application Cloud where it can be co-mingled with other information such as customer records, open trouble tickets, marketing automation insights, shipping information, and so on to produce a higher level of application insight. The Device Cloud is like a blue collar worker it deals with the nitty gritty of products, their locations, their firmware levels, and their security credentials and so on. Without a Device Cloud, product voice would never be heard and would certainly never join the larger conversation. The Analytics/Application Cloud is more aristocratic and more concerned with issues like business logic and insight, and concerned with making sense of voice as a whole, with product voice being just one component.
Given how IoT Platforms are marketed, it is easy to fall into the trap of thinking of a monolithic cloud, but thinking of the voice metaphor points to at least two distinct blocks of functionality.
In the next blog, we’ll look at the metaphor of voice curation and see what that has to reveal about Analytics/Application clouds. In the meantime, to finish up Paul McCartney’s advice: “Just let it be.”
Blog post was originally posted on IoT Today on January 5, 2016.
At Sierra Monitor, we understand how important sensors are to industrial products. Sensors provide critical information like calibration and maintenance intervals or enable diagnostic features to make day-to-day tasks more effective and efficient. With our sensor technology, our Sentry IT fire and gas detection solutions are all IoT-enabled, smart connected products.
But what about the industrial equipment that don’t have sensing capabilities? Plenty of industrial equipment around the world today do not have sensors embedded in the product, missing out on a lot of tasks that can be done online, remotely, and in the cloud. If a facility manager or engineer wants to move into the IIoT space, it would be wise to implement sensors to unlock new opportunities for equipment product support and analytics.
MSI Data interviewed Sierra Monitor to discuss why embedding sensors to connect machines and analyzing the right data is vital for success in an increasingly connected and technological age. Some of the topics we explored revolve around cloud access and the importance of sensors to the IIoT.
I caught up recently with my old friend and mentor, Bruce Sachs, General Partner at Charles River Ventures. CRV is a terrific early stage venture capital fund, and Bruce is that rare VC who has walked the walk as a Bell Labs engineer, and then as CEO of a major company like Stratus Computers (fault tolerant computing) before he became a VC.
Given that I am currently obsessed with the IIoT and how smart connected products might provide new ways for product companies to provide service or innovate in novel ways (as described in my last blog post), it was only a matter of time before our conversation moved to how developers, product managers, and business managers at Original Equipment Manufacturers (OEMs) should think differently to take advantage of the IIoT.
Bruce then provided an insight that I thought was simple yet profound, and worth sharing. He recalled our early days as engineers when the term “DFX” became prevalent. If you are too young to remember, or if that phase of your life has become hazy over time – let me elaborate. As engineers, we were exhorted to not just design products to implement a certain set of functions, but rather to take a broader set of requirements into consideration while designing products. We were asked to make sure the products we designed were designed to be high quality, or reliable, or supportable, or manufacturable, or low cost, or environmentally friendly. These disciplines were called DFQ, DFR, DFS, DFM, DFC, DFE, and so on. They were collectively referred to as “DFX”. If I recall, the catalyst for the whole movement was the fear that the Japanese were outsmarting us by looking holistically at products while we were not.
Bruce pointed out that the IIoT is a similar disruption. The companies that “get it” will design their products differently to take advantage. These products will be designed so they can be monitored or fixed remotely; the products will call home and provide usage data that the developers can use to identify new features; the products will leverage capabilities on companion products to get their job done, and so on. He collectively called this new set of disciplines “DFIoT” and posited that this term may become just as common in the future as DFX used to be in the 80’s and 90’s.
Product developers at industrial OEMs would do well to remember Bruce’s advice. The companies and engineers who thought DFX was a fad were wrong. The OEMs who think the IIoT is neither an opportunity nor a threat are similarly fooling themselves.
So if you are a developer, educate your boss about DFIoT. If you are a product manager, expand your requirements matrix to reflect new reality. If you are a business manager, don’t leave DFIoT to just the developers. History repeats itself, but if you listen to the right guys (like Bruce), history can be on your side.
There is no shortage of stories and case studies about the IIoT. In aggregate, they support the assertion that the classic Buffalo Springfield song makes: “There’s something’s happening here; what it is ain’t exactly clear”.
Unfortunately, the many IIoT case studies being written up throw the phrase “cloud” around like there is no tomorrow, and all the stories begin to blur together! Personally, I find it useful to have a model that helps me categorize IIoT use cases. I’d like to share the model that we use within our company, both when we are thinking about what IIoT use cases make sense for us as an OEM (with our Sentry Fire and Gas line), and also when we are working with our leading OEM customers to discuss and enable their use cases (with our FieldServer protocol gateway products).
As the diagram shows, we categorize use cases into four steps, with each step having a different benefit or theme. And the reason they are laid out as steps is because we believe it is necessary to master each step before moving on to the next step.
Step 1 is the lowest hanging fruit. OEMs who make “smart connected products” can use the IIoT to improve support and service. By connecting securely and remotely with their connected devices (no matter where they are or how they were sold), the OEM and their sales/service agents can remotely monitor and troubleshoot their products. The OEM’s customers (the end customers) can avail of such a capability themselves as well, allowing the facility manager to always be connected to his assets. Note that we are not just suggesting that the OEMs feed their data to a SCADA or other management system and think their job is done. We are suggesting that every OEM, to the extent possible, look to establish their own secure connection to their products in the field. Armed with this remote knowledge, the OEM can either fix problems remotely or dispatch an appropriately equipped and informed service tech to the field, thereby leading to a much higher resolution rate. The key here is providing secure remote connectivity and access. This step is not about long-term data retention in the cloud, fancy analytics, and so on. In this step, the “cloud” is just a mechanism to provide this functionality. Also, as a general rule, in this step the maximum benefit accrues to the OEM, as it helps them raise their service game and helps them differentiate themselves from other OEMs. So we recommend that OEMs bundle such a secure remote access capability with their products. Shipping the smart connected product along with a FieldServer that can connect over a secure remote access “tunnel” to a cloud-based registration and access point is one way to do this.
Step 2 focuses on using the IIoT to improve operational efficiencies – for the OEM, and even more interestingly, for the OEM’s customers. We have gathered many examples from the literature that fit in this “efficiency” category. For example, an OEM may use the data from their smart connected devices to understand their product quality and failure modes over time, or the OEM’s marketing department may use this data to identify which customers might be ready for a product upgrade offer. The OEM’s customers can greatly benefit from insights too. A facility manager of a building may use the data collected from the smart connected products to identify energy efficiency opportunities, or an airline may use the data gathered from the sensors in the engines across all its aircraft to determine if certain flight paths result in greater fuel efficiency. A commercial kitchen may use the automated logging and reporting of temperature data from all its refrigerators to satisfy food safety regulations, instead of the traditional approach of sending a worker out to each refrigerator every hour to record the temperature. Smart elevators may use information about how many people are waiting and past history of where people go at what time to provision elevator banks efficiently in high rises, and commercial fans may regulate their speeds based on occupancy, external humidity, individual preferences and so on. So many cool examples – but once you get the 4 step model in your head, you’ll realize they are all just variations of Step 2, both from a benefits perspective and from a technology architecture perspective.
A word on the technology architecture required for Step 2. Identifying efficiency opportunities requires “analysis” and possibly (that other infamous word) “big data”. So while Step 1 as explained earlier is about secure remote access to the data stored in the remote smart connected products, Step 2 is about bringing that data to the cloud, organizing it, storing it, and sifting through it looking for efficiency improvements. That is the “cloud” plays a different role in Step 2 relative to Step 1. The cost of proving Step 2 benefits to themselves or to their customers are higher to the OEM relative to Step 1 as the OEM has to move and store data long-term in the cloud, and has to put in the intellectual work to define and develop the algorithms that drive the desired outcomes. We recommend that in Step 2, OEMs think carefully about selecting and pairing the right cloud storage and analytics platform to the cloud-based secure remote access capability established in Step 1. Shipping a smart connected product with a FieldServer along with the ability to plug into the right cloud analytics platform is one way for the OEM to offer Step 2 benefits.
Best-in-class OEMs are actively looking at Steps 1 and 2 (often in that order), and we are privileged to have the opportunity to brainstorm these with our OEM customers.
In the next blog post, we will look further ahead at Steps 3 and 4 and speculate on how smart connected products and the IIoT might usher in an unprecedented era of innovation, and not just efficiency.
This month, let’s take a break from our obsession about business models, and focus on technology instead. Perhaps some of you have heard about and are actively following the Industrial Internet Consortium. The organization was founded in March 2014 to bring together the organizations and technologies necessary to accelerate growth of the Industrial Internet by identifying, assembling and promoting best practices.
A few weeks ago, the consortium published the first version of the “Industrial Internet Reference Architecture Technical Report” to drive interoperability and to simplify development of Industrial Internet Systems (IIS). The consortium believes that traditional industrial and commercial control systems will be brought online, connecting them with people, and fully integrating them with processes, enterprise IT systems, and data analytics solutions. The data generated by sensors and human-machine interaction will be combined with other organizational or public information (think about outside temperature and humidity information from weather.com for example) to yield more significant insights. We couldn’t agree more.
The report outlines an “implementation viewpoint” or a generally applicable view (but allowing for use case specific variations) of the components required to put a solution together along with the distribution and interplay between the various components. I encourage you to turn to Page 36 of this report and read the excellent description. To whet your appetite, let me liberally borrow from the original text and summarize the key points.
IIS implementations will generally display the following architectural patterns:
- A three-tier architecture consisting of the Edge, Platform, and Enterprise Tiers.
- Three networks: Proximity network (for devices within the Edge tier), Access network (to connect the Edge tier to the Platform tier), and Service network (to connect the Platform tier to the Enterprise tier).
- Edge Gateways as a core component of the Edge tier, pulling together all the devices in the proximity, providing data aggregation and management services.
- The Platform tier as the long-term repository of structured and unstructured field data. You could think of this as a local server implementation or a cloud-based implementation.
- The Enterprise tier that implements the domain specific application functionality, acting not only upon the field data from the Platform Tier, but also interfacing with other data elements and systems that make up the IIS.
These architectural guidelines are consistent with our practical experience.
In our FieldServer Protocol Gateway business, we are actively looking to offer our OEM customers (the device makers), not just the gateway to connect devices, but an integrated platform and application tier with value-added applications. We are looking at implementations where all three tiers could be resident on the gateway, or could be distributed between the gateway and the cloud. But in all cases, we recognize that the implementation must be “open” enough to incorporate best-of-breed technology from other vendors.
In our Sentry IT Fire and Gas Solutions business, we are eating our own cooking – adding the gateway, platform, and application tiers to the Sentry IT Controller (the Sentry Controller is a specialized PLC for fire and gas). Here too, we recognize that some of our customers (safety managers at facilities with a higher-than-normal risk of gas and fire) might prefer to keep all elements of the 3 tier architecture local (on-premise), while some will be enterprising enough to leverage the cloud for some of the tiers.
Hopefully, the consortium’s report will provide end customers with a common vocabulary as they discuss technology with vendors pushing their latest wares. Clarity on technology will allow the extended community to get back to the more vexing issue of business models! More on that next month.
If you are a fan of the movies, maybe you remember the classic line that Robert De Niro delivers in “Taxi Driver”. I am of course referring to “You Talkin’ to Me?”.
Some weeks ago, I attended a conference hosted by the Measurement, Control, and Automation Association (MCAA). The MCAA is the trade association of leading companies who manufacture and distribute a wide variety of process controls, field measurement and analysis instrumentation, systems and software used in industrial process control and factory automation around the world. As you would expect at an annual event like this, we had invited guest speakers to inform and stimulate us with data and ideas that we could presumably take back to our companies and apply to the running of our businesses. The speakers all highlighted the Industrial Internet of Things (IIoT), the use of big data, the potential to change business models and add new revenue streams, and so on. They talked about how products would evolve from being not-so-smart and not-so-connected to being smart and connected. Typical stuff you hear at conferences.
What was out of the ordinary was the reaction from the 200 or so attendees representing 150+ companies. The thought many of them seemed to be sharing appeared to be, “seems interesting, but what does this have to do with me.” In other words, “You Talkin’ to Me?”, minus the cool accent and attitude.
At the breakout sessions and over drinks/dinner, I tried to get a handle on why the MCAA members who would surely be instrumental in making the IIoT a reality had this sort of a tepid reaction. Why wasn’t every vendor there excited about the prospect of transforming their product into a “smart connected product”?
Well, here are a few things I learned.
In some cases, it came down to where in the value chain a company sits. For example, a leader of a company that makes flow meters explained to me that his meters do collect data and provide it through simple analog methods to a higher-level Programmable Logic Controller (PLC) in the commercial or industrial facility. Unfortunately PLCs are a different product segment and are made by a different set of companies. So what does the IoT mean for a flow meter company? Could his company compete better if he provided richer data to the PLC? But what specifically would the PLC vendors value? Could he circumvent the PLC in some way? It would be great if he could reach remotely to his installed flow meters behind the PLC to see how his meters were performing, so he could make operational suggestions to his customers or design suggestions to his own engineers. But the flow meters are hidden behind the PLC and inaccessible. Overall, it was unclear if and how the IIoT would change his world. He noted that the PLC vendors are different in that they could access their systems remotely and get more involved in data management, and that some of the “smart connected products” concepts could be more applicable to them. So an important lesson I took away was that a player’s current position in the value chain and future value chain strategy greatly influence their ability to enable or exploit the IIoT trend.
A second conversation with the CEO of a Human Machine Interface (HMI) company shed light on a different challenge. After a few Sangrias, we were able to identify use cases where more data, access to that data, and ability to analyze that data could all conceivably add greater value to his product line. In all cases, we agreed that these capabilities would be enabled by software. The challenge though was his channel. He pointed out that his distribution network knows how to sell hardware. He didn’t believe this channel could articulate and sell the value-add of software and services, which is what a lot of the IIoT is about. And so, he was in no hurry to spend R&D dollars to make his products smarter and more connected in the IIoT context.
These are just two business model barriers that hinder the adoption of the IIoT. More broadly, we in industry need to learn from each other so that the IoT concepts that the keynote speakers and IoT vendors talk about are mapped into actionable plans by each industry. And as outlined in this blog post, how the concepts map vary not just by industry, but by player and circumstance. In the case of the MCAA constituents, I hope that over the next year, we will be able to develop a working group that can discuss this topic on-line, culminating in a workshop on this topic at the next MCAA conference.
I would be remiss without a shout out to Teresa Sebring and her staff at MCAA for organizing a wonderful conference!
Over the last few years, many of us in the controls industry have been using the phrase “Industrial Internet of Things” or IIoT to describe the evolution of control networking in industrial environments. The IIoT is a truly compelling vision of how the industrial world will look in the interconnected future. Some companies with foresight like GE are starting to implement this IIoT vision in a few target industries like aircraft engine maintenance. However, in my conversations with the vast majority of our OEM customers who use our FieldServer brand of gateway products to interface their products to other systems, or in discussions with our end customers who use our Sentry IT line of fire and gas products to increase the safety of their facilities, I keep hearing the same question: “So what does the IIoT mean for me and what should I do differently?”
In November 2014, Professor Michael Porter and Jim Heppelmann attempted to answer the above question by introducing a framework around “Smart Connected Products” in the Harvard Business Review. They noted that each industrial device now has an unprecedented amount of sensing, processing and communications capability built into the product itself. As a result, these products can produce a lot of useful data which can be fed in near real time for analysis, which in turn opens up many strategic possibilities for players in the value chain.
Consider an example highlighted by Accenture in their recent report on the IIoT. By adding sensors to their tires, Michelin now has the opportunity to sell “tires-as-a-service” by charging their customers for actual kilometers driven. Also, Michelin has created a fuel consumption reduction service for its customers. Data on fuel consumption, tire pressure, temperature, speed and location is brought from each vehicle to the cloud, where fuel efficiency experts analyze the data and make recommendations to the fleet manager on how to use less diesel for driving. Also, the data is available to Michelin product engineers so that they can continuously improve tire performance and reduce tire cost.
In an interview with McKinsey Quarterly, Jim Heppelmann, CEO of software company PTC, outlined how product manufacturers (OEMs) and users (the OEM’s customers) could develop their IIoT strategy by asking:
- How can I (the OEM, the user, or an intermediary) operate the products better?
- How can I (the OEM, the user, or an intermediary) service the products better?
- How can I (the OEM) make the product better?
Assessing how the (smart connected) product can be made, sold, operated, or serviced differently is critical and necessary for articulating a response to the IIoT, and in fact, as I workshop with my customers, these are exactly the questions I would use to frame the workshop. But the real issue on the table that we in the industrial controls business (OEMs, end users, intermediaries, and technology suppliers to OEMs) need to address is the lack of clarity around business models. Yes, there are legitimate technology questions around security or reliability of communications or local versus remote decision making, and I will tackle them in subsequent blog posts. But in my opinion, it is the lack of business model definition that is the primary inhibitor to the adoption of IIoT. Open questions linger such as:
- How do you put a value on the fact that the product can be operated better or serviced better?
- What is the value of insight into product usage that helps an OEM design a better product?
- Who incurs the cost and who gains the benefit?
- What is every extra byte of information worth (because the cost of transmitting and storing data in the cloud is not free)?
- How should the cost of the incremental technology be recovered?
- What % of the value captured by the end user should be shared with the OEM, by an intermediary, or by the OEM’s technology supplier that makes the smart connected model possible?
- What activities should be performed by the various players?
Bluntly put: who does what, and who pays what?
At Sierra Monitor, we are in a somewhat unique position as we grapple with these questions. We get to see this problem from two distinct vantage points along the value chain: One, we provide our FieldServer protocol gateways to OEMs to turn their devices into smart connected devices. Two, we offer our Sentry IT fire and gas detection system – which is a smart connected product – to our facility manager / safety manager customers. As a result, we are in constant conversations with different constituents in the value chain.
During the course of the year, we will be exploring use cases and equitable business models with our OEM customers, our facility manager end customers, and our peers at industry forums like the MCAA. We will be developing and demonstrating cloud based applications to our customers because a conversation around a business model is easier to have while looking at and manipulating real screens. We will be in workshop / exploration mode rather than sell mode because there is still much to learn collaboratively. I hope to use this blog to share those learnings and to speed up our industry’s collective adoption of the IIoT vision.