Three Workspaces, Countless Projects

Clive “Max” Maxfield, who received his BSc in Control Engineering from Sheffield Hallam University in England in 1980, began his career designing CPUs for mainframe computers. But he has branched out far beyond that, becoming a prolific writer of engineering books, an EE Times editor, a blogger, and a designer of “interesting stuff,” from silicon chips to Steampunk “Display-O-Meters,” according to his website.

Max, who now lives in Huntsville, AL, recently shared with Circuit Cellar photos and descriptions of some of his ongoing projects and creative workspaces:

I would say that I have three personal workspaces. But before we talk about my workspaces, it might be appropriate to first mention two of my several projects, which vary from artistic to technological.

This is the future home of the Prognostication Engine.

This is the future home of the Prognostication Engine.

One of my projects that is currently in full swing is my Pedagogical and Phantasmagorical Inamorata Prognostication Engine. What do you mean “What’s that when it’s at home?” Isn’t it obvious?

Pedagogical = Educational
Phantasmagorical = It’s pretty darned fantastic
Inamorata = The woman with whom one is in love
Prognostication = Predicting the future
Engine = Machine

The Prognostication Engine is intended to help me predict my wife’s mood. Will the radiance of her smile fall upon me when I return home from work in the evening?

My Prognostication Engine is going to be housed in a beautiful wooden radio cabinet circa 1929. This is going to feature two brass control panels, both of which are going to be festooned with antique knobs and buttons and switches and analog meters (the ones with the black Bakelite bezels). I’m aiming at a Steampunk “look-and-feel” that would not look out of place in a Victorian setting.

One of the tricks I use when working on this type of project is to first create to-scale Visio drawings of all of the knobs, switches, meter, and so forth, and then I create a full-sized card-and-paper mockup as shown below. This makes it much easier to move things around and experiment with different placements so as to decide on the final layout.

The paper and card mockup of the Prognostication Engine's upper and low control panels

The paper and card mockup of the Prognostication Engine’s upper and low control panels

Observe the two small pink dots at the top and bottom of each of the vertically-oriented switches and on either side of the horizontally oriented switches and buttons; also the 16 pink dots around each of the five potentiometers. These are going to be faux mother-of-pearl dots, behind which will be tri-colored LEDs implemented using Adafruit’s individual Flora NeoPixels and NeoPixel Rings, respectively.

Everything is going to be controlled using an Arduino Mega microcontroller development board. Speaking of control, the potentiometers are going to be motorized, so that if an unauthorized operator tries to modify any of the settings, the other potentiometers will automatically change to compensate (later they will all surreptitiously return to their original settings).

Now observe the three black momentary push-buttons located on the lower panel, just under the modestly sized red button (do not press the red button). These equate to gifts of chocolates and flowers and hugs. Judicious use of these buttons increases the chances of happy times; overusing them, however, may trigger the “suspicion of wrongdoing” algorithm. In reality, there’s far too much “stuff” to go into here. Suffice it to say that the large meter in the top right-hand corner of the upper panel will reflect the full range of female emotion, from “Extremely Disgruntled” to “Fully Gruntled” (LOL).

Max has another project, dubbed “BADASS Display,” which was inspired by an item he saw in an electronics boutique-type store—a “really cool 9″ tall, cylindrical Bluetooth loudspeaker, whose outer surface was covered with tri-colored LEDs implementing a sort of spectrum analyzer display.”

While Max wasn’t interested in the $199.95 price, the “seed had been sown,” he says.

Thus was conceived my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display. First of all, I took a look around YouTube to get some ideas. It turns out that there are many different ways to present spectrographic data. For example, check out Gavin Curtis’ “My Big Blue 32 Band Audio Spectrum Analyzer Lady Gaga,”  RGB Styles’s “Coffee Table,” and Techmoan’s “Giant LED Graphic Music Display (DJ Spectrum Analyzer).”

I decided that the first incarnation of my display would boast a 16 x 16 array of tri-colored LEDs. I decided to use Adafruit’s NeoPixel Strips. Once again, I started by creating a cardboard and paper mockup as shown below.

Cardboard and paper mockup of the BADASS Display

Cardboard and paper mockup of the BADASS Display

The NeoPixel strips I’m using have 30 pixels per meter. I’m mounting these vertically, which means the vertical separation between adjacent pixels is 33.33 mm. To provide some visual interest, I decided to make the horizontal spacing between columns 50 mm, which is 1.5 times the vertical spacing.

In the real version, the cardboard will be replaced by plywood stained to look like expensive old wood. Meanwhile, the main display panel and the smaller control panel will be formed from hardboard painted to look like antique brass. In front of each pixel will be a 1″-diameter brass bezel accompanied by a 1/2″-diameter clear Fresnel lens in the center. The hardboard panels are going to be attached to the plywood panel using brass acorn nuts. Once again, the finished unit is intended to have a Steampunk look and feel.

I’m planning on using an Arduino Mega microcontroller development board to drive the display itself. This will be accompanied by a chipKIT Max32 microcontroller board that will be used to process the stereo audio stream and extract the spectrum data.

Max’s three project work areas include his office, his kitchen table, and his garage:

I would say that my first personal workspace is the Pleasure Dome (my office). Why do I think of this as a personal workspace? Theoretically I work out of a home office. In reality, however, I prefer to rent a room in a building belonging to an engineering company called MaxVision (no relation).

When you cross the office threshold, you enter a small corner of “Max’s World” (where the colors are brighter, the butterflies are bigger, the birds sing sweeter, and the beer is plentiful and cold). One of the walls is lined with wooden bookshelves containing an eclectic mix of science books, technical books, comics, and science fiction and fantasy books and graphic novels.

Welcome to the Pleasure Dome (Max's office)

Welcome to the Pleasure Dome (Max’s office)

My office is also the repository for all of the antique knobs and switches and analog meters and large vacuum tubes and such that I collect on my travels for use in my projects. Also, I can store (and present) larger objects in the bay outside my office.

My second personal workspace is the kitchen table in the breakfast nook at our home. This is where I tend to implement the electronics portions of my projects. At the far end of the table in the image below we see the jig I constructed to hold the two brass control panels for my Inamorata Prognostication Engine project. On the floor in the right-hand side of the image is the tool box that contains my electronics tools including screwdrivers, snip, and suchlike. It also contains my test equipment in the form of a cheap-and-cheerful multimeter from Amazon, along with an iPad-based oscilloscope and an iPad-based logic analyzer, both from Oscium.

Max's kitchen table

Max’s kitchen table

Observe the plastic storage box on the nearside of the table. I have a separate storage box for each of my projects. Anything associated with a project that’s currently under construction is stored in that project’s box, including any notes I’ve made, any electronic components and their datasheets, and any mechanical parts such as nuts and bolts.

I tend to gather everything associated with a particular function or sub-unit together into smaller boxes or plastic Ziploc bags. In the case of my motorized potentiometers, for example, I have the potentiometers along with the appropriate nuts, washers, antique knobs and suchlike all gathered together. I cannot tell you how much time and frustration a bit of organization like this saves you in the long run. It also make it much easier to pack everything up when my wife, Gina, informs me that she needs the table cleared.

Below we see another view of the test jig I constructed to hold the two brass panels for the Prognostication Engine. Creating this jig only took an hour or so, but it makes life so much easier with regard to assembling the electronics and accessing everything while I’m in the prototyping and software experimentation phase of the project.

The test jig for the Prognostication Engine on the kitchen table

The test jig for the Prognostication Engine on the kitchen table

Max’s third personal workspace is his garage. When his family’s three vehicles are parked inside, his projects are packed away in a corner, including tools and tiles for a mosaic he is creating that will feature ceramic tiles fired in his recently purchased kiln.

Everything tucked away

Everything tucked away

The shelves covered in plastic sheet to the right are where I place my freshly-rolled clay tiles to gradually dry without cracking. The low-down rolling cabinet in the foreground contains all of my handheld ceramic equipment (shapers and scrapers and rolling pins whatnot) along with general protective gear like face masks and safety goggles. Each of the plastic boxes on top of this cabinet is associated with a currently in-progress project. Behind this cabinet is a red rolling tool cabinet, which contains any smaller power tools, clamps, screwdrivers, wrenches and spanners, and also my soldering station and magnifying lens with helping hands and suchlike. To the right of that tool cabinet is a door (not visible in this picture) to a built-in closet, where I keep my larger power tools such as a diamond saw, desktop grinder, router, and so forth.

On the weekends, Max’s garage space opens up as his stepson drives out in his truck and Max’s wife leaves for her real estate agent’s job. “As soon as she has left, I leap into action,” Max says. “I roll out my tool boxes, set up a folding table and chair, and start work on whatever it is I’m currently working on.”

Another little corner of Max's garage work area

Another little corner of Max’s garage work area

As he works on projects in his garage, Max says he is “happily listening to stuff like Led Zeppelin, Genesis, Pink Floyd, Yes, Supertramp, Gentle Giant, The Moody Blues…”

The image below shows a close-up of the current state-of-play with regard to my BADASS Display. A week ago, I routed out the areas in the big plywood panel that will accommodate the hardboard display and control panels. In this image, I’m poised to mark out the hardboard panels and start drilling the mounting holes along with the 256 holes for the tri-state LEDs.

The BADASS Display

The BADASS Display

What can I say? Working on my hobby projects is a great way to wind down after a hard day at work, and being in any of my three personal workspaces makes me happy.

Max poised to give a presentation at the EELive! Conference in San Jose, CA, earlier this year

Max poised to give a presentation at the EELive! Conference in San Jose, CA, earlier this year

Editor’s Note: To find out more about Clive “Max” Maxfield, read his 2013 interview in Circuit Cellar. You can follow Max on Twitter @MaxMaxfield.

Q&A: Robotics Mentor and Champion

Peter Matteson, a Senior Project Engineer at Pratt & Whitney in East Hartford, CT, has a passion for robotics. We recently discussed how he became involved with mentoring a high school robotics team, the types of robots the team designs, and the team’s success.—Nan Price, Associate Editor

 

NAN: You mentor a FIRST (For Inspiration and Recognition of Science and Technology) robotics team for a local high school. How did you become involved?

Peter Matteson

Peter Matteson

PETER: I became involved in FIRST in late 2002 when one of my fraternity brothers who I worked with at the time mentioned that FIRST was looking for new mentors to help the team the company sponsored. I was working at what was then known as UTC Power (sold off to ClearEdge Power Systems last year) and the company had sponsored Team 177 Bobcat Robotics since 1995.

After my first year mentoring the kids and experiencing the competition, I got hooked. I loved the competition and strategy of solving a new game each year and designing and building a robot. I enjoyed working with the kids, teaching them how to design and build mechanisms and strategize the games.

The FIRST team’s 2010 robot is shown.

The FIRST team’s 2010 robot is shown.

A robot’s articulating drive train is tested  on an obstacle (bump) at the 2010 competition.

A robot’s articulating drive train is tested on an obstacle (bump) at the 2010 competition.

NAN: What types of robots has your team built?

A temporary control board was used to test the drive base at the 2010 competition.

A temporary control board was used to test the drive base at the 2010 competition.

PETER: Every robot we make is purposely built for a specific game the year we build it. The robots have varied from arm robots with a 15’ reach to catapults that launch a 40” diameter ball, to Frisbee throwers, to Nerf ball shooters.

They have varied in drive train from 4 × 4 to 6 × 6 to articulating 8 × 8. Their speeds have varied from 6 to 16 fps.

NAN: What types of products do you use to build the robots? Do you have any favorites?

PETER: We use a variant of the Texas Instruments (TI) cRIO electronics kit for the controller, as is required per the FIRST competition rules. The motors and motor controllers we use are also mandated to a few choices. We prefer VEX Robotics VEXPro Victors, but we also design with the TI Jaguar motor controllers. For the last few years, we used a SparkFun CMUcam webcam for the vision system. We build with Grayhill encoders, various inexpensive limit switches, and gyro chips.

The team designed a prototype minibot.

The team designed a prototype minibot.

For pneumatics we utilize compressors from Thomas and VIAIR. Our cylinders are primarily from Bimba, but we also use Parker and SMC. For valves we use SMC and Festo. We usually design with clipart plastic or stainless accumulator tanks. Our gears and transmissions come from AndyMark, VEX Robotics’s VEXPro, and BaneBots.

The AndyMark shifter transmissions were a mainstay of ours until last year when we tried the VEXPro transmissions for the first time. Over the years, we have utilized many of the planetary transmissions from AndyMark, VEX Robotics, and BaneBots. We have had good experience with all the manufacturers. BaneBots had a shaky start, but it has vastly improved its products.

We have many other odds and ends we’ve discovered over the years for specific needs of the games. Those are a little harder to describe because they tend to be very specific, but urethane belting is useful in many ways.

NAN: Has your team won any competitions?

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

PETER: My team is considered one of the most successful in FIRST. We have won four regional-level competitions. We have always shined at the competition’s championship level when the 400 teams from the nine-plus countries that qualify vie for the championship.

In my years on the team, we have won the championship twice (2007 and 2010), been the championship finalist once (2011), won our division, made the final four a total of six times (2006–2011), and were division finalists in 2004.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

Team 177 was the only team to make the final four more than three years in a row, setting the bar at six consecutive trips. It was also the only team to make seven trips to the final four, including in 2001.

NAN: What is your current occupation?

PETER: I am a Senior Project Engineer at Pratt & Whitney. I oversee and direct a team of engineers designing components for commercial aircraft propulsion systems.

NAN: How and when did you become interested in robotics?

PETER: I have been interested in robotics for as long as I can remember. The tipping point was probably when I took an industrial robotics course in college. That was when I really developed a curiosity about what I could do with robots.

The industrial robots course started with basic programming robots for tasks. We had a welding robot we taught the weld path and it determined on its own how to get between points.

We also worked with programming a robot to install light bulbs and then determine if the bulbs were working properly.

In addition to practical labs such as those, we also had to design the optimal robot for painting a car and figure out how to program it. We basically had to come up with a proposal for how to design and build the robot from scratch.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

NAN: What advice do you have for engineers or students who are designing robots or robotic systems?

PETER: My advice is to clearly set your requirements at the beginning of the project and then do some research into how other people have accomplished them. Use that inspiration as a stepping-off point. From there, you need to build a prototype. I like to use wood, cardboard, and other materials to build prototypes. After this you can iterate to improve your design until it performs exactly as expected.

A Quiet Place for Soldering and Software Design

Senior software engineer Carlo Tauraso, of Trieste, Italy, has designed his home workspace to be “a distraction-free area where tools, manuals, and computer are at your fingertips.”

Tauraso, who wrote his first Assembler code in the 1980s for the Sinclair Research ZX Spectrum PC, now works on developing firmware for network devices and microinterfaces for a variety of European companies. Several of his articles and programming courses have been published in Italy, France, Spain, and the US. Three of his articles have appeared in Circuit Cellar since 2008.

Photo 1: This workstation is neatly divided into a soldering/assembling area on the left and developing/programming area on the right.

Photo 1: This workstation is neatly divided into a soldering/assembling area on the left and a developing/programming area on the right.

Tauraso keeps an orderly and, most importantly, quiet work area that helps him stay focused on his designs.

This is my “magic” designer workspace. It’s not simple to make an environment that’s perfectly suited to you. When I work and study I need silence.

I am a software engineer, so during designing I always divide the work into two main parts: the analysis and the implementation. I decided, therefore, to separate my workspace into two areas: the developing/programming area on the right and the soldering/assembling area on the left (see Photo 1). When I do one or the other activity, I move physically in one of the two areas of the table. Assembling and soldering are manual activities that relax me. On the other hand, programming often is a rather complex activity that requires a lot more concentration.

Photo 2: The marble slab at the right of Tauraso’s assembling/soldering area protects the table surface and the optical inspection camera nearby helps him work with tiny ICs.

Photo 2: The marble slab at the right of Tauraso’s assembling/soldering area protects the table surface. The optical inspection camera nearby helps him work with tiny ICs.

The assembling/soldering area is carefully set up to keep all of Tauraso’s tools within easy reach.

I fixed a marble slab square on the table to solder without fear of ruining the wood surface (see Photo 2). As you can see, I use a hot-air solder station and the usual iron welder. Today’s ICs are very small, so I also installed a camera for optical inspection (the black cylinder with the blue stripe). On the right, there are 12 outlets, each with its own switch. Everything is ready and at your fingertips!

Photo 3: This developing and programming space, with its three small computers, is called “the little Hydra.”

Photo 3: This developing and programming space, with its three small computers, is called “the little Hydra.”

The workspace’s developing and programming area makes it easy to multitask (see Photo 3).

In the foreground you can see a network of three small computers that I call “the little Hydra” in honor of the object-based OS developed at Carnegie Mellon University in Pittsburgh, PA, during the ’70s. The HYDRA project sought to demonstrate the cost-performance advantages of multiprocessors based on an inexpensive minicomputer. I used the same philosophy, so I have connected three Mini-ITX motherboards. Here I can test network programming with real hardware—one as a server, one as a client, one as a network sniffer or an attacker—while, on the other hand, I can front-end develop Windows and the [Microchip Technology] PIC firmware while chatting with my girlfriend.

This senior software designer has created a quiet work area with all his tools close at hand.

Senior software engineer Tauraso has created a quiet work area with all his tools close at hand.

Circuit Cellar will be publishing Tauraso’s article about a wireless thermal monitoring system based on the ANT+ protocol in an upcoming issue. In the meantime, you can follow Tauraso on Twitter @CarloTauraso.

System Safety Assessment

System safety assessment provides a standard, generic method to identify, classify, and mitigate hazards. It is an extension of failure mode effects and criticality analysis and fault-tree analysis that is necessary for embedded controller specification.

System safety assessment was originally called ”system hazard analysis.” The name change was probably due to the system safety assessment’s positive-sounding connotation.

George Novacek (gnovacek@nexicom.net) is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

Columnist George Novacek (gnovacek@nexicom.net), who wrote this article published in Circuit Cellar’s January 2014 issue, is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer of embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004.

I participated in design reviews where failure effect classification (e.g., hazardous, catastrophic, etc.) had to be expunged from our engineering presentations and replaced with something more positive (e.g., “issues“ instead of “problems”), lest we wanted to risk the wrath of buyers and program managers.

System safety assessment is in many ways similar to a failure mode effects and criticality analysis (FMECA) and fault-tree analysis (FTA), which I described in “Failure Mode and Criticality Analysis” (Circuit Cellar 270, 2013). However, with safety assessment, all possible system faults—including human error, electrical and mechanical subsystems’ faults, materials, and even manuals—should be analyzed. The impact of their faults and errors on the system safety must also be considered. The system hazard analysis then becomes a basis for subsystems’ specifications.

Fault Identification

Performing FMECA and FTA on your subsystem ensures all its potential faults become detected and identified. The faults’ signatures can be stored in a nonvolatile memory or communicated to a display console, but you cannot choose how the controller should respond to any one of those faults. You need the system hazard analysis to tell you what corrective action to take. The subsystem may have to revert to manual control, switch to another control channel, or enter a degraded performance mode. If you are not the system designer, you have little or no visibility of the faults’ potential impact on the system safety.
For example, an automobile consists of many subsystems (e.g., propulsion, steering, braking, entertainment, etc.). The propulsion subsystem comprises engine, transmission, fuel delivery, and possibly other subsystems. A part of the engine subsystem may include a full-authority digital engine controller (FADEC).

Do you have an electrical engineering tip you’d like to share? Send it to us here and we may publish it as part of our ongoing EE Tips series.

Engine controllers were originally mainly mechanical devices, but with the arrival of the microprocessor, they have become highly sophisticated electronic controllers. Currently, most engines—including aircraft, marine, automotive, or utility (e.g., portable electrical generator turbines)—are controlled by some sort of a FADEC to achieve best performance and safety. A FADEC monitors the engine performance and controls the fuel flow via servomotor valves or stepper motors in response to the commanded thrust plus numerous operating conditions (e.g., atmospheric and internal pressures, external and internal engine temperatures in several locations, speed, load, etc.).

The safety assessment mostly depends on where and how essentially identical systems are being used. A car’s engine failure, for example, may be nothing more than a nuisance with little safety impact, while an aircraft engine failure could be catastrophic. Conversely, an aircraft nosewheel steer-by-wire can be automatically disconnected upon a fault. And, with a little increase of the pilots’ workload, it may be substituted by differential braking or thrust to control the plane on the ground. A similar failure of an automotive steer-by-wire system could be catastrophic for a car barreling down the freeway at 70 mph.

Analysis

System safety analysis comprises the following steps: identify and classify potential hazards and associated avoidance requirements, translate safety requirements into engineering requirements, design assessment and trade-off support to the ongoing design, assess the design’s relative compliance to requirements and document findings, direct and monitor specialized safety testing, and monitor and review test and field issues for safety trends.

The first step in hazard analysis is to identify and classify all the potential system failures. FMECA and FTA provide the necessary data. Table 1 shows an example and explains how the failure class is determined.

TABLE 1
This table shows the identification and severity classification of all potential system-level failures.
Eliminated Negligible Marginal Critical Catastrophic
No safety impact. Does not significantly reduce system safety. Required actions are within the operator’s capabilities. Reduces the capability of the system or operators to cope with adverse operating conditions. Can cause major illness, injury, or property damage. Significantly reduces the capability of the system or the operator’s ability to cope with adverse conditions to the extent of causing serious or fatal injury to several people. Total loss of system control resulting in equipment loss and/or multiple fatalities.

The next step determines each system-level failure’s frequency occurrence (see Table 2). This data comes from the failure rates calculated in the course of the reliability prediction, which I covered in my two-part article “Product Reliability” (Circuit Cellar 268–269, 2012) and in “Quality and Reliability in Design” (Circuit Cellar 272, 2013).

TABLE 2
Use this information to determine the likelihood of each individual system-level failure.
Frequent Probability of occurrence per operation is equal or greater than 1 × 10–3
Probable Probability of occurrence per operation is less than 1 × 10–3 or greater than 1 × 10–5
Occasional Probability of occurrence per operation is less than 1 × 10–5 or greater than 1 × 10–7
Remote Probability of occurrence per operation is less than 1 × 10–7 or greater than 1 × 10–9
Improbable Probability of occurrence per operation is less than 1 × 10–9

Based on the two tables, the predictive risk assessment matrix for every hazardous situation is created (see Table 3). The matrix is a composite of severity and likelihood and can be subsequently classified as low, medium, serious, or high. It is the system designer’s responsibility to evaluate the potential risk—usually with regard to some regulatory requirements—to specify the maximum hazard levels acceptable for every subsystem. The subsystems’ developers must comply with and satisfy their respective specifications. Electronic controllers in safety-critical applications must present low risk due to their subsystem fault.

TABLE 3
The risk assessment matrix is based on information from Table 1 and Table 2.
Probability / Severity Catastrophic (1) Critical (2) Marginal (3) Negligible (4)
Frequent (A) High High Serious Medium
Probable (B) High High Serious Medium
Occasional (C) High Serious Medium Low
Remote (D) Serious Medium Medium Low
Improbable (E) Medium Medium Medium Low
Eliminated (F) Eliminated

The system safety assessment includes both software and hardware. For aircraft systems, the required risk level determines the development and quality assurance processes as anchored in DO-178 Software Considerations in Airborne Systems and Equipment Certification and DO-254 Design Assurance Guidance for Airborne Electronic Hardware.

Some non-aerospace industries also use these two standards; others may have their own. Figure 1 shows a typical system development process to achieve system safety.
The common automobile power steering is, by design, inherently low risk, as it continues to steer even if the hydraulics fail. Similarly, some aircraft controls continue to be the old-fashioned cables but, like the car steering, with power augmentation. If the power fails, you just need more muscle. This is not the case with the more prevalent drive- or fly-by-wire systems.

FIGURE 1: The actions in this system-development process help ensure system safety.

FIGURE 1: The actions in this system-development process help ensure system safety.

Redundancy

How can the risk be mitigated to at least 109 probability for catastrophic events? The answer is redundancy. A well-designed electronic control channel can achieve about 105 probability of a single fault. That’s it. However, the FTA shows that by ANDing two such processing channels, the resulting failure probability will decrease to 1010, thus mitigating the risk to an acceptable level. An event with 109 probability of occurring is, for many systems, acceptable as just about “never happening,” but there are requirements for 1014 or even lower probability. Increasing redundancy will enable you to satisfy the specification.
Once I saw a controller comprising three independent redundant computers, with each computer also being triple redundant. Increasing safety by redundancy is why there are at least two engines on every commercial passenger carrying aircraft, two pilots, two independent hydraulic systems, two or more redundant controllers, power supplies, and so forth.

Human Engineering

Human engineering, to use military terminology, is not the least important for safety and sometimes not given sufficient attention. MIL-STD-1472F, the US Department of Defense’s Design Criteria Standard: Human Engineering, spells out many requirements and design constraints to make equipment operation and handling safe. This applies to everything, not just electrical devices.

For example, it defines the minimum size of controls if they may be operated with gloves, the maximum weight of equipment to be located above a certain height, the connectors’ location, and so forth. In my view, every engineer should look at this interesting standard.
Non-military equipment that requires some type of certification (e.g., most electrical appliances) is usually fine in terms of human engineering. Although there may not be a specific standard guiding its design in this respect, experienced certificating examiners will point out many shortcomings. But there are more than enough fancy and expensive products on the market, which makes you wonder if the designer ever tried to use the product himself.

By putting a little thought beyond just the functional design, you can make your product attractive, easy to operate, and safe. It may be as simple as asking a few people who are not involved with your design to use the product before you release it to production.

Test Pixel 1

Client Profile: Digi International, Inc

Contact: Elizabeth Presson
elizabeth.presson@digi.com

Featured Product: The XBee product family (www.digi.com/xbee) is a series of modular products that make adding wireless technology easy and cost-effective. Whether you need a ZigBee module or a fast multipoint solution, 2.4 GHz or long-range 900 MHz—there’s an XBee to meet your specific requirements.

XBee Cloud Kit

Digi International XBee Cloud Kit

Product information: Digi now offers the XBee Wi-Fi Cloud Kit (www.digi.com/xbeewificloudkit) for those who want to try the XBee Wi-Fi (XB2B-WFUT-001) with seamless cloud connectivity. The Cloud Kit brings the Internet of Things (IoT) to the popular XBee platform. Built around Digi’s new XBee Wi-Fi
module, which fully integrates into the Device Cloud by Etherios, the kit is a simple way for anyone with an interest in M2M and the IoT to build a hardware prototype and integrate it into an Internet-based application. This kit is suitable for electronics engineers, software designers, educators, and innovators.

Exclusive Offer: The XBee Wi-Fi Cloud Kit includes an XBee Wi-Fi module; a development board with a variety of sensors and actuators; loose electronic prototyping parts to make circuits of your own; a free subscription to Device Cloud; fully customizable widgets to monitor and control connected devices; an open-source application that enables two-way communication and control with the development board over the Internet; and cables, accessories, and everything needed to connect to the web. The Cloud Kit costs $149.