Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design,comp.arch.embedded
Subject: Re: Validation in non-regulated industries/markets
Date: Tue, 12 Nov 2024 17:28:59 -0700
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <vh0rsf$1redv$2@dont-email.me>
References: <vgk30d$323tl$1@dont-email.me> <vgkn3l$358tg$1@dont-email.me>
 <8b52b8a7-7f5b-0526-6df0-2d1219e3a179@Strand_in_London.Gov.UK>
 <vh0re9$1redv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 13 Nov 2024 01:29:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="6f4ad9a2b5f729d44ea3502577c03dda";
	logging-data="1948095"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+eK8AHsDTqRXImeAqvHhSi"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:YwxU47b0QuFW95YL7eZFEKGLvUs=
Content-Language: en-US
In-Reply-To: <vh0re9$1redv$1@dont-email.me>
Bytes: 2364

On 11/12/2024 5:21 PM, Don Y wrote:
> Validation exists for a reason -- separate from and subsequent to
> product testing.  Because these sorts of SNAFUs happen all the
> time!

[Sidetracked by my anecdotes...  :< ]

Anyway, the question posed is how to address the "product as delivered"
(in terms of hardware) requirement inherent (and mandated) in validation
for those markets where there are no "rules".

How much can you alter the hardware and still, in good conscience
(and, more practically, in having faith in your results), attest
to the fact that you have verified the product is what it SHOULD
be, despite any deficiencies in the specification(s)?  When are
you rationalizing equivalence just because a true "as delivered"
environment is not possible?

[How do you test subsystems, on which you rely, inside an MCU
without a bond-out option?  Or, do you simply say that anything
that can't be tested need NOT be tested -- and not even make
an attempt to do so?  E.g., Why do we checksum internal FLASH?
Can you simulate a failure -- without altering the hardware -- to
be able to verify that you can detect it?]