It is SSM’s charter to explore Open Design methodology in an automotive engineering environment. There are at least two aspects of this Open Design Infrastructure: Licensing and tools. We already have a draft version of the license in place and it’s working out well so far. Now we need to look at the tool aspect of the problem. And, we are seeking public advice on our go-forward plan.

Overview

To enable Open Design, the infrastructure should offer a collaborative development environment, preferably web-based for ease of access and not requiring users to own or download any special software tools - which means significant departure from proprietary PDM (Product Data Management) or PLM (Product Lifecycle Management) tools.

There are two levels of considerations: groupware and documentation repository. Groupware is one that manages users, enables discussions, shares files, assigns project tasks, event calendars, etc. essentially a virtual office in a global level. SourceForge is an example, except ours will need to have better documentation and product data/product structure capabilities specific to system development(hardware and software).

PDM/PLM Requirements

We will need PDM (Product Data Management) or PLM (Product Lifecycle Management) or combination of the two. For those who are not familiar with manufacturing process, generally speaking, it has the following capabilities:

1. maintain product structure (construct parts lists and bills of material)
2. configuration control (product configuration - you know what you get when you specify a part number - software being part of it)
3. drawing/parts approval process (enforcement of signature cycles)
4. revision control (keep track of all changes)
5. change management: problem reporting, change requests, feature requests (more common in open source projects), etc.
6. interfaces with procurement system, MRP and parts database.
7. being able to find parent parts and child parts
8. track reworks of actual parts (changes made to a particular serial number)
(have I missed anything?)

And for our project, we also need:
9. document control (for writing specifications)
10. requirement traceability
11. repository for CAD models and simulation data
12. Daily capture of changes and timestamping via a third party (e.g. DigiStamp.com)

Here are commonly found objects in a PDM system are Piece Parts, Assemblies (a list of piece parts) and documents describing the parts/assemblies.

We are currently in the system-level design of the Kernel CDV1. An online documentation tool that provides Rich Text editing similar to Microsoft Word is highly desirable. An open source, royalty-free software package is also desirable.

MediaWiki Proposal

After evaluating several options, MediaWiki, although deficient in a lot of ways as a PDM/PLM tool, seems to be the most helpful at this time.

MediaWiki (as is or with some minor changes or usage rules) can do requirement # 1, 2, 4, 5, 7, 9 and 11 above. Item 6 and 8 are not as critical at this time (but will be, in a few years). So it’s pretty close, if we could hack it into doing the other things, this could actually become de facto for future open-design projects.

Possible implementation:

First, create a page for each design part / assembly. Each page will contain specific information about the part, including: part identification, applicable specifications and standards, outstanding problem reports/change requests/ECOs, possible vendors, suggested off-the-shelf parts, other references;

Requirement #1 Maintain product structure:  Each page will represent a design part. It will be mandatory to enter parent part(s) and child parts in a designated section of the page.

Requirement #2 configuration control: MediaWiki allows editors to lock the content of a page. What we could do is to lock the page of the assembly, which contains a parts list, then recursively lock all lower level assemblies - until the entire configuration is determined. A person will be designated the Configuration Manager, whose responsibility is to ensure the integrity of the product structure.

Requirement #4 revision control: This feature is built in. All modifications are logged in the MediaWiki database, allowing the administrator to revert any page to a previous state.

Requirement #5 change management: This is really weak but we could use the “discussion” page for tracking changes and problem reports.

Requirement #7 being able to find parent parts and child parts: See implementation of Requirement #1 above.

Requirement #9 document control: That’s exactly what Wiki is for.

Requirement #10 requirement traceability: This will need some work, including modifying wiki to assign a unique identification number to each section of a document, thus allowing a lower level specification to trace up to it.

Requirement #11 repository: Wiki has a built-in function to store uploaded files.

After all, MediaWiki is known for its:
1. Revision control
2. Ease of use
3. Platform independence
4. Scalability
5. Stability and security

Shall we proceed with MediaWiki? Are there any other suggestions?

Other Information

Part numbering is usually organization specific. For us, part numbers will be formatted: K01-100001. For assemblies, we have a “dash” number suffix, like: K01-100001-01 denoting different configurations. Documents will have a suffix like K01-100001SCD , based on its type.