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.