PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 27th Nov 2019, 20:51
  #4177 (permalink)  
Mad (Flt) Scientist
 
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by GlobalNav
Beg to differ a bit. DAL A assurance is supposed provide convincing evidence that requirements are validated, and that they are traced to the code. The process for establishing software Design Assurance Level A is painfully extensive in time and resources. It is not an absolute guarantee of no software errors because testing to prove that is not possible. But the process, developed by manufacturers and regulators together has been in use for decades, though not without attempts to push back. Hopefully, energy to resist pushback at the rigor of DAL processes will be renewed as a result of the MAX debacle.
Differ on your "differ".

As you say, DAL-A is fundamentally a SOFTWARE assurance process not a systems design assurance process. For a holistic systems design process with rigour with regard to requirements, one has to look to something like ARP4754 instead. DAL-A starts with the assumption that the systems designer knows what he is doing, and makes sure the software does what he intends. DAl-A requirements validation will typically validate the software requirements against the systems requirements, but go no further into the design. ARP4754 more fundamentally questions the systems design and the assumptions therein.

True, the DAL-A process can sometimes highlight deficiencies in the higher level requirements - muddled thinking there may cause a muddle at the software level, and software design assurance will probably catch that, and if the breadcrumbs are followed (and the software folks will be motivated to do so, to prove it's not their fault!) then the problem may be found. But if the problem is not muddle but rather being wrong, but consistently so, then all DAL-A ultimately proves is that the SW does what it's supposed to.

A lot of what we sometimes lazily call a "software problem" is actually a systems design problem, and would have occurred whether the design were implemented in software, analogue electronics or even hardware. In other words, DAL-A is a necessary but not sufficient condition for correct design execution.
Mad (Flt) Scientist is offline