Philosophy and documentation

When I worked for Control Data (actually a subsidiary) every schematic was given a simple identifying number that was arranged in ascending order. The same was true for mechanical drawings and printed circuit boards. Although I was employed in the documentation department, I must admit that I don’t remember how they all came together to create the minicomputer we were working on.

Back in those days everything was generated by hand – the schematic was sketched and given to the drafting department and they would transpose it onto vellum (also tracing paper, although for younger readers both concepts may be as foreign as carbon paper) using standard symbols often achieving uniformity using stencils. A specialist draftsman would lay out the PCB using dot and tape and a mechanical engineer would create the packaging at a drafting table. Intra-office communication was via memos, reports, meetings, and of course individual interaction. I did a blog of my memories of how things were “How It Was: PCB Layout from Rubylith to Dot and Tape to CAD”.

As computer-aided design improved, so the drawings became electronic with a paper trail but it was merely a more convenient way of implementing the status quo in documentation. As far as the PCB was concerned, the schematic was only a way of getting the netlist. The mechanical drawing needed one or two steps to convert the PCB output to a .dxf file to import into Autocad. It was easy to separate and categorise the different document outputs.

The products I work on are built in stages, so there are subassemblies. We have always been troubled by this. Let’s assume we have various builds using different components. In the documentation hierarchy there is a point where there is a partial build that is a common antecedent. At what level does the schematic belong? Does it reside at the earliest level, where there are no component values assigned or is there a unique schematic at each of the top levels with showing the selected component value. To some degree the choice may be determined what the schematic is being used for: is it being used to debug the system, is it providing an overview for production, or is it being used for service.

Over the years my employer’s documentation system has evolved inconsistently and haphazardly. Given that we have had several people influencing it and since they have brought their experience from other organizations, I presume elements of it will appear familiar to all of you. One overriding principle I have tried to implement is taken from the aerospace industry. There is only one given document and it cannot exist in two places since maintaining more than one is cumbersome and error prone.


Figure 1. One of the slightly more complex products we make. The complete product bill of materials for A includes drawings that cover the side labels (B), the housing (C), the drawings for the front panel (D), the plug in connectors and drawings for the labelling on the connector (E & F), the subassembly (G) and not shown, the documents for the firmware to be programmed onto the micro on G. The packaging is also added. The subassembly consists of a PCB and all the components mounted on it. Where in the hierarchy do we place the schematic? (Source: Author)

Every product we make has a identifying number (mostly allocated sequentially) that we call a “catalog number”. All the documents at its level (top) level in the hierarchy are made up of a letter prefix, the catalog number and a suffix of the revision. For instance the schematic (rev C) of catalog number of 330924 would be W330924C, the mechanical drawing (ref F) would be M330924F and the BOM (rev G) would be P330924G. If there is a subassembly it would be allocated its own sequential number (e.g. SB00123) and the documents that are needed for that level would be numbered according to using the same idea of a prefix-SB00123-suffix. Documents are only present where needed, and the schematic for instance would sink to the level of the common antecedent. Component values that may change across builds are marked with a symbol that denotes that the value is defined on the bill of materials. Mechanical assemblies and firmware follow the same idea. Similarly the PCB gets a sequential number and revision – no prefixes.

But the CAD world has changed, and the conundrum has become more enigmatic. Packages like Altium integrate many aspects of the design. The schematic, PCB, assembly drawing, mechanical and possibly even firmware are all part of the same design environment. So much so that our draftsman insists that the PCB is the physical manifestation of the schematic and so both should always be in lockstep using the same revision. So if a component value changes, the PCB revision must change! What do you do? And on top of that, what is the number allocated to the schematic, assembly and mechanical drawings that is modified any time the PCB is changed (including possibly trivial stuff like silk-screen updates)? Where in the hierarchy do they lie – are they associated with the catalog number or the PCB number? And where do you file them so that when an engineer updates a drawing, the draftsman works from the changed drawing and not the one automatically stored as part of the PCB package? HELP!

Does anyone know of a system that is modern, consistent and if possible described somewhere so that I can try to update our system? Does anyone know of a PhD philosophy student looking for thesis material? Please add your thoughts and descriptions of your experience below.

10 thoughts on “Philosophy and documentation

  1. “We have the same issue where I work. The way we handled it is by introducing the concept of “schematic” or “board” variants. We're using Mentor Graphics tools that support this philosophy so I'm not sure how to implement it with other tools.nnThe id

    Log in to Reply
  2. “Elizabethnn” You really need to have support for something like this in your tools though. And it really helps to have people who really know how to use the tools…. “nnSometimes it's nice to work for a small organization and sometimes a few more r

    Log in to Reply
  3. “We have a database that includes ALL parts (including revision info) that are in the products we build. This database is somehow linked into Mentor Graphics so when we create a schematic we use parts from the database. The resulting schematic / PCB / as

    Log in to Reply
  4. “I think it's nowadays crucial to use a version control system for PCBs. Altium has built in SVN which works quite okay (quite). And you see every change done to a particular schematic and this can be shared among the whole company/team. “

    Log in to Reply
  5. “There's no question that you need a version control system. SVN and its ilk have the advantage that they only updates under controlled circumstances. However it appears to me that they require some form of network administration and in a small organizatio

    Log in to Reply
  6. “We use SVN for our software source code version control and also for some engineering documents and reports. Our manufacturing drawings and versioning is done with another document/ workflow management system from Aras called Innovator. You're asking a

    Log in to Reply
  7. “Schematic and PCB can and sometimes must be kept in lockstep. But for us, it became tricky. We encoded the PCB revision in the copper traces of the PCB layout. In this way one could look at a PCB assembly and know what layout revision was in play. How

    Log in to Reply
  8. “@WorknhardnnThanks for the link. Although syntactically correct (as far as I can tell) it doesn't link to the document you mention. I searched for “Configuration Management” in the “Not Found” page and it shows up as the first in the list.nnIt has

    Log in to Reply
  9. “On the philosophy side, I struggled with revising my company's ECO system for some time. I went though many books. The most useful was Engineering Documentation Control Handbook: Configuration Management and Lifecycle Management. It does not give you f

    Log in to Reply
  10. “MarknnIt's good to know that others have managed to approach and quantify this issue. It would be nice to find one of these kinds of documents in the public domain.”

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.