System Engineering in the R/D World

Aug 3, 2005

Thanks Fred, you did a great job, I know it will help a lot of
engineers, me too, who are still new to SE practices.

joe

Aug 3, 2005

Hi Joe,

You can find some definitions and nice opinions about sys engineering
here:

http://www.iee.org/oncomms/pn/systemseng/definition.cfm

P.S.
If I were you, I would use more specific terms when trying to convince
my colleagues to do something, instead of ambiguities such as "system
engineering practices". Take software projects for example, terms such
as CMM are a lot more well-defined and therefore more powerful.

K

JeffM · Aug 4, 2005

The EARLY Pentiums were architected by a single person.
Need I say more ?
Jim Thompson

Well, a name would be nice.

The story I hear is that Frederico Faggin
was the last guy to single-handedly design a uP (Z-80).

Rune Allnor · Aug 4, 2005

Fred Marshall wrote:

jjlindula@hotmail.com> wrote in message
news:1123083687.394543.131660@g49g2000cwa.googlegroups.com...
Hello, to be brief SE involves

controlling your design processes - isn't there a VP Engineering to set
policy? Isn't there a way to communicate what's working and not working?
It must be a really overdone project to need a *person* dedicated to this.

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!"

reproducability - I think you mean produceability.

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."

Just part of good
engineering with adequate discussion with the manufacturing folks. Not a
special discipline / position.

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

to build a system around this activity."

integration planning - the system guru takes the lead and, unless the guru
does it all alone (which is common) then it's a group 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".

To make a point:
It is told that a Japanese company licensed the production of an American
engine. They took the original drawings and began production. But they
couldn't build engines with those drawings! Why? Because at that time, the
Japanese built all the parts to exceptional tolerances so there could be
virtually 100% interchangeability. And, because at that time, the Americans
had built the parts to looser tolerances and were willing to do some mixing
and matching of parts, they didn't recognize that the dimensions in the
drawings were "wrong" - that is, a working engine could not be assembled out
of a set of parts that were perfect according to the drawings. I don't know
if the story is true but it's sure interesting.....

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

Clay S. Turner · Aug 4, 2005

"Jim Thompson" <thegreatone@example.com> wrote in message
news:tqv1f19en0pj7rclndiq6r8uvn0mbg3uho@4ax.com...

The EARLY Pentiums were architected by a single person. Need I say
more ?

...Jim Thompson

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

Clay

Genome · Aug 4, 2005

<jjlindula@hotmail.com> wrote in message
news:1123088364.723402.137130@g47g2000cwa.googlegroups.com...

What?

......

Go ride a bike. Turn a corner.

Now start thinking about/analysing what you are doing. Turn a corner.

DNA

Aug 4, 2005

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

Jim Thompson · Aug 4, 2005

On Thu, 4 Aug 2005 07:59:08 -0400, "Clay S. Turner"
<Physics@Bellsouth.net> wrote:

"Jim Thompson" <thegreatone@example.com> wrote in message
news:tqv1f19en0pj7rclndiq6r8uvn0mbg3uho@4ax.com...

The EARLY Pentiums were architected by a single person. Need I say
more ?

...Jim Thompson

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

Clay

480)460-2350 | |
| E-mail Address at Website Fax

Jim Thompson · Aug 4, 2005

On Thu, 04 Aug 2005 13:25:29 GMT, "Genome" <ilike_spam@yahoo.co.uk>
wrote:

jjlindula@hotmail.com> wrote in message
news:1123088364.723402.137130@g47g2000cwa.googlegroups.com...
What?

.....

Go ride a bike. Turn a corner.

Now start thinking about/analysing what you are doing. Turn a corner.

DNA

480)460-2350 | |
| E-mail Address at Website Fax

David L. Jones · Aug 5, 2005

jjlindula@hotmail.com wrote:

Hello, to be brief SE involves requirements analysis, risk managment,
controlling your design processes, interface control, supportability,
realiability, maintainability, reproducability, peer reviews and
technical reviews, test planning, integration planning. SE is used to
manage a project to control costs, schedule, and performance. I"m still
learning all the areas and probablity left out a ton of stuff.
Although, I'm more interested in the technical side of SE, rather than
counting the money stuff.

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

Fred Marshall · Aug 5, 2005

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:1123142445.607473.191750@g14g2000cwa.googlegroups.com...

Fred Marshall wrote:
jjlindula@hotmail.com> wrote in message
news:1123083687.394543.131660@g49g2000cwa.googlegroups.com...
Hello, to be brief SE involves

controlling your design processes - isn't there a VP Engineering to set
policy? Isn't there a way to communicate what's working and not working?
It must be a really overdone project to need a *person* dedicated to
this.

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!"

reproducability - I think you mean produceability.

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."

Just part of good
engineering with adequate discussion with the manufacturing folks. Not a
special discipline / position.

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

to build a system around this activity."

integration planning - the system guru takes the lead and, unless the
guru
does it all alone (which is common) then it's a group 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".

To make a point:
It is told that a Japanese company licensed the production of an American
engine. They took the original drawings and began production. But they
couldn't build engines with those drawings! Why? Because at that time,
the
Japanese built all the parts to exceptional tolerances so there could be
virtually 100% interchangeability. And, because at that time, the
Americans
had built the parts to looser tolerances and were willing to do some
mixing
and matching of parts, they didn't recognize that the dimensions in the
drawings were "wrong" - that is, a working engine could not be assembled
out
of a set of parts that were perfect according to the drawings. I don't
know
if the story is true but it's sure interesting.....

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

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

Aug 5, 2005

You mean the ones with de devision bug inside?

*SCNR*

bye Thomas

Aug 5, 2005

You mean the ones with de division bug inside?

*SCNR*

bye Thomas

Aug 5, 2005

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

KoKlust · Aug 5, 2005

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: customer<-->product marketing<-->product development
manager<-->multidisciplinary project leaders<-->monodisciplanary
architects<-->monodisc. 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

<kd_ei@yahoo.com> wrote in message
news:1123107281.146672.157300@g47g2000cwa.googlegroups.com...

Hi Joe,

You can find some definitions and nice opinions about sys engineering
here:

http://www.iee.org/oncomms/pn/systemseng/definition.cfm

P.S.
If I were you, I would use more specific terms when trying to convince
my colleagues to do something, instead of ambiguities such as "system
engineering practices". Take software projects for example, terms such
as CMM are a lot more well-defined and therefore more powerful.

K

John Larkin · Aug 5, 2005

On Fri, 5 Aug 2005 13:55:32 +0200, "KoKlust" <marco_sp@xs4all.nl>
wrote:

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: customer<-->product marketing<-->product development
manager<-->multidisciplinary project leaders<-->monodisciplanary
architects<-->monodisc. engineers.

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

KoKlust · Aug 5, 2005

The most important technical customer requirements come to the engineers
via
the flow: customer<-->product marketing<-->product development
manager<-->multidisciplinary project leaders<-->monodisciplanary
architects<-->monodisc. engineers.

Where are the system engineers? One of the above, or off to the side
somewhere?

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.

Who do they report to?
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.

What authority do they have?
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.

Fred Abse · Aug 6, 2005

On Fri, 05 Aug 2005 00:12:48 -0700, usenet_10 wrote:

You mean the ones with de devision bug inside?

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)

John Larkin · Aug 7, 2005

On Thu, 04 Aug 2005 13:25:29 GMT, "Genome" <ilike_spam@yahoo.co.uk>
wrote:

jjlindula@hotmail.com> wrote in message
news:1123088364.723402.137130@g47g2000cwa.googlegroups.com...
What?

.....

Go ride a bike. Turn a corner.

Now start thinking about/analysing what you are doing. Turn a corner.

DNA

Good way to get killed.

John

Jerry Avins · Aug 7, 2005

Genome wrote:

jjlindula@hotmail.com> wrote in message
news:1123088364.723402.137130@g47g2000cwa.googlegroups.com...

What?

.....

Go ride a bike. Turn a corner.

Now start thinking about/analysing what you are doing. Turn a corner.

The centipede was happy (quite!)
Until the toad for spite
Asked, "Pray; which leg comes after which?"

That threw his soul in such a pitch
He lay distracted in a ditch,
Considering how to run.

Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

System Engineering in the R/D World

Guest

Guest

JeffM

Guest

Rune Allnor

Guest

Clay S. Turner

Guest

Genome

Guest

Guest

Jim Thompson

Guest

Jim Thompson

Guest

David L. Jones

Guest

Fred Marshall

Guest

Guest

Guest

Guest

KoKlust

Guest

John Larkin

Guest

KoKlust

Guest

Fred Abse

Guest

John Larkin

Guest

Jerry Avins

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

System Engineering in the R/D World

Guest

Guest

JeffM

Guest

Rune Allnor

Guest

Clay S. Turner

Guest

Genome

Guest

Guest

Jim Thompson

Guest

Jim Thompson

Guest

David L. Jones

Guest

Fred Marshall

Guest

Guest

Guest

Guest

KoKlust

Guest

John Larkin

Guest

KoKlust

Guest

Fred Abse

Guest

John Larkin

Guest

Jerry Avins

Guest

Log in

Welcome to EDABoard.com

Sponsor