Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29815

Re: Group Design

Show all headers | View raw

On 7/9/2020 7:01 PM, Rick C wrote:
> On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
>> On 7/7/2020 6:46 PM, Rick C wrote:
>> The downside of groups is folks tend to have narrow "specialties" and
>> there often are not "generalists" who can look at the entire project and
>> see where (function) responsibilities could better be shifted.
>> 
>> (I worked on a 30-man project where one developer designed a ~80 sq in PCB
>> populated entirely with DIP switches -- cuz it didn't occur to him that
>> the processor could make those settings more economically and in a more
>> user-friendly manner than he -- with no MCU experience -- had ever
>> considered)
> 
> How can a design group operate with so little communication that this could
> happen???

Who *should* take responsibility for that sort of decision, other than
the Project Manager?  Should his competencies include ALL of the areas
of expertise for the team?  Should each team member question the
requirements imposed on himself by other team members' aspects of the
project?

You start off with the assumption that folks are (nominally) competent.
If you question each assertion/demand, then you spend all of your time
asking "Why" instead of assuming that there is a Good Reason "why"
and, other than your own insecurity or curiosity, there's no need for
you to KNOW all of those details ("Why is the machine painted beige?
Why are we using steel instead of aluminum?  Why HiNIL instead of CMOS?
Why Motogorilla instead of Intel?")

Most folks don't have much experience outside of their own narrow field
of expertise.  So, it doesn't dawn on them that the design constraints
COULD be different.

I designed a CPU many years ago.  My best friend was writing the code to
execute on it.  When we installed the code on the prototype processor,
NOTHING worked!  We were each infinitely confident in the OTHER'S abilities
so immediately assumed the mistake lie in our own efforts.  Eventually,
we each realized there were no errors that we could identify in our own
efforts.  So, started looking at each other.  It turned out, my friend
(being a software person) instinctively thought in terms of "bytes".
I, in a hardware role, had designed the processor to operate on WORDS
(it was not possible to address individual bytes).  So, all of the
addresses in his code were off by a factor of two!

"Didn't you think it unusual that ALL of your address fields were EVEN??"

Neither of us had even considered this would be something that we'd have
to agree upon; it was "obvious" to both of us, individually -- just not
the same assumptions!  :<

The (hardware) guy designing the DIP switch board knew that he had to
have a bunch of user-specified parameters for his circuit to operate.
So, he relied on the "usual" means of getting parameters into a
hardware circuit:  switches/jumpers/etc.  Because no one was actively
overseeing his design ("trust the designer"), it never occurred to
anyone (other than me) to suggest "there's a better way!"

But, I was only involved because of my own personal curiosity as to
what his circuit did and how it did it.  The project manager (a MechE)
was completely clueless...

>> cGMPs tend to center around having a thorough (documented!) process and
>> good papertrail to show that you took the effort "seriously".  If you
>> don't have a written spec BEFORE you start the design, how do you know
>> WHAT you are designing ("Did you make this up, as you went?")? And, how
>> can you evaluate whether or not you have met your design goals?
> 
> Yes, I have tried to get a spec done for selection a new processor (without
> doing it all myself), but the inputs were thin.  The one software developer
> started talking about how much better the tools are with ST micros and
> tossing part numbers out so that is what was picked.

Regulatory agencies don't care that he "picked" an ST device instead of
a GI device.  What they want to see is that there was a formal specification
of what was needed and a VERIFICATION that the chosen device met those
requirements.

You can implement a multiplication operator many different ways.  The
regulators don't care WHICH way you choose -- just that the chosen
way satisfies the stated requirements.

> Much is being made up as we go along.  When it was decided to go with I
> believe it is called "assisted" mode ventilation, that puts a whole
> different set of requirements on the system including the plumbing and the
> main circuit board.
> 
> If a design is produced that works, and can be shown to work by the methods
> required, why would the lack of documentation of the process be a stumbling
> block?

FDA is all about process.

When you (personally) design something, I'd wager that you do lots of
testing WHILE putting the design together, evolving its requirements, etc.
Even if that testing is informal, shirt-sleeve sort of effort.  Why do
you do it?  Why not just wait until you're done and test "end-to-end"?
Ans:  the testing gives you increased confidence in the design at various
levels WITHIN the design.

I can design/implement an HVAC system and verify that it keeps the house
at 72 degrees, "exactly".  But, if I notice that the furnace is running
continuously and it's 71 degrees outside, I don't have much faith in that
design/implementation!  Is the furnace not generating the required amount
of heat?  Is the blower running too slowly?  Are there air leaks?  etc.

How confident (put a NUMBER on this!) would I be that it could maintain
that 72 degrees if it was 20 degrees outside?

How confident would you be that the ventilator would work against an
increased back pressure?  Or, at a lower desired flow rate/volume?
Or, with a "low mains" voltage?  Can you test EVERY possible operating
condition?

>> What tests did you run?  What were the results?  What did you do to remedy
>> substandard behaviors?  Did these efforts achieve the desired result (did
>> you even BOTHER to rerun the tests after those changes?)
> 
> Not sure what you are getting at here.  The tests must be met by a finished
> unit.

Testing occurs at two levels (at least -- a developer can always do his
own "experiments" off on the side).  There's an "inner loop" that consists
of "specify, design, implement, VERIFY" that can potentially be repeated
many times.  (but, each time it is a FORMAL process... an ENDORSED spec,
documented test suite, documented results, documented triage)  Each of
these iterations becomes part of the Design History File (DHF) -- a
written record of how you adhered to your process (which was FORMALLY
codified *before* you started all of this!).

Once you think you are "done", your design is formally VALIDATED.
This is when you prove that it meets the intended design goals/user
requirements.  If you fail the validation step, you reenter the above
iteration sequence until you think you're ready to try again.

VALIDATION is typically "expensive" (time/labor) so you don't want to
undertake it casually.  By contrast, VERIFICATION is largely an
internal effort that YOUR PROCESS has control over (who can perform
the activities, how they are controlled, logged, etc.).  So, its
less expensive than validation but more expensive than a lone
developer "tinkering" with some aspect of his design "off the books".

Once validated, the design and implementation are frozen.  You can't
replace multiply() with an "equivalent" version without requiring
revalidation.  You may THINK that all that matters is the "product"
produced by that routine but may discover (in a validation) that
there are unintended side-effects that compromise the design...
maybe the addresses of some routines/variables have been altered,
slightly (though "equivalently") and a bug has been uncovered
that was masked by the previous address bindings!  Or, maybe the
routine is faster and it exposes a race that had previously been
"biased" advantageously.

Remember, the product is not the *abstract* representation that
exists on your design documents (schematics, source code, etc.)
but, rather, the ACTUAL reification that "Manufacturing" churns
out the loading dock.  So, change the compiler switches and you
end up with a new binary --> revalidate!  Change the compiler
and you end up with a new binary --> revalidate!  Change the
processor (because it had an internal bug that has been fixed
in the latest mask) --> revalidate.

Or, engage in a *more* complex analysis that PROVES that the
change(s) have no impact on the design -- at all levels IN the design!

>> There is no one at the FDA who is going to evaluate your schematics, check
>> your code for errors or even check that your device does what it claims to
>> do!  They typically don't have the resources nor expertise to do so.
>> *You* make those assertions and convince them of your sincerity and
>> diligence with your papertrail/process (and reputation).
> 
> That seems like even more work than any other method of verification.  In
> DOD it's all about passing the acceptance test.  Of course there are
> requirements on the process, but that is mostly about developing the
> requirements and tests.

My experience with DoD has only been as a Manufacturing Engineer.  I
recall lots of "useless paperwork" (in the eyes of a teenager) that had
to document each change I made (even if it was obvious:  "The hole is
tapped for #6-32 and the parts list calls out a #4-40"), every
"defective" component that I replaced (along with SAVING the
actual component for later analysis), how I uncovered the fault,
how long it took to diagnose, repair, retest, etc.  None of these
activities make *this* unit operate better; but, they can be
insightful to folks (bean counters) behind the scenes revising
the design, preparing courseware, etc.

But, I can't imagine there isn't a similar set of controls over process,
behind the scenes.

>> [And, of course, expose yourself to future litigation if things go tits
>> up!]
>> 
>> Bottom line, any manufacturer who would consider producing the device 
>> would want the same sort of assurances (from you)
> 
> No, not from us.  That is ally their baby.

But THEY have to make these assurances to the regulators.

I've only dealt with one product that had *direct* exposure to patients
(all of the others were indirect -- diagnostic, etc.).  But, it was
a proof of concept design that was never intended to be manufactured
"as is".  Instead, we had to flesh out the design to show ONE WAY
that the desired functionality could be provided, "reliably".  The
commissioned goal was a "dog-and-pony" that executives/investors
could poke at to decide if it was a worthwhile product to develop
(that THEY would then take on with their armies of STAFF) as the
half-dozen of us had neither the resources (manufacturing) nor
desire (the IDEA is where all of the fun lies!) to undertake FOR
them.

So, we could employ all sorts of "undisciplined" design methodologies
to get to that point -- something that they couldn't do due to their
adherence to all of that formal structure.

I've worked on other projects where we made a very deliberate effort
to produce a product that was "a step away from manufacturing" (including
hundreds of kilobucks of machined stainless steel parts, custom designed
mechanisms, electronics, software, etc.) only to see the design scrapped
when brought to REAL production.  (when you try to make a REAL product,
instead of an approximation, you identify lots of little issues that
seriously impact manufacturability -- in that case, the mechanism was
incredibly elegant but would be hard to reliably produce in volume)

>> that the FDA wants as they would be putting THEIR reputation (and assets)
>> on the line.  They're likely NOT going to opt for an "Arduino" as a key
>> component unless they have some assurances that the module will remain
>> available for a considerable amount of time AND won't change (i.e., no
>> firmware upgrades as they'd require the product to be revalidated)
> 
> Not THE Arduino, the processor and basic design.  The Arduino really is
> nothing more than a power supply and a processor with a crystal.  I think
> there is a USB debugger chip.

No firmware onboard?  Toolchain never revised?  Libraries?  No mask
revisions in the processor?  Die shrinks?  Layout changes?

They are interested in making a product hobbyists/hardware-challenged
want to buy so are concerned with cost/profit and features.  They likely
don't expect any of their customers to complain because they trimmed
a clock cycle off of some particular opcode in the processor.  Or,
increased the amount of onboard RAM, or supported USB3, etc.

>> OTOH, if you're trying to *hack* together something for disadvantaged 
>> third-world countries (pandemic or otherwise), they'll likely be grateful
>> for whatever they can get their hands on.  And, you'll likely want to use
>> components that can be easily acquired instead of requiring some
>> significant design or purchasing investment.
> 
> Yeah, that was one of the goals, but the case is a custom design of
> stainless steel sheet metal and a custom plastic overlay for the front
> panel.  Of course the main board is a custom design and there are components
> used that will be sole sourced... the O2 sensor, the pressure sensors, the
> gear motor.  I think there are some plexiglass pieces for pressing on the
> bag and that will be one design since variations may well cause changes in
> how the pressure varies with force from the motor, volume, etc.  Then there
> will be specific parts indicated for the external plumbing.  So while anyone
> can build one, it won't be a simple matter of going to the hardware store to
> get the parts.

So, the idea that it's an "affordable" design suited for "less resourceful"
environments is no longer the case.

> One of the trickier parts is the air flow sensor.  They are measuring the
> differential pressure across an orifice.  Most of the use will be at the low
> end where the response is not linear and sensitivity is not good.  I found
> they are using a commercial product to calibrate their 3D printed device.
> Why not just buy the commercial device, the look almost the same.  The 3D
> printed device has a socket for the O2 sensor...

<shrug>  Despite their possible motivations, it really looks like this is
just a glorified hobbyist exercise -- being able to tell themselves they
are doing something "worthwhile" when, in fact, they are throwing away
their time/resources.

There was a group, here, that wanted to build "little houses" for The Homeless.
Lots of energy, excitement, press coverage, etc.  But, totally lacking in
the skills needed to actually BUILD little houses!  They'd have done more
good if they had flipped burgers at McDonald's for all the hours they
spent meeting and talking about it... and donated the monies to the
first homeless person they encountered on a street corner!

I think the idea of a low-cost, third-world ventilator would be admirable.
It's a "market" that doubtless won't be addressed (go where the money is!).
And, can likely avoid all of the effort/tedium/expense/legalese that selling
into first-world markets would entail.

It's also a much more challenging project!  Not just coming up with a
reproducible design but, also, looking past that to MAINTAINING the
design in environments that don't have easy access to the same sorts
of technology that we are accustomed to.  E.g., imagine every component,
individually, breaking.  How would you replace them if you were in
Sudan?  Yemen?  Ethiopia?  What do you do if you have a single "15A"
branch circuit powering an entire ward?  How many of these can you
support in addition to the other "required" equipment?  How will
your design fare if power fails/fluctuates often?  etc.

[I've had to "dumb down" designs, in the past, to ensure they could be
maintained in places hat are off-the-beaten-track.  It's really hard
to imagine how LITTLE you actually NEED when you are accustomed to having
more-than-enough!]

Good luck!

(BTW, if you're interested in the FDA issues in greater detail, chase
down Title 21 of the FDA's CFR 820.30 to get a general overview)

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 18:46 -0700
  Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-07 19:02 -0700
    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 20:36 -0700
      Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-08 09:31 +0200
        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:08 -0700
  Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 14:13 +0200
    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:19 -0700
      Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 18:57 +0200
        Re: Group Design Theo <theom+news@chiark.greenend.org.uk> - 2020-07-08 18:28 +0100
        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 11:12 -0700
          Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 23:34 +0200
            Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 15:20 -0700
              Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 23:00 -0700
              Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:09 +0200
              Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 00:01 +0100
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 17:37 -0700
                Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 03:06 -0700
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 21:50 -0400
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:12 -0700
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 22:27 -0400
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:36 -0700
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 23:39 -0400
                Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 12:30 +0100
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 09:57 -0400
                Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:37 +0100
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:29 -0400
                Re: Group Design upsidedown@downunder.com - 2020-08-08 08:59 +0300
                Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-08-10 15:43 +0200
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-10 09:18 -0700
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 07:12 -0700
                Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:00 +0100
                Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:30 -0400
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:57 -0700
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:56 -0700
                Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 18:10 -0700
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 19:43 -0700
                Re: Group Design Dimiter_Popoff <dp@tgi-sci.com> - 2020-08-07 20:42 +0300
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 13:48 -0700
      Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 14:11 -0700
      Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 04:25 -0400
        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 11:37 -0700
          Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-09 11:54 -0700
          Re: Group Design Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-07-09 20:02 +0100
          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 15:31 -0400
            Re: Group Design lasselangwadtchristensen@gmail.com - 2020-07-09 15:36 -0700
              Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:36 -0700
                Re: Group Design Clifford Heath <no.spam@please.net> - 2020-07-10 16:17 +1000
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:36 -0700
                Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:22 +0200
      Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-09 14:40 +0200
  Re: Group Design John Speth <johnspeth@yahoo.com> - 2020-07-09 07:59 -0700
  Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 18:33 -0700
    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 19:01 -0700
      Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 22:32 -0700
      Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-10 17:36 -0400
        Re: Group Design Ed Prochak <edprochak@gmail.com> - 2020-07-14 11:09 -0700
          Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-16 00:26 -0400
  Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 22:48 -0700
    Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 23:53 -0700
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-10 01:15 -0700
        Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-10 02:22 -0700

csiph-web