Systems Engineering
Andrew Schaumberg
Department of Software Engineering
University of Wisconsin - Platteville
Platteville, Wisconsin53818
Abstract
Often in a system, the hardware is abstracted away by layers of software. This allows for reuse of both high and low level software, which in turn saves time and money. After successfully implementing abstraction-based solutions, it is tempting to use this approach on nearly every system we design. While the abstractions should allow the hardware to be developed independently from the software, these same abstractions could end up making the system less economical to manufacture, build, and run due to abstraction-induced bloating. Sometimes it holds true that less is more. This paper will explore the engineering of a system which can either be kept optimally small by considering both the hardware and software together as a whole, or could be bloated with an incredible amount of features and use multiple layers of abstraction. We will emphasize the importance of letting the system requirements dictate which approach should be taken, or perhaps a combination of these two said extremes, when engineering such a system.
Introduction
While developing my project, ConfiGuitar [conf], I have encountered a significant number of obstacles, most of which were caused by hardware limitations. As more and more features were added to the guitar's list of requirements, progressively more sophisticated hardware was required. What started as a project involving double-pole, double-throw switches has evolved into a modern piece of machinery which includes, but is certainly not limited to, a robust microcontroller, ethernet controller, and LCD. It is also interesting that the strategy of understanding software as various "layers" can be used equally well when considering hardware, e.g. the LCD is controlled by the microcontroller, which in turn interfaces with some other chips, which themselves take input from debounced switches. The software itself can be seen as further "layers" on top of the physical architecture, which has convinced me that to optimally design a system, both the hardware and the software should be understood as a whole rather than two distinct yet interoperable parts. The difference is subtle, but the results can be significant, especially when engineering a system which must be both efficient, expandable, and mass produced, as is the case with ConfiGuitar. I will try to share my limited experience in system design and systems engineering in this paper, trying to generalize this to software engineering topics where appropriate.
Case Study: Guitar
The guitar is a good system to consider in systems engineering for several reasons:
- It is familiar to nearly everyone.
- Its architecture has been reengineered several times.
- There are current architectures which exhibit particular promise in further reengineering.
For example, everyone knows what a standard electric guitar should do, roughly how it works, and a few other people have modified the electric guitar to perform differently. Indeed, the electric guitar is a great platform to hack as it includes very few parts, all of which are easily swappable. We'll explore the guitar in depth in this paper as an example of systems engineering at work. Let's consider the guitar from its acoustic origins all the way to its experimental electronic cousins.
Background and Requirements Gathering
The first guitars were made well before electricity became available. They had to be rugged, transportable, maintainable, economical to build, and they had to play well with other instruments, which required ample volume and tonal range. These guitars were usually built of sturdy wood and had a resonant body cavity to amplify the volume of the strings. Early lutes ( the parent of the guitar ) [lute] were extremely rugged because the resonant cavity was a hemisphere, but later guitars sacrificed some ruggedness for sound quality by using the familiar boxy resonant cavity.
This design served musicians well for hundreds of years, not being changed significantly until Les Paul invented the electric guitar [les paul]. Using magnetic pickups to transduce the motion of the strings to an electric signal was revolutionary and simple. The electric guitar hasn't been significantly changed over the years either, with mostly minor modifications to the architecture, including phase controls, changes in pickup construction, and added tone/volume controls.
In the end, what our acoustic guitar gives us is an extremely low maintenance instrument that is easy to play and transport, just as the requirements dictated. However, what if our acoustic guitar users want to control the guitar's output signal directly instead of simply trusting the signal to be shaped and amplified by our provided resonant chamber? The acoustic guitar wasn't designed with this in mind. We have two options: we could add a microphone to the existing acoustic guitar, or we can refactor the acoustic guitar's architecture, just as Les Paul did.
To Reengineer or Not to Reengineer
While there are some exotic options for controlling the guitar's output, the most reasonable seems to be transducing the guitar's mechanical energy into electrical energy, then manipulating the electrical signal, and finally rebuilding sound based on the resulting electrical signal. A microphone is a cheap add-on to our acoustic platform and will give us the electrical impulses we would like, but there are some things to consider here, most notably transduction quality and cost. Mics are notoriously bad at transducing an acoustic guitar's natural "warm" tones and feeling. Keep in mind also that including a microphone with our guitar obviously will not make it cheaper. However, mics are widely available and companies have already thoroughly tested them ( or at least should have ) before they put them on the market, so you can rest assured that your mic will be easy to install and should serve you well for many years.
In contrast, by totally rebuilding the architecture from scratch and reincluding only the features we find desirable, we can do ourselves a lot of favors. If we choose to do this and build an electric guitar, it is possible to implement a guitar that transduces audio signal well using pickups and is actually cheaper to build. We have no need for a resonant cavity anymore ( we'll be relying on an electrical, not mechanical, system now ), and eliminating this cavity greatly simplifies our design and cost of materials/manufacturing. Electric guitars are very popular now because of their simplicity and robustness, but I have encountered some startling pitfalls in the electric guitar designs typically sold to consumers. Not surprisingly, guitar manufacturers try to make electric guitars as cheaply as possible. The extremes that they go to accomplish this is amazing to me, and I'll list a few examples here [nuts].
Component quality
Not surprisingly, you'll find some of the cheapest components in your guitar if you choose to open it up. Even wires are avoided in favor of bending contacts around and doing some creative soldering. Also, pickups are usually not "potted," which means that the pickups have not been dipped and sealed in wax. Potting improves tonal richness and response significantly. Wax is cheap.
Ground loops
Having these really wrecks the quality of the electric signal and is usually a product of the manufacturer soldering directly on the bodies of the tone and volume control potentiometers, which then provide multiple unique paths to ground for the signal to travel. The guitar is much more noisy as a result.
Shielding
A total lack of shielding built into an electric guitar makes it highly susceptible to ambient noise. This ambient 60Hz hum is picked up, in my experience, most readily from florescent lights, which I found to be all too common in the basements and garages I had played in. Oddly enough, some manufacturers have stated that this noise ( they call it "hum," which sounds better ) is part of an authentic electric guitar's sound. This is nonsense. Guitar bodies should be shielded with conductive paint at least, but I have used tin foil and white glue in the past with good results. Another option would be copper tape.
Electrical shock
Musicians have died due to a combination of poor electrical work done in the club they are playing at and poor guitar design. In these sad cases, the electrical surge usually travels through the mic that the performer is singing into, then through the performers neck and torso, out his hand, through the guitar strings, and into the amplifier. This shock can be greatly minimized with a single capacitor. I have never seen such an isolation capacitor installed in a stock electric guitar.
"Well gosh," you might say, "I had no idea!" Most folks don't, but now that we do, we'll be motivated to make guitars better than them. If we take our time with designing our electric guitar and don't skimp on the parts we use, we will certainly have a beautiful sounding machine that will last a lifetime and have cost us about the same as an acoustic. So what have we just covered here?
Actually, it should sound a lot like software reengineering! We could do a simple hack ( microphone ) which would be cheap and give us some of the functionality that we want, or we could totally refactor the architecture from the ground up, which requires more time and resources up front to develop, but if we were a company and produced cheap electric guitars by the truck-load, we would be rich! Rest assured, they are, and this is one of the great potential benefits from refactoring an architecture.
So you build your own guitar, taking time to properly shield it and pot the controls, and all is good. That is, until one day. Yes, on this one fateful day you realize that your guitar's requirements have changed yet again. Before chastising yourself as a bad client, you explore your innermost desires for this new guitar, and you have both a problem, and an idea.
A Guitar with Configurations
You're bored. You want a new combination of pickups to use. You could rip open your guitar's body again and remap the electrical connections, but that does not satisfy you. The problem lies in the little switch that has become nearly ubiquitous to the electric guitar. This five or six position switch allows you to select which pickups you'd like to use. The problem is, each of your four pickups can be wired in phase, out of phase, or in a "hum-canceling" configuration. They can also be put into series or parallel with one another. And of course, you want to use any combination of your coils. You demand flexibility. This existing switch is clearly insufficient. You nobly stare into the sunset with your new conviction and tell yourself that you are going to introduce something totally new to the electric guitar. And then it hits you. You have no idea how you're going to make this actually work. After all, you have a lot of combinations to account for, and this will have to be cheap and easy because you also happen to be a poor college student with a never-ending list of projects to do, courtesy your loving professors. Okay folks, let's get started!
Electromechanical
You still want to easily change the pickup configuration of your guitar as you play, and because you know you're going to want a lot of different options, you decide that using rotary switches and larger toggle switches is a good idea. Then you write up some schematics and realize that this is more tricky than you've thought. The fact is, while rotaries are good for selecting multiple paths for electrical current to go, they are not particularly good for toggling coil phasing or changing how the coils are wired relative to each other ( series/parallel ). You tried using special toggles for these applications, but after trying to hunt down components like a 7-pole, 16-throw rotary switch from a specialty switch store online, you wisely decide you need more than just switches.
Solid-state
You see that the pure electromechanical approach is not only costly ( those fancy switches cost a lot of money! ) but nearly impossible to implement and would be even worse to fix if it broke. You decide you're going to need some cheap solid-state devices to help you manage this beastly project. It is up to you to choose to use either BJTs or MOSFETs, but I would recommend MOSFETs because, in my experience, they are a bit more intuitive to use because they are voltage-controlled, as opposed to the current-controlled BJTs. Picking a solid-state device to suit your taste in electronics, you implement a backing solid-state switching network for your electromechanical devices. You find you have gained easy control over every aspect of what you wanted! Coil phasing, coil selection, and series/parallel switching are all no problem to achieve! What you've run into now, however, is power. Sure enough, these solid-state devices need batteries at least to function, and this bothers you. The standard electric guitar doesn't need batteries to run as it is an entirely passive system. So you stop, think, accept the fact that you are going to need batteries, and then you have another great idea! You could simplify your solid-state network by introducing a few low-cost and highly efficient chips from your favorite electronics distributor!
IC
Sure enough, these integrated circuits on a chip are the hottest thing since sliced bread! You can relegate all the logic to the ICs now, simplifying your architecture yet again. Your electromechanical serves as simple input, your solid-state deals only with directly manipulating the pickup configurations, and the ICs glue the whole system together, ensuring the input at the electromechanical is translated into signals that the solid-state can understand. Awesome! You get so excited that you add memory to the system with an SRAM chip! Now you can save your favorite configurations to memory and recall them with a touch of a button! Congratulations, my friend. If you've gotten this far, you've just made your very own ConfiGuitar! You have a new problem, however. Now that you have so much control, how do you display the current state of the guitar? There are so many possible configurations available, not to mention that some are being stored in memory now, that you decide a large bank of LEDs is the easiest and cheapest route to go. You implement this and realize something terrible is happening. Your batteries are dying very, very quickly. Even the low-power LEDs you're using consume 10mA each, and working with 5V adds up to a lot of power consumption. This is the problem the original ConfiGuitar ran into as well. So what can we do?
MCU
We can add more parts, of course! MCU stands for MicroController Unit, and these little chips have a whole lot of power in a tiny package. They are both programmable and feature-rich ( onboard RAM, ROM, ADC, UART, and [serial and/or parallel] I/O). Much of the logic that we previously did with ICs can now be relegated to a simple program! "Hold on a second," you say, "don't these MCUs consume a lot of power? They have so many features..." Good observation, but they do allow us a lot of options, most importantly the ability to easily drive an LCD. A liquid crystal display consumes very little power compared to our 30 LED bank, and this is where we'll come out ahead. We can do ourselves more favors by using an MCU with power-down states so we can have it run idle with very little power consumption. By choosing our MCU wisely, we can also eliminate the need for a vast majority of our ICs. "Sounds great," you add, "but you haven't mentioned what I can do by programming this MCU." We'll talk more later about wringing the most capability out of your MCU by programming it.
SoC
Still think our design takes too many chips? You still have more options in the form of a System on a Chip. Yes sir, you could use a FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit) to put nearly our entire system on a single device! FPGAs are programmable, so if we need to change our system on a chip, we can simply reprogram it to include to new hardware! ASICs are especially nice because they are much more efficient than FPGAs, though ASICs are not programmable. Both ASIC and FPGA designs can be described in hardware description languages, like VHDL [VHDL]. If you are a software engineer like me, you should find it very comforting to know you can essentially compile hardware out of software. VHDL, as a language, is somewhat similar to C and Pascal. Let's review what we just did with our hardware platform.
We actually reengineered our platform over several iterations just then. Take another look at our progress. What you should notice is that we rebuilt our guitar-controlling-machine from the ground up in several distinct "layers". This "layering" approach should be all too familiar to your software engineers out there, especially the ones with kernel experience. Ah, the comforting parallels between hardware and software. Should one really shun one while embracing the other? I think not, and the little system we just developed should be a good example of what we can achieve when we conceive a system with no prejudice in mind. If we design our hardware with the same requirements that the software has in mind, it follows that our system should be extremely easy to develop. Want to sample your guitar's signal and do something in your program based on what that signal is? No problem, just have your MCU's ADC channels connected to your guitar's pickups and you're all set! What is key to our project here is having good taste in our MCU. We have to make sure to buy one with just the features we want and may like to have in the future. Granted, in most cases we do not have the luxury of developing the hardware and software alongside one another, but why pass up the opportunity? But I'm digressing, let's get on with it and talk about integrating some software!