Q: What do you see currently in terms of adoption and implementation of IIoT and analytics?
A: There are three user groups, with some overlapping and some distinct needs.
The first group is end users who are interested in deriving insights from production data and are driving IoT and analytics in their plant machinery.
The second group is machine builders, who would like to establish new business models, but most have not been able to find solutions to satisfy all end users as most have their own goals with connectivity that may not align.
The third group is system integrators, who are finding a place to help end users implement software and hardware solutions for IoT and analytics but are also looking for ways to turn the implementation into repeat and/or service-based business.
While all of these user groups are growing, the majority of projects and are taken on by larger end users at this point.
Q: What is the barrier to entry for companies starting IoT and analytics projects?
A: In the early days of applied IoT and analytics, it was all about how to connect machines. Beckhoff’s strategy for IoT connectivity is enabling our machine-builder customers to be confident that sending Beckhoff-controlled machines to their end users means sending IoT-enabled machines that fulfill their end customers’ requirements no matter their IT infrastructure, ERP, MES, databases or security model. We ensure that our machine-builder customers have everything they need for IoT and analytics built into a standard machine controller.
Most think of Beckhoff as a technology leader in machine controls and motion, but our platform can also be used to create very powerful and flexible IoT gateways and edge-computing platforms to bridge nearly any protocol, IT standard or fieldbus. It works with any cloud provider like AWS or Azure, supports modern edge software architectures such as containers, and enables remote debug and diagnostics.
Q: Some end users don’t allow network connectivity, especially not to the cloud. With every end user having different requirements, how can machine builders still take advantage of data analytics?
End users and machine builders can have different needs and different scales of implementation. We built our TwinCAT analytics tools to address those many use cases. Let’s talk through some scenarios.
The first place that data analytics often starts is at the machine-builder or system-integrator location to make the machine run as optimally as possible, to find issues faster and reduce machine development or commissioning time.
It’s important to not just visualize and graph information from the controller, but to be able to answer questions using the data. For example:
- Is the process sequence timing-constant? If not, why, and where in the program can I optimize it?
- What process step is taking the most time? That’s where you need to focus to squeeze out a bit more cycle time. Where are any intermittent behaviors coming from? Find those issues without modifying code until you’re confident you’ve found the problem.
You can configure all of this from an engineering laptop using one development environment, no servers or IoT infrastructure required.
For end user sites without connectivity, the OEM can enable a machine “flight recorder” in the main PC-based controller to log data locally, even thousands of variables per PLC cycle. This information helps find issues faster and send more than just error messages back to the OEM controls engineer for analysis. This flight-recorder approach provides valuable, actionable data.
OEMs or integrators would also like to provide machine-operation statistics or maintenance insights, adding value and services along with the machine. While this approach is great for cloud-connected machines, it can also be done strictly within the user’s internal network, if preferred. An industrial PC can serve as the hardware for the analytics runtime and serve up the dashboard.
Again, this could be alternatively cloud-based or even housed on servers at the OEM’s location, which could feed into another service-based revenue stream.
Q: Will OEMs or integrators need specialists with skillsets or programming knowledge beyond what typical controls engineers possess to implement these scenarios?
A: With the huge shortage of skilled engineers, asking your team to also become cloud platform experts may be too much. The idea with TwinCAT Analytics is to give machine experts and controls engineers the ability to leverage data and find insights without having to learn new data-science platforms or programming languages.
Fortunately, controls engineers can build the complete workflow, from a file-based flight recorder to full analytics runtimes and dashboards, in the same programming environment as would be used to program the PLC and machine control.
Familiar tools are available, designed for simple dragging-and-dropping of algorithms and variable/tag browsing in IoT and analytics projects. And currently there are more than 90 algorithms that can be combined to derive just about any answer needed from the data. If you don’t have the right algorithm, you can add your own to the toolbox.
The analytics runtime code and dashboard are then automatically generated from the graphical drag-and-drop environment.
The results include the logic for the data analytics and are generated in the structured-text PLC language. The dashboard is created in our HTML5-based HMI platform in TwinCAT. These are all well-known platforms and technologies for machine builders and system integrators that have been modernized for the IoT era.
Q: What happens in cases where an end user already has a large and very mature analytics solution, say with AWS, Azure or SAP? What opportunities do OEMs have to offer any kind of analytics as a value-add with their machine?
A: Machine builders or integrators can use one or a combination of the implementation scenarios we talked about to augment an end user’s implementation. Here’s an example: Typically, end-user data includes machine health and runtime data that is sent perhaps in 1-second increments. This is great for looking at overall equipment effectiveness (OEE) and long-term vibration data for predictive maintenance, but it’s not enough for optimizing PLC code or troubleshooting the fieldbus.
Why is this the case? A PLC cycling at 1 ms is running logic 1,000 times between data samples if it’s sending every second, so a lot happens between samples. It’s a good idea to collect real-time (RT) data at or near every PLC scan for a short time, say for 24 hours for troubleshooting and optimization, then use that RT data to calculate dashboard information and average or downscale the data into meaningful 1-second intervals. For machine troubleshooting and machine optimization, those values at high frequency might hold the key information. In this way, the fast cyclic data is available to the OEM for analysis, and the end user is able to get all the data they need at the rate they need it.
Everybody wins.
For more information, visit www.beckhoff.com/IoT.
