promo-fig.gif

4 Reasons to Consider Distributed Over Centralized Control

Download this article in .PDF format
This file type includes high-resolution graphics and schematics when applicable.

Mechanical control plays a big role in the hydraulics industry. Though many low-end machines require very little intelligence, manufacturers and OEMs are increasingly responding to customer needs with solutions that incorporate smarter tools, allowing for increased flexibility and efficiency. However, this trend often elicits one key question: Should the mobile applications implement a central control architecture or distributed control architecture?

Centralized vs. Distributed

Centralized control architecture is wired back to a central microcontroller and all control operations report to the microcontroller. Central architecture has been an effective and useful control schema that has dominated control systems for years (see figure).

The declining cost of producing silicon has dramatically increased production, spurring wide adoption throughout a range of industries. Smartphones are the consumer-facing indicators of the kinds of changes rippling through every industry. As the technology decreases in cost, adoption widens and applications grow many-fold.

This infographic shows the different wiring configurations between centralized and distributed control. (Click image to enlarge)

 

Distributed control using smarter valves takes advantage of the widespread adoption of smart technology, enabling controllers to be placed closer to the desired actuation points. The resulting “embedded systems” allow for newer technology with increased sample rates, which in turn brings about faster responses and increased precision. In addition, with distributed control, intelligence can migrate from the microcontroller to the embedded system, increasing the processing power and capacity of the entire smart system.

Design Engineers Face New Challenges

One of the great things about distributed controls today is that the collaboration process is more straightforward and painless—there is no need to be an expert in subsystem control. Instead, system integrators buy the components that experts have designed to build the system that perfectly fits their customers’ needs.

Still, as the adoption of embedded-system technology continues to grow, new questions arise for OEMs integrating systems on behalf of their customers. In particular, what are those functional, economic, and complexity tipping points where it starts to make sense to pursue the newer, promising control schema of distributing controls? Thus, four primary questions must be answered by anyone weighing the merits of decentralized controls for mobile applications.

Questions About Distributed Control

How complex is my application?

A simple application is perfect for central control. A one-operation application will likely not tax a central controller. Physical distances may be small, and communication bandwidth is not a concern these types of applications.

A complex application, however, running fast with many simultaneous commands and operations, may affect control priorities and a central controller’s response time. These more complex applications typically work at higher speeds and require much feedback, resulting in higher productivity and more precise control. And while systems that exchange real-time data between subsystems may be good candidates for use with a central controller, not every application is the same:

• Applications requiring asynchronous control may work well with distributed control, e.g., feedback loops that need higher frequency sampling than other loops. When different tasks are required at different intervals, distributed control might be the answer.

• Subsystems that have limited interaction with the higher-level system, such as when performing closed-loop control on a valve spool or pump swash plate, may be good candidates for distributed control.

Judging exactly when a controller will be taxed too heavily may be more art than science, but certainly an increasing number of parts will affect machine speed and, ultimately, the operations to be performed by the application. One starting place for phasing out complexity versus simplicity is to ask about the high-level requirements.

Physical size (of the machine) may be another indicator of complexity:

• Putting the embedded system closer to the operation/actuation point quickens response times. There is less need for the central controller to be sorting smaller operations because the embedded system handles that task.

• Putting the embedded system closer to the operation/actuation-point brings down manufacturing and service costs because less dedicated wiring is needed to enable communication with the central controller.

In fact, physical size raises a few more questions.

How large is my application and how much processing power does it need?

A physically large machine requires more dedicated wiring to reach spatially distributed points of operation from the central controller. The cost of wiring multiple routes from machine extremities to the central controller can become expensive. For a spatially large machine with distributed points of operation and control, it may be more cost-effective to process information locally using distributed control.

Servicing a machine with multiple wiring paths may also prove problematic. Tracing service issues across a spatially large machine with distributed wiring can be time-consuming. Plus, distributed control can add to the process power by adding multiple nodes of decision-making capability.

What is the total cost of ownership?

Though smarter components are dropping in price, adding distributed control can initially be more expensive. However, OEM system integrators routinely look at the total cost of ownership for guidance on when to steer toward distributed control.

Total cost of ownership takes into account manufacturing costs and service costs along with the initial purchase cost. Performance is another factor in determining total cost of ownership. If the solution becomes more efficient and/or productive with distributed control when compared with centralized control, that is worth consideration.

Manufacturing and service costs can be reduced with distributed control. Control signals pass on a controller area network (CAN) bus rather than require dedicated wiring. Savings is realized in cost of materials and cost of assembly. Tracing problems and finding fixes is quicker and easier with network systems versus tracing physical wires. Added benefits with distributed control include more uptime and improved productivity and safety, as well as easier service.

How will distributed control prepare our designs for growth?

Simply put, machinery continues to become more complex as time goes on. Handling that increased complexity can look like an investment in dedicated wiring and larger, more powerful central controllers. But distributed control breaks with that complexity mindset by using communication across a CAN bus with easily added embedded systems.

Incorporating more sensors and more hydraulic valves is a simpler matter when all communication is through a bus. Growing expectations about feedback, feedback signals, and fidelity of control are much more easily handled with distributed control. And since most engines over 50 HP are digitized, networking makes even more sense when considering the larger control picture.

Smarter valves allow for more easily designed and easily altered control systems.  Decentralized control is a way of physically breaking complex control problems into smaller control problems, and then solving them closer to the control operation itself.

Chris Schottler is Engineering Manager—Advanced Technology Team at Eaton’s Hydraulic Group. For more information, visit www.eaton.com.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish