Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: comp.arch.embedded
Subject: Re: Diagnostics
Date: Fri, 18 Oct 2024 19:38:18 -0700
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vev635$3mf56$1@dont-email.me>
References: <veekcp$9rsj$1@dont-email.me> <veuggc$1l5eo$1@paganini.bofh.team>
 <77k5hjprfq0ipjp6pcdd03lnph1i76ssuu@4ax.com> <veunj9$3gbqs$2@dont-email.me>
 <vev398$1r4v5$2@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 19 Oct 2024 04:38:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="89048b1778d1f63268abb85022497358";
	logging-data="3882150"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pnJt30vW8R3CkLVf4sVg1"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:kA5JiqGOKufyq27iSJP9c4r7NJQ=
In-Reply-To: <vev398$1r4v5$2@paganini.bofh.team>
Content-Language: en-US
Bytes: 3586

On 10/18/2024 6:50 PM, Waldek Hebisch wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 10/18/2024 2:42 PM, George Neuner wrote:
>>
>>>   To ensure 100%
>>> functionality at all times effectively requires use of redundant
>>> hardware - which generally is too expensive for a non safety critical
>>> device.
>>
>> Apparently, there is noise about incorporating such hardware into
>> *automotive* designs (!).  I would have thought the time between
>> POSTs would have rendered that largely ineffective.  OTOH, if
>> you imagine a failure can occur ANY time, then "just after
>> putting the car in gear" is as good (bad!) a time as any!
> 
> TI for several years has nice processors with two cores, which
> are almost in sync, but one is something like one cycle behind
> the other.  And there is circuitry to compare that both cores
> produce the same result.  This does not cover failures of the
> whole chip, but dramaticaly lowers chance of undetected erros due
> to some transient condition.

The 4th bit in memory location XYZ has failed "stuck at zero".
How are you going to detect that?

One of the FETs that controls the shifting of the automatic
transmission as failed open.  How do you detect that /and recover
from it/?

The camera/LIDAR that the self-drive feature uses is providing
incorrect data...  etc.

There are innumerable failures that can occur to compromise
the "system" and no *easy*/inexpensive/reliable way to detect
and recover from *all* of them.

> For critical functions a car could have 3 processors with
> voting circuitry.  With separate chips this would be more expensive
> than single processor, but increase of cost probably would be
> negligible compared to cost of the whole car.  And when integrated
> on a single chip cost difference would be tiny.
> 
> IIUC car controller may "reboot" during a ride.  Intead of
> rebooting it could handle work to a backup controller.

How do you know the circuitry (and other mechanisms) that
implement this hand-over are operational?

It is VERY difficult to design reliable systems.  I am not
attempting that.  Rather, I am trying to address the fact that
the reassurances POST (and, at the user's perogative, BIST)
are not guaranteed when a device runs "for long periods of time".