Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

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

Views on submitting native files 1

Status
Not open for further replies.

dozer

Structural
Apr 9, 2001
502
I wondering what other's policy on releasing native analysis files (structural files like STAAD or RISA or pipe stress like Caesar II) to clients for review is. Historically, at companies I've worked at we typically don't do it. I have had a few cases where we are working closely with a client that is an engineering firm and we have released structural analysis input files that they can run themselves at their request.

I used to have a boss that claimed if someone reviewed calcs at that level then they were taking on responsibility for the design. I don't know if this is just something he said to get people to back off or if there is actually some validity to that legally.

I'm not crazy about handing out native files for a couple of reasons. For one, a less than scrupulous company might take your file and just change some dimensions and use it to create their own design. Perhaps a bit far fetched but I suppose it could happen, though I don't lay awake at night worrying about that. Another reason is that I've found when you give someone that much data they tend to question a lot of things. Heck, I'm guilty of that. If I get a STAAD (structural analysis) file from somebody I'll invariably find things that I would have done different. Maybe their judgment was that offsets were insignificant and didn't include them. I might not be convinced and think they should have modeled them. Now we're in a pissin' contest to see who will prevail.
 
Replies continue below

Recommended for you

Structural models are always an idealization, so like you mentionned, there are often differences of opinions on what is correct. The results are also open to interpretation as well to some degree. My preference would always be not to hand them over, but if that's what the client wants that's what they get.
 
I think that many would agree that alteration of input files is a definite possibility. PDFs of all documentation are a reasonable compromise. Any alterable files could be accompanied by a digital hash signature like SHA2 or SHA3 to ensure that intentional and unintentional changes to the documents can be readily detected.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529
 
Yep, I try to avoid sending native anything because of the danger of alteration - even by accident - leading to loss of 'configuration control'.

Obvious exception is if you're actually being paid (i.e. in the contract) to deliver native format.

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
This is mostly a contractual issue. This is the point where one learns to be much more explicit about the deliverable the client is paying for.
 
If you are concerned about files being altered, you can document the exact bit size and last save date of the files you send. Even the slightest change to your files will be reflected in this information.
 
Sadly in the FEA world it becomes apparent that some are less than competent when it comes to creating pretty colored stress diagrams from an FEA program. So if we repeat an analysis that your new graduate has performed and that passed your 'stringent' QC, exactly why are you frightened to give us your files?

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
I give them out, genrally we give them along with our calc set, I do have a clause in my contract that states any changes requested by the client to models due to difference of opinion, all changes will be done at hourly rates or to that effect. But genrally only use this if the changes are significant and unreasonable. If they find an error i see it as very good outcome, and we send a box of beer to say thanks. I am not perfect and i would rather find put before construction.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
 
I usually offer to include any services related to furnishing and reviewing engineering data on an hourly cost basis, so the client has this as an option. This can turn into a profit center all by itself. It's also an opening to get paid when the AHJ questions your engineering ad infinitem.
 
dozer,

I have on several occasions now, done safety calculations by hand using Microsoft Word. I have submitted these to the customer or to the customer's consulting engineer. I am not a professional engineer, so I am not authorized to stamp and seal stuff. This fact is clearly noted on my calculations. Under the circumstances, I have to submit the calculations.

The engineers who review my stuff have come back and asked what the heck I am doing. This has been a useful exercise. My calculations do not show the opto-electronics that make our systems actually work, so IP is not an issue. I archive my emails, so I can verify what I sent out. In my world, I don't see why the customer or his consultant would modify or copy my stuff. Your world sounds very different.

I have attached FEA output to my notes. I explained what I was working out, and I explained my FEA[ ]model. I believe I provided enough information that an engineer could reproduce my analysis on their software.

How useful is your FEA[ ]model if your customer is not running the same software you are?

--
JHG
 
What's that mechanic joke?

$50/hr mechanic work
$100/hr if you watch
$150/hr if you help

Seems like it might apply here.
 
My utility usually includes language in our contracts with consultants that native files shall be submitted upon request. We paid for the work, and we feel we are entitled to the files. This is particularly important when a consultant concludes that a structure or piece of equipment needs to be strengthened or down-rated. We need to verify before we spend millions of dollars to remedy. More often than not, we find an error in the calculations.

Whether receive the files or not, we are in fact responsible for the consequences of errors. If a dam fails and kills dozens of people, is a utility insulated from liability if a consultant makes a mistake? Not likely. The NTSB report on the Rt. 35 bridge collapse in Minneapolis made this clear when they placed some of the liability on the owner for the design error.
 
Just for the record, I'm not "afraid" to give out native files. It does, however, usually bring on a whole slew of questions and/or request that you wouldn't normally get if you had just given the client some abbreviated report. I like the suggestions about structuring your contract so you get paid for this additional time. Unless, of course, the client finds an error, then he shouldn't have to pay for you to fix it.

From a strictly academic standpoint, I actually like getting feedback from other engineers and discussing technical issues. Unfortunately, I live in the real world and the people who pay me want me to design something and move on.

The reason I brought up the question is because I'm aware of a situation where an engineering firm is asking for native files from a vendor (not us) so they can do a more in depth review. The vendor is pushing back with a vengeance, making me wonder if they are hiding something. I was just wondering what other people's policy/experience is and if there is a good reason not to hand out native files.

As I mentioned, I don't submit them as a matter of course but if a client ask I'll give it to them.

Oh, someone asked suppose you're not using the same software. Well, then, of course, it doesn't really make a lot of sense to share an input file with them. In my case, our major client has most of the same software that we have.
 
Are they pushing back because it's not in the contract, perhaps they consider it IP or similar?

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
Kenat, the reason I heard is they are afraid the client will change the file. I don't get that. So the client says, "Hey, you used the wrong property for member so and so!" All they have to do is call up their file and say "No we didn't! You changed the file! Here's our original file and the member property is correct."

I would like to understand more about IRstuff's suggestion about using a digital hash signature to ensure that the original file is still intact so you don't have to rely on he said, she said.
 
" All they have to do is call up their file and say "No we didn't! You changed the file! Here's our original file and the member property is correct."

But that takes someones time to do that, and if they can't come to an agreement quickly can drag out and lead to issues with accusations over who changed the file and when etc..

I'm not without sympathy for the party not wanting to share the data if it wasn't contractually required, in which case it should have been baked into the cost and relevant configuration control provisions taken as several people allude to above.

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
If you were revising a drawing (layout, P&ID, SLD ...), the native file belongs to the owner, and the engineer will send the native file to the client with the invoice. I am sure that no one has a problem with this, and processes are in place to protect the engineer should the native file be revised (wet signatures). Therefore, why is there a problem sending out native files for reports, calculations and software program inputs. If IP exists in the Excel calculations, then that should not be handed over, but if the engineer is on the client dollar entering calculations into Excel, or putting the information into an off-the-shelf product, then to me the native should be provided to the client. The client should not have to pay twice they go to a second engineer?

The way I look at it, as an engineer, how do you get more work from the client? You solve its problems and make it easy for them to do work. I assure you, I will come back to time and time again if you make the process of doing work easy for me.
 
IRStuff is right, hashing of files has been done for ages, particularly when verifying integrity of open source operating system images, but use in this particular context is probably something new.

If you hash the files at handover, and keep copies of the generated hashes, then it should be relatively easy to prove that the native (source) files have been changed. Time and date stamps are tricky as they're often file system dependent, and the same file may end up with a separate time / date stamp depending on whose system its stored on. Other things like metadata can also throw the timestamp, thus I'd not recommend using it as a verification of file integrity.

I believe, although I've not confirmed, that CollabNet's SVN versioning tool uses hashing to detect file changes for the purpose of file versioning.
 
This was several years ago but it's my take on calculations...I think our profession has drifted away from this (my) view which it too bad.
Are we a profession or a commodity?

thread507-89434

Check out Eng-Tips Forum's Policies here:
faq731-376
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor