What is a Processor and Software in Context of Reliability Analysis?

How is a "processor" defined when considering requirements on developing a =
design?  A project I am on is shoving software into HDL to design an FPGA w=
hich is being considered "hardware".  I'm not fighting it because FPGAs are=
 what I do.  Board level design is a necessary evil to support the FPGA. If=
 not for the desire to make approval easier the FPGA would not be on the bo=
ard.=20

I'm concerned that the thinking it will take less effort to get approval on=
 the FPGA than approval on the equivalent software running on an MCU.  I'm =
not seeing a basis for this comparison. =20

The context is medical equipment, specifically a ventilator.  I'm working o=
n one of the many open source projects that have sprung up in response to C=
OVID-19. =20

The functionality of the FPGA is to detect the alarm conditions.  To do tha=
t the FPGA requires sensor readings of pressures, O2 levels, temperature an=
d a couple of voltages.  Fixed calculations will be performed, not under co=
ntrol of any software, rather state machines.  The issue is whether any of =
this constitutes "processor software" since at some level there is source c=
ode that is compiled by tools. =20

Compare to the C programs being developed for the MCU as well as to the sch=
ematic editors and layout software that are used to generate the Gerber fil=
es and pick and place files for automated assembly.=20

Where does the definition of "processor software" begin and end?=20

--=20

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

On 03/09/2020 18:45, Rick C wrote:
> How is a "processor" defined when considering requirements on developing a design?  A project I am on is shoving software into HDL to design an FPGA which is being considered "hardware".  I'm not fighting it because FPGAs are what I do.  Board level design is a necessary evil to support the FPGA. If not for the desire to make approval easier the FPGA would not be on the board.
> 
> I'm concerned that the thinking it will take less effort to get approval on the FPGA than approval on the equivalent software running on an MCU.  I'm not seeing a basis for this comparison.
> 
> The context is medical equipment, specifically a ventilator.  I'm working on one of the many open source projects that have sprung up in response to COVID-19.
> 
> The functionality of the FPGA is to detect the alarm conditions.  To do that the FPGA requires sensor readings of pressures, O2 levels, temperature and a couple of voltages.  Fixed calculations will be performed, not under control of any software, rather state machines.  The issue is whether any of this constitutes "processor software" since at some level there is source code that is compiled by tools.
> 
> Compare to the C programs being developed for the MCU as well as to the schematic editors and layout software that are used to generate the Gerber files and pick and place files for automated assembly.
> 
> Where does the definition of "processor software" begin and end?
> 
My understanding (which is not definitive) based on working with people 
in Aerospace several years ago but some are still buddies, and more 
recent work on making a device potential capable of being certified for 
use on civil aeroplanes:

A long time ago (10 years) FPGAs kind if slipped under the software 
regulations radar. This led to people trying to hide stuff in FPGAs.
The regs are now much tighter and whatever is inside an FPGA and the 
software tools to make and test it are subject to the same regime as 
software as we've always know it. This may be a pain but it does make sense.

You would need to be an expert on medical regulations (and I'm certainly 
not) but I would expect them to up with the rest. Which would mean that 
every line of code in your HDL will need to be traceable back to a 
requirement and traceable forward to a test that proves it did whatever 
it was for, correctly.

But if you are worried about potential litigation rather than the exact 
letter of the rules, then you must assume that a US court would expect 
you to apply "best practice" anyway.

My starting point with these things is that all this software quality 
methodology doesn't work very well, and you should assume that the 
micro, FPGA or whatever behaves as if guided by malevolent intelligence 
to do the worst thing it possibly can. You protect the system with some 
external hardware that prevents the bad stuff from happening.

You'll need an expert to say if you can partition the system and apply 
different rules to different parts of it.

I think I've argued myself into thinking that you should consult an 
expert in medical electronic system regulatory approval :-)

MK

On Friday, September 4, 2020 at 10:21:04 AM UTC-4, Michael Kellett wrote:
> On 03/09/2020 18:45, Rick C wrote:
> > How is a "processor" defined when considering requirements on developing a design?  A project I am on is shoving software into HDL to design an FPGA which is being considered "hardware".  I'm not fighting it because FPGAs are what I do.  Board level design is a necessary evil to support the FPGA. If not for the desire to make approval easier the FPGA would not be on the board.
> > 
> > I'm concerned that the thinking it will take less effort to get approval on the FPGA than approval on the equivalent software running on an MCU.  I'm not seeing a basis for this comparison.
> > 
> > The context is medical equipment, specifically a ventilator.  I'm working on one of the many open source projects that have sprung up in response to COVID-19.
> > 
> > The functionality of the FPGA is to detect the alarm conditions.  To do that the FPGA requires sensor readings of pressures, O2 levels, temperature and a couple of voltages.  Fixed calculations will be performed, not under control of any software, rather state machines.  The issue is whether any of this constitutes "processor software" since at some level there is source code that is compiled by tools.
> > 
> > Compare to the C programs being developed for the MCU as well as to the schematic editors and layout software that are used to generate the Gerber files and pick and place files for automated assembly.
> > 
> > Where does the definition of "processor software" begin and end?
> > 
> My understanding (which is not definitive) based on working with people 
> in Aerospace several years ago but some are still buddies, and more 
> recent work on making a device potential capable of being certified for 
> use on civil aeroplanes:
> 
> A long time ago (10 years) FPGAs kind if slipped under the software 
> regulations radar. This led to people trying to hide stuff in FPGAs.
> The regs are now much tighter and whatever is inside an FPGA and the 
> software tools to make and test it are subject to the same regime as 
> software as we've always know it. This may be a pain but it does make sense.
> 
> You would need to be an expert on medical regulations (and I'm certainly 
> not) but I would expect them to up with the rest. Which would mean that 
> every line of code in your HDL will need to be traceable back to a 
> requirement and traceable forward to a test that proves it did whatever 
> it was for, correctly.
> 
> But if you are worried about potential litigation rather than the exact 
> letter of the rules, then you must assume that a US court would expect 
> you to apply "best practice" anyway.
> 
> My starting point with these things is that all this software quality 
> methodology doesn't work very well, and you should assume that the 
> micro, FPGA or whatever behaves as if guided by malevolent intelligence 
> to do the worst thing it possibly can. You protect the system with some 
> external hardware that prevents the bad stuff from happening.
> 
> You'll need an expert to say if you can partition the system and apply 
> different rules to different parts of it.
> 
> I think I've argued myself into thinking that you should consult an 
> expert in medical electronic system regulatory approval :-)

Yes, I am aware of this.  I've asked questions about how this is going to come about and the thinking is that a company will be found capable and willing to improve the design so it can be approved and then market the machine.  This seems to be the project management version of "and then a miracle happens".  

I'm an older guy, essentially at the end of my career, and I have been learning about the non-technical aspects of engineering the whole time.  Virtually every project I've been on was poorly managed.  But none were done with such inexperience that essential aspects were for all practical purposes, ignored... until now.  

On the other hand, it is amazing how much progress has been made on the technical side of things.  It's also fun to work with people on the other side of an ocean.  

I hate preparing documents, but I appreciate how important it is to have a proper set of detailed, accurate requirements before starting work... especially if time is of the essence.  Lincoln once said that if he had but an hour to chop down a tree, he would spend the first 30 minutes sharpening the ax. 

I should add that to the beginning of the document.  

-- 

  Rick C.

  + Get 1,000 miles of free Supercharging
  + Tesla referral code - https://ts.la/richard11209