EE Student here who recently finished the classical control theory class. I was wondering the process of how the industry or anyone goes from drawing block diagrams to actually implementing in hardware. For example, I'm trying to design a system that keeps a battery from reaching a threshold temperature without having the battery reduce its power output. I'm having trouble visualizing how I will go from a PID controller in theory to the actual hardware system.

  • \$\begingroup\$ How do you normally cool things? \$\endgroup\$
    – Chu
    Jul 28, 2019 at 8:13
  • \$\begingroup\$ Start by showing your block diagram. \$\endgroup\$
    – Andy aka
    Jul 28, 2019 at 11:13
  • \$\begingroup\$ Questions here must be specifically answerable; this is not. Your topic belongs in a discussion forum rather than here. \$\endgroup\$ Jul 28, 2019 at 13:12
  • \$\begingroup\$ That logic is so flawed, 99% of the time there are many ways to solve a problem. Its up to the reader to filter all the inputs and take what they want from it. \$\endgroup\$
    – Sorenp
    Jul 28, 2019 at 13:16

1 Answer 1


I used to have the same feeling when I were introduced to control systems. We always worked on this perfect little DC motor with a nicely made test bench with good sensors etc.

Implementing the hardware is usually, drivers (high/low side), communication protocols, sensors networks, this isn't really the worst thing.

Always research your options https://www.electronicdesign.com/electromechanical/add-simple-temperature-monitoring-battery-management-systems

So my way to go about this -

  1. Identify your sensors and actuators. (Learn all you can about them most important step!!)
  2. Identify your system. (disturbances, integrating influences, unlinearities etc.)
  3. Choose a proper control scheme. (Fuzzy logic, cascaded, MIMO etc.)
  4. Draw a block diagram. (then think about the system as a whole and redraw it 10 times)
  5. Implement and tune accordingly.

That's the quick and dirty, as you gain experience you will start to look at more advanced things, such as the influence of clock jitter, automatic gain scheduleing etc.

  • 1
    \$\begingroup\$ First thing is to list all the functionalities you want, deciding to add one at the end of the process is fatal... \$\endgroup\$
    – Solar Mike
    Jul 28, 2019 at 7:58
  • \$\begingroup\$ There is some good stuff here, so it is unfair to mark this as wrong or not useful, but the design process normally starts with requirements. \$\endgroup\$
    – Mattman944
    Jul 28, 2019 at 13:09
  • \$\begingroup\$ This is why we do not allow broad question on stack exchange, but only questions which can be specifically answered. This question cannot be. \$\endgroup\$ Jul 28, 2019 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.