Fork over your engineering changes

While drafting boards and vellum are either a distant memory or a perplexing Wikipedia look-up for the younger set, most engineers are still handling design changes like chain smoking and leaded gasoline are still all the rage.

We’ve grown a little complacent to the change techniques that were carefully crafted to work within the limitations of the past: checking things out one at a time, revising linear histories, and writing ECOs as separately released changes. The cloud has introduced new technology that is fostering a collaboration renaissance. It very well may transform how engineering is revised forever.

An eternity of linearity

Classical engineering change is highly linear, purposefully invented within the limitations of the physical realm, when designs were kept in a physical vault. Even as software has developed over time, physical vaults were merely replaced with digital ones operating under the same principles. The paradigm was only enhanced, not transformed. Only one person at a time can work on anything (check-out, check-in) and ECOs are heavily favored over direct revision in many cases, regardless of the stupid cost of unincorporated change.

This is especially true when identified change is implemented out of sequence, or when change is applied to a specific variant of the product either according to service date, production lot, target customer, or various other stipulations. Products becoming more complex doesn’t help matters, often requiring a variety of complex management solutions like effectivity or configured variants to handle pesky change on change scenarios.

Sounds like engineering has to stay in linear purgatory, and ECOs must continue to spew forth until the end of time, doesn’t it?

And now for something completely different

As all design going forward is exclusively in the digital realm, the physical limitations in handling change are no longer necessary, they are a choice. For an alternative we need only look to another industry struggling with enormously complex products constantly overwhelmed by multiple sources of non-sequential change authored by large, diverse teams constantly perturbing configuration.

Of course, we’re talking about software source control.

If software is eating the world, then source control might very well eat engineering change and configuration management. It’s only possible now because cloud solutions are abstracting away from conventional file systems and file-centric database structures.

What that means to you: Save and SaveAs may just go away. The digital vault no longer has to be a facsimile of the traditional physical vault.

Calm damaging DAGs

The key in source control is that it’s entirely non-linear. I could get into a protracted discussion about Directed Acyclic Graphs (do ya like DAGs?) but it might begin to damage your calm. So instead I’ll show you a picture:

Untitled

Via http://nvie.com/posts/a-successful-git-branching-model/

Traditional engineering change is a single line, each change comes sequentially and inseparably. The model severely limits how you handle out of sequence change, but makes changes easy to manage and implement. In source control, however, change can be isolated on its own “fork” on a whim, occurring in parallel with any number of other change forks. Think of forks as a branch on an inverted tree from a common earlier version. In addition any of the forks can be merged back into the main product line at any future time or with each other, or left out to grow as a full alternative design. In the case of a merge you look at differences between each fork and resolve any overlapping conflicts where different changes exist for the same feature.

Resolving those differences is appropriately called a “diff.” With each fork, merge, or even new version in any given fork, metadata can be stored. That’s where we’ll maybe see things like Fork Change Order (FCO) or Merge Change Order (MCO) in the future. It sounds complicated (and it is) but the model is extremely powerful and applicable to engineering design. The paradigm removes the consequences of change, allows collaboration to happen in parallel, and permits an infinite combination of change upon change for even the most complex development process. All around, it’s pretty heavy.

Famously, Github has popularized software source control for both individuals and companies – taking some (but definitely not all) of the rough edges of handling a more labor intensive distributed Git repository (or “repo” as we like to say around the cool kids). Expect to see a lot of Github-like functionality popping up everywhere in the CAD landscape. It’s already started with products like Onshape, but this is only the beginning.

But Why Should We Bother?

If it ain’t broke don’t fix it. Expect objection from older engineers especially at the mere suggestion of changing some of the most sacred and long-lived engineering practices (like ECOs for example). Current check-in/out and ECO change management works, right? That’s not the point – the point is what we need to evolve engineering change for the future. It’s kind of like coal for power – sure it works quite well now, but you know in the long term, it’s time to move to something better. Look at it this way: it’s yet another change on change.

 


 

  • Yes, yes, and yes! I was just thinking about GitHub and how it works versus modern engineering collaborative practices. I totally am with you on this idea, particularly when it is a large-scale open-source piece of work. Imagine how we could change the world if the brains of many worked together on something for the sake of design, not the brains of few working together to turn a company profit.

    I believe that the biggest challenge associated with this concept is the fragmentation of CAD systems. With GitHub, you can basically use any text editor and it works. With CAD, you will find some consequential limitations in opening a model in 2 different software programs. although, even that could be worked around if the community knows to avoid using tools that limit others (configurations in SolidWorks jump out, first), especially if the collaborative cloud-based tool can download the models in a universal format, such as a STP or IGES.

  • Christopher Maher

    Alex may have a point with some collaborative open source project, but I don’t see how this works with a more traditional company.

    Once I lock down a design through the release process; procurement goes out to get quotes then ultimately a contract is made with a shop to produce a part to a specific requirement (the released engineering drawing). If something is changed, we must go out and get cost impacts from the supplier based on the new revision (which is formally released through an ECO process).

    If I’m having a prototype part made in our internal shop I sometimes have a little more flexibility/freedom to make changes or work with unreleased engineering, but it doesn’t come without risk. It’s not uncommon to see parts being made to the incorrect version of a drawing because of a miscommunication between the engineer and the shop.

    It seems like it works for software because it is so compartmentalized now that you can push and pull modules in and out of it without disturbing the core. If I’m working a complicated part file, I don’t really want others tweaking the file because of how interconnected features are (not to say I don’t want input from others). If by some chance someone was working a parallel effort to mine and there model file/design became the new baseline; we could just “fork” over to it and ditch the version I’m working on.

    I think there must be ways to improve the flow when you are at the high-level conceptual phase (determining the basic system architecture) because it gets clumsy just using ‘save as’ to make a random assy names as you are trying new concepts. For the bulk of the work, when it is more doing detail design and getting hardware made; I appreciate the security check-in/check-out gives you (Creo/Windchill for me).