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


Groups > sci.electronics.design > #728407

Re: Validation in non-regulated industries/markets

From Don Y <blockedofcourse@foo.invalid>
Newsgroups sci.electronics.design, comp.arch.embedded
Subject Re: Validation in non-regulated industries/markets
Date 2024-11-13 12:59 -0700
Organization A noiseless patient Spider
Message-ID <vh30fa$2bvr0$1@dont-email.me> (permalink)
References <vgk30d$323tl$1@dont-email.me> <6734fb90$0$2873011$882e4bbb@reader.netnews.com>

Cross-posted to 2 groups.

Show all headers | View raw


On 11/13/2024 12:18 PM, bitrex wrote:
> On 11/7/2024 11:10 PM, Don Y wrote:
>> In *regulated* industries (FDA, aviation, etc.), products are
>> validate (hardware and software) in their "as sold" configurations.
>> This adds constraints to what can be tested, and how.  E.g.,
>> invariants in code need to remain in the production configuration
>> if relied upon during validation.
>>
>> But, *testing* (as distinct from validation) is usually more
>> thorough and benefits from test-specific changes to the
>> hardware and software.  These to allow for fault injection
>> and observation.
>>
>> In *unregulated* industries (common in the US but not so abroad),
>> how much of a stickler is the validation process for this level
>> of "purity"?
> 
> <snip>
> 
> OK boss says i gotta build a self driving car huh... ok lets see... java, 
> that's a given.. alright... *starts typing* public class Car extends Vehicle {...

Failure to recognize that there WILL be some need to validate your product
is often the undoing of what might otherwise be a successful product.

The effort is usually significant (in Pharma, it begins long before the
product development -- with audits of your firm, its process and procedures,
the qualifications of the personnel tasked with the design/development,
etc.).

For a specific product, you must verify everything documented
behaves as stated:  show me that you will not accept invalid input;
show me that the mechanism moves to a safe state when configured
(or accessed) improperly; show me that you can vouch for the information
that your sensors CLAIM and the actions that your actuators purport
to affect; etc.  Just stating that a particular error message (or other
response) will be generated isn't proof that it will -- show me HOW you
sense that error condition, how you report it and then give me a real
exemplar to prove that you *can*.

The *customer* ultimately knows how the product will be (ab)used -- even
if he failed to communicate that to the developer at the time the
specification was written (a common problem is the impedance mismatch
between domains:  what the customer takes for granted may not be evident
to the specification developer).  He will hold its feet to the fire
and refuse to accept the device for use in his application.

[We test drive cars for a reason -- we will eventually BE driving that car!]

So, for a self-driving car, how do you prove you can avoid running over
pedestrians?  That you will heed the warning sounds from emergency vehicles?
That you won't drive off a cliff?  That you can observe driving constraints
(minimum and maximum speeds, lane closures, etc.)  Because the purchaser/driver
of such a vehicle surely wouldn't want to find themselves in one of these
situations!  "Ooops!  You're entitled to a partial refund..."

E.g., we have one of the few roads in the US that is marked in metric
units (KM/Hr).  Will the designer have considered this in his optical
recognition of road signs?

We use blinking yellow arrows to indicate "turn if safe to do so".
We also make left turns AFTER the thru traffic has come to a complete
stop -- except for cases where the "leading left" is observed.
Will the car expect this?  Will it know when it is safe to use the
center (reversible/"suicide") traffic lane?

[ISTR places in D.C. where the direction of one-way streets changes
based on time of day.  Will the GPS know NOT to route you that way
based on time of day??]

Unless you've considered these issues and responsibilities, you will be
"surprised" at how a profitable DESIGN endeavor can become a money sink!

Back to sci.electronics.design | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Validation in non-regulated industries/markets Don Y <blockedofcourse@foo.invalid> - 2024-11-07 21:10 -0700
  Re: Validation in non-regulated industries/markets David Brown <david.brown@hesbynett.no> - 2024-11-08 10:53 +0100
    Re: Validation in non-regulated industries/markets "Niocláiſín Cóilín de Ġloſtéir" <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-11-13 00:27 +0100
      Re: Validation in non-regulated industries/markets Don Y <blockedofcourse@foo.invalid> - 2024-11-12 17:21 -0700
        Re: Validation in non-regulated industries/markets Don Y <blockedofcourse@foo.invalid> - 2024-11-12 17:28 -0700
        Re: Validation in non-regulated industries/markets David Brown <david.brown@hesbynett.no> - 2024-11-13 09:58 +0100
  Re: Validation in non-regulated industries/markets bitrex <user@example.net> - 2024-11-13 14:18 -0500
    Re: Validation in non-regulated industries/markets Don Y <blockedofcourse@foo.invalid> - 2024-11-13 12:59 -0700
      Re: Validation in non-regulated industries/markets Don Y <blockedofcourse@foo.invalid> - 2024-11-13 14:42 -0700

csiph-web