Connected Controls: Seven Engineering Decisions That Decide Machine Performance

Forty-six percent of manufacturers already use Industrial IoT solutions at the facility or network level, according to Deloitte's 2025 Smart Manufacturing Survey, yet the figure says nothing about whether connected machines actually perform better. A new engineering guide from Dan Furrow, Senior Vice President and General Manager for US Industrial, Global Accounts and International Markets at Wesco, argues that connectivity alone does not improve performance. The decisions made before a connected control architecture is implemented determine whether the system delivers actionable information or, in Furrow's framing, simply creates another layer of data to manage.

The guide sets out seven engineering decisions that govern the outcome.

Where should control decisions occur?

The first decision is architectural. Engineers should divide control and information processing into three levels: primary control at the device level, secondary control at the machine or cell level, and higher-level systems for fleet monitoring, trend analysis, energy management and remote diagnostics. Speed control, interlocks and trips require rapid response and should remain at the device level; higher-level functions do not need millisecond-level responses. Sending every decision to a supervisory or cloud system introduces latency and adds points of failure. Keeping all intelligence at the device level, conversely, makes cross-machine trend identification difficult.

What can the existing architecture support?

New machines can specify drives, controls and communications modules as an integrated architecture from the start. Retrofits demand more care. Before replacing or adding a VFD or PLC, engineers should document available I/O, communication protocols, controller capabilities, motor characteristics, network infrastructure and existing safety functions. A replacement drive may carry considerably more diagnostic capability than its predecessor, but that capability has no value if the PLC cannot receive the data or the network cannot carry it. Gateways, communication modules and edge devices can often bridge new equipment and legacy controls, and not every machine needs replacement.

Which protocol, which data?

Protocol selection should follow the application, not novelty. Key factors include response time and latency, data volume, diagnostic requirements, network redundancy and future expansion. A simple machine may need a straightforward communications structure; a complex production line may need Ethernet-based communications among drives, PLCs, HMIs and supervisory systems. The goal is not to connect every device to every other device across the plant floor.

The same discipline applies to data collection. Modern VFDs can report operating conditions that reveal developing problems without additional sensors, but engineers should first identify the decisions the data will inform. To detect an overloaded motor, current and torque information may be more useful than unrelated parameters. The guide poses a direct test: what action will we take if this value changes? If there is no clear answer, the data does not need collecting.

How should motor, VFD and control strategy match the load?

Motor, drive and control strategy must work together to deliver the required speed, torque and efficiency. Vector control provides more precise torque control for conveyors, extruders and positive-displacement pumps that demand high torque at low speeds or fast dynamic response. Scalar control may suffice for fans and pumps where simplicity and cost take priority. Synchronous motors offer higher power density and efficiency; induction motors are generally easier to replace and repair. Engineers should weigh upfront cost, operating efficiency, maintenance and service life as one system design question.

Energy performance follows the same application-based logic. A VFD running a motor at the application's optimal speed, rather than continuously at full speed, can deliver substantial savings in variable-torque applications from even modest speed reductions.

What does the EU Cyber Resilience Act change?

The guide treats cybersecurity as an engineering requirement, not a post-commissioning concern, and cites regulatory pressure: the European Union's Cyber Resilience Act mandates reporting of actively exploited vulnerabilities and serious incidents for hardware and software products with digital elements that connect directly or indirectly to devices or networks. The regulation currently applies to products placed on the EU market, but global manufacturers may need to account for it in product design and lifecycle management. Specification questions include how devices are authenticated, how credentials are managed, and how firmware and security updates are handled.

Can the architecture grow?

The final decision is scalability: whether additional drives, sensors, machines or cells can be incorporated without redesigning the system. For OEMs replicating equipment across installations, standardized architectures, consistent device configurations, repeatable communications structures and reusable parameter sets reduce engineering and commissioning effort.

The optimal architecture, the guide concludes, is not the one with the most devices or the newest technology, but the one engineered around a defined operational objective. The open question for adopters is whether their specification process now treats cybersecurity, latency budgeting and data triage with the same rigor as torque and efficiency.