View Single Post
  #169   Report Post  
Posted to uk.d-i-y,uk.transport
TMS320 TMS320 is offline
external usenet poster
 
Posts: 101
Default Accelerator stuck wide open while car is going fast: what should

On 30/07/18 09:42, wrote:
On Sun, 29 Jul 2018 16:39:18 +0100
TMS320 wrote:
On 29/07/18 09:16,
wrote:
I assumed ABS systems had always been microcontroller controlled,
didn't realise there were analogue versions. Interesting to know.


The electronics industry didn't make a quantum leap from analogue to
microcontroller. There was an intervening period with boards full of
logic chips, plenty of which would have been part analogue, such as
monostables. Then, not all of it could instantly be mopped up by micros.


I suppose in theory there's little you can do in software that you couldn't
hardwire in TTL, but it would take a lot of hardware to do anything
sophisticated so would be hard to fit into a car module. I'm guessing the
earlier ABS systems were pretty simple affairs.

No doubt, but the more complex ian algorithm becomes the more likely
it is that there's some nasty undisovered edge cases lurking in there
either due to the implementation or the algorithm itself which might
cause serious problems. In aviation they do formal proof checking,
multiple implementations of the same algorithm by different teams and
god knows what else to mitigate this, but I doubt the automotive
industry is quite so thorough simply due to cost.


Formal proof has limits. Test, test and test again on real product.


Yes, formal proofs have been somewhat oversold in the past. All that happens
is you move a portion of the debugging from the code to the proof - its
irrelevant if the code passes the formal testing if the proof is bug ridden
itself and for any significant project the formal proofs can be gargantuan.


It's probably not so bad for software that processes data in a computer
system (with "unlimited" resources), which is [hoped to be] scalable and
the compiler and os handle the i/o. I don't have experience of this type
of project.

The problem is in attempts to rigidly impose these methods on a real
time system with complex hardware. High level stuff can be simulated and
when incorporated doesn't give problems but the bulk of development is
low level work and nothing can be proved except with physical live kit.
"Bugs" are not usually coding errors but an incomplete understanding of
the system.