Step 0: Kick-off Development Cycle

The kick-off is essential to inform everyone that the object is now in-flight for another development cycle. The steps for kick-off are:

For information about how an object is designed, reference In Action Product Design Process.

For information regarding Testing Criteria, reference Basic Hardware Testing Criteria.

Step 1: Create Design Artifacts

The first step of the design and manufacture of mechanicals is to create all of the relevant design and production artifacts (files).

We are currently using Solidworks, Rhino, or Illustrator to design Mechanicals. Production documentation (drawings) is executed in Solidworks and output as PDF. Derivative CAD format files (those sent to vendors) are SLDPRT, STEP or EPS, depending on manufacturing process.

Step 2: Create a Prototype (Designer, ProtoMgr)

To validate the design we produce an in-house prototype when possible. This is a somewhat lightweight process and is not a tagged GitHub release, because there may be many of them.

Step 3: Test the Prototype (HWTE, Designer)

Hand off the document package to the Designer.

Step 4: Create Release Candidate (RC) Artifacts (Designer)

For a mechanical/housing manufacturing run, the release package contains the following documents, as appropriate to the design and type of manufacturing process (in other words, not all designs will require each of the file types below). The filenames derive from the base product ID, e.g. POSCON.XXXXXX

CNC Manufacturing typical file sets

File Example Prod/Design Folder
Drawing POSCON.FACE.dxf Production
Drawing POSCON.FACE.pdf Production
Vector File POSCON.FACE.eps Production (if lasercut)
Solidworks File POSCON.FACE.SLDPRT Production (if CNC)
STEP file POSCON.FACE.STEP Production (if CNC)

Lasercutting File typical file set:

File Example Prod/Design Folder
Drawing POSCON.FACE.pdf Production
Vector File POSCON.FACE.dxf Production
Vector File P2X142 POSCON.FACE.eps Production (if lasercut)
README POSCON.FACE.README.docx Production (if lasercut):

Lasercut production file naming convention:

3D Printed File typical file set:

File Example Prod/Design Folder
Drawing POSCON.FACE.stl Production
Drawing POSCON.FACE.pdf Production

Bill of Materials, Engineering Change Order file set:

File Example Prod/Design Folder
BOM POSCON.MECH.BOM.xlsx Production
ECO POSCON.FACE.eco.xlsx Production

A typical release package would include some combination of:

Editing ECOs:

If changing the design of a previously released object, best practice is to update and commit the ECO as the object is being designed.

If working on a new production object, follow these steps:

If working on a previously released production object, follow these steps:

These changes should also be reflected in the commit messages in Git.

If there is a design change to any part in the assembly, the entire assembly needs to increment, but other drawings in the same assembly that are separate and not changed do not need to increment. Any levels above the re-versioned assembly will also need to increment.

Ensure that drawings made for production (other than laser cutting) comply with ANSI Standards:

For a complete ANSI checklist, refer to ANSI Dimensioning Guidelines v1.1.

Step 5: Commit the Release Candidate Package to GitHub

When working with RC files, best practices dictate that all files being created, edited and committed to GitHub be managed from the same place to keep the workflow consistent.

Step 6: Release Checklist

Step 7: Build RC Articles (ProdMgr & HWTE)

Once a part releases as RC, we send the release package to the CMS for a request to quote for manufacture. RC articles are not needed if the same outside CM has manufactured the prototype, and the same design has been approved for production with no changes. If either the design or manufacturing process changes from the approved prototype, RC articles are needed.

Hand off the document package to the Production Manager.

The CMS is not allowed to make any changes to this package without first looping back to Codeshelf to obtain an approved ECO. If we receive an ECR from the CMS, we review it and decide if we will approve the change. If we agree to approve the change, then we capture that change in the appropriate documents (BOM, ECO, etc.) and re-release the product with these changes, incrementing the tag.

Hand off the document package to the Hardware Test Engineer when RC Articles are complete and delivered.

Step 8: Test and Validate RC Articles (HWTE & Designer)

RC articles must be approved by the HWTE / designer in order to release for production.

Hand off the document package to the Hardware Test Engineer.

If the HWTE approves the device for production then proceed to step 9, otherwise go back to step 4. Step 9: Release Tag (Designer)

Hand off the document package to the designer/engineer.

When RC articles are proven good and approved for production:

Github automatically notifies ProdMgr of the release.

Hand off the document package to the Production Manager.

Step 10: Release Announcement (ProdMgr)

Issue a release announcement
Update the Current and Planned Hardware Releases and Products in need of release documents.

The item is then cleared for ongoing production.

Step 11: Post Release Review (ProdMgr)