The Human-in-the-Loop

Athulan Vijayaraghavan, CTO and co-founder of System Insights, argues that when we think of data-driven manufacturing, we shouldn't forget about the human consuming that data, since the kind of data one needs depends upon who is using it.


Facebook Share Icon LinkedIn Share Icon Twitter Share Icon Share by EMail icon Print Icon

A lot of the discussion about data-driven manufacturing has been focused on software for collecting, analyzing and managing data from devices and sensors on the shop floor. While data from these sources is critical for data-driven manufacturing, we should not forget the most important source—and consumer—of data in a manufacturing system, the human-in-the-loop.

Let’s first look at the human-in-the-loop as a consumer of data. Devices and sensors from the shop floor are capable of streaming large amounts of data, and by using standards such as MTConnect, it’s easy to capture this data at high rates. While it’s tempting to present all of this data for decision-making, we need to keep in mind that the information will be applied in specific manufacturing contexts to achieve a goal. The manufacturing context and the type of data required to make a decision are different based on the role of the data consumer, which can include
operator, programmer, maintenance engineer or production supervisor. Here are some considerations for presenting information:

Pertinence. The information has to be pertinent to the task that the user is performing. A maintenance engineer fixing a failure at a machine needs different information than the engineer who is reviewing past failures.

Context. Information has to be embellished with contextual data to make sure it supports the task that is being performed. In the case of the maintenance engineer reviewing fault events from a machine, the fault events can be embellished with the machine’s operating parameters, such as speed, feed, load, overrides and so on, to help build a better understanding of what was happening at the machine when the fault occurred.

Ubiquity. The information has to be presented across multiple interfaces, exploiting their capabilities and keeping in mind specific tasks that users will perform using those interfaces. For example, fault events can be displayed on a real-time shopfloor display using color-coded indicators, on a smartphone as a notification and on a PC interface using rich historical reports with deep-dive capabilities.

Of equal importance is looking at the human-in-the-loop as a source of data. Data from the skilled operator or engineer is critical to building a holistic record of the manufacturing process that he is part of. This data has to be captured either explicitly, by requesting information from the user, or implicitly, by tracking the actions the user is performing relative to the process. Here are the same considerations for capturing this information from the user:

Pertinence. Information gathering should be pertinent to the task the user is performing, such that he has to put in minimal effort. Implicit mechanisms (which allow the user to provide information passively) are preferred over explicit mechanisms (which require the user to provide information actively).

Context. Information has to be captured with as much context as possible, describing the manufacturing environment at the specific time. This might include ambient conditions, process parameters and sensor data.

Ubiquity. The user should be able to provide information across multiple interfaces, so he can choose the interface that minimizes effort.

Considering the human-in-the-loop when developing data-driven manufacturing systems changes the focus of these systems from simply collecting and analyzing information issued by “dumb” data sources to supporting complex decisions made by skilled operators and engineers. The ultimate success of data-driven manufacturing is dependent on how well the systems integrate with existing work flows of the humans-in-the-loop and leverage their intelligence in improving manufacturing effectiveness.