Back when I was designing subsystems for museum exhibits, experimental apparatus, and recording studios (among other things) I quickly learned that if I didn‘t spend the time thinking about maintenance and repair when I built it, I cursed my past self for it.

As it is said in the code writing business concerning documentation, inline comments, and avoiding ”clever” code:

Be kind to the maintenance programmer because it’s very likely to be you.
​

And, even it it isn’t you, you could be the one getting the phone call to assist the unlucky person who inherited your not-easy-to-maintain code.

There is a broad overlap between making maintainable code and physical devices, but of course there are also differences. Some of the main points of commonality are solid documentation and eschewing obscurity. One thing that makes physical devices very different is that they can break without any changes being made.

Here are some of the things I included, off the top of my head so not an exhaustive list. But I am very interested in whether you did any of these things or not. I didn‘t always do all of them but I usually did as much as time allowed and criticality of the device demanded.

Status Indicators
An any important signal I put an externally visible indicator so at a glance and without tools you could see if it was present when it should be. This includes (when present):

1. Power Supply Related
   

   1. Mains (usually a neon lamp)​
   2. Battery (with a test button so it wouldn’t be a drain)​
   3. PS Rails (each rail voltage, occasionally with comparators driving over/under indicators)​
   4. Switching (inputs to relays, SSRs, and MOSFETs)​
   5. Test Points (I used pin jacks to provide access to measure voltages without opening the case)​
2. Physical Aspect
   

   1. Easy open cases (minimal screws and/or quarter turn captive hardware)​
   2. Connectors on all point to point wiring (including a way to plug it back in while disassembled, for testing. This sometimes meant providing an extension cable which was stored in or with the device, and was clearly labeled.​
   3. Single fastener size (as much as possible using a single size screw, and making any other screws distinctly different when required)​
   4. DIN rail mounting or simple ear type flanges​
   5. If space permitted, documentation in a well attached 4-8mil zipper locking bag​
   6. Fuses always had spares, on board (sometimes in the documentation envelope, sometimes in a parallel mounted fuse holder marked SPARE)​

These are only a few, there’s much more but I am going to stop. I was hoping to hear your reaction and about what you do in this area. Please comment with your best stuff!

 

Having never been a professional and never been responsible for maintaining a large number of devices in the field, I have little concern for repairability.

But that being said one of my design practices has always been modularity for the sake of easy assembly, which turns out to be very useful in troubleshooting and repair.

 

+1 on modularity. Helps with design, assembly, trouble-shooting, repairablity, feature upgrade/addition .

 

Most of the stuff I worked on was for satellites, so obviously maintenance and repair was not a priority, only reliability and tolerance of launch vibration, temperature extremes, and radiation.

 

Having never been a professional and never been responsible for maintaining a large number of devices in the field, I have little concern for repairability.

But that being said one of my design practices has always been modularity for the sake of easy assembly, which turns out to be very useful in troubleshooting and repair.

Modular construction is a great thing. It is definitely a part of my best practices. Power supplies are an example. By having connector and form factor standards I could use the same supply in multiple projects. It simplifies parts inventory, and means spares are generic.

 

Designing for Maintenance & Repair :-

Mine was in a slightly different area than yours, Mainly in the industrial manufacturing industry, for the most part, in industrial machine control and CNC.
One first priority, was no SMPS supplies.!
Another is recognizing the importance of plenty of documentation.
Use reliable parts sources for e.g. N.A. and EU standards.
DIN mounting panel construction.
Conform to NFPA79 standards.
One great gift that Dick Morley gave to the industry in 1968, was the PLC, together with its display of his replication of a schematic in the Boolean logic format traditionally used by maintenance personnel. but displayed on a visual screen, with its ability to shown the status of any logic in a highlighted manner.
This virtually replaced all physical relay based logic used up until then. (together with huge cabinetry required)!!
This PLC format became included in almost every CNC machine from then on.

 

Designing for Maintenance & Repair :-

Slightly off-topic, I often wonder why N.A., in general, has been slow to adopt the Safety Relay?, mainly mandatory in Europe now.

 

Don't go cheap with anything with bearings. Even the cheapest, poorly designed electronics will likely last for decades. I've seen fans, motors and moving assemblies with cheap, junk, atrocious metallurgy bearings fail in a few years and sometimes even in months.

 

I use meaningful designators for both schematics and PCBs testing points as TP5V, TP3.3V; TP19KHz, TPin... instead of TP1, TP2, TP3, TP4 ... that need a reference table to find what is what. If can be etched, better.

I prefer latching catches than screws to hold circuit sections onto chassis.

 

I lectured the young designers, both electrical and mechanical, that the buzz-term DFM does not mean "Design For Manufacturability". It is "Design For Maintenance". The easier something is to take apart for maintenance, the easier it is to assemble (and debug - !) in the first place. No Chinese puzzle boxes, please.

Also, I sprinkled LEDs around boards. If there were a few unused gates, or unused CPLD I/O pins, I would use them to drives LEDs showing the status of the signals most commonly scoped during maintenance - enable lines, sensor status outputs, etc. Of course a lot of the maintenance needed a real scope, but often the LEDs told you where to start with nothing but visual inspection.

With CPLD's in particular, I would bring out internal nodes that were critical for diagnosing, but had no other reason to be brought out. I'd put a low-current LED and resistor, plus a single 0.035" plated-through hole, the right size to hold a scope probe tip. Way easier than probing a 0.22 mm SMT lead.

ak

 

Another important thing I just recalled, it is based on an idea from the designers of the PL/I programming language (though as with many vocal advocates of this idea, they honored it mostly in the breach as the language matured).

This is POLA, the principle of least astonishment—later least surprise. Though the idea was well established lore among programmers of the time, it was expounded on in a paper in Advances in Computers (1972):

For those parts of the system which cannot be adjusted to the peculiarities of the user, the designers of a systems programming language should obey the “Law of Least Astonishment.” In short, this law states that every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible, and exceptions to previously established rules of the language should be minimal. ​

​

Apple supposedly embraced this principle and mostly I think this is true, but there are many violations of it in their designs often seeming to be justified only by aesthetics. Perhaps they use the last clause as justification. In any case, I learned early on that nothing is inherently intuitive. Rather, things become intuitive when they are repeated and consistent.

Sometimes we might choose to force a new pattern on the user which, initially, well be annoyingly counter-intuitive but over time with the proper consistency in application across cases that match its purpose, becomes “more intuitive” than the previous, less widely applicable but more familiar convention.

The application of this idea (I have called it the principle of least surprise through my career) is far from specific to programming languages. It is applicable to every case where a human must interact with a design. My formulation goes like this:

In each case where a person interacts with a design the outcome of any action should be the most expected one based on conventions generally known to users of such things, the overall behavior of the design itself, and the logic embedded in the design. When the design will defy the expectations of the user, in-place documentation will reduce the surprise of the user. Surprise will also be mitigated by experience based on particular attention by the designer to consistency allowing the user to intuit the correct operation of the design to get the intended result.​

​

When choosing "conventions generally known” standards may trump less formal conventions giving preference to consistency over familiarity. For example, color codes might follow de jure standards promolgated by recognized standards bodies rather than vernacular, de facto standards peculiar to an industry or in general, informal use. Since this will cause surprise, the rules require documentation in-place, and I would do just that with labels calling out functions and colors.

The overall behavior of the design and the logic of the design itself refer to the consistent application of internal conventions. This allows the user to intuit what to do to get the desired result. With the former referring to the conventions of operation and the latter to the underlying reasoning for these conventions.

This idea can be applied at every level for high abstraction to concrete details, and the more rigorously it is applied the more powerful it becomes. Done successfully, it gives the impression that the user already knows how to use the design and they are simply recalling or being reminded of the details.

Among the many opportunities to apply this idea are:

1. Controls—switches, knobs, and the like are made consistent in direction, size, and color, and other attributes used on their function. For example: attenuation and gain controls might feature grey knobs of medium size while limit and trigger level controls might be smaller, black ones. Input-related controls and switches might have blue legends while output-related are marked in green. Power related controls might have red legends.
   
   There is nothing inherently in the proposed scheme, the idea is consistent application so the user learns to “trust” the colors and can find things easily even if they can’t articulate the rules behind them.
   
   
2. Connectors—the type and pinouts of connectors would always be the same, except for cases where the difference is intended to be a surprise to avoid mistakes. Once a connector becomes design-conventional, its pinout is kept exactly the same from application to application. For example, on a given connector pin 1 might be GND and pin 8 VCC. The other pins might have conventional signals on them, such as pin 2 IN and pin 3 out; pins 4-7 might vary but can also have sub-conventions depending on their purpose for example pin 4 might be a status signal like PWR GOOD or SYS RDY, while pin 5 might be ENABLE or START.
   
   Connectors are always of a keyed, locking type unless there is a strong case for doing otherwise. Connectors can be further keyed by blocking female ports to prevent accidental insertion into the wrong, but close by connectors. Additionally the connectors have color on the mating housings, usually Sharpie or paint marker to avoid the cost and difficulty of sourcing an array of colored housings, the exception being natural and black which are often readily available.

This is quite long enough already but I think it gets the idea across, and every aspect of the design is subject tot it. For example the way a particular device is opened for access should be the same as every other device that uses that housing. If there is a reason to deviate, in-place documentation would clearly call out the differences. Power supply rails would be consistent in voltages and all general power connectors from supplies of the same capacity would be the same, with the same pinout. If there is a difference for an unavoidable reason, the connector on the deviant supply would not be able to mate with standard connectors.

Properly applying this principle is a life-long process for the designer who will establish a “language of design” that user of their designs learn to understand. One more idea is that the naïve user should be able to do the most common things most easily even without fluency in the design language. This demands good choices about conventions so they overlap with the generally known ones in these areas as much as practical, or occasionally having the general convention available in addition to the vernacular one of the design. It also places an emphasis on the power and necessity of in-place documentation for the neophyte which is very easily to overlook for the designer fluent in their own design language.

There you have it, something that most people will find excessive I expect but that I have found very important for both users and myself in that I can reconstruct how something I designed works even if I have forgotten designing it. This has happened many times and it is always gratifying.

 

One thing I swear I will do next time, is include a connector for serial out on every microcontroller based board I design. Too many times, I have ended up hacking one on afterwards. Priceless for debugging.

 

What isinteresting is the existance and publishing of what seems to be the opposite of all of the recommendations so far:
The "Design For Assembly" set of guidelines. They recommend snap-together assemblies, which makes most consumer items non-repairable, as well as welding and crimping, or gluing, instead of screw or bolt fastening. That concept has been touted in a number of publications. My interpretation is that it means that the product is intended to not be worth repairing!!

The problem is not so bad in machine tool designs because many corporations have standards for their equipment, and many suppliers want to get additional orders for more equipment.