Hi, has anyone out there ever worked as an electronics design engineer in industry? I am a hobbyist electronics designer and I would like to know the life cycle of a project from start to finish and what software analysis tools are used i.e distortion, noise, Fourier etc.

 

You need to narrow things down a lot. The life cycle that a project goes through is highly variable and depends on all kinds of factors, some of them technical, some of them legal, some of them specific to a company or industry segment. Similarly, the software tools that are used vary widely. Someone designing a computer motherboard is not going to be using the same tools as someone designing a high-end audio system and those will be very different from soneone designing a high speed data acquisition system or a radar system or an infrared imaging system.

So try to narrow down your request. Also, indicate if you are primarily interested in the technical tools that are used, or in the project phases and management stuff.

 

yeah, I'm looking for a standard procedure that is common to all areas of electronics. The main areas I design in is instrumentation and measurement systems i.e transducers, signal conditioning, ADC, DAC etc and a lot of stuff with motor-based microcontroller circuits.

I have a degree in electronic engineering but at uni we never actually got told about how an electronics engineer goes about designing and analyzing a project.

I'm interested in both the technical and project phase stuff, I just need some kind of order to my designing and what kind of results I should be showing on paper.

 

Here is a link to a very general overview.

http://www.industrologic.com/gtepdad.htm

Does your employer not provide you with product development guidelines? Or perhaps you are self-employed?

 

No neither, I'm just a hobbyist with an electronics degree. My uni never went into how an engineer in industry goes about designing a circuit in stages or what kind of analysis should go into a technical report.

I also stupidly never took the opportunity to take a year out after year 2 in a placement. I am hoping to maybe have an interview with an engineer in industry and ask about a typical day, week, year etc in design.

 

So, you have an EE degree, but you work in another field? Or maybe you don't have to work? Sorry if my questions are too personal; just ignore them.

 

Yeah its both an electrical and electronic degree, I'm trying to get into a graduate role for either but preferably in electronics design but it just isn't happening so I was going to try and build a portfolio of work using a standard procedure for designing and analyzing circuits.

 

As I noted earlier, the details are all over the map and even the high level stuff has a large amount of variability. But in general I think you would be looking at something like this:

1) Non-technical problem description
2) Technical problem description
3) Performance specifications
4) Development of performance test plan
5) Problem decomposition
6) Subproblem interface specifications
7) Development of itegration test plan
8) Solve subproblems
9) Execute itegration test plan
10) Execute performance test plan
11) Finalize documentation

Note that this is a recursive description. Specifically, Step 8 basically says to take each of the subproblems and go solve it using this same process. At each level you keep doing that until you get to a problem that is directly solvable.

The key things to note are that, in general, problems that you are asked to solve are seldom given to you in technical terms and specifications, so your first (and most critical step) is to make sure that you and your customer agree on what the problem actually is and this is best done using the language of the problem and not the language of the solution. Once the problem is understood, then work on performance requirements, again in terms of the problem, and a test plan that will satisfy the customer that any solution that passes the test plan will meet their needs. The break the problem down into smaller chucks and define how they will need to play together and how they will be assembled together and tested in stages as the system is built up. Now you put this level of recursion on hold and go solve the smaller problems. Once they are all solved you now have a bunch of building blocks that you can start assembling and testing according to the test plan and then, finally, do the full-up performance testing agains the performance specifications. All along these stages should be being documented, so your final step is simply wrapping that documentation up with some intro material.

This should not be taken as a set-in-stone approach. Engineering has to be flexible and adaptive. It also has to recognize that the nature of problem solving involves unknowns and so you may be several levels down in the process and discover something that forces tweaking things at several layers or even a complete rework of the whole thing.

 

I agree with WBahn that a critical part of any job is accurately defining the specifications for what task is. Without that being well defined you are likely to build something that doesn't completely solve the requirements, so you will have an unhappy customer and an unhappy boss.