The purpose of bringing industrial-connected equipment to market is to embed your products and services inside the customer value chain and break the spiral toward hardware commoditization. To accomplish this goal, you must first understand each link of the chain, mapping the requirements, skills and constraints of each actor from development and delivery through to sales and consumption.
In many cases, this mapping activity will touch actors in the value delivery chain with which your company has not previously had a direct relationship. How will you determine the appropriate levels of investment and capabilities required at each system layer to ensure each actor has what they require from the beginning, avoiding costly rework and market failures after your production release?
Over the past decade, Bright Wolf has helped some of the largest companies in the world to understand and solve these and other challenges of industrial IoT and connected product systems.
Using heavy machinery human-machine interface (HMI) development and operation as an example, there are likely to be the following roles:
- Software developer
- Internal engineer
- Machine system integrator
- Service technician and dealer
- Owner and operator
At each level there are more individuals, starting with the core development team and ending with the individual consumers of the products produced. When you combine the roles by size and activities by frequency into a single chart, you will see clear patterns emerge for guiding your product strategy.
Right away this tells you there will be a lot of users wanting specific layouts and display widgets on their HMI dashboards. If you don’t build in the ability for individual owners to easily configure their own screens, then either your small team of software developers is going to be incredibly busy following up on support tickets to make necessary code changes for each HMI operator — or your product is going to fail in the market due to a fixed one-size-fits-all user interface that nobody wants to buy.
On a related note, there are certain configuration changes that your service techs and dealers are going to need to be able to make that end users should not be allowed to access. How are you going to restrict different levels of configurability for your equipment in the field? This ability to enable or disable functionality based on user role (and the methods for properly authenticating each user) must be part of your overall system architecture or this simply will not be possible. IoT product managers must plan accordingly and include this as part of the initial specification and requirement documentation, budgeting for sufficient development resources to accomplish these tasks.
We’ve seen another scenario occur in connected product systems that is equally problematic if not accounted for upfront. How will the system enable customers to configure I/O during installation? In these situations, manufacturers typically include a set of open I/O ports in addition to an initial set of supported sensors, such as humidity and altitude. When new data types are desired in the future, for example, temperature or vibration, operators are able to plug the appropriate sensors into these channels and begin immediate collection — at least at the physical level. Critical information will be lost, however, unless the digital system has been architected to accept, pass along and process this new data and its associated configuration.
Beyond this, the architecture will also need to account for displaying these new values inside mobile apps and web applications. While new data types as a concept may be anticipated, the specific types of data are unknown until the customer identifies a new requirement or opportunity. Therefore, the architecture must allow for system operators to configure the application user interface and data reporting after deployment. Otherwise, the new sensor values may appear in the list of metrics for each asset in the field, but with fixed, unhelpful names like “DataPoint8” and “Item9” with values shown in generic number formats that must be deciphered manually.
The specifics around how much configuration to make possible for actors at each point in the value chain will vary across industry verticals and the products themselves. IoT product managers must consider all of the actors involved in creating, operating and using the system from end to end so they can provide sufficient specifications for the IoT development teams designing the system architecture. Each actor must be well-understood upfront — their requirements, goals and the tools they’ll need based on their likely skill sets — in order to deliver a commercially successful connected product system.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.