Managing Drawings

Drawings are what engineers produce, yet far too many of us let entropy rule, rather than carefully developing a way to insure the products are correctly built to the drawing. This piece describes a drawing system, the text of which is available here.

Published in EDN in July, 1994.

By Jack Ganssle

Experienced engineers know that the new college graduate is really nothing more than a blank slate with no experience and little practical knowledge. The four or five years of cramming Maxwell's equations and cranking triple integrals gives a nice theoretical grounding in the basis of our profession, but leaves much lacking that only on-the-job training can fulfill. I remember not being allowed to solder in lab courses because of the instructor's fears that "we might burn ourselves". Appalling but true.

Do young CPAs and lawyers graduate with so few immediately useful capabilities?

Though our white collar self-esteem may bristle at these words, in fact I think engineering is very much like the trades practiced hundreds of years ago. We've substituted "Junior Engineer" for the older word "Apprentice" and "Senior Engineer" for "Journeyman", but in fact most of the practical aspects of our profession are handed down, on the job, from the master craftsmen to the newcomer.

This isn't bad; with a technology half-life of perhaps 3-5 years no college could ever adequately prepare engineers for the workplace. They learn the critical thinking so necessary to the business, and (hopefully) learn to never stop studying and learning. An engineer not constantly involved in self-education will be obsolete in very short order.

One thing we never discussed in college was drawings - amazing, since most engineering output is nothing but drawings. Sure, we sketched a few simple schematics and analyzed blackboarded circuits ad nauseam, but somehow never addressed the issue of creating, maintaining and updating the drawings that are the product of our work.

Every small company passes through a phase of creative chaos. Crank out a few sheets of Orcad schematics and hand-annotated assembly drawings, and ship the product. With time the product line broadens necessitating more drawings (all stored in a drawer... somewhere). New hires, not so intimately familiar with the product, now are expected to build and maintain the products, working often from memory. Comments like "Oh yeah, we always put a 10k resistor in that spot", or "Jeez, you forgot the mod we do to that version of the product" are heard ever more often.

This is a classic case of the company's systems breaking down. Management texts talk about MRP and inventory control systems, but ignore the most important system for manufacturing and engineering: the drawing control system.

My company went through this evolutionary phase. Hundreds of drawings accumulated. Sure, we had bills of materials and assembly drawings, but they were impossible to track. Which was the current version? What changes were implemented between versions? How could we guarantee that the products were being made to current specification?

In desperation I tasked a young engineer with the job of developing a formal drawing system, not realizing that, having had no experience with functioning systems, he had no idea where to start. The result was, well, primitive and crude.

On a memorable cross country flight shortly thereafter I pounded in a specification for a document control system, drawing on the experience I had obtained as a very junior engineer years before. The concepts were frankly pirated from the system used by a former employer, whose system in turn was based on one used in the airplane industry. Though our system has refinements for dealing with embedded designs (PAL and ROM files, for example), it looks much like any system dating from the 50s or even 40s.

Now I secretly smile, realizing the my company's crop of engineers will probably take this third generation system along to other employers in the future, tuning it to specific needs but keeping many of the core concepts for two simple reasons: it works, and it has become another comfortable tool in their skills bag in their journey towards master craftsmanship. There is nothing new under the sun!

Teaching apprentices is very much like having children. Your own kids are a source of genetic immortality; your mentored protégé likewise perpetuates a piece of you.

The Paperless Office

Plenty has been written about our evolution towards the paperless office, but it seems few technology companies have made this transition even in the highest of the high tech environments - the engineering department. Sure, we now use schematic capture instead of a pencil and vellum, and word processors rather than scrawled notes, but almost all of these electronic documents get reincarnated in paper form.

Production wants paper drawings for the assemblers. Test needs test procedures and schematics on paper. Let's face it - even engineering wants the schematics on paper. It's a lot easier to work with a paper schematic that you can scribble and make notes on then to call up the drawing on a screen somewhere.

Electronic documents suffer from another flaw. Every single sort use one of dozens of capture packages; assembly drawings may be in AutoCAD or some other format; even text documents can be in Word, Lotus, or any of a million other formats. You cannot display and manipulate all of the system's documents unless you own all of the applications... on your workstation.

Does this suggest that an organization should standardize on a single word processor, single database, and the like? That's the tack we've taken.

The new reality of a drawing control system must recognize that while masters are inevitably in some computer format, working copies are almost always on paper. Paper is not bad per se; it is yet another component of a modern information management system.

To deal with the realities of standard office equipment I believe all schematics and other documents should, if at all possible, be formatted for 8.5 X 11 paper. The days of D size schematics are long gone. You can't copy them without a monstrous blueprint machine; you can't fax them; and storing large format paper requires special cabinets. At my business our entire drawing system fits in one drawer of a standard file cabinet - a space- conserving, easy to access format that greatly simplifies life.

"But", you sputter, "we've always used huge drawings!" Times and technology change. Embrace change. My dad tells me in the pre-mylar days they did drawings on starched linen in ink - a single bead of sweat, in those pre-air- conditioned 1950s, could ruin a week's work. We thankfully got past linen, and will hopefully obsolete huge rolls of vellum as well.

The New Realities

When I first entered this field all we managed were drawings and bills of materials. The digital age has only increased the kinds of "documents" any reasonable drawing system must manage.

Perhaps, though, it makes sense to outline the goals of a document control system:

1. Guarantee that all departments are using accurate, up-to-date, drawings.
2. Control product versions, so production knows how to make each kind of product
3. Provide a historical record of changes, so the service group can bring older products up to current revisions without heroics
4. Insure that adequate backups exist so the knowledge embodied in the system can survive a fire or malicious intent.

Goals 1 to 3 have been around since the dawn of engineering. I suppose Roebling himself built the Brooklyn Bridge with a primitive drawing system that obviously functioned well. The fourth goal is a result of new challenges from the computer age and the realization that the company must survive despite any sort of disaster.

How do you manage a document that lives in some purely electronic form? Schematics and artwork should have paper (or film) copies filed in the drawing drawer, but what about the original files?

One solution is to define an electronic repository. At my company one computer has a master directory, available to everyone over the network, where a copy of every critical file is stored. Modern networks are really great, since on even the simplest you can define read/write access rules and passwords. We find there's little problem leaving these files available to everyone, but a paranoid outfit could easily restrict write-access to those folks with a "need to write".

Every project has its own subdirectory, with further subdirectories containing: ROM files, PAL files, Schematic files, CAD files, and word-processing documents. Draconian rules, accompanied with an assigned "enforcer", ensure that the files are copied back to the master computer whenever they are changed.

With all of the files mastered on one machine it's easy to run weekly backups to tape. In effect we can back up everything critical to the business in 30 minutes from a single machine, and need not rely on forgetful and busy employees to run regular backups of their own systems. When the place was burglarized a year ago almost every decent computer was destroyed or stolen, yet we lost virtually no data.

PALs and ROMs pose special documentation challenges. A PAL or a ROM is a physical device that must be purchased, so it requires a call-out on a bill of materials. Yet, the device itself is incomplete until it is burned with the proper equations or program. Our solution is to call out the chip on the BOM, with an associated drawing number that describes the part's programming.

The ROM/PAL drawing includes the file name(s) of all source code modules used to build the equations or program. PALs are always a single .PDS file compiled via PALASM. ROMs invariably are composed of dozens of source code modules. By listing every file used, its full filename on the master computer, and the required make files, it's possible to recreate the program from the backup files even if a software engineer's computer dies (or is stolen!).

Responsibilities

No system of any sort will work unless it's clearly understood who is in charge of keeping it up to date. By tasking an individual with the responsibility of managing the drawing system, everyone knows who to turn to for help and advice. The responsible individual clearly knows what is expected, and management can hold his or her toes to the fire.

The drawing system is too important to leave to chance. Its management should be part of the responsible person's annual review.

"The E Myth" by Michael E. Gerber (1986, Harper Business, New York) examines how businesses start, grow, and sometimes choke on their own success. The book's most important point is that the entrepreneur should work on and not in the business. That is, spend as much time designing systems and procedures that make it possible for the business to thrive despite its success. In April Business Week described how DEC is suffering from systems that cannot keep up with their new thrusts into the PC business. Even the big boys have these problems.

Though Gerber never mentions drawing systems, surely document management is as important as any other system, and deserves as much attention as even the accounting.

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: