Bench Talk

When designing large, complex products the value of the principles and practices systems engineering is quite apparent. But what about when designing custom homebrewed electronics, are systems engineering practices valuable or overkill?

Let’s first consider what is systems engineering. According to INCOSE, systems engineering is defined as “ an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.”1 In a nutshell, systems engineering is a disciplined approach to design that helps one move through various phases including requirements gathering, functional analysis, physical allocation, integration of components and finally various levels of testing. This process is graphically represented in what is affectionately known as the “Systems Engineering Vee Diagram”.

Obviously when developing homebrewed electronics following the entire systems engineering process is, well, a bit much. So what aspects are valuable? Let’s consider the following. Let’s imagine we’ve been hired to build a custom solution and the top-level requirement we have received from our customer is they want a way to be alerted when someone enters a room in their house. The requirement is vague, so how do we move forward? At this point, if you are like me, your mind immediately jumps to thinking of all the electronics components and software we’re going to need. But we need to resist that urge. Instead spend some upfront legwork fleshing out the requirements and identifying the functionality, not the components, needed for the project. So let’s brainstorm the functionality we want include. Then if you’re like me we will to graphically notate the requirements in top level Functional Block Diagram (see Figure 1):

 1. Detect when someone attempts to enter a room.

 2. Alert trespasser that they have been detected.

 3. Allow user to arm and disarm the system.

 4. Remotely notify user that an entry attempt has been detected.

Figure 1: Functional Block Diagram

Another important point while identifying needed functionality is to be thinking about how you will test that functionality in the end. How will you validate that we have met the customer’s requirements? Once we have a firm grasp on the functionality needed to meet our customers requirements then we can identify the hardware and software components and allocate the various functions accordingly. As part of this process I will make note of electrical parameters I should expect at various test points in my circuit to make troubleshooting easier. For any circuits I design to provide inputs to a microcontroller or control circuitry for actuators I will simulate the circuit first to provide some insight on what I should expect to see when I build the first prototype. Same thing with software I will try and my educated guesses and document various functions I will need to code and expected variables that will need to be passed around. I also consider and document critical points where I will want to potentially add debug messages via a serial terminal. This type of upfront planning really pays off in the long run because let’s be honest, a new design rarely works on the first try.

So there is a nutshell how systems engineering practices can support your homebrew electronics projects. If nothing else, I hope you see the value in this process after you try to reconstruct an earlier project. Before I got into the habit of rigorously documenting my projects I would spend as much time re-engineering as I had done during the original build. Now it’s just a matter of reconnecting components and re-uploading the firmware.

_________________________________________________________________________________________________

1 https://www.incose.org/practice/whatissystemseng.aspx