Collaborative Design Part 2: Building a Better System

From my previous blog on design collaboration, it’s clear that good tools have strong capabilities for visibility, differencing, and merging. The features and interactions seen by end users are just the tip of the iceberg though, and really, the back end of a collaboration system determines how effective it can be. A well-organized core structure provides the foundation for seamless collaboration.

It’s almost mandatory in a software development environment to enact a strict organizational structure. There are just too many different people potentially working from several revisions of code, and without a system in place to control it all, every development cycle would be a mess. Since version control is so pervasive as an organizational file structure in that domain, it only makes sense to use it as a jumping off point for our electronic design collaboration system..

Version Control: A Not-so-Brief Introduction

Anyone familiar with a version control system knows about trunks, branches, merges, and tags.  

A trunk represents the main line of development for a design or project, with the latest revision on the trunk called the head revision. From that, branches are split off as various changes are made by different designers and for different areas of the project. So it’s possible (and actually unavoidable during collaboration) to have several parallel lines of development, and at some point, these need to be consolidated to reach a final design or milestone during development.

Figure 1: In a version control system, development is organized into a main line called the trunk, with parallel lines stemming from that called branches. Branches can either be merged back into the trunk, or discarded, and certain milestone revisions can be tagged.

Branches can either be merged or discarded, depending on their relevance or usefulness to the final design. If it’s determined (through the use of design collaboration comparison tools) that a particular branch doesn’t have any useful information to add to the head revision, it will simply be discarded. If, on the other hand, progress can be made towards the final design using the developments of a certain branch, those changes should be merged with the trunk to create a new head revision.

Periodically, a revision will be tagged, giving a snapshot of a project during development. A tag is simply used to give users somewhat of a milestone during a product cycle. For the case of collaboration however, it can also be thought of as a good benchmark after collaboration branches have been merged into the trunk.

So What Does This Have to Do with Collaboration?

Of course, understanding version control doesn’t mean that every designer will suddenly be able to collaborate flawlessly. Figure 1 is simply intended to help visually define parallel development. While collaboration tools, even those that visualize changes in real-time, would seem to be following some complex, cryptic algorithm, they rely on nothing more than a gussied up version control system at their core. The difference is that the type of structure discussed in the previous section is masked by some sort of GUI that is specific to collaboration.

Designers independently make changes to their own version of a project (i.e. their own branch), and at the end of the day, those changes are merged or discarded. Collaboration software simply provides the tools to help designers avoid stepping on each others’ toes, while being able to efficiently make decisions about conflict resolution.

Building a Better System

Version control is a good foundation for collaboration, but there are ways to implement an even better structure. Expanding on the idea of a design snapshot, what if we could take that snapshot and enter it into a larger data management system, with lifecycle state changes and approvals? This is the ultimate goal, because while version control does keep an accurate revision history to help maintain data integrity, it doesn’t necessarily provide integration into a product’s overall lifecycle. As shown in Figure 2, a product spans several domains, from supply chain, to electrical and mechanical design, all the way to manufacturing. Version control keeps the revision history of items in these domains separate, whereas a true data management system can span all domains required to bring a product to market.

Figure 2: A design release encompasses all information from the design side, as well as from other relevant domains for bringing a product to market, at a particular point in time.

With so many different facets, and potential hazards, for electronic designers to worry about, life can quickly start to look like something out of a horror movie. Product Lifecycle Management (PLM) is all about managing and tracking a product from beginning to end, but this is not limited to the design release as a whole. The best way to understand a design release is to start from the top:

Design release

• PCB documents
• PCB footprints        
• Land patterns
• Pad stacks
• Bounding courtyards
• Assembly drawings
• 3D mechanical models
• Re-use blocks
• Templates
• Rules and constraints
• Schematic documents
• Schematic symbols
• Alternate views
• Supply chain information
• Datasheets
• Re-use blocks
• Templates
• Pin swap data
• Library documents
• PCB footprints        
• Schematic symbols
• Parametric data
• Lifecycle status
• Supply chain information
• Mechanical assembly documents
• 3D mechanical models
• 3D output prints
• 2D CAD drawings
• Output documents
• Fabrication outputs
• Assembly drawings
• Bill of materials
• Supply chain information
• 3D output prints

There is a definite top-down structure, but there is also a significant amount of cross-linking and dependency between different items. Proper data management ensures that all parent and child items are managed independently, and have a revision history kept for them. Similarly, lifecycle status is tracked for all items, down to the finest granularity. While this may seem complicated, what it boils down to is that each designer needs to worry only about themselves, and the natural structure in place will ensure that changes and revisions are visible and approved by an administrator when needed. There are no guessing games when it comes to item tracking, and a product can only move forward in its lifecycle when all parties involved are on the same page.

Having a strong medium for integration between several domains promotes teamwork and collaboration far better than a straight version control system would. So, we’ve figured out that a design release process is ultimately the best engine to drive collaboration, especially across separate domains, but another interesting topic is just how end users can handle moving between these domains. In the next blog, we’ll look into this.