yang686526

documentation of electrical/electronic design intent
this doesn't apply to gd&t, but i am hoping there are some standards to cover this topic.
i'm looking for ways to reduce the number of calls from field service techs contacting engineering everytime there is an electrical connection or electronic controller issue with our products in the field.
we provide basic system block diagrams (interconnection diagrams) and wiring diagrams. we also have production harness drawings available. we develop and manufacture our own controllers, pcbs, and software logic.
since we are predominately a manufacturing company of transit equipment, the electronics and electrical is always the "red-headed step child" of the company. i'm looking for advice on what details or other documents we should be creating. for starters, we list (or name) the inputs/outputs of our controllers, but never provide information as to what conditions are required to get the proper input/output.
i think there is a world market for maybe five computers.
thomas watson, chairman of ibm, 1943.
we use ds (design specification) documents that go with pcb's. it would go with the drawing and match the part number, i.e. ds12345.
this doc tells them everything they need to know to build, test, program, etc.
chris
sr. mechanical designer, cad
solidworks 05 sp3.1 / pdmworks 05
the best service schemaics i've seen include little 'scope' drawings of expected waveforms for analog signals at important points, expected voltages at various pins where they're not obvious, text descriptions of what each block is supposed to do, photos with arrows showing you where to hook up to test and adjust things, stuff like that.
ideally, a tech should be able to evaluate the operational state and health of the block he's looking at, without _ever_ referring to an interconnect diagram to find out what's at the other end of every wire he can see.
it may well be possible, but i've never seen a design operation generate drawings like that. your own service department may have ugly home- grown paste-ups that will knock your socks off for their clarity. if they don't, study the sams manuals for some things you think you understand.
one way to get started is to log, record, and analyze the incoming phone calls with an eye to understanding why the guy who's out there in the trenches didn't immediately grok what your stuff is trying to do, and what you would have to add to help him 'get it' right away.
mike halloran
ft. lauderdale, fl, usa
in order to trouble shoot, a technician needs to understand what output to expect for any possible combination of inputs.
for simplistic control logic a classic flow chart may suffice.
for more complex control, state diagrams are extremely useful, once you learn how to use them properly.
the ieee has some standards for software documentation.
the aircraft industry has some good standards for service manuals, i don't recall the acronym or number at the moment.