Make Any Sensor a Smart Sensor with PICMG IoT.1, Part 5: Integrating Effecters 

June 22, 2022

Story

Smart sensors are the front line of any automation system. However, automation implies motion, and sensors only observe, capture, and report data about their surroundings. The responsibility of putting that data to use falls to effecters. 

A Renewed Focus on Data 

Effecters, by definition, bring change to the surroundings that sensors can only observe. These can be motors, solenoids, valves, or any other analog component that “effects” change in the real world. In industrial automation, for example, effecters are responsible for applying motion, temperature, pressure, and other physical transitions to systems like conveyor belts, robotic arms, presses, fans, and so on.  

Today, most effecters operate completely independent of IoT sensor data. Of course, the goal of Industry 4.0 and smart factory concepts is to leverage the data captured by sensors in tuning these effecters to  improve yields, increase uptime, lower costs, reduce energy consumption, etc. This could manifest in the form of data analytics that control effecters directly; or more likely in scenarios like motor control that run highly structured programs, inform parameters of a command that defines how an effecter excites a machine to reach a certain set point.  

In either case, sensor data analytics refines the deluge of raw sensor data into information that one or two commands can use to influence effecter (and subsequently equipment) operation. However, we must remember that the ultimate goal of Industry 4.0 deployments is to unify the factory floor with IT operations centers where the focus is on optimizing the orchestration of entire production lines.  

Jobs-Based Automation and the Factory IT Operations Center 

For uninitiated automation stakeholders with backgrounds in IT data modeling, this level of granularity doesn’t help meet their objective of ensuring that production happens and happens efficiently. It’s not even particularly relevant to factory engineers who are responsible for implementing profiles across the equipment on a production line to help achieve the goals set forth by the IT operations center. It more accurately describes data that would be useful to someone like a control systems specialist who would tune controllers to run motors at a certain velocity or position overshoot based on the application requirements. 

But that level of specialization is precisely what we hope to get away from in the new smart factory. Instead, the future is focused on jobs-based orchestration where IT ops personnel can view sensors and effecters and oversee more rudimentary aspects of equipment control like system initialization, error state management, or even orderly equipment shutdowns from their own native environments. So, rather than thinking of automation objectives in terms like “this motor must reorient itself 10 degrees along the Z axis” or “this hydraulic piston must extend 100 cm,” they can approach problems by saying “I want this machine to produce six gadgets then turn off.” 

For this to work, jobs in a smart factory must appear to these users as a sequence of steps coordinated across one or more effecters to reach a desired outcome. This job-based scheduling provides factory automation at the highest levels of abstraction, which is great in theory, but not currently possible in most factory settings. 

There are many reasons for this, but almost all of them result from the fact that different machines from different manufacturers don’t communicate well with each other. This not only presents a major challenge for IT operations center engineers, but also engineers on the factory floor whose responsibility is to interpret jobs from the operations center and communicate corresponding sequences out to all the effecters on a production line at scale. 

One Data Model to Rule Them All 

The only way to unify entire smart factories, from the automation engineer to the ops center and from the smallest OT effecters through to the most abstracted IT orchestration systems, is through common data models. As discussed in Part 2 of this series, “a data model … is a structured way of organizing data that contains specific rules or instructions for how that data is packaged.” Simply put, the data model provides a structure for how the data relates to specific states in the manufacturing system.  

In a broader factory context, however, a common data model provides an interface across all hierarchical levels so that top-down and horizontal jobs-based communications can be more transparent. Obviously, what and how much data is shared with different departments within the newly integrated IT/OT factory can be determined on a case-by-case basis for security, reliability, and privacy reasons.  

But the fact that it is possible to combine abstracted sensor data with abstracted effector data in a unified model has greater implications for things like digitally modeling systems of systems so you can simulate the performance of physical factory lines before they’re ever powered on. And, as it does with smart sensor vendors, it allows smart effecter vendors to specify exact parametric requirements without having to do much, if any, application-specific coding. 

The same PICMG Configurator used to generate data models for smart sensors can be leveraged in a similar capacity to create smart effectors that are compatible with this type of stateful control. 

We’ll demonstrate how in Part 6.