Help with first revision engineering design document

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys, Best wishes to everyone. Hopefully this is the right place to post a question about electronics designing. I've searched the forum with query Documentation design, couldn't find anything, feel free to suggest different keywords, anyways, onto my question

I have just got my first engineering job and I am tasked with designing an electronic device for a firm. I am not as smart as a lot of you guys and definitely not as experienced in designing as I would like to be. I have been writing a document to describe the device I need to make for the company and I'm having a hard time coming up with things that should go in it. So far I have the following sections and what they contain.

Title Page - Doc name, Author, Doc Rev.#, Proprietary Statement

Document Description - What the purpose of this document is ("to document the design of the product I'm developing")

Product Description - What the product does

Level 1 System Level Requirements - Cost, Size, Devolopment time

Level 1 Subsystem Requirements
Power - 2 hour operating time, battery powered, on off switch
Command and Data - must acquire and record data, etc
Structure - impact resistant, small, lightweight, plastic housing, etc
Sensory - frequency of sensors, filtering

What am I forgetting? What other sections do you guys put in your documents that are similar to mine. The list above is greatly abridged. I want to be an awesome engineer one day please help me, I've already written about 5 pages but I feel like it is really lacking stuff, I can't think what though. Any input into how I should document my design would be much appreciated. Unfortunately I must write this post with a little ambiguity, I'm under contract to not disclose stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DFM - Design for manufacturing.
Can this thing actually be made economically ?
Can it be economically tested ?
To what level can it be tested using ATE solutions ?
Are boundary scan techniques required to fulfil/part fulfil the testing ?
What is the cost of developing adequate test equipment ?
What QC procedures will be put in place/are in place to ensure tht the product is built to adequate quality level ?
How will warranty/field failure be handled ?
Will the buying dept. be instructed to only buy from authorised distributors, thus ensuring component traceability ?
What level of assistance is required by your assembly operators to enable them to build the product right first time ?(assembly diagrams, critical mechanical instructions)
Who will be authorised/qualified to change faulty components found during test ?
That should give you plenty to get on with :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I have been writing a document to describe the device I need to make

I guess it depends upon the company you work for, but you might find it easier to have separate documents describing the global parameters, development time, cost, project team, (you), time line, etc.; and a detailed specification of the device itself. Management and accounting want the first doccument, engineering wants the second one.

You are off to a great start, but a few more areas to consider might include:

Power source / Battery type / recharge capability.
FCC etc. compliance testing.
Thermal range of peration, (Impacts the electronics, the battery, and the plastic used for the case. Also impacts LCD displays, etc.).
Vibration, (factory environment, vehicles, etc.).
EMI input and output considerations. (Does the device operate near any high powered motors, generators, current carrying lnes, RF antennas, etc.).
Input circuitry protection. (Someone connects a sensor backwards, tries to plug the wrong sensor / lead into a delicate input, etc.)
Internal power up testing, gross fault mode detection and idiot light warnings.
Data capture format and any redundancy requirements, (record to two SD cards simultaneously, or to SD and FRAM simultaneously, with occassional data checks, etc.).
Data storage formats, and user interface for reviewing the data.
Mission Critical? Redundancy, software testing.
Security? Data encription or not.
Propriatary? Schematics releasable or not? (Service and repair)

Mention whether this replaces any current company products or not, and if so any backwards compatibility in terms of sensors, data formats, data review software, etc.

Lastly, are there any similar documents in the company for prior product development that you can review? Were they one page briefs or 50 pages in minute detail?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That was super helpful thanks guys! Splitting it up into a couple documents might be the trick and all the talking about redundancy, encryption, testing procedure, manufacturability, profit margins, etc are all things I should be taking into consideration (none of which even crossed my mind before reading your responses). The previous engineer at the company isn't there any more and I guess he never divulged any of his documents to the company so I had nothing to go on besides previous experience and advice from here. I'm going to think about and add these sections later today, thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For management graphics are key. Treat them like you would any non-technical person. The best (and easiest) way to get a point across to business minded management is through a Powerpoint presentation on a projector. I would also include flowcharts for the projected development cycle, projected expenses and revenues. Lots of caparatives between the current products you are replacing. The easiest way to convince someone your device is better if to tell them HOW it's better. Research returning issues with the current product and explain how you will prevent those from ever happening again. Constant technical problems or product limitation issues are like a wound that won't heal for most management and marketing directors.

Essentially show them all they want to see and nothing they don't. There is no point in spending hours into technical details with a crowd that doesn't understand any of it, so show the big lines, and let them ask you questions. You can distribute more detailed documents on paper for them to read (or not read) at their leisure.

I also agree with JC splitting up each document tightly and cataloging everything into an index makes it a lot easier for both you and the rest of the team working on the project to find the data you need fast and when you need it. There is nothing worse than having to sift through pages of marketing BS to find a technical parameter you omitted to transcribe to your own design notes.

I would also recommend you carry a portable voice recorder around to meetings and presentations. Taking notes prevents you from listening 100%, and not taking anything assures you will forget a key requirement mentionned briefly in the questions period.

A lot of the design happens not in CAD programs but in the designer's head. Find a way (other than millions of post-it's) to make sure everything is archived. Often you will be in a later stage of development, face a problem, and remember that you had a brilliant idea to solve it months ago, but you forgot what it was.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, Congrats on the job!

If the business is small it may not have a central server which you are operating off of, and storing files on, and auto-backing up every night.

Get use to making your own backups. Computers will crash and you will eventually/occasionally get hit with a virus. Your employer is paying you to be productive, not to lose all of your work!

Occasionally, for research or for some proprietary projects you may be required to keep your development notes in a bound journal, with daily progress initialed by your boss.

When less stringent documentation of the development process is required you have more options for creating and storing your development progress, (HW designs, notes, parts selection, data sheets, software versions, PCB layouts, case designs, eMails and memos from your boss and other team members, etc.)

Develop a system that works well for you, and stick with it. Organization is a difficult skill for many, but developing it early in your career will help you for years to come.

Personally, I quit writing lots of my thoughts / design notes on paper. These days I can type faster than I can write, and my writing is very poorly legible. Any time I am about to pick up a pen to write a note / thought to myself I type it on the project's notes (Word) file. When I am working on a project the file is always open, and just a click away. I document more, can read it later, and can go back to further develop the thoughts and ideas that I had in the middle of something else.

About the only papers I have are rough schematics, (before they get drawn on the computer), calculations, and notes & measurements taken while at the bench.

I could ramble on about what works for me but it may be different from what works for you. Bottom line, however, is be organized. Have your data, (notes, data sheets, eMails, schematics, PCB layouts, etc.), readily available.

Good luck with your first big project!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Implying my thousand sticky notes all over my office is a bad thing =/ good tip on pictures though, voice recorder is the way to go also, I'll dig mine up. What do you use to archive everything? N/m you all are super geniuses

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh man thanks JC, didn't even start thinking of backing up stuff, been working on an old E-Machine they gave me. Most of the stuff you guessed about this place is spot on, gotta document stuff, keep the boss informed, and we have no server/nightly backup, nothing like that. I gotta start my organization out sooner than later, all my papers are kept on pads and piled up in a corner of my desk, most of my assignments are stuck to walls of the cubicle, etc... Nightly backup and all electronic is a good tip, I'll start bringing my laptop to work and meetings, thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could I add a few things also?

Document your list of assumptions and constraints. Like, I can work on this and that but not that other aspect which you the client is responsible for.

And get a definition of success. What has to happen for the project to be successful for you (works, payment, no legal gothchas), for the client (finished in time, works, documented, reproducible, no legal issues) and the end customer (works, attractive, affordable, safe, reliable). Nothing worse that you thinking the project was a success, but everyone else bagging you for a failed product. You are all responsible for delivering a success.

And don't forget that the marketing guys are NOT your friends. They will change everything in pursuit of their sales commission including changing the agreed specification and getting you to wear the sh!t when it doesn't match their story.

Best of luck.

Ross

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm so green I've never even met a marketing guy. I find it hard to even imagine my prototype becoming a product one day, it would be a dream if that happened but it seems so far off. A definition for success, I'm going to bring this up with my boss this weekend

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If there is no likelihood of an end product, there is no reason for a prototype. Let me send you, via a PM, a small document I did a dozen years ago that might help. Will need to hunt it out.

Cheers,

Ross

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd love to see a real profession doc, thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... and this thread might provide some other viewpoints also.

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hell of a learning curve to go up.... that thread is a whole course in embedded design, it'll take me the weekend to digest it

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

If the business is small it may not have a central server which you are operating off of, and storing files on, and auto-backing up every night.

Using something like subversion will help to revert when things inevitably go wrong. Although built with software in mind, our hardware team (and even our marketing team!) use it.

The central repository will still need backing up, but at least you have everything on at least **two** machines :)

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smkipus wrote:
Implying my thousand sticky notes all over my office is a bad thing =/ good tip on pictures though, voice recorder is the way to go also, I'll dig mine up. What do you use to archive everything? N/m you all are super geniuses

An excellent substitute for sticky notes is a wiki. It's also good for design notes and other bits of information that don't make it into formal design documents... and they're much more searchable than a designer's notebook!

We use confluence at work, and I use Dokuwiki at home. Oh course, the mighty MediaWiki is used for wikipedia, but it's syntax can be a little complicated for very fast use.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dont forget, the product is the packaging and shipping materials and methods as well. Cost it and include it in Your documentation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Iso9001 outlines the basic requirements for implementing a qualitycsystem.

http://www.askartsolutions.com/i...

Look at chapters 34 to 37

This would form your top level framework. Basically, what is it that we're wanting to achieve, define inputs(documents etc), outputs, who's doing what, how you will verify and validate.

Once you've ticked off all your outputs, the project should be complete. The idea is that each of the requirements can be verified easily- eg
Produce schematic in electronic and printed form.
if someone was auditing the project and asked you this question, it should be simple to answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although I didn't read fully the thread and besides the fact that where I live in another country, I recommed you also to keep an eye on the legal issues. Underwriter Labs (UL mark, for sure you know their logo) may have a bunch of legal-technical requirements that deserve they own chapter on the documentation. Maybe you should take into account any tests or homologations they may do on the product. Remember that few 'critical components' may be also into the UL list, as well as your PCB manufacturer should add the UL mark, and such.

Legal issues and homologation of the product may be a totally different and new world for many people, that require a lot of time.

Guillem.
"Common sense is the least common of the senses" Anonymous.