Configuration Management

2023-11-20 · 15 min read
configuration management

Technical debt is like entropy, slowly creating more disorder in a project. There are many forms that technical dept can take, but one of the large reasons is due to lack of Configuration and Data Management. Configuration Management is documenting a product through its lifecycle, including:

The key is finding a lightweight set of tools and processes that promotes good record keeping.

Project Scoping

Scoping a robotics project includes:

  • Defining the application problem, and goal.
  • Defining a Concept of Operations, of how your robotics system will perform tasks to accomplish the application goals.
  • Creating a Verification test plan, to check that the final system can perform the Concept of Operations.
  • Defining requirements for the system.
  • Creating a Validation test plan, to check that each requirement is met, or to document defficiencies.
  • Creating a Block Diagram, and possibly a wiring diagram.
  • Separating the system functions into subsystems, including requirements and functional tests.

There are several tasks in this list that will require you to create some documentation. You should be saving these documents as files in your PLM tool, against the Item that they are related to. This Item could be the top level assembly that you intend to create, or one of its children subassemblies.

Design

PLM

Your project should include a Product-Lifecycle-Management (PLM) tool. This is some way of creating unique Item Numbers to store the items related information:

  • Item Number.
  • Item Name.
  • Revision.
  • Files, which can including drawings, datasheets, source CAD, and other technical documentation.
  • Sourcing information, including distributors and suppliers.
  • Bill-Of-Materials if the Item is an assembly comprised of other Items from your project.

A spreadsheet can be used to track this information, but you can save a significant amount of time by using PLM software even for small projects.

Data Management

Common datamanagement practices for revision controlling data include:

  • Mechanical and Electrical source CAD, using Windows File Explorer, naming files with the Item Number and revision.
  • Mechancal source CAD, using PDM software Product Data Management.
  • Electrical CAD using SVN or Git.
  • Software source using Git.
  • Documentation manuals using Git, or a version controlling wordprocessor like Google Docs.

Build

Quality Control

When parts enter your facility, you can perform Quality Control checks to confirm that the incoming parts form meets the technical reqirements you listed for the related Item.

For example: if you order a M4×0.7 X 10 Round Head Stainless Steel Screw you expect it to conform to the standard ISO 7380. The rigor of you checks should depend on how critical you project's application is. For this example, it may be acceptable to visually check that:

  • The packaging says it containts M4×0.7 X 10 Round Head Stainless Steel Screws
  • The screws have threads
  • The screws have a hex cutout for tightening them
  • The head diameter is less than Ø8 mm

After these checks you can place the incoming parts in a bin labeled with your Item Number for M4×0.7 X 10 Round Head Stainless Steel Screws.

Revisions Through Build

A Item Number should be uniquie, and have a defined set of requirements. These defined requirements are what let you know that a physical object can be called Project Item XXXXXX. Similarly, the assmbly you intend to build will have a unique Item Number.

NOTE A unique assembly is not synonymous with a Marketing Product Name. For example, you can configure a MacBook with different components, such as Screensizes, Colour, Processor, RAM, and Storage. These different configured assembles would have their own uniquie Item Numbers or SKUs. MacBook does not define a unique Item, but covers a range of varaiants.

As you build your assmebly, you may notice issues with the inteded design, such as a hole being too small, or a connector having an non-ideal pinout. You should update your design if you decide to deviate from the design to make a more ideal assembly. Updates can be made by revising an existing Item, or be creating a new Item in your PLM system.

Be cognizant of your revision process, and try to make it simple enough to promote making design updates, while maintinging good records of the product history.

Testing

Your test plans will have been defined in the Project Scoping stage of the project. It will depend on the rigor of your project of how you document that you have run tests, with artifacts of the results. As a lightwight option, you could use a tool like Jira or Trello for each test, and then save hyperlinks of these tickets to your PLM tool. Heavier, more thorough options include tools like IBM's DOORS or Jama's Connect.

Overall, you want to run tests, document what the results were, and then cause some action to the project:

  1. Accept the design as-is, since it successfully completed the test
  2. Accept the design as-is, noting that the design does not comply with the initial requirements.
  3. Redesign and build aspects of the assembly, and then test it again to see if it is compliant with the initial requirements.

Deployment and Servicing and Reirement

Depending on your application, you may want to track each fielded unit that has been built. For example, cars have a unique Vehicle Identification Number (VIN) that includes information like, when it was manufactured, and the variant of it, (colour, engine size, interior options, etc). Manufacturers' maintain a database of every VIN. This database includes:

  • Who owns the vehicle with this VIN, and how to contact this person.
  • The shipped configuration of the vehicle.
  • The intended configuration of the vehicle.
  • The current configuration of the vehicle.

This allows manufacturers to contact owners who should replace a component due to a safety recall.

NOTE There are other reasons for VINs and Serial Numbers. This example is intended to show how Serial Numbers are used for configuration management of Items through their lifecycle.

Updates and Upgrades

Updates are either:

  1. A change where both old configuration or the new one are interchangeable.
  2. A change to the design, where all fielded assembles get updated to match the new design.
  3. A change to the design, where some of the fielded assemblies get updated, where the new design is an upgrade.

A new revision of the affected assemblies is the accepted practice for scenarios 1 and 2. Typically, a new top level Item would be created for scenario 3, since it is effectively a new product variant.

Obsolescence

There are a few reasons you may want to document when designs are considered obsolete:

  • For safety or regulatory reasons.
  • To discourage people from building obsolete designs.
  • To redirect people to replacement designs.
  • To help identify and dispose of unused child items from inventory.