April 27, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems
This series of four posts looks at the management of items, data and bills of material for mechatronic products. It is split into mechanical aspects, electrical aspects, software aspects and integrated aspects.
In the minds of many, managing electrical aspects of products has, well, already be done. Meaning there have been approaches and technologies that have been around for some time to manage the artifacts representing electrical components. But actually there have been some relatively recent advancements in the technology that, by and large, isn’t commonly managed centrally today. Let’s take a look.
Managing Electrical Aspects of the Product
When you start talking about the electrical side of the house, things tend to be a bit more complicated compared to the mechanical side of things. What is considered a part can be dramatically different depending on the type of electric item you’re discussing. Here it makes sense to split up the discussion based on the type of electronics being developed.
Managing PCB Schematics, Diagrams, Layouts and Libraries
Printed circuit boards (PCB) are used pretty frequently in today’s products. The design of a PCB often starts with a 2D logic diagram that represents the functions of the PCB. Next the design moves on to a 2D schematic, where the connections between the different board components are symbolically shown. And finally, the layout shows a detailed view of the placement of components and the path and layer for each trace in the board. From a manufacturing or sourcing perspective, the lowest level items on a PCB are the components (resistors, etc.) and the board. However, there is information embedded in these design artifacts that describe a deeper level of granularity in the board itself: the traces that connect the components on the board. To further complicate things, the components and connections between them are represented in both the schematic and layout. That means if that connection changes in one, it should change in the other.
Today’s PLM or PDM systems often recognize that the diagram, schematic and layout all essentially represents the same electronics assembly. And as such, they create links between them. And while integrated tools recognize that a change to a connection in the schematic should propagate to the layout, most PLM or PDM systems do not. Furthermore, the information about the connections themselves that is embedded within these design artifacts are often not extracted into the PLM or PDM system. From a Bill of Material (BOM) perspective, most PLM or PDM systems will extract the counts of the different electronic components, creating a flat list with quantities. The diagram, schematic and layout are often attached to the top level board assembly.
What shouldn’t be lost in all of this details is the fact that most PCBs are assembled almost completely out of off-the-shelf items. As such, a centralized library composed of approved parts lists generated by the procurement organization is used to identify which components are OK to use for designers and engineers.
Traditionally, PLM and PDM systems have managed this library as a single item that can be downloaded to a desktop. From there, the ECAD or EDA application accesses the library directly.It can certainly work. However a fair amount of functionality exists in PLM and PDM systems to manage libraries of parts, to manage change across those libraries and to promote reuse so that higher volume discounts can be achieved. By managing the electronics component library as a single item, none of those things can be proactively managed. Ultimately, electronics components would be managed as individual items, just like mechanical parts, in PLM and PDM systems.
Managing FPGA Programming
In many circumstances, manufacturers want to optimize processors to do a specific job. One option is to custom build application specific integrated circuits (ASICs), but they are extremely expensive because they require custom dies and manufacturing runs. The number of ASIC manufacturers in the world can probably be counted on a couple hands. So, instead, manufacturers often use field programmable gate arrays (FPGAs). This type of chip is a off the shelf component that can be programmed with custom logic to perform specific jobs more quickly and efficiently than generic chips. However, since they are off the shelf components, they aren’t nearly as expensive as ASICs.
So how are FPGAs programmed? Traditionally, manufacturers would hire programmers to code the logic of these chips. And managing that environment looks very much like a Software Configuration Management (SCM) problem. But times are changing. There are new software applications that will let a user create a logic diagram and then, in an automated fashion, generate the code to program the FPGAs. This is an advancement in terms of enabling everyday engineers to define the logic they want without working through a programmer, a proxy who often doesn’t understand the engineer’s design intent. This approach is sometimes referred to as visual programming. Now don’t get me wrong. The code generated by these software applications aren’t perfect. However they often enable the programmer to just check the code instead of writing it themselves. And that can be a huge time savings for an expensive resource.
As you can imagine, either programming directly or using a visual programming approach will generate a number of design artifacts that should be centrally managed in some manner. More often than not, this type of deliverable though is managed as a generic artifact, just like a word document, and as a result doesn’t have any automated association with the FPGA item it will affect. Furthermore, none of the information or intelligence embedded in these artifacts are exposed to the broader audience. But most importantly, the logic of the FPGA is disconnected from the logic of the PCB on which it resides. Combining the two holds the potential to perform more realistic simulation. However, let’s hold off on that discussion for the integrated aspects post in this series.
Conclusions and Questions
In summary, there is a great amount of complexity in managing the design artifacts used to develop PCBs ranging from schematics, diagrams and layouts. They are each connected and change from one should propagate to the others. Today’s PLM and PDM systems manage these representations as an interconnected set, extracting the BOM from them, but infrequently extracting more granular information than that. From an FPGA perspective, most design artifacts are managed by PLM or PDM systems as unintelligent files. Instead, it is more frequent that the artifacts for FPGA programming are managed with Software Configuration Management (SCM) systems.
Time to sound off. What are you using to manage these artifacts today? Do you think PLM or PDM systems manage these design artifacts to enough granularity or is there still room for improvement? Weigh in and let us know what you think.
