Purpose:

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

Scope:

     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 whom 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 developers.
  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. 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.
  8. 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 preceeding vehicle” must be defined in detail along with actions to take when detected.
  9. Having more than one (1) glossary, (2) set of hazard analysis results, and (3) set of basic SDG requirements is dangerous.
  10. Competitive requirements suggest unsafe cultures.
  11. An industry-supported edge-case simulator for software verification will also 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 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 quality-aware development.
  5. Encourage specification of quality attribute requirements using a tailored 3D quality model.
  6. Encourage staffing of a Quality and Productivity function (part 3 of Quality Goals chapter).
  7. Encourage development and use of an industry-supported edge-case simulator for SDG software verification.

     Note: Details of mitigations 4-6 can be found at www.quality-aware.com

     If there are other candidate mitigations, please share. Thanks