Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Engineering Revision Control Procedures

Status
Not open for further replies.

Swiftest

Aerospace
Aug 14, 2018
5
0
0
US
We are revamping our engineering practices here, and a common case came up that brought a question to mind.
Our engineering team works closely with our programming team on new products. There is a lot of back and forth with the drawings and designs.

In this particular case the drawing was created and communicated to programming, who noticed a missing dimension and release date.
It is preliminary and technically unreleased. That being said, is a revision necessary when adding the dimension, or could it still qualify as initial release?

Or was it simply an engineering mistake to send the drawing to programming without a release? Granted it's being released to another engineering department, and has not
hit the floor or the schedule.

How much flexibility is there in the drawing standards for compartmentalization? Could we streamline the engineering process between departments by stamping our
drawings "Preliminary" to avoid multiple revisions during the release process?

Thanks for any advice.
 
Replies continue below

Recommended for you

You could hire a checker.

Failing that, once it gets out of your personal control, there could be an infinity of incorrect copies that are guaranteed to surface at the most inopportune time.

I'd issue a revision. Whether you allow informal/minor revisions for typos and such is something to be included in your revised design standards.



Mike Halloran
Pembroke Pines, FL, USA
 
There's always the question over what release is relevant, and what bug fixes or other rectification gets applied to make sure that the identified issue has been negated.

A lot of it depends on how formal and involved your release process is (i.e. if its all paper based, and involves wet signatures of artefacts then there's usually a push for 'just release it with the same revision' rather than push for a new release). It also, as you noted, depends on who the artefact gets released to as to whether a new iteration gets released.

'Was it simply an engineering mistake' - Probably. That doesn't change the issue, rather the need to iterate has been identified for a particular reason, regardless of how it came about.

This is a software centric basis for identification of revisions, and a means to identify a minor versus major release. I agree with the assertion though, that a change requires a revision iteration, although I'm aware that the practicalities of doing so may not be easy.

EDMS Australia
 
Depending on the level of trust in your organization you could implement a 'None' revision to correct an inconsequential error (spelling mistake 'Weld' replaces 'Wled' or remove stray geometry, change drawing size or border)where an end user could use either print (rev A or rev None directly after rev A) without issue.

Screw up once and include a consequential change under the 'None' revision (12" was 10") and you lose that trust

I've worked in companies where we ran numerical revisions during the development process and switched to alpha for release
 
I understand the need purposes of revisions after release, but this hasn't been released to the floor yet. To me its a simple compartmentalization of
enginnering. Viewing the entire engineering department as an entity vs. needing revisions between your drafter, detailer, and process engineer.
Upon looking through the ASME Y14.35M on Revision standards, it leaves quite a bit open to interpretation. Especially with these inconsequential
drafting errors like misspellings or missing constraints which are present in the solid model, but not on the drawing. I've seen it at other
companies I've worked for where these drafts of the drawings were passed around with a stamp across "PRELIMINARY" and revisions were never rolled.

This leads me to my next question, if our ISO requires a revision roll for these, what would be the process for changing the standard?
Signatures from auditors? Mass Emails to customers? etc.

 
Logically, if you change your internal standards, you need to update external copies, too.
Easy if you keep track of who got what.


Mike Halloran
Pembroke Pines, FL, USA
 
For documents that haven't been released yet but need to be shared outside of the owning department, we "stamp" them with a preliminary notice or watermark and the date and time. That way, anyone can easily see if they have the most current version (not revision).

For other quick fixes, like typos, we actually prepend the document with a NOTICE. The notice gets added to the first sheet of the document so it can't be ignored, and the notice states the clerical changes were made to the document. The document is fixed and re-released under the same revision. I don't like it, and I motivate the company to not abuse it, but it has its place in certain circumstances. One hard rule is that notices are for clerical errors only. The procedure defining the use of notices is explicit regarding their application.

--Scott
www.aerornd.com
 
Swiftest,

When you do a formal revision, you should describe what you did.

REV-A ADDED MISSING DIMENSION. NO CHANGE TO PART.

--
JHG
 
Status
Not open for further replies.
Back
Top