Hey all, this is an oddity of a request. First, I'm not an electrical engineer; next, I wouldn't know a good circuit if it gave me a lap dance, so...I'm asking the community for help.

I'm writing a blog and would like to include some circuit diagrams; it seems like they would be perfect for visualizing a process. Here's what I'm looking for:

1. 2 Diagrams of different circuits that do exactly the same thing
   1. one circuit is simple, the other is unnecessarily complex
   2. perhaps some old circuit design from the 50s that was updated/simplified recently?
   3. I'm hoping there is some classic teaching example that is commonly used?
2. It would be helpful if the contrast in complexity were visually obvious

The purpose of the comparison is to describe, in simple terms that anyone (including execs) should be able to easily understand, that 2 different processes can yield the same result but one of them is simpler and therefore easier to build, manage, produce, test, etc. while the other requires more components, and therefore costs more, is clearly less efficient, etc.

I thank the community for the help in advance. Happy holidays everyone!

 

Welcome to AAC!

You are writing a blog.

1st question: What is the field or area of application?
2nd question: Who is your target audience?

 

Here is an example of a complex circuit diagram.






This is an example of how it would be presented to managers and non-technical people:

 

One of the biggest transformation events that occurred in my area of expertise, was the creation of the Industrial PLC. Programable Logic Controller.
This transformed Industrial control circuits that housed huge cabinets full of relays and timers in order to control factory processes and assembly Lines to a small PC screen and a controller the size of a shoe box.
In the late 60's, a fellow by the name of Dick Morley answered a call from G. Motors to come up with a solution of trouble shooting assembly line control, the PLC was the result.
So instead of finding a problem by searching through the cabinets, and trouble shooting at the actual machine, much could be done locally at one location by studying the status of Relay Logic on the small screen.
The screen not only displayed the circuit, but the actual status (on/off) of inputs & outputs, i.e. switches and relays.

 

Welcome to AAC!

You are writing a blog.

1st question: What is the field or area of application?
2nd question: Who is your target audience?

1) I'm in cloud computing. The area of application is to reign in some questionable design ideas floating around the blogosphere and provide some context as to why those concepts are questionable. Specifically, we'll be digging into the IEEE Software Engineering standards after setting this baseline; those concepts will include

• Requirements Engineering
• Software Testing
• Application Development
• Application Deployment, etc (pretty wide range)

2) The target audience is primarily technicians that are already working in the cloud but perhaps aren't senior enough to distinguish between good/bad design. As you know, there are many bad design ideas for every one good idea; giving those folks the ability to distinguish between them is one of the primary goals of the blog.

 

Here is an example of a complex circuit diagram.

View attachment 283726




This is an example of how it would be presented to managers and non-technical people:

View attachment 283728

While I love the coloring book nature of the second diagram, I wasn't really looking to represent the same circuit from 2 different views.

Rather a redesign of the same circuit, from the same view (like the first diagram). The hope is that the comparison obviates the 2 different approaches.

 

Engineering design methodology for software design is the same as for hardware design. It is what I call Systems Engineering Design.

It embodies two approaches: Top-Down Design and Bottom-Up implementation.

When a design skips the Top-Down Design approach it is a good indication of poor design.
Too often program development begins with writing code while omitting flowcharting and Top-Down design.
As in all aspects of proper engineering designs, specifications must be laid out at an early stage. Top-Down design leads to modular design, enhanced testing, debugging, reusablity and maintenance.

 

Just a thought. Any engineer can design something complex. A good engineer can design something simple.

 

What about a more complex circuits that offer better efficiency vs a simple circuit that doesn’t? It’s not one dimensional. Describe complexity? Does that mean more complements? In engineering there are always tradeoffs. A complex program that can be written simply is not always a good analogy for circuit design. Example look up the various ways an oscillator can be designed. It doesn’t make one necessarily better than another, it can affect the outcome based on your individual needs for a specific circuit. I can also give examples of an over simplified circuit that’s worse than a more complicated one with more components.

 

Hey all, this is an oddity of a request. First, I'm not an electrical engineer; next, I wouldn't know a good circuit if it gave me a lap dance, so...I'm asking the community for help.

I'm writing a blog and would like to include some circuit diagrams; it seems like they would be perfect for visualizing a process. Here's what I'm looking for:

1. 2 Diagrams of different circuits that do exactly the same thing
   1. one circuit is simple, the other is unnecessarily complex
   2. perhaps some old circuit design from the 50s that was updated/simplified recently?
   3. I'm hoping there is some classic teaching example that is commonly used?
2. It would be helpful if the contrast in complexity were visually obvious

The purpose of the comparison is to describe, in simple terms that anyone (including execs) should be able to easily understand, that 2 different processes can yield the same result but one of them is simpler and therefore easier to build, manage, produce, test, etc. while the other requires more components, and therefore costs more, is clearly less efficient, etc.

I thank the community for the help in advance. Happy holidays everyone!

I think you are going to have to be very careful that whatever example you come up with is actually an apples-to-apples match to the point you are trying to make.

If you look at designs from the 50s, you are going to see a lot of complexity because that was necessary given the parts of the day. For instance, a lot of vacuum tubes and the support circuits needed to run them. Also, a fair degree of complexity would be involved in making circuits work adequately in the presence of the poor tolerances on component values. If that same circuit were redesigned today, there would be none of the complexity associated with all of those tubes. The functions performed by dozens, perhaps hundreds, of tubes would be replaced by a single integrated circuit and a few tight-tolerance components.

But it would be wrong to hold that up as an example of a bad design and a good design.

 

There's only proper design: every component must be justified against the design specification. If a component cannot be justified, it is superfluous. If the design doesn't meet the specification, it is not correct.

 

I'm curious about what might be considered "questionable design ideas". Would it be possible to elaborate further about what comes to your mind in this context?

 

If you look at designs from the 50s, you are going to see a lot of complexity because that was necessary given the parts of the day. For instance, a lot of vacuum tubes and the support circuits needed to run them. Also, a fair degree of complexity would be involved in making circuits work adequately in the presence of the poor tolerances on component values. If that same circuit were redesigned today, there would be none of the complexity associated with all of those tubes. The functions performed by dozens, perhaps hundreds, of tubes would be replaced by a single integrated circuit and a few tight-tolerance components.

A prime example was a TV broadcast station’s sync generator. I once saw one made exclusively of vacuum tubes. The schematic diagram covered something like 12 pages. All hand drawn!
It was housed in an equipment rack the size of a small fridge. Nowadays a single IC does that and several additional functions.

 

I think you will find, just as in computing, the ”simplification” of circuits has mostly been a matter of encapsulation. That is, teh complexity is hidden from the person operating at the circuit level by the consolidation of even more complex circuitry into the magical boxes known as integrated circuits.

Most circuit designers don’t care about the internals of the ICs they use, any more than most developers are concerned with why libraries work. The circuit designer knows the signals that must be provided to the IC, and what will come out. The identity and function of the pins is the most common level of understanding for people working in application of ICs.

Developers use libraries in a similar way. They learn the function calls and what input they need; and the learn what will be returned. To them, potentionally hundreds–or even thousands—of lines of code are boiled done to one call().

Imagine a code listing that, instead of using the function calls simply reproduced the code the call references. A ”simple” program would suddenly be very complex. In fact, it already was, but the complexity was hidden in the encapsulated* code the library represents. The call is only shorthand for all those other lines.

An example from the world of circuits would be the venerable and ubiquitous 555 timer IC. This little 8-pin chip is an amazingly flexible device that can be made to do an impressive array of things with only a few external components, mostly passives.

A typical application for the 555 would be a monostable multivibrator also called a one shot. When the circuit it triggered it changes its output from low to high (or vice versa as needed) for a fixed interval determined by the value of the capacitor and resistor chosen. Using the 555, the very simple circuit looks like this:

[source]
​

The circuit is simple, easy to understand and very useful. But, if we assume the 555 isn’t packaged up, then we have to include its internal circuitry which looks like this:

[source]
​

As you can see, the complexity is hidden in the chip. I think this is the case in computing as well. The modularization of modern development platforms and tools, as well as operating systems for that matter, hide the complexity to the average developer who may never even have looked at the kernel code, the libraries she regularly uses, or the internals of the language used to write the programs.

It’s a matter of of the level at which you choose to observe the process. Surely there have been improvements in techniques and algorithms that allow bumming a few instructions here and there, but if anything, the world of circuits—and software—has become much more complex, the difference being that it is possible to manage the complexity thanks to the tools and components that encapsulate that complexity with a simple (or at least simpler) interface, the complexity is well hidden to those who just need to make things work.
—
* I use encapsulation here figuratively and not in the sense of OO terminology, necessarily. Of course OOP is a very obvious version of what I am talking about.

 

Maybe the concept of "questionable design ideas" needs to be put in a historical context. It could be a terrific design idea for the 1950's, but a terrible idea for the 21st century. I'm not sure if the converse would automatically be true. It further seems like good ideas to an engineering mind can morph into questionable ones for the people charged with installation and maintenance. The whole concept might be a moving target, and I'm less than certain that any systematic approach can quantify, let alone analyze the difference.

 

Thinking about your focus on poor design choices and following the theme above, I would say that many times I encounter poor designs they involve—for no justifiable reason—avoiding the use of the encapsulated complexity and baking in all of the functionality natively, so to speak.

So in software, rather than using well known, written, and maintained libraries a developer chooses to write the same functions in the program itself, and so losing the many person-hours of effort put into writing, polishing, and of course updating the readIy available library.

The same is true in circuits where someone might choose to avoid well known and supported ICs opting to increase the complexity of the BoM (Bill of Materials), PCB (Printed Circuit Board), and circuit itself leading to more error, less functionality, and even more power consumption in many cases.

Choosing the right level of reliance on modules/libraries/ICs is part of a good design. There can be legitimate reasons to avoid any or all of the possible “shortcuts” but those reasons are the exception not the rule. A example is the case of someone avoiding using an MCU (MicroController Unit, e.g.: an “Arduino”*) because they don’t know how to program.

While this may be a legitimate reason in one way, the MCU creates such a different level of capability and flexibility, learning to use them, even very basically, is generally much more sensible than doing circuit gymnastics to avoid them.

So maybe the problem is ironic. Maybe visible complexity (and bad design) are often the product of avoiding the encapsulated complexity that is on offer everywhere.

—
* “Arduino” is a vague appellation that can mean an organization, a development board produced by it, or the development environment produced by it. It usually means “a development board (from any manufacturer) that is compatible with the Arduino IDE. This is a messy and convoluted topic but I wanted to clarify at least a bit.

 

So in software, rather than using well known, written, and maintained libraries a developer chooses to write the same functions...

Programmers, IMHO, are generally incompetent.

I'd never trust my products to a 3rd party library.

 

How do you define a good circuit design?
It does not depend on the simplicity or complexity of the circuit. It depends on whether the circuit meets the required specification. That will include meeting the electrical requirements and working reliably in the specified environment. It also depends on the reproduceability and testability of the circuit.
It will be very difficult to convince technicians that one circuit is better than another without including all of the above parameters. The only parameter I can imagine that would discriminate between simple and complex circuits that meet the same requirements would be production cost but there could be cases where complex circuits using inexpensive components are cheaper to produce than simple circuits that use expensive components.

 

Take the following two design activities:

1. Circuit design and layout
2. Embedded software development

Most of us are familiar with one or mor convenient methods of describing, implementing, and documenting our intentions and the work product.

The main problem I see between these two activities is that with circuit design there is the "D" size drawing, that with appropriate levels of abstraction, allows you to view the entire thing in one glance. So far as I know, there is not any commonly used and maintained method of seeing an embedded software project in one glance.

Before you object and mention "flowcharts" and their progeny, I have to tell you that in a career that spanned half a century I NEVER encountered a set of flow charts that wasn't created and thrown in a drawer. The same cannot be said for a schematic drawing of a circuit that was to be rendered in copper and fiberglass.

The only apparent difference is that in case 1 we have a graphical representation and in case 2 it is textual. The same could be said of the law which is entirely textual. Has anybody ever seen a law that you could get the sense of in a single glance?

 

Take the following two design activities:

1. Circuit design and layout
2. Embedded software development

Most of us are familiar with one or mor convenient methods of describing, implementing, and documenting our intentions and the work product.

The main problem I see between these two activities is that with circuit design there is the "D" size drawing, that with appropriate levels of abstraction, allows you to view the entire thing in one glance. So far as I know, there is not any commonly used and maintained method of seeing an embedded software project in one glance.

Before you object and mention "flowcharts" and their progeny, I have to tell you that in a career that spanned half a century I NEVER encountered a set of flow charts that wasn't created and thrown in a drawer. The same cannot be said for a schematic drawing of a circuit that was to be rendered in copper and fiberglass.

The only apparent difference is that in case 1 we have a graphical representation and in case 2 it is textual. The same could be said of the law which is entirely textual. Has anybody ever seen a law that you could get the sense of in a single glance?

Both are handled the same way -- by judicious use of abstraction.

Consider a program that has the following line of code in it:

y = printf("%0.3f\n", Vf - Vi*(1 - exp(-t/tau)));

There is a LOT of code that makes up both that exp() call and the printf() call. But that is all abstracted away.

The same is true for a line that might look like:

noise_rms = AnalyzeNoise(GetDataFromSensor(sensor[currentSensor], DATABUFFERSIZE));

Each of those functions might constitute hundreds or thousands of lines of code, but at a sufficiently high level, they can be abstracted to just a call to them. The sensor array may be an array of structures having dozens of fields, but that detail is unimportant at this level of abstraction, so it is left hidden.

Just as a well-structured electronic design can be captured at a high level on a single sheet of paper, so too can a well-structured program. And, in both cases, detail is hidden in the process. The rule of thumb that I use when developing code is that any function should be readily viewable on a single screen, from the main() function all the way down to the lowest support function (and most are kept to just a few lines of code, typically six to ten). There is a cost for this in terms, of course, generally in memory requirements and speed of execution, but if the performance is acceptable, then the cost is worth it. The same is true, though usually to a lesser degree, with modular electronic designs that lend themselves to ease of abstraction.