As we start these projects, the focus is not all strategy, markets, and business cases. We eventually get to the tech stuff – and have already hit a few things that start off as puzzles and end up as interesting insights, decisions to reduce complexity, and/or necessary evils.
As we start these projects, the focus is not all strategy, markets, and business cases. We eventually get to the tech stuff – and have already hit a few things that start off as puzzles and end up as interesting insights, decisions to reduce complexity, and/or necessary evils.
An example of the first type – a puzzle that led to an insight. A basic problem area in the IoT Framework is Communicating from the Field – once we collect some data from this Thing, how are we going to send it to the Cloud? Are we adding a cell phone to every pump (maybe) or every square yard of this farmer’s field (not likely)? How do we bridge that air gap?
This challenge came up when working through a use case where the Business Unit (BU) is interested in operational details of their Things in the field – how many cycles, how much energy / horsepower / RPM per cycle, operating temperature before / during / after, remaining fuel levels, fuel consumed, pressure generated, etc. These are valuable details for product development Engineers, for example, to have a history of operating parameters that led up to a (rare!) product problem; with data like that, we can solve root-cause issues and improve performance in future versions of this Thing. Our customers’ Service Techs could use the same information to troubleshoot issues in the field. And the Operator could use the information to tune the Thing as part of a system, or to know that the Thing is ready to operate when it is needed.
This level of info makes me upload daily ..
As we backed through that “value chain” of information consumers – from the “back office” of Product Engineers in the development lab to the “front office” of the point-of-use Operator – we realized that the end user interface could address our Communication challenge. I compared the situation to my fitness band – this Thing is gathering all sorts of information that is interesting to me right away, so I use my smartphone to pull the data and show me interesting stats on Sleep and Steps. Ah, but it also shows me Calories – it’s exchanging data in my Fitness Cloud, and giving me a complete picture of how well (or poorly) I am doing.
Voila – the trick to communicating data from My Things to My Cloud is to use the end users’ smartphone! And it’s not really a trick – we would deliver information value to the Operator. Actually, there is strong pressure to deliver relevant value for the Operator, because we want them to upload this data for our use every day, regularly, into the future.
Caveats, Of Course
Challenge: In retrospect it’s seems obvious – but remember, we are dealing with product engineers in industrial manufacturing. Brilliant in their chosen field, quite probably with a large body of experience in mobility, communications … but not many have been designing user interfaces or interacting with operators that have consumer-friendly expectations of usability. What is obvious to B-to-C developers is often new and insightful for B-to-B folks.
Challenge: This communications link will not fit all use cases – for BU’s that put Things out en masse into chemical plants, farmer’s fields, or drilling sites, the friendly mobile phone interface may not be practical, and ubiquitous cell coverage may not be available.
Challenge: There will also be data ownership and privacy things to consider – I’ll talk more about that in a future post.
Check out my growing series of posts on IoT Field Notes …
