CAD User Online Article Archive

Feature

The five pillars of EDM

From CAD User Mechanical Magazine Vol 22 No 4 - APRIL/MAY 2009

Installing a generic enterprise content management system in your design department? FirstTrace reckons you have to ensure your engineering document requirements are also met - and have lain down a set of rules to help you do just that, as Albert Whipple of FirstTrace explained to me recently!

Engineering document management systems range from simple, single file configurations to complex, hierarchical models with many file types and significant parent-child relationships as well as ad-hoc relationships between files. They tend to fall into two categories: Engineering-specific applications that meet most engineering requirements, or generic/enterprise applications with added engineering modules.

The former tend to be very configurable, and often difficult to use - a significant impediment to rolling it out to a wider enterprise audience. Generic enterprise solutions, though, don’t cover all engineering requirements and merely include minimal additional work by engineers, creating separate document control groups to coordinate the document management process.

So we now have two distinct lines of development. If your company is going to invest in a full EDM solution, though, you really need to know what an engineering solution should contain.That means looking at the critical structures that drive engineering organizations - the product and resource allocation hierarchy, product groupings, and deliverable items (the documents, of course) extending to project schedules, bill of materials, design specification, and design files - all explained to me by Albert Whipple of FirstTrace, experts in Engineering Document Management, and laid out in their White Paper - The Five Pillars of EDM.

VERSION CONTROL

Engineering documents start out as uncontrolled documents and progress through a sequence of events until they are placed under configuration control. Each change to a document results in a new version, with the contents of the previous version preserved.

Documents are stored in controlled and uncontrolled format in numerous locations

-private local storage (My Documents), shared uncontrolled storage (the G drive), and shared version controlled storage (the vault). Documents under version control also inherit a security model that provides access control (View, Read, Write, Update, Delete), and access to various application functions based on a configurable set of roles. The Check Out function, for example, may not be available to a user who only has a View role. Engineering tools allow users to define properties or meta-data to capture vital information about the document, such as part numbers, serial numbers, component types, values, tolerances, etc. To make it easy to get at this information, it is necessary to provide version-specific property sets. An example might be: Revision A of a part has a part number A12345, while Revision B of the same part has a part number A12345-1. Assemblies referencing the part may produce incorrect part lists if only the Revision B part number is available.

This leads to complex version controls that have to include revision sequencing or branching and merging. The former is a key part of the configuration management plan. A typical revision sequence might be: Initial Revision 0, modify and release to A, modify and release to B, etc. with the Revision Label simply a property of a unique version of a document. Revision sequences also need to be flexible, as they may change based on criteria such as product, contract, division, and so on.

Branching is the ability to create unique parallel branches in a version hierarchy, useful for tracking specific engineering prototypes or information such as equipment configuration, facilities layout, etc. Merging enables users to converge branches.

Engineering applications provide standard libraries of components, or allow users to create custom libraries, used to create standard parts lists, project parts lists, process standardization lists, etc. Document management systems should be able to reference library parts externally, because they can get very large. In practice, a hybrid assembly may reference version controlled documents from the document management system as well as uncontrolled library parts.

Most engineering tools allow comparison and analysis of independent files, and should also provide an ability to compare two versions of the same document to identify changes or differences.

RELATIONSHIP MANAGEMENT

Relationships between documents are important, and an EDM system should allow documents to reference specific versions of other documents - Version A of an assembly referencing parts in Revision B, and so on.

Relationship objects should also allow property sets that can control document management functions for behaviour between two objects. For example, Check Out of an assembly also requires Check Out of the related document. These properties are specific to each relationship, so configuration by file type, document type, or document category becomes possible (i.e. Check Out all of the model files [.dwg] and Copy Out all other references [.doc, .xls, .pdf, etc.]). For security purposes, relationships should also convey access control and roles.

DOCUMENT LIFE CYCLE MANAGEMENT

The document life cycle model describes the life cycle phases of a document as well as the valid document states within each phase. The document management function chain of events comprises a sequence that can be configured by group, document type, life cycle phase, etc.

For example, the Release function in the Design phase would consist of a document Lock, change of State to Pending Release, launch of an Approval Workflow, generation of PDF renditions of the CAD models after approval, setting the State of the documents to Released, and Publication of the Release Package to a controlled location. A complex automatic set of procedures - that should, nevertheless, also allow for user intervention and modification at any stage.

Document objects should contain property sets specific to the role of the user - designers accessing properties related to design such as component value, tolerance, and packaging, and manufacturers properties such as process

capability, DPMO, sigma level, upper and lower specification limits, etc. Users with design and production roles may want to access both property sets.

Document access control can be managed based on life cycle state, which should, of course, include, full access auditing including read, write, update, and delete.

DISTRIBUTION/PUBLICATION

An EDM should be able to create structured hierarchies or taxonomies used for document categorization as well as specific hierarchies (or folksonomies) by life cycle phase used for searching and ease of access. It should also be able to generate common file formats for viewing and collaboration such as pdf, eDrawings, or dwf. and support distribution and deployment of content and packages.

The document management system should also allow notification initiated by triggers such as read, update, and delete.

APPLICATION/INTEGRATION

It goes without saying that an EDM system should be well integrated with engineering applications, providing uniform access to documents and applications, at both user and API level, in a smooth and intuitive manner. And they should be capable of providing two-way synchronization between CAD relationships and document management system relationships.

Going further, an EDM should generate triggers or event hooks to implement auditing, content management and customizations using scripts or workflows. It should monitor documents, using triggers to notify users of changes being made to related documents.

A demanding engineering scenario with complex repository features - as we have seen - needs a comprehensive search facility, allowing for property and content searches, and able to include links to

referenced objects - regardless of the data source. It should allows users to search, access and aggregate files from distributed repositories so there is no need to modify regular work habits, utilise multiple document management applications simultaneously or invest in time consuming data migration projects.

THE KINNOSAONE SOLUTION

First Trace has developed an evolutionary product family called KinnosaONE that addresses all Five Pillars of Engineering Document Management. The 'ONE' refers to its focus on seeing engineering departments become a part of a single document environment for the entire enterprise. The KinnosaONE family consists of two product lines, Korrigo and Kinnosa. Both products integrate with CAD tools from Autodesk, SolidWorks, and Bentley, as well as desktop applications such as Windows Explorer, Microsoft Word, Excel, and OpenOffice.

Korrigo is an 'Enterprise-Ready' EDM product designed for customers who have a primary interest in their CAD environment but are concerned about future connectivity with the greater enterprise.

Kinnosa is First Trace's 'Enterprise- Compatible' EDM product, bridging the gap between engineering and the enterprise. Through its open architecture, Kinnosa can unify and manage data in enterprise systems such as EMC Documentum, Microsoft SharePoint, IBM Lotus Notes, FileNet, Interwoven TeamSite, OpenText Livelink and more.

Kinnosa is the only document management solution built on industry standards with a true enterprise-capable architecture that is intuitive enough to be used by novice users and robust enough to serve the complex needs of engineering.

www.firsttrace.com

Feature

Click here for a Print Friendly Version

The products referenced in this site are provided by parties other than BTC. BTC makes no representations regarding either the products or any information about the products. Any questions, complaints, or claims regarding the products must be directed to the appropriate manufacturer or vendor. Click here for usage terms and conditions.
For Comments towards this website please contact the webmaster