End-to-End Tracking of Your PCB Design

Have you ever run a board re-spin only to discover you’re not even sure what the changes were? I’m not talking about comparing GERBERs from Rev A to Rev B, rather I am referring to understanding the requirements that drove the changes, the reason behind the changes, and all the dialog that was happening around the changes. For most of us we capture these details via email, commit history in our version control system (e.g. Subversion, Perforce, ClearCase, etc.), or in a notebook. For large, collaborative teams, these methods aren’t always good enough. In this article we explore an elegant, yet simple, way of tracking your design changes and keeping them transparent for the whole team to see and participate in. Additionally, this methodology does not limit itself to just design changes but the whole design process from requirements gathering all the way to manufacturing.

But the Back of My Napkin Is Good Enough!

There are many different systems that one can use to manage and track tasks associated with their design. A classic and most fundamental example of this is a checklist. Though it may sound primitive, the old-fashioned checklist has been used for quite some time and made a spectacular reappearance in the 21st century thanks to Atul Gawande in The Checklist Manifesto. Luckily, the purpose of this article is not to convince you to use a checklist… at least not the paper version. More sophisticated checklists, or tracking systems in this case, exist in fancy web front-ends written in Angular or React so they look great but are still (fairly) simple to use (e.g. Jira, Bugzilla, Trello, etc.). You may ask the following, “The back of my napkin (covered in taco grease) works just fine. Why go through the bother of using an online system?” Working from the back of a napkin, notebook, or even a text document on your local hard drive does not enable you to take advantage of real-time collaboration, decentralized tracking, and divide-and-conquer strategies.

The Case For More Sophistication

You’ve heard it plenty of times: as designs become more sophisticated people need newer, more sophisticated systems. As systems become more sophisticated people get fed up and beg for simpler systems. Simpler systems eventually can’t support sophisticated designs so more sophisticated systems are reinstated and the cycle just repeats itself.

Figure 1: Sophistication vs. Complex Systems Cycle

Just like anything in engineering the true solution is found with trade-offs and compromise. We need a system with a little more sophistication and some added complexity, yet not too much sophistication so that we can use the system without pulling our hair out. When a team is able to effectively use a centralized tracking system, the benefits to a collaborative environment really start to show and you can start to take advantage of the three pillars of collaboration:

Figure 2: The three pillars of collaboration

Following the three pillars of collaboration enables everyone who is part of your design cycle can contribute and share the tasks with you. Users are able to update their status in real-time into a single place (real-time contributions), view the status of each others work without sending nagging emails to the project manager (decentralized tracking), and split the load up of design efficiently and effectively (divide-and-conquer). Again, there are many ways to skin the cat and an Excel spreadsheet on a network drive may work for you (though good luck not overwriting each other). This article merely proposes one solution that has been proven to work in multiple workplaces and completely different environments.

The Solution

The solution presented in this article uses Jira as the issue/requirements tracking system, Bitbucket as the version control system, and Altium Designer^® for the schematic capture/layout tool. Honestly, any tool that enables you to get this job done is fine. A hammer is a hammer and the tools presented here worked out well for my teams across multiple workplaces, industries, and environments. Other tools that follow this framework may work just as well (or better) for you.

The first key is to commit early and commit often. You want to check in your design early in the development and continue to check in any design changes, major or minor, as often as possible. In our setup we use Bitbucket server (a Git repository) in conjunction with the built in Git tools in Altium. This makes committing to and reviewing a managed design much easier (versus an external check-in tool like TortoiseSVN).

Figure 3: Git commit using Altium Designer and Altium 365

Figure 4: Git commit history in Bitbucket linking to the Jira issues

Figure 5: Comparison of versions of Git history within Altium /

When using a tool with built in check-in capabilities the committing is rather straightforward but the key to “meaningful” commits (and commit messages), is linking them to an issue that you are tracking. For example, you’ve just got your prototype boards back and discovered on the bench that you undersized your power supply circuit. You haywire in the correct circuit, test it out, and are now ready to update your schematic. When you, or whoever is doing your board bring-up, discover the failure mode in your design, you capture that as an issue/ticket right away. In the case of this article we use Jira for creating and tracking issues.

Figure 6: Example of a simple Jira ticket

Within that ticket you now have all the information you need to fix and validate the issue you are facing. For transparency purposes you want to keep all the conversation and documentation pertaining to the issue in that particular ticket. This will enable you to collaborate effectively with your team without meaningless meetings or even worse, “Death by Reply to All” emails. Now here comes the best part: the commit history: when you link your commits to an issue you can now view every change in the design, every step throughout that process, in the issue itself. The Jira ticket now becomes the center of activity for making those changes happen in a collaborative fashion.

Figure 7: Git commit history represented in Jira ticket

You can now take this principle one step further with requirements in Jira itself. One can create each Jira task item as a requirement and start to build up the full system of requirements to complete that project. This can be as simple as:

1. Design Schematic
2. Board Layout
3. Firmware Development

Or it can be broken down into a more detailed approach:

1. Design power supply circuit with 28V-40V input and 3.3V output
   1. Simulate circuit
   2. Circuit design schematic capture
2. Design spacewire core with TMR
   1. HDL code development
   2. Generate constrained random testbench
   3. Circuit design schematic capture
   4. Test with simulated hardware

Figure 8: Example of Jira issue with sub-tasks

Regardless of what method you use to break down your tasks you are now able to reference these tasks in a very clear fashion and point to, in a single place, where your design requirements and changes occurred.

Jira Integration Directly in Altium 365

3rd party version control systems have their place in many companies, particularly when most of the product data is not PCB centric or spans across multiple product groups within a company. But for design teams that focus totally on PCB design and need a cloud/on-premises product data management solution, Altium 365 provides a built-in version control and management system with a direct integration into Jira as an issue tracking system.

The limitation of a 3rd party version control system like Bitbucket is that Jira tasks (if applicable) are only listed in the commit notes, so they only exist at the project level. Jira integration in Altium 365 takes issue notes a step further by allowing Jira tickets to be applied directly to objects in the schematics or the PCB layout, rather than being applied at the project level.

A comment with a Jira issue can also be applied to electrical and non-electrical objects. For example, take a look at the schematic sheet image below, where a Jira task is being added to a notes table in a schematic sheet. The table for UVLO/OVLO thresholds can have a comment attached by a designer, and the object can be tagged with a Jira issue. Between direct commenting on these objects in the schematics and information in the Jira ticket, it's much easier to ensure a designer has the context required to understand any context required to resolve the issue.

• Learn more about Altium 365 Jira integration

Designers and engineers on your team who have access to the Altium 365 Workspace are also able to see all relevant issues to which they are assigned as Tasks. This helps managers segment issue tracking from design and keeps an engineer's focus on their assigned task within the design workspace, yet the link between design and issue tracking is maintained so that progress can be tracked. With Altium 365 as the primary dashboard to task/issue tracking and data management, everyone involved in a project has the visibility they need to complete assigned tasks quickly and efficiently.

Jira is just one of the 3rd party resources available for issue and requirements tracking and it is a useful platform that helps manage projects spanning beyond PCB design and layout. For example, large software projects that leverage a custom hardware platform are an excellent use case for Jira + Altium 365 as the Jira platform will be the primary tool used by the software team, and they can create issues that are seen by the hardware team inside the Altium 365 Workspace. But for PCB-centric projects which do not use Jira, there is another solution built into Altium 365.

Altium 365 Requirements & Systems Portal

Altium 365 Requirements & Systems Portal also provides a type of requirements tracking tool that automatically performs design checks directly on objects in the PCB layout and schematics. This provides the same advantage as a direct Jira integration with Altium 365 in that requirements can be tagged directly onto electrical and non-electrical objects, giving team members the information they need to implement the requirement and solve issues without leaving the Altium ecosystem.

Requirements tracking in Altium 365 occurs natively in an Altium 365 Workspace and without requiring any 3rd party platforms. It is designed by hardware engineers, for hardware engineers and automates checking of design objects against system-level requirements defined by engineering managers. Requirements setup is extremely easy and uses a simple query system that calls out objects in your schematics and PCB layout, such as reference designators, component parameters, and net names. In addition, complex requirements documents can be instantly distilled down to a set of system-level requirements with a built-in AI tool, which greatly reduces the time required to set up requirements tracking and automate verification.

• Learn more about Altium 365 Requirements & System Portal

Conclusion

Many people have different systems in which they track design changes or requirements. This article presented a simple, yet elegant, way to capture all these requirements and view design changes in a single location. More than just basic commit history, or glorified shared spreadsheets this narrows down code commits to requirements, and rich conversations that occur between the designers. This process, in turn, enables the designers to work in a more effective and collaborative fashion.

Ready to experience a truly unified electronics design environment? Start your free trial of Altium Designer and discover how extensions and the Altium 365 application suite can help you work smarter, not harder.