[SystemSafety] Another Bloomberg article

Eric Burger Eric.Burger at georgetown.edu
Wed Nov 13 18:47:33 CET 2019


I’m hoping again the reporter got it wrong. Two systems? Space shuttle had four so you could have a 3-against-1 vote. I suppose having three to have a 2-against-1 vote is OK for non-space applications. However, two is insane. A failure of the backup system results in the primary being taken down? Really?


> On Nov 13, 2019, at 4:06 AM, Peter Bishop <pgb at adelard.com> wrote:
> 
> Quote from Bloomberg article:  "Delays in Boeing Max return began with near crash in simulator"
> https://www.bloomberg.com/news/articles/2019-11-08/delays-in-boeing-max-return-began-with-near-crash-in-simulator?fbclid=IwAR1R6_y2DtwhHi5wq9kaOCRLMEcwE2cxIeAu_-aivpR2k_swaZZxYTQr5ok <https://www.bloomberg.com/news/articles/2019-11-08/delays-in-boeing-max-return-began-with-near-crash-in-simulator?fbclid=IwAR1R6_y2DtwhHi5wq9kaOCRLMEcwE2cxIeAu_-aivpR2k_swaZZxYTQr5ok>
> -------
> 
> By contrast, the 737 Max had two separate computers. One operated the flight systems and another was available if the first one failed, with the roles switching on each flight. But they interacted only minimally.
> 
> Boeing decided to make the two systems monitor each other so that each computer can halt an erroneous action by the other. This change is an important modernization that brings the plane more in line with the latest safety technology but raised highly complex software and hardware issues..
> 
> 
> --------
> I don't think this change is a good idea at all.
> 
> Who trusts whom when two computers think each other is wrong?
> How do you address the fact that each computer is asynchronous with slightly different sensor values and timing which might cause the two computers to diverge at decision thresholds?
> 
> Either:
> 
> 1) Change the hardware to improve fault detection within each computer
> (i.e. it fails silent if it gets scrambled) e.g. each computer is upgraded to a lockstep processor pair with hardware cross-comparison.
> 
> 2) Change the system to a TMR design so failure of a single processor can be tolerated.
> 
> The first option would be the easiest from a software perspective.
> 
> Peter Bishop
> 
> --
> 
> Peter Bishop
> Chief Scientist
> Adelard LLP
> 24 Waterside, 44-48 Wharf Road, London N1 7UX
> 
> Email: pgb at adelard.com <mailto:pgb at adelard.com>
> Tel:  +44-(0)20-7832 5850
> 
> Registered office: 5th Floor, Ashford Commercial Quarter, 1 Dover Place, Ashford, Kent TN23 1FB
> Registered in England & Wales no. OC 304551. VAT no. 454 489808
> 
> This e-mail, and any attachments, is confidential and for the use of
> the addressee only. If you are not the intended recipient, please
> telephone 020 7832 5850. We do not accept legal responsibility for
> this e-mail or any viruses.
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20191113/f924b347/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20191113/f924b347/attachment.sig>


More information about the systemsafety mailing list