Re: Validation in non-regulated industries/markets

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!