Lifting the Veil After the Sale: another IoT “Essential Truth”

Count me among those who believe the Internet of Things will affect every aspect of corporate operations, from manufacturing to customer relations.

Perhaps one of the most dramatic impacts will be on the range of activities that take place after the sale, including maintenance, product liability, product upgrades and customer relations.

In the past, this has been a prime example of the “Collective Blindness” that afflicted us before the IoT, because we basically had no idea what happened with our products once they left the factory floor.

In fact, what little data we did have probably served to distort our impressions of how products were actually used. Because there was no direct way to find out how the products were actually used, negative data was probably given exaggerated weight: we heard negative comments (warrantee claims, returns, liability lawsuits, etc.), loud and clear, but there was no way to find out how the majority of customers who were pleased with their products used them.

That has all changed with the IoT.

Now, we have to think about products  in totally new ways to capitalize on the IoT, and I think this merits another “Essential Truth” about the IoT:

Everything is cyclical.

Think about products — and industrial processes in general — in the old industrial system. Everything was linear: perhaps best exemplified by Henry Ford’s massive River Rouge Complex, the world’s largest integrated factory, and the epitome of integrated production.

Ford River Rouge Complex

“Ford was attempting to control and coordinate all of the necessary resources to produce complete automobiles.  Although Ford’s vision was never completely realized, no one else has come so close, especially on such a large scale.  His vision was certainly a success, one indication of this is the term Fordism, which refers to his style of mass-production, characterized by vertical integration, standardized products and assembly-line production”

At “The Rouge,” raw materials (literally: it had its own coke ovens and foundry!)  flowed in one side, and completed cars flowed out the other, bound for who knows where. Once the cars were in customers’ hands, the company’s contact was limited to whatever knowledge could be gleaned from owners’ visits to dealers’ service departments, irate calls from customers who had problems, and (in later days) safety recalls and/or multi-million dollar class-action lawsuits.

That linear thinking led to a terrible example of the “Collective Blindness” phenomenon that I’ve written about in the past: who knew how customers actually thought about their Model T’s? How did they actually drive them? Were there consistent patterns of performance issues that might not have resulted in major problems, but did irritate customers?

Sure, you could guess, or try to make inferences based on limited data, but no one really knew.

Fast forward to the newest auto manufacturer, Tesla, and its factory in Fremont, California (aside: this massive building — Tesla only uses a portion, used to be the NUMMI factory, where Chevy built Novas and Toyota built Corollas. Loved the perceptual irony: exactly the same American workers built mechanically identical cars [only the sheet metal varied] but the Toyotas commanded much higher prices, because of the perception of “Japanese quality.” LOL. But I digress….).

Tesla doesn’t lose track of its customers once the cars leave the plant.

Tesla assembly line

In fact, as I’ve written before, these “iPhones on wheels” are part of a massive cyclical process, where the cars’ on-board communications constantly send back data to the company about how the cars are actually doing on the road. And, when need be, as I mentioned in that prior post, the company was able to solve a potentially dangerous problem by simply sending out a software patch that was implemented while owners slept, without requiring customer trips to a repair shop!

I imagine that the company’s design engineers also pour over this data to discern patterns that might indicate elements of the physical design to tweak as well.

Of course, what would a blog post by me about IoT paradigm shifts be without a gratuitous reference to General Electric and its Durathon battery plant (aside to GE accounting: where should I send my W-9 and invoice so you can send me massive check for all the free PR I’ve given you? LOL)?

I can’t think of a better example of this switch to cyclical thinking:

  • including sensors into the batteries at the beginning of the production process rather than slapping them on at the end means that the company is actually able to monitor, and fine tune, the manufacturing process to optimize the critical chemical reaction. The same data allows the workers to remove defective batteries from the assembly line, so that every battery that ships works.
  • once in the field (and, remember: these batteries are deployed in incredibly remote areas where it might take days for a repair crew to reach and either service or repair them) the same sensors send back data on how the batteries are functioning. I don’t know about the specifics in the case of these batteries, but GE has actually created new revenue streams with other continuously-monitored devices by selling this data to customers who can use it (because the data is shared on a real-time basis, not just historically) to optimize performance.

Elsewhere, as I’ve mentioned before, General Electric’s William Ruh has said that being able to lift the veil of “Collective Blindness” through feedback from how customers actually use their products has even revolutionized their product design process:

“… G.E. is adopting practices like releasing stripped-down products quickly, monitoring usage and rapidly changing designs depending on how things are used by customers. These approaches follow the ‘lean start-up’ style at many software-intensive Internet companies. “’We’re getting these offerings done in three, six, nine months,’ he (Ruh) said. ‘It used to take three years.’”

Back in the ’90’s, I used to lecture and consult on what I called “Natural Wealth,” a paradigm shift in which we’d find all the inspiration we needed for an information-based economy in a table-top terrarium that embodies billion-year-old  principles of nature:

  • embrace chaos, don’t try to control it. (i.e., use open systems rather than proprietary ones)
  • create symbiosis: balance competition with cooperation (, where you release your APIs to create synergistic mashups with others).
  • close the loop.

With the IoT, we can finally put that last principle into practice, substituting cyclical processes for linear ones.  At long last, the “systems dynamics” thinking pioneered by Jay Forrester and his disciple, Peter Senge, can become a reality. Here’s a closing tip to make that possible: in addition to SAP’s HANA or other analytics packages, look to systems dynamics software such as isee systems’  iThink to model your processes and transform linear into cyclical ones. Now get going: close the loop!

MQTT: important Internet of Things facilitator?

Posted on 9th May 2013 in automotive, Internet of Things, M2M, manufacturing

As I mentioned at the time, part of the news when IBM announced its new heavy-duty MessageSight appliance to handle the vast quantity of real-time data sharing between sensors on the Internet of Things was that MessageSight would use the MQTT protocol to communicate the data.

MQTT, or Message Queue Telemetry Transport (whew!), is an existing protocol for sharing telemetry-style data which OASIS recently proposed as a standard for M2M data sharing. According to IBM, its primary virtues are “low power consumption, high performance and reliability (which) allow real time updates that can be acted upon immediately,” — important because of the need to reduce sensors’ drain on their batteries. Other types of pervasive devices that might use the protocol include “mobile phones, embedded systems on vehicles, or laptops and full scale computers.”

According to GigaOm, “’s already in use for satellite transmissions and in medical and industrial settings where low-bandwidth communications are essential. ” In addition to IBM, it’s already supported by Kaazing, Red Hat, TIBCO, and Cisco.

According to The New York Times, MQTT advocates say it could be the M2M equivalent of the Web’s HTTP protocol.  Co-inventor Andy Stanford-Clark of IBM is one of my fav IoT experimenters (you’ve got to see his TedX talk about how he’s automated his home on the Isle of Wight — and didn’t stop there, making the whole island a laboratory for the IoT!). He and co-inventor Arlen Nipper wrote the first version of MQTT in 1998 for oil platform sensors.

As in several of my recent posts, the automotive industry was singled out by the NYT as one field where MQTT might be applied:

“Vijay Sankaran, director of application development for Ford, said improved message-handling technology will be vital to the company’s plans for automated diagnostics and new consumer services.

“Mr. Sankaran pointed to two examples. In the Focus Electric car, he said, Ford wants to get continual, detailed sensor data on the state and performance of the vehicle’s electric battery, then feed that information into product development.

“And drivers, Mr. Sankaran said, seek to do more things while in their cars. A stock trader, for example, might want to continue trading from the road. If the trader sent in an order to sell 30,000 shares of Apple, he said, that transaction must be reliably and securely communicated.

“’You need an advanced messaging engine for these kinds of services,’ Mr. Sankaran said.”

The Times article points out that for MQTT to achieve its full potential it must be adopted not only by IT companies such as IBM and Cisco, but also by “…industrial technology heavyweights including General Electric, Honeywell, Siemens and United Technologies.

These companies make many of the sensor-equipped big things in the so-called Internet of Things — like jet engines, power turbines and oil field equipment.”

MQTT looks like it will play a major role in allowing harvesting of data from sensor networks, but we’ll have to see how much of an IoT lingua franca it really becomes!