System Engineering in the R/D World

In R&D, there is no such thing as "policy" or "corporal memory". I have never met a "scientist" or "researcher" who did acknowledge that skill and competence were personal attributes, that each person have to make an effort to gain for themselves or communicate to others. "What do you mean I can do better? I am a professor at [insert your favourite university or R&D organization here], for crying out loud!"

Not necessarily. Some attention to reproduceable results would keep certain not entirely all that good techniques from enetering the scene. Remember, R&D is all about "publish or perish." Making a second check of those "brilliant" results might lose a much cited paper.

"Never measure twice."

The common R&D argument is that "we do this only once, there is no need

to build a system around this activity."

Again, since an R&D activity usually is done only once, or a couple of times at most, no one see the need for systematic planning.

These are the factors that in my experience separate R/D from engineering. In R&D, stuff like the above are generally considered "waste of time and talent".

Heh, that's my average experience when I try to make some algorithm or technique work, be it from an academic paper or an in-house technical report: The documentation doesn't work. Either there are typos, the key

tricks are left out or "documentation" is taken to mean "a short general description of a concept". I don't think I have ever implemented a technique based on a single document "and the references therein".

I always had to go to other literature, and more often than not, do the

complete derivations myself to make sure I got it right.

Rune

Thanks a million for the reference link, I'll check it out.

Yes, But certainly not the one who made P4's slower than P3's, for numerical operations.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

Is this the one that couldn't divide very well. I.e., had the floating point bug?

Clay

Depends how much time, money, and resources you've got and what you are working on. On military projects for example (I've worked on several) you've usually got plenty of all three. In this case you would (and are required to) do a lot more paperwork stuff like requirements analysis, risk management, supportability, integration planning etc. But to real design engineers this sort of stuff adds no real value, i.e. you aren't using your time to produce anything useful.

A commercial project on the other hand with limited budget, time and resources, where you are expected to produce miracles, you just need to get the job done. Any formal process that doesn't add value in getting the job done is simply ignored. Of course you always keep one eye on the important side stuff like requirements, testing, maintainability etc, but you couldn't care less about formal risk management and integration planing for example.

Peer reviews are valuable in ANY situation. Often these are informal like "I'll check the schematic over while I'm on the can".

Dave :)

Rune,

It's clear that you're heavy on the "R" in R&D. I'm heavy on the "D" in R&D in these descriptions but I've also done "R" and there are different objectives to be sure. Reproducibility is important in "R" and early stages of "D". Producibility is important in "D". Reproducibility should be a foregone conclusion at this stage.

et cetera

Fred

You mean the ones with de devision bug inside?

*SCNR*

bye Thomas

You mean the ones with de division bug inside?

*SCNR*

bye Thomas

HI,

SE (System Engineering as well as Software Engineering) is always a problematic field. I don't think, that you will find a project that uses all possibilities nor a (sucessfully finished) project that ignores every aspect of SE.

I think the most companies use a more or less golden middleway.

We use any point mentioned above but in some cases a bit weaker than my old SE teacher would like. We did this whole effort only for ASICs in the past but actually changed to use these techniques in every design. Of course this leads to a overhead of paperwork especially for small projects but pays when it comes to products (not very funny if a bug rise after the last chance of repair is gone and therefore need a rebuild).

bye Thomas

Where are the system engineers? One of the above, or off to the side somewhere? Who do they report to? What authority do they have?

John

In the company I work for, there is a 'System Engineering' group. R&D department has about 1500 FTE. The system engineers focus on all the aspects that cover multiple subsystems of the (huge) manufacturing machines we design.

Especially things like : safety norms, EMC norms, and the system characteristics like throughput and accuracy.

The system engineers are responsible for bringing in requirements on the subsystems, so that the engineers that do the subsystem designs, deliver a complete system that can meet the above system level requirements. So this is a pure technical function in the specification phase of the project.

The most important technical customer requirements come to the engineers via the flow: customerproduct marketingproduct development managermultidisciplinary project leadersmonodisciplanary architectsmonodisc. engineers.

indicates twoway communication (in practice, one of the two ways may be much stronger than the other). The architects are sometimes skipped.

The actual realization of e.g. safety measures is completely delegated to the subsystem projects.

The system engineers are NOT responsible for management. Project leaders are.

At our company there is a standardized design process flow.

1) feasibility phase (skipped if obvious) 2) specification phase 3) design phase 4) prototype production // test development phase 5) design qualification phase 6) release for volume

I think a bit of structure helps.

However creativity DOES often come from a bit of chaos. :)

Just my 2 cents.

Marco

off the side. the best fit in the above flow would be at the level of the product development manager. So the multidisciplinary project leaders receive requirements from both product development managers and from the system engineers.

The system engineers report to their groupleader and their multidisciplinary project leaders (matrix organisation). the groupleader is responsible for resource assignment, quality, way of working, career development. the project leader is responsible for in-time and on-spec (sometimes even on-budget ;-) ) delivery of the subsystem.

They only bring in the requirements. The decision on how and if to implement the requirements is made by the project leader. The implementation itself is done by the mono disc. engineers. If the SE does not agree with the monodisc. engineers he can escalate to the project leader, after that the product development manager. So i guess this process is not based on formal predefined authority but more based on convincing the right people with the right arguments at the right moment. An experienced SE knows how to persuade the people he needs to persuade.

And the F00F bug

-- "Electricity is of two kinds, positive and negative. The difference is, I presume, that one comes a little more expensive, but is more durable; the other is a cheaper thing, but the moths get into it." (Stephen Leacock)

Praise the messenger!

Make sure the rest of the group hears the praise, not just his manager.

Many years (10?) ago, my boss handed me a paper titled "Bugs are Good" by Doug Clark. Scribbled on it was "must read". I haven't been able to find it online, but it's easy to find references to it. (We were all working for DEC/Digital at the time.)

The main theme, at least as I remember it, is that you should praise the people who find bugs. It take a group-culture approach to understand the logic. Finding bugs today is better than having them find you tomorrow.

The other half is that you want other people to check your work. They have a different point of view. They won't make the same errors/blunders that you made. (hopefully)

-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer\'s.  I hate spam.

Just curious: did you also post your original query to the misc.business.product-dev newsgroup?

John

(snipped)

(snipped)

Hi,

"DEC/Digital", huh? Didn't they used to make computers?

[-Rick-]

Can't be true. One can easily design a 16ish bit processor in under a week's time. But it will have to be embedded. You are right if you mean a "competitive general purpose uP". It is awfully hard to compete single-handedly against the likes of Intel.

This was in response to the following claim in parent message: "The story I hear is that Frederico Faggin was the last guy to single-handedly design a uP (Z-80). "