Jeremy McCullough is senior product/application engineer at SEW-Eurodrive, where he specializes in helping others understand and apply complex technologies across the SEW electronics portfolio. His work spans condition monitoring, energy management systems, industrial communication, controls integration and functional safety. He supports internal teams across the United States by breaking down technical barriers and troubleshooting difficult problems.

Jeremy's expertise and responsibilities include everything from processing scope trace data with Python and Plotly or troubleshooting industrial communication issues using Wireshark to helping SEW teams to size and deploy modular energy-buffering drive systems. He often works across electrical, mechanical and software system boundaries to diagnose edge cases, identify integration issues or uncover details others might miss.

Can you explain what a decentralized drive is and how decentralized drives differ from centralized drive systems, in terms of installation, wiring complexity and maintenance?

For energy efficiency, there have been improvements in motor control and loss reduction, but some of the largest gains now come from architecture: regenerative operation, energy storage, buffering and reuse (Figure 1). Recovering energy that would otherwise be dissipated may have a much greater impact than a small incremental improvement on an individual datasheet.

What sorts of emerging technologies, such as edge computing, AI-assisted diagnostics or advanced simulation are being integrated into drives and inverters?

Jeremy McCullough, senior product/application engineer, SEW-Eurodrive: I think AI has a great deal of potential in industrial automation. I am less convinced by the idea that every problem immediately needs to become an AI problem.

Get your subscription to Control Design’s daily newsletter.

The first challenge is what I would call the context gap. Industrial automation is extremely broad, and useful conclusions depend on knowing what the asset is, how it is configured, what application it is performing, what state the machine is in and what normal behavior looks like.

That context is not always well represented in general-purpose training data. This industry also values uptime, reliability, deterministic behavior, compatibility, and product lifecycles that may extend for decades. That does not mean the industry is anti-technology. It means the technology has to produce a real benefit without compromising those priorities.

There are already useful capabilities that do not require a large AI model inside the drive. A system can perform plausibility checks, identify configuration mismatches, aggregate process values or trend measurements over time. It might notice that the brake voltage stored in a digital nameplate does not match the configured value or that torque during a repeatable part of a machine cycle has gradually increased over several months.

Drives already monitor current, torque, speed error, temperature and other internal values at high sample rates. In some applications, developing mechanical symptoms may be visible in that existing data without installing dedicated sensors everywhere.

Digital nameplates, motor and gearbox data, user-unit scaling and application-state information all help close the context gap. The drive’s role may be to produce reliable information, perform relatively simple local checks and pass appropriately aggregated data to an edge or upper-level system that can interpret it.

Before rushing to add AI, I think the first step is to determine what data is actually useful, what context it requires and what decision it is intended to improve.

Speaking of advanced simulation, the definition of a digital twin can vary, based primarily on the application. What's your definition, and how are digital twins utilized within the development and commissioning processes, and what impact have digital twins had on reducing project lead times or improving reliability?

Jeremy McCullough, senior product/application engineer, SEW-Eurodrive: Fundamentally, I think a digital twin is a digital representation of something physical.

There are two major aspects to that representation. One is model fidelity: how much of the physical system is represented and how accurately it behaves. The other is state fidelity: if the twin represents a specific physical asset, how closely it reflects that asset’s current condition and operating state.

Customers usually ask me about digital twins in the context of either virtual commissioning or condition monitoring and asset management.

Virtual commissioning is especially valuable when project schedules contain many dependencies. In an automotive plant, for example, a new production line may need to be installed during a shutdown lasting only a few weeks. Steel fabricators, electricians, mechanical installers and controls integrators may all be working sequentially. When one activity is delayed, the time available for commissioning gets compressed, but the start-of-production date usually does not move.

Any PLC, motion or sequence logic that can be tested before the physical equipment is available reduces that risk. It means fewer problems have to be discovered and corrected during the limited on-site window. It can also reduce travel costs and the amount of time the commissioning team spends away from home.

There is a reliability benefit, as well. More operating scenarios and edge cases can be evaluated before the equipment is running, and the commissioning team is less likely to make rushed changes under production pressure.

Digital twins can also provide operational context. SEW uses autonomous mobile robots (AMRs) in its own production processes, with a three-dimensional representation showing where the robots are on the plant floor. If one reports a fault, you can immediately see where it is and what it was doing.

A digital twin does not have to be an elaborate physics simulation. Even a gearbox can have a useful twin containing its identity, configuration, installation date, warranty information and maintenance history. Its value should be measured by whether it helps someone design, commission, operate or maintain the equipment more effectively.

What kinds of data and sensor inputs are most valuable for building accurate digital twins of drive systems, and how important is it to ensure real-time synchronization between physical and virtual models?

Jeremy McCullough, senior product/application engineer, SEW-Eurodrive: The most valuable data is the data that supports a defined operational or maintenance decision. Before selecting sensors or update rates, I would first ask what problem the digital twin is intended to solve.

Two areas that are often undervalued are asset management and fault tracking.

The first question is simply: What equipment do you have in the plant? Many customers do not have a complete answer. Equipment may have been installed over many years by different OEMs, integrators and vendors. An accurate inventory is useful for spare-parts planning, identifying duplicated equipment, and managing obsolescence.

Fault tracking is just as important. If someone asks for condition monitoring, one of my first questions is, “What problem are you trying to solve?” The answer is usually uptime. The next question is, “What is affecting your uptime?”

Most HMIs have some kind of fault history, but that does not necessarily mean the information is usable. The history may be difficult to export, may roll over before anyone reviews it or may record a specific drive fault as nothing more than “VFD fault.” It may also be missing the machine state, commanded operation or surrounding process events needed to understand why the fault occurred.

In that case, the first step is not necessarily adding more sensors. It may be making the existing event data more specific, persistent, contextual and accessible.

Other useful information may include operating hours, duty cycle, torque, current, speed error, temperature, thermal utilization, energy counters and overload history. External vibration or environmental sensors may also be valuable where the application justifies them.

The required synchronization rate depends on the use case. A live model showing AMR positions needs frequent updates. Faults and component replacements are best treated as events. Maintenance and asset information may only need to synchronize hourly or daily.

More data is not automatically better. It has to be transmitted over existing networks, stored, processed and interpreted. The update rate should be selected according to how quickly the metric changes and what decision it supports.

Even apparently static data can be valuable when it changes. If maintenance replaces a gearbox overnight to restore production, the serial number associated with that machine location changes.

Recording that event creates traceability without requiring someone months later to interrogate the maintenance team or search through work orders and purchase orders.

A useful digital twin does not only show how the machine is behaving right now. It also records how the machine has changed over its life.

Tell us about one of your company’s state-of-the-art product.

Jeremy McCullough, senior product/application engineer, SEW-Eurodrive: A conventional diode rectifier largely gives you whatever dc-bus voltage results from the incoming ac supply. The MDP92A combines that rectifier with an actively controlled dc-dc stage, which turns the dc bus into something the machine can deliberately manage. You can control the bus voltage, including boosting it when needed, and control how much current or power is drawn from the supply.

That makes it practical to use relatively large capacitor banks for energy buffering, limit peak demand from the mains and retain regenerative energy within the machine rather than immediately dissipating it.

The MDP92A fits within SEW-Eurodrive’s broader Power and Energy Solutions portfolio, which in turn is part of Movi-C (Figure 2). One of the biggest advantages is that the energy-management system was designed to work with the rest of the automation platform rather than as a separate, isolated solution.