“The developers of avionics software are confronted with the fact that many lives depend directly on the software they are constructing and
they pay meticulous attention to detail. A culture tends to evolve that leads developers to act cautiously, to not rely on intuition, and
to value the critiques of others.” … “An organizational culture that encourages and supports such attitudes is called a “safety culture”, and it is widely recognized as an essential ingredient in the engineering of critical systems.” [2007 National Research Council report on Software for Dependable Systems, page 49]

Purpose:

To identify current, but unnecessary, hazards to self-driving guidance (SDG) software
and suggest mitigations.

Scope:

     The focus is the safety of the guidance software.
     Neither the sensor processing software nor the effector control software is included in this initiative.

Strategy:

  1. Identify facts and assumptions (hazards) about the current competitive approach to requirements.
  2. Identify safer approaches (mitigations) e.g., cooperative requirements development.
  3. Raise awareness of safer approaches by vehicle manufacturers and roadway regulators.
  4. Solicit one-page position statements on this issue - pdf with contact name, organization, location, and email. Click here, when position statement is ready.
  5. Hold a workshop (group discussion) to kick-off the initiative. Click here to join the conversation.

Candidate hazards:

  1. SDG software will be at least an order of magnitude more complex than any embedded automotive software in production use today.
  2. As is well known to [some] software engineers (but not to the general public), by far the largest class of problems arises from errors made in the eliciting, recording, and analysis of requirements. [2007 National Research Council report on Software for Dependable Systems, page 40]
  3. Most US software engineers have never taken a requirements course. Only four of the “top 25” software engineering colleges in the US teach such a course. It is likely that most embedded software developers, some of which are EEs, and system engineers have never taken a requirements course either.
  4. Most software engineers, system engineers, and embedded software developers do not understand the nature of software quality requirements i.e., requirements for safety, security, reliability, and understandability. They do not know how to specify, achieve, nor verify them.
  5. In the US, regulators of self-driving vehicles (SDVs) know less about software requirements than software engineers.
  6. There are more than 40 companies worldwide “racing” to create components and vehicle guidance software with a poor understanding of software requirements in general and software quality requirements in particular.
  7. Without formal methods, the top 10% of software developers create 1 defect per KLOC.
  8. While the potential benefits of SDVs are very desirable (i.e., the ends), risks in the current competitive development approach (i.e., the means) are significant and unnecessary.
  9. When manual tasks are automated by a team, a detailed glossary is essential. Otherwise, something worse than a “tower of babel” is created within the team. The same words will have many different meanings. For example, the meaning of “erratic driving of the vehicle ahead” must be defined in detail along with actions to take when detected.
  10. Across industry, having more than one (1) glossary, (2) set of hazard analysis results, and (3) set of basic SDG requirements is a very bad idea.
  11. An industry-supported edge-case simulator for software verification will increase safety.
  12. People will die needlessly, especially early adopters, without industry-consensus work-products because significant confusion will be added to the significant complexity of this task.
  13. The volume of early deaths may endanger acceptance of the technology and thus its benefits would be lost or delayed due to risky development tactics.

     If there are other unnecessary hazards to the SDG software, please share. Thanks

Candidate mitigations:

  1. Encourage industry to cooperate in the development of industry-consensus, "open-source", requirements information including a glossary, hazard analysis, and specification of basic SDG requirements.
  2. Develop an ISO standard on "meta-requirements for critical software requirements". Click here to download a straw draft. Click here to share comments.
  3. Encourage regulators to require compliance with the meta-requirements standard.
  4. Encourage development and use of an industry-supported edge-case simulator for SDG software verification.

     If there are other candidate mitigations, please share. Thanks