Software Controlled Trucks Crash

The West Australian reported that two autonomous haulage systems (AHS) trucks experienced a collision when one of the trucks backed into the cab of the second truck that was stationary at the time.  This is of interest to us as the AHS trucks are software controlled and they crashed.  Clearly a failure mode.  The initial report is that the sequence of events leading to the crash were:

  • The first truck was in a reverse operation when WIFI coverage was lost.
  • The first truck stopped in response to the loss of WIFI coverage.
  • When WIFI signal returned, the first truck activated LiDAR (light detection and ranging), and presumably remained stationary because of LiDAR detection of the second truck.
  • For reasons not known at this time, the first truck then resumed the reverse operation at which point it struck the second truck.

Interestingly the company executive said that the crash [of the software controlled trucks] was not the result of any failure of the autonomous system.  So what did fail?

As software professionals we can learn much from real-world scenarios and actual events.  This event draws attention to the concept of “safe states” – what is the proper safe state given the intended use of the system and potential for harm when the system is operational or stationary.  Stopping the motion of the truck in response to WIFI loss seems obvious and reasonable to prevent a crash.  We would call this a risk control measure and likely a “safe state.”  However, should an autonomous system require operator intervention to re-start?  Or does the system have adequate sensor inputs to perform a re-start on its own?  The activation of the LiDAR seems to be part of a safe re-start protocol but one wonders if the LiDAR should have already been activated during a reverse operation (of course we are only reading an early news account).  Perhaps the software processing of LiDAR needs historical information to establish the presence of an obstacle (i.e., object is new to the field, rather than it existing in the original image) – just questions one begins to pose in the root cause analysis process.

What about testing?  Testing fault conditions, and plausible scenarios like loss of WIFI while in a reverse operation.  We are challenged to consider failure modes and we must do this activity as a team because one person cannot think of the many scenarios to consider.

It will be interesting to follow the investigation as this will reveal much about the fault analysis and software design process for this autonomous system.  Hopefully the details of the root cause discovery will be made public.

Another domain where autonomous operation is very critical is with outer space operations.  Ron Baerg wrote an interesting blog related to this a while back – read about it NASA Software Verification Article and Key Points.

About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: TBD

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.