Parts Database | Deferred Procrastination

As design work continues towards a prototype, which will be simultaneously available as a development kit, the increasing number of parts is beginning to need an planned method of organisation; and one that can be used indefinitely, even as parts change and are refined.

As I want to make the whole project open source, meaning open access to the design documents, that means I have to use a parts definition that is easy to understand; is extendible for more parts to be created; and, because this is a continual design/refinement process, allows for parts revisions.

I’m intending to use a numerical format split by parts group (sub-assembly), part number within that group, and a version number, each one being three numeric characters.

This gives a format of:

A_P_V This way, updating a part just means updating the version number. An entire assembly or group of parts would be specified by:
A_V Which defines a versioned set of parts (part and version number -- because a group of connected parts is likely to need to be revised togther, but some may remain unaltered). And each vehicle version can be identified just by:
V Which specifies a set of versioned assembly numbers. This format should make it easier to find parts than just a set of sequential numbers with no context. This way part numbers relate to position or function on the vehicle as well as show the specific part revision. It should be easy to find a part number by it's position. Find the area or structure where the part is, and find the part number on an exploded diagram. And it should also be fairly clear from a part number where it goes: steering wheel mounting plates will all have the same assembly number, which is different from chassis parts, or front axle assembly parts. Obviously where assemblies join and parts could be in either assembly group, they would only have one part number, but might appear in two diagrams. _Can anyone see a particular problem with that specification, or suggest a better one (before I have _too_ many parts to re-number)?_ The whole point of this is to make it easier for anyone to find the details of the parts of Atomic Duck, and this includes having a publicly accessible parts database. Each part version then gets to have it's own page with details, specification, technical drawings and CAD models; all organised by vehicle version, assembly type, assembly version and part version. Obviously, this is the kind of thing that databases were made for (!) but it needs to be human readable. I'm using TikiWiki for the parts databse, MediaWiki is a little too democratic enough for a top down project like this, and TikiWiki has more fine-grained permission controls. This also give me the right kind of space to start constructing the build instructions…

Post meta

Taggged:

Browse posts

Comments

podcake wrote, “Hello Paddy, you are making some serious progress here. I have one thought about this that might get somewhat confusing. I think that updating an assembly number and a part number is good. It does, however, seem that you have 'V' three times, is this three version numbers or one the same throughout. My concern is that if they are the same and you decide to update a part ( say something so trivial as taking a sharp corner off a piece of metal on the rear bulkhead for example) this may well constitute a 'part number version change' as it is a different version of the part. This change is, one presumes, so trivial that it surely should not mean a vehicle version number change? if they are differnet, ( ie: vehicle version and assembly version are different) might i suggest the use of other descriptors. maybe the Vehicle is a 'MK' (like MK2 escort) the assembly is a 'version' and the part is a 'revision' just a thought for you to mull over.. PoD out”

Patrick Fenner wrote, “Three different versions numbers. I suppose that's why software uses additional numerals for increasingly minor updates. Maybe any revision at a part level could have one part number (R001, R002, R003,…), assembly could be versioned depending on the impact of the change (V1-2-1, V0.1.5, V1·0,…) and vehicle could have model, similar to the format of assembly version (M1-2-1, M0.1.5, M1·0,…).”

podcake wrote, “maybe thus, obviously a far nicer way WILL exist: cycle 1.0 assembly 2.0 part 10.0 so the part is actually 1.0.2.0.10.0 ( in effect) so if you update the part ( but it still fits the assembly) you have 1.0.2.1.10.1 ( it is still part 10 on assembly 2 but it is the 2nd version of them both) were you to then update part 7.0 to 7.1 you would have: 1.0.2.2.7.1 (as it were) that way you know exactly which assembly, which version, which version of the part and which model pod out”

podcake wrote, “in fact thinking about that poses another issue, I'll debate it in my head when I have a moment. but basically if you update just the part number and not the assembly number it works better. let the 1st number of each mean which part, the 2nd number mean which revision, but if a new part still fits an old assembly its not a new assembly, just a new part.... also until the design is fully finalized it is traditional for the part number to be 0.1 or 0.4 or whatever ( 1 implies the first proper version)”

Patrick Fenner wrote, “I'm not sure about including the assembly version and vehicle model in the part data because then a single part update means any part update changes every part number. Keeping the model, assembly and part revision info separate makes it more like tagging, and less like folders… although it does mean an external list of parts/revisions is needed to specify a the part revisions. However, it would still be reasonable to give a concatenated set of data for a single part like: M0.1_A001_V0.1_P001_R001 which is: M_A_V_P_R”

Blog comments are closed, please get in touch with us.