There’s no doubt about it: system engineering seems to be a hot issue over the course of the last year. As I’ve dug deeper and deeper into this discipline, I’ve been a bit surprised at some of the specialization I uncovered. I mean, isn’t system engineering all the same? No. All system engineering is not the same. In fact, specialized flavors of system design can vary dramatically from one another.

In this post, I’ll share some of the different flavors of system design that I’ve found, their similaries and differences and why it matters.

Specialized System Design: The Different Flavors

Mechanical Systems Design

In this flavor of system design, you have a complex mechanical system that needs to be broken down into sub-systems. There are interfaces. You have all sorts of artifacts that describe the logical behavior of the system, like those found in top-down design practices. You also have functional models that can be used for analysis but don’t accurately represent the detailed design. You often need to explore many different architectures here before you settle on the best one to take forward.

Electrical Systems Design

In this variation on system design, which focuses on distributed electrical systems, you build up an architecture by selecting the major electronic items you plan to use. That includes the embedded systems, busses, antennas, sensors and other items that exist at the end of cables and wires. You assess the viability of those architectures by assigning functions to different resources and checking constraints. An example would be to assign some function to an embedded system and seeing how much processing power has been consumed. It could also be assigning certain signals and seeing how much network bandwidth is left.

Electronic Systems Design

This flavor is similar to electrical systems design, but its scope is within the context of multi-board systems. Here, you select the major electronic components that will be a part of your multi-board system or other embedded systems. That could be processors, memory, imaging components, and the like. You assign functions to those various components and check your constraints, like weight, cost, and power. You create different architectures and compare their performance, selecting the one that best fits requirements.

The Similarities and Differences

In all of these variations on system design, RFLP (Requirements, Functions, Logic, and Physical) acts as the backbone. In each, you define and break down requirements until they are actionable. Then you define functions that fulfill those requirements.

Where each of these processes diverges, however, is in the logical and physical manifestations of the systems. In each case, these systems need a different logical representation. The same holds true of the physical aspect.

Last, but not least, the way you assess architectures in each of these processes varies dramatically.

Why Does This Matter?

Because how you deploy these kinds of processes will differ dramatically.

The team you need to develop an electrical system will be very different from the team that develops a mechanical system. Sure, the R and F is the same. But having the right skillset is critical when defining the L and P for those two different systems. Just as importantly, you will need very different technologies to assess different candidates as well.

That’s my take folks. What’s yours? I’m interested to hear what you think. Post your comments below.