For any sizable design, PCBs are usually designed by a team of multiple design engineers (EEs) creating the schematic and multiple layout designers placing all the parts on the board and routing the traces. These teams often work with an extended team of experts in the supply chain, signal integrity, and mechanical and thermal analysis. Engineering management also has a stake in the design process, as it monitors design progress, resources, and scheduling. For a successful design, this multitude of interactions requires mandatory mechanisms to keep everyone on the same page during the design process.
Design teams worldwide are running into problems with supply chains (see All Systems Go: Supply Chain Woes—Which Comes First, the Design or the BOM?). Consequently, it’s critical that designs not use obsolete parts or parts that cannot be sourced. Therefore, good communication and coordination systems must be in place between the design and the supply chain teams.
Similarly, if someone has made a change in the design and believes, erroneously, that they have communicated this to you, you could be working from bad assumptions. In contrast, if you make a change that isn’t communicated to the greater team, everyone else could be working off a false premise.
Another common situation is for someone to make a perfectly valid change, which is communicated to everyone who needs to know. Still, the reason for the change is lost because it wasn’t documented anywhere (or maybe it was, but no one remembers where this document resides, which amounts to the same thing). These scenarios happen far more often than most people think. At this very minute, design engineers and layout designers around the globe are looking at their computer screens, saying, “Who did this?” Or, “I know I did this, but why did I do it?” Or, “This made sense when we did it, but it’s not working as planned, so why did we choose to do things this way?”
This can become overwhelming, especially if you don’t know whether you have access to the latest information. Teams often develop workarounds (aka Band-aids) to address these problems.
For example, some teams coordinate via email. Individual members keep a special folder associated with each project, a subfolder containing messages from the EEs, and another subfolder containing messages from the layout designers. For version control, some teams adopt a simple file naming convention such as V1.0, V1.1, V1.2, V2.0, etc. More sophisticated teams may use real version control systems such as Apache Subversion. However, these systems are typically created for software developers, and hardware designers think, “Great, just what I need, yet another useless tool to learn!”
Spreadsheets are commonly used to track information. They are easy to create, hard to maintain, and can become monstrous in size, creating something that people workaround. Often, teams that are co-designing something share drives and develop a method (some form of a semaphore) to identify who is working on a specific part of the design at any one time.
These solutions are best described as ad-hoc; as you soon realize that you are responsible for training someone new on all the side-band communications stuff, the team has evolved to survive.
In retrospect, all this boils down to data management or, more specifically, product data management (PDM). In large companies and organizations that already support sophisticated product lifecycle management (PLM) systems, one common question is: “Hey, isn’t PDM the same as the PLM we already have?” (Answer: No, they are not.)
PLM systems support products throughout their manufacturing and post-manufacturing lifecycle (hence, product lifecycle management). Consider defense manufacturers. They need to consolidate all their work in one place so that 20 years from now if they need to understand how a system was made, they know where to find the information to replicate it, even if the original designers are not around.
PLM systems are predominantly employed in the context of finalized products or, at least, finalized versions of those products. The idea is that once a product is manufactured, it is eventually deployed into the field. Sometime later (months, years, or decades), a bug rears its ugly head, and the PLM system is used to access the archived design, fix the bug, and release a new version of the product.
By comparison, in PDM, we’re talking about a work in progress. PDM is not necessarily useful at the end of the design; instead, it’s something that design engineers, layout designers, and others involved in the design decisions are constantly using throughout the design process.
The role of PDM is, first and foremost, to facilitate communication between everyone involved in the design. For example, a substitution is made because a particular part is no longer available due to a supply chain problem. Any change made to the schematic by the design engineer should automatically be communicated to all the members of the engineering, layout, and supply chain teams. If a layout designer changes a component as part of the layout process, details of this change should automatically be made available to the engineers in charge of the schematics. The PDM system should also facilitate communication between teams, support requests for changes, and discussions between team members. Furthermore, the PDM system can capture any decisions made at any stage of the design (“We opted to use this connector because…”).
Knowing that PDM and PLM systems serve different needs, one caveat with the PDM system is that it should interface well with the PLM system. The PDM system should help you upload all the design-related data into your company’s PLM system.
One final caveat is that the PDM system should be largely invisible to the user. Any tools used to create a new PCB design, including the schematic capture and layout, should have the appropriate PDM “hooks,” even if the PDM system’s capability has not been enabled. In addition, when the PDM is turned on, it should be as seamless as possible for the users.
The last thing anyone wants is to be forced to learn yet another tool. Everyone wants a tool that works in the background, makes their lives easier, boosts productivity, minimizes miscommunications, and speeds time-to-market. Welcome to the wonderful world of PDM.
Nitin Bhagwath is director of product management, PCB front end at Cadence Design Systems.
Download The System Designer’s Guide to… System Analysisby Brad Griffin along with its companion book The Cadence System Design Solutions Guide.You can also view other titles in our full I-007e book library here.