FPGA Central

Jerry Avins skrev:
> Rune Allnor wrote:
> >
> > Fred Marshall skrev:
> >>Sometimes you won't know the requirements until you've tried some things.
> >
> >
> > Would this type of project qualify as cases C)-D) above?
>
> In some fields, it's typical. If you can specify the outcome and the
> path to it, it isn't research.

Ah, sorry. I didn't mention that these cases applied to projects in
general, not necessarily R&D projects. R&D comes into case C) and D)
almost by default.

Rune

"Rune Allnor" <[email protected]> wrote in message
news:[email protected] oups.com...
>
>
> Jerry Avins skrev:
>> Rune Allnor wrote:
>> >
>> > Fred Marshall skrev:
>> >>Sometimes you won't know the requirements until you've tried some
>> >>things.
>> >
>> >
>> > Would this type of project qualify as cases C)-D) above?
>>
>> In some fields, it's typical. If you can specify the outcome and the
>> path to it, it isn't research.
>
> Ah, sorry. I didn't mention that these cases applied to projects in
> general, not necessarily R&D projects. R&D comes into case C) and D)
> almost by default.
>
> Rune
>

Yeah, I thought we were talking about projects that result in a product of
some sort. Now, research results would be a "product" to a researcher but I
was thinking in terms of "harder" deliverables: a system, a box, an
application program, etc. So, research papers weren't in my frame of
reference as a "product". Engineeers do research but is research
"engineering"? A narrower definition for engineering is to "build"
something (as in design, build, test). A definition from the web:
1.. The application of scientific and mathematical principles to practical
ends such as the design, manufacture, and operation of efficient and
economical structures, machines, processes, and systems.
I thought that was the context and perhaps beyond into "project management".

So, when we are engineering something, sometimes we have to do a little
research along the way and that was the crux of "sometimes you don't know
the requirements until you've tried something". But, at that, I think this
is about finding out how certain things interact or behave that require some
experimentation but I don't think of that as "research" as such. I can
think of lots of examples in real life.

Here's an example:
An underwater vehicle that looks like a torpedo would be launched and would
deploy a towed array rather immediately after launch. The vehicle was
controlled by a circular shroud at the tail around the propellors that would
move up/down port/starboard. The tow cable was wrapped around the shroud
and held in place with some hardware claptrap.
The idea was that the claptrap would be released, the flow of water would
pull it aft and away. The cable would deploy and the control surface would
be free to move.
When it failed to work that way, not only did the cable not deploy but the
vehicle had no dynamic control.
Off to the water tunnel....
It became apparent that the flow of water over the tail cone had velocity
not only aft but *toward* the skin of the vehicle. It pressed the claptrap
*toward* the tail cone - which was in direct opposition to the force needed
for it to deploy.

.... that was an experiment to support development but it wasn't research.
The result changed the specifications for the claptrap and its release
mechanisms.

....shake, rattle and roll testing often ends up with new requirements on the
design unless the designers are very experienced. That's probably a good
example.

Once I managed a project that had the purpose of "developing technology" -
which meant that we were trying new ideas for known end applications within
a system context. Now that was somewhat researchy and was certainly
development. Having best practices regarding how to do research yields a
different set of suggestions doesn't it?

Here's an example:
We were trying to reduce the drag of underwater vehicles using all sorts of
very high tech methods. One of the groups (no doubt with a vested interest)
reported experimental success of their technique. But, some the of the
tests had failed. When asked why they threw out those results, they said:
"something must have been wrong and invalidated those tests". But, they had
no idea what might have been wrong or if the tests were truly invalid. In
the end we decided that the technology lacked robustness and the results
were valid: they were indicative of a technology that was "on the edge" of
working or not working.

So, for research we add to best practices: design of experiments, how to
handle results, repeatability, etc.

Fred

Fred Marshall skrev:
> "Rune Allnor" <[email protected]> wrote in message
> news:[email protected] oups.com...
> >
> >
> > Jerry Avins skrev:
> >> Rune Allnor wrote:
> >> >
> >> > Fred Marshall skrev:
> >> >>Sometimes you won't know the requirements until you've tried some
> >> >>things.
> >> >
> >> >
> >> > Would this type of project qualify as cases C)-D) above?
> >>
> >> In some fields, it's typical. If you can specify the outcome and the
> >> path to it, it isn't research.
> >
> > Ah, sorry. I didn't mention that these cases applied to projects in
> > general, not necessarily R&D projects. R&D comes into case C) and D)
> > almost by default.
> >
> > Rune
> >
>
> Yeah, I thought we were talking about projects that result in a product of
> some sort. Now, research results would be a "product" to a researcher but I
> was thinking in terms of "harder" deliverables: a system, a box, an
> application program, etc. So, research papers weren't in my frame of
> reference as a "product". Engineeers do research but is research
> "engineering"? A narrower definition for engineering is to "build"
> something (as in design, build, test). A definition from the web:
> 1.. The application of scientific and mathematical principles to practical
> ends such as the design, manufacture, and operation of efficient and
> economical structures, machines, processes, and systems.
> I thought that was the context and perhaps beyond into "project management".
>
> So, when we are engineering something, sometimes we have to do a little
> research along the way and that was the crux of "sometimes you don't know
> the requirements until you've tried something". But, at that, I think this
> is about finding out how certain things interact or behave that require some
> experimentation but I don't think of that as "research" as such.

How would you prepare for such a project, if you were to take on
something you knew/suspected would need to break new ground? Divide it
into lots of small projects, where one could decide whether to proceed
or not, after each sub-project? Allocate large fractions (25% - 50%)
of the budget to "unexpected expenses"?

> I can
> think of lots of examples in real life.
>
> Here's an example:
> An underwater vehicle that looks like a torpedo would be launched and would
> deploy a towed array rather immediately after launch. The vehicle was
> controlled by a circular shroud at the tail around the propellors that would
> move up/down port/starboard. The tow cable was wrapped around the shroud
> and held in place with some hardware claptrap.
> The idea was that the claptrap would be released, the flow of water would
> pull it aft and away. The cable would deploy and the control surface would
> be free to move.
> When it failed to work that way, not only did the cable not deploy but the
> vehicle had no dynamic control.
> Off to the water tunnel....
> It became apparent that the flow of water over the tail cone had velocity
> not only aft but *toward* the skin of the vehicle. It pressed the claptrap
> *toward* the tail cone - which was in direct opposition to the force needed
> for it to deploy.
>
> ... that was an experiment to support development but it wasn't research.
> The result changed the specifications for the claptrap and its release
> mechanisms.

I'd say this example involves "unexpected expenses". The goal, to make
this device work, has not changed. Getting it to work, takes a little
bit longer and involves more cost than previously anticipated.

> ...shake, rattle and roll testing often ends up with new requirements on the
> design unless the designers are very experienced. That's probably a good
> example.

I can see how the design requirements are refined or adjusted, as
experience is gained. But do the goals change? Perhaps we are splitting

hairs here, but I don't see that they do.

> Once I managed a project that had the purpose of "developing technology" -
> which meant that we were trying new ideas for known end applications within
> a system context. Now that was somewhat researchy and was certainly
> development. Having best practices regarding how to do research yields a
> different set of suggestions doesn't it?

The goals for that kind of project are not easy to measure/quantify.
"You are two weeks late on the breakthrough idea!" Can't really see
that happening...

> Here's an example:
> We were trying to reduce the drag of underwater vehicles using all sorts of
> very high tech methods. One of the groups (no doubt with a vested interest)
> reported experimental success of their technique. But, some the of the
> tests had failed. When asked why they threw out those results, they said:
> "something must have been wrong and invalidated those tests". But, they had
> no idea what might have been wrong or if the tests were truly invalid. In
> the end we decided that the technology lacked robustness and the results
> were valid: they were indicative of a technology that was "on the edge" of
> working or not working.

These are questions of craftmanship, regardless of whether we define
this as an engineering or R&D project. If you do a set of tests, there
are certain standards one would like to keep in order to "sell" the
results. Explaining large amounts of "anomalies" should include a
discussions of reasons, including the possible non-robust method.

A few years ago, I met a former colleague who had got a new job in a
company dealing with marine operations, since I last met him. He
described a project he was involved in, where they had as ambition to
deploy certain types of kit at the sea floor, at given locations in the

deep sea and with very high accuracy. As he finished describing the
goals,
my reaction, expressed as a combination of body language and verbal
comments was to the effect of "You guys must be mad to attempt
something
like this!" "Oh yes, that's how it might look." he responded. "We don't

expect to actually meet the ambitions, though, but we would like
to see how close we can get, and what it takes to get there."
Most reassuring.

We went on to discuss various ways of getting close to these goals.
My friend said that somebody from some service company had approached
him to discuss methods to deploy the kit. The people from the service
company had said they could do this with standard technology. "Do you
believe they can?" I asked quietly. "No. The representatives didn't
even blink an eye when I described our ambitions."

Our unspoken mutual understanding was that anyone who understood the
complexity (well, semi-sanity) of the stated goals, would be very
sceptical to whether this was at all possible. The service company
showed, as I understood my friend's tale, no signs of understanding
what this was all about, and did thus not get the contract.

> So, for research we add to best practices: design of experiments, how to
> handle results, repeatability, etc.

Exactly. To me, these aspects are embedded in the term "craftmanship".

Rune

"Rune Allnor" <[email protected]> wrote in message
news:[email protected] oups.com...
>
>
> Fred Marshall skrev:
>> "Rune Allnor" <[email protected]> wrote in message
>> news:[email protected] oups.com...
>> >
>> >
>> > Jerry Avins skrev:
>> >> Rune Allnor wrote:
>> >> >
>> >> > Fred Marshall skrev:
>> >> >>Sometimes you won't know the requirements until you've tried some
>> >> >>things.
>> >> >
>> >> >
>> >> > Would this type of project qualify as cases C)-D) above?
>> >>
>> >> In some fields, it's typical. If you can specify the outcome and the
>> >> path to it, it isn't research.
>> >
>> > Ah, sorry. I didn't mention that these cases applied to projects in
>> > general, not necessarily R&D projects. R&D comes into case C) and D)
>> > almost by default.
>> >
>> > Rune
>> >
>>
>> Yeah, I thought we were talking about projects that result in a product
>> of
>> some sort. Now, research results would be a "product" to a researcher
>> but I
>> was thinking in terms of "harder" deliverables: a system, a box, an
>> application program, etc. So, research papers weren't in my frame of
>> reference as a "product". Engineeers do research but is research
>> "engineering"? A narrower definition for engineering is to "build"
>> something (as in design, build, test). A definition from the web:
>> 1.. The application of scientific and mathematical principles to
>> practical
>> ends such as the design, manufacture, and operation of efficient and
>> economical structures, machines, processes, and systems.
>> I thought that was the context and perhaps beyond into "project
>> management".
>>
>> So, when we are engineering something, sometimes we have to do a little
>> research along the way and that was the crux of "sometimes you don't know
>> the requirements until you've tried something". But, at that, I think
>> this
>> is about finding out how certain things interact or behave that require
>> some
>> experimentation but I don't think of that as "research" as such.
>
> How would you prepare for such a project, if you were to take on
> something you knew/suspected would need to break new ground? Divide it
> into lots of small projects, where one could decide whether to proceed
> or not, after each sub-project? Allocate large fractions (25% - 50%)
> of the budget to "unexpected expenses"?

I guess you might budget a lot for unexpected expenses. But, I didn't think
we were talking here so much about project management as about best
practices in development. Frankly I'd not be too comfortable with such an
allocation *if* cost and schedule were paramount - which they often are.

Maybe you could break things down into smaller pieces and maybe not. The
notion is a good one to be sure - but agreeing or disagreeing in such
general terms is too speculative for me. Maybe that's the essence of
"complex" - that something hasn't been well partitioned and organized, eh?

I can imagine control systems engineering as dealing with things that are
complex and making them simpler by virtue of the tools. Once you know about
the tools then most things in this context are perceived as simpler aren't
they? That doesn't make them easier to deal with "seat of the pants" - but
knowing that the tools are there and what they do, etc. makes things appear
to be simpler. Computers are great for keeping track of a lot of things at
once - much better than humans.

We designed a control system for a semisubmersible oil and gas production
platform in Sweden. The thing had over 50 ballast tanks that we would
control with a computer program (model, etc.). When it went to sea the crew
tried to trim the tanks by hand and were never able to level the platform.
Eventually they decided to try out the new-fangled computer thingy and the
platform leveled out directly. The task was too *complex* for humans unless
they used the computer controls and then the task was made simple for them.
They were incapable of dealing with all the subsystems and their
interactions. Too many subsystems and too many interactions. So, breaking
it into smaller parts wasn't the solution.

>
>> I can
>> think of lots of examples in real life.
>>
>> Here's an example:
>> An underwater vehicle that looks like a torpedo would be launched and
>> would
>> deploy a towed array rather immediately after launch. The vehicle was
>> controlled by a circular shroud at the tail around the propellors that
>> would
>> move up/down port/starboard. The tow cable was wrapped around the shroud
>> and held in place with some hardware claptrap.
>> The idea was that the claptrap would be released, the flow of water would
>> pull it aft and away. The cable would deploy and the control surface
>> would
>> be free to move.
>> When it failed to work that way, not only did the cable not deploy but
>> the
>> vehicle had no dynamic control.
>> Off to the water tunnel....
>> It became apparent that the flow of water over the tail cone had velocity
>> not only aft but *toward* the skin of the vehicle. It pressed the
>> claptrap
>> *toward* the tail cone - which was in direct opposition to the force
>> needed
>> for it to deploy.
>>
>> ... that was an experiment to support development but it wasn't research.
>> The result changed the specifications for the claptrap and its release
>> mechanisms.
>
> I'd say this example involves "unexpected expenses". The goal, to make
> this device work, has not changed. Getting it to work, takes a little
> bit longer and involves more cost than previously anticipated.

The point was whether it was development or "research" - not that it cost a
bit more to accomplish.

>
>> ...shake, rattle and roll testing often ends up with new requirements on
>> the
>> design unless the designers are very experienced. That's probably a good
>> example.
>
> I can see how the design requirements are refined or adjusted, as
> experience is gained. But do the goals change? Perhaps we are splitting
>
> hairs here, but I don't see that they do.

I agree that the goals don't change. The point was that some try/fix
process was likely.

>
>> Once I managed a project that had the purpose of "developing
>> technology" -
>> which meant that we were trying new ideas for known end applications
>> within
>> a system context. Now that was somewhat researchy and was certainly
>> development. Having best practices regarding how to do research yields a
>> different set of suggestions doesn't it?
>
> The goals for that kind of project are not easy to measure/quantify.
> "You are two weeks late on the breakthrough idea!" Can't really see
> that happening...

In this case the schedule was fixed for a wide array of technologies.
Either things panned out in time or they didn't. If someone was trying to
make too great a breakthrough then they would probably fail. That was OK
because the next step was to take the best, proven technologies and build
something real. Nobody in their right mind would start a product
development with an unproven technology while there were proven technologies
available.

The goals were easy to measure and quantify. Either the technology appeared
to work well or it didn't or it never really got off the ground. The next
phase of system development would decide which technologies really made
sense.

(In the end, some technologies were carried a bit too far into development -
for reasons that seemed good at the time but were really more emotional than
real. "High risk, high payoff" turned out to be really "high risk, very
modest payoff". In the end, money determined the best approach - which was
the right outcome).

>
>> Here's an example:
>> We were trying to reduce the drag of underwater vehicles using all sorts
>> of
>> very high tech methods. One of the groups (no doubt with a vested
>> interest)
>> reported experimental success of their technique. But, some the of the
>> tests had failed. When asked why they threw out those results, they
>> said:
>> "something must have been wrong and invalidated those tests". But, they
>> had
>> no idea what might have been wrong or if the tests were truly invalid.
>> In
>> the end we decided that the technology lacked robustness and the results
>> were valid: they were indicative of a technology that was "on the edge"
>> of
>> working or not working.
>
> These are questions of craftmanship, regardless of whether we define
> this as an engineering or R&D project. If you do a set of tests, there
> are certain standards one would like to keep in order to "sell" the
> results. Explaining large amounts of "anomalies" should include a
> discussions of reasons, including the possible non-robust method.
>
> A few years ago, I met a former colleague who had got a new job in a
> company dealing with marine operations, since I last met him. He
> described a project he was involved in, where they had as ambition to
> deploy certain types of kit at the sea floor, at given locations in the
>
> deep sea and with very high accuracy. As he finished describing the
> goals,
> my reaction, expressed as a combination of body language and verbal
> comments was to the effect of "You guys must be mad to attempt
> something
> like this!" "Oh yes, that's how it might look." he responded. "We don't
>
> expect to actually meet the ambitions, though, but we would like
> to see how close we can get, and what it takes to get there."
> Most reassuring.
>
> We went on to discuss various ways of getting close to these goals.
> My friend said that somebody from some service company had approached
> him to discuss methods to deploy the kit. The people from the service
> company had said they could do this with standard technology. "Do you
> believe they can?" I asked quietly. "No. The representatives didn't
> even blink an eye when I described our ambitions."
>
> Our unspoken mutual understanding was that anyone who understood the
> complexity (well, semi-sanity) of the stated goals, would be very
> sceptical to whether this was at all possible. The service company
> showed, as I understood my friend's tale, no signs of understanding
> what this was all about, and did thus not get the contract.
>
>> So, for research we add to best practices: design of experiments, how to
>> handle results, repeatability, etc.
>
> Exactly. To me, these aspects are embedded in the term "craftmanship".

I agree. It was just that the original question was about best practices for
development and not for research. So, the responses were about development.
Then Jerry brought up "research" and we started a bit down that path. I
simply tried to say that changing the question would change at least some of
the answers. It's a bit harder for me to envision a product engineering
team deciding that failed tests were actually "OK" - although I know that it
happens. (e.g. see Richard Feynman's treatment of the space shuttle
disaster. Thus, I say "harder" not impossible).

Maybe there needs to be another item on the list:
"Make sure there is good craftsmanship in every discipline"

Fred

Fred Marshall wrote:

...

> I agree. It was just that the original question was about best practices for
> development and not for research. So, the responses were about development.
> Then Jerry brought up "research" and we started a bit down that path. I
> simply tried to say that changing the question would change at least some of
> the answers. It's a bit harder for me to envision a product engineering
> team deciding that failed tests were actually "OK" - although I know that it
> happens. (e.g. see Richard Feynman's treatment of the space shuttle
> disaster. Thus, I say "harder" not impossible).
>
> Maybe there needs to be another item on the list:
> "Make sure there is good craftsmanship in every discipline"

I didn't mean to sidetrack the discussion. My ought to have been more
explicit: some exploration is inevitable for all but the most mundane
projects. It surprises none of us that R&D has become a single concept.
I recall choosing an ADC converter peripheral card with bipolar
multiplexer whose specs suited the needs of a project well, only to find
-- after the hardware was assembled and drivers written -- that
dielectric storage in the holding capacitor made the sampler unable to
follow the multiplexer at speeds well within the spec. Oops!

(That time, I didn't have to start over. I found and fixed the problem
and told the manufacturer how. They issued a recall and change order.)

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