Setup idea for engineering R&D projects

10-19 Concepts 14 Build your system
1

I’ve been thinking for a few weeks now, about a system to manage an upcoming university project, on a per device base, and I also got carried away thinking about organizing future projects. The system was starting to get into shape, based mainly on a specific system I saw elsewhere, but it felt a bit incomplete. That’s when I found the Johnny.Decimal system, and after applying a few ides from it, I think that my system is getting close to being usable, and I’m now curious what people think about it.

So my base problem was that we need to track and organize files related to devices. Circuit diagrams, PCB layouts, configurations, programs, so basically both the hardware and software of a device. I decided to go with the PRO.AC.ID format and change it up according to our needs. PRO would stay the same, and serve the same purpose, identifying projects. AC would similarly stay the same format, but it would identify a standardized set of subsystems, like say 42 would be “fuel cell” and it would be that within every project to come. This folder would contain all the control and measurement equipment necessary for that subsystem. I think a 100 subsystem types should be more than enough for what we do. Now ID is a bit more interesting, the format would be changed to 2 letters 1 number. The letters would again be standardized e.g.: “MT” would mean motor. The number is just simply incremented. A full device ID would look something like this: “B23.11.MT0”. This whole system’s main strength would be, that even within an unknown project, you could get around just by glancing at the full IDs.

Now there are some things I’m still not really sure about. Mainly, how would files be handled which are not connected to a device? Just for the record, we wont have many of these, a general project description, a bill of materials, and an index file, that’s all that’s needed. I was thinking about just leaving these in the project’s folder directly, like say B23.GEN, B23.BOM, and B23.IND. Yes this would alienate them from the systems, but maybe that’s not a bad thing, they are still easily found, and recognizable after all, but I’m open to ideas on this.

2

On first read this sounds like a really nice system.

Couldn’t the files just fit in to a category so that all identifiers are consistent? So you’ve got B23.11.MT0, let’s say you use category 00 for your files, then you’d have B23.00.GEN, B23.00.BOM, and so on?

3

I think that would be a good solution yes. The system probably wont be implemented fully till September, but I will give updates on anything I come with(e.g.: the standardized letters)until then. Thanks for the help!

4

I’ve been part of a long running project that used a J.D.-ish system. (I’ve realized later) it used multiple devices in several products, so I figured I might share. Maybe it will be of some use.

First off; this was implemented metadata, so all documents were in a single large table and you would slice and dice to get the documents you needed. Therefore it may be less appropriate for a regular file system.

You define the following areas and categories:

  • 10-19 Top level is the top of the hierarchy. Each item in here cannot be subdivided further.
    • 10 Product family contains an abstract collection of a product (family). 10.01 Product A is an example. You would put things like project plans for Product A inside 10.01. (More on document naming later)
    • 11 Products is a representation of the top level of a physical product. It consists of all physical parts; packaging, labels, actual device, so forth. Important; you don’t specify those items here, only reference. Just as there is a category for complete products there is a category for labels, packaging, devices, etc.

You continue to separate your items/parts/components using areas. Some suggestions:

  • 20-29 Parts and subassemblies
  • 30-39 Mechanical parts
  • 40-49 Electronic components
  • 50-59 Software
  • Reserve 90-99 Organization for things that don’t relate to a product. This could be procedures, equipment, etc.

Inside each area you categorize; e.g. 31 3D printed. Then each part gets its ID; e.g. 31.01 Lid hatch.

At this point, it is all purely abstract. Next, you define a list of document types and assign them a three letter abbreviation. For instance, CAD.

Now you are ready to create a document. Select your part and document type and assign it a unique number for that specific combination. Your document name will then be 31.01CAD01 Lid hatch model, with the first part being the unique identifier.

If your system supports the metadata, you can then quickly find groups of documents.

I’ve found this to be very effective. (I can take absolutely no credit for this, I haven’t made the slightest improvement)

This solves the issue of reusing a component in multiple devices. For instance, your fuel cell might be used in two devices. How do you handle duplication and syncing in a reliable manner?

I think there is a very important distinction between this system and J.D. J.D. is very intuitive and concrete.
The system here requires you to link the parts. For example, if 11.01 Product A contains 21.15 Subassembly B, how would you know? (We used the BOM) How do you decide if 11.01 Product A contains 62.05 Application C, or is it part of 43.33 iPad 6th gen?

All that is defined by convention and familiarity with the system, which increases the odds of decay. We’ve managed to keep it working with close to 2000 documents of 5 years, but we regularly discuss it. (Especially in the beginning)

1 Like