A: Most industrial-analytics products are focused on large end users and globally operating companies.
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.