Showing posts with label safety. Show all posts
Showing posts with label safety. Show all posts

Monday, June 17, 2024

Perspective on Waymo's Safety Progress

I am frequently asked what I think of Waymo's progress on safety.  Here are some thoughts on progress, mishaps, and whether we know they are acceptably safe. At current deployment rates it will take Waymo about 20 years with ZERO fatalities to show they are net as safe as average human driver fatality rates (including the old cars, impaired drivers, etc. in that comparison baseline). Their current statements that they are already saving lives are hype.

Safety at scale still remains the biggest question.  And even with reasonable growth rates that question will remain open for many years for robotaxi technology.  With Waymo currently in the lead, there are even more question marks for the other players with regard to safety.


Waymo has made impressive progress in scaling up operations. Some had previously criticized their ramp-up for being slower than other companies, but they are looking a lot smarter these days for having done that. 

We've seen some recent incidents (for example the utility pole crash) and an investigation from NHTSA. I hope those are not signs that they have started scaling up faster than they should due to funding pressure.

This piece in Forbes notes that Waymo is now doing more than 50,000 paid rides a week across three cities and plans to do more launches.  

Sounds like a lot!  But from a safety point of view not enough to really know how things will turn out.  

Waymo is disingenuously messaging that they are already saving lives, but the truth is nobody knows how that will turn out yet.  At this rate they will need perhaps 20 years without a single fatality (see math check below) to show they are no worse than an average US human driver. And that is under some wildly favorable assumptions (e.g., software updates never create a new defect -- which is not how things work in the real world.). So for practical purposes the bar is set at perfection right now. We'll have to see how things turn out.

It certainly feels like Waymo has been more aggressive lately, perhaps because they are feeling pressure to show progress to justify further investment with a good news story. The danger is if Alphabet puts too much pressure on Waymo to expand too fast that could generate a bad news story instead of a good one. What happened at Cruise provides a strong cautionary tale for the whole industry. Let's hope Waymo is not pushed into making the same mistakes.

Sunday, June 16, 2024

Truths & Myths About Automated Vehicle Safety -- Video Series

The past year has seen both peak hype and significant issues for the automated vehicle industry. In this talk we recap general trends and summarize the current situation for autonomous vehicles such as robotaxis, as well as conventional vehicles that have automated steering features. Many of the issues the industry faces are self-inflicted, stemming from a combination of inflated promises, attempts to scale immature technology too aggressively, and an overly narrow view of safety. Overall, the companies deploying the technology have failed to address legitimate concerns of a wide variety of stakeholders. There are a number of different aspects that still need to be addressed including: legislation, regulation, liability, insurance, driver skills, traffic enforcement, emergency services, vulnerable road users, engineering standards, business models, public messaging, investor pressure, cultural change, ethical/equity concerns, and local oversight. We concentrate on how all these pieces need to fit together to create sustainable automated vehicle technology approaches.

Truths & Myths About Automated Vehicle Safety

All Released Videos: YouTube Play List | Archive.org big video

Slide deck (acrobat)

Individual Videos:






Wednesday, June 5, 2024

Live Talk: Challenges in Autonomous Vehicle Safety Assessment

Challenges in Autonomous Vehicle Safety Assessment

Recorded live at a US DOT workshop on May 29, 2024.

Knowing whether an autonomous vehicle is safe enough to operate on public roads is an extremely difficult challenge. Assessment must include acknowledging that operating millions of miles does not come close to proving safety, that robot drivers will make mistakes -- often the same mistakes people make, fundamental incompatibilities between conventional safety engineering processes and the machine learning technology used by these systems, a pervasive lack of automotive safety standard adoption by the industry, and important considerations of safety that go far beyond net statistical risk.



Monday, June 3, 2024

Five views into the Cruise Robotaxi Pedestrian Dragging Mishap

 On October 2, 2023, a Cruise robotaxi dragged a woman 20 feet underneath the vehicle in San Francisco. The circumstances of the mishap and everything else are complex. But the robotaxi industry was profoundly shaken.


Here are four descriptions of the events and what might be learned from those events. Each is in a different style, intended for a different audience.

Additional content:
  • A video podcast where I walk through the mishap events with Junko Yoshida & Bolaji Ojo: https://youtu.be/OaF6IbYoVHQ
  • Cruise also maintains a safety page. A the time of this writing the big fonts are used to say "transparent about safety" and "continuous improvement". So far not a lot of detail about what has changed and what transparency will mean as they get back on the road.


Saturday, May 11, 2024

Video: Autonomous Vehicle Safety: More Than Net Risk (Live)

 Talk for EV Society of Canada, May 7, 2024 -- recorded as a live webinar

Safety will ultimately be the deciding factor for the viability of autonomous vehicle technology. Despite various pronouncements and hype over the years of the inevitability that they will (or won't) be safe, nobody actually knows how safety will turn out. Beyond that, practical safety will require going far beyond the usual metric of whether a robotaxi or robotruck is safer than an average human driver. This talk covers how robotaxi incidents over past year have illustrated the need to expand our view of safety, and which aspects of safety urgently need attention for the industry to succeed.






Thursday, April 25, 2024

Proposed new definitions for safety (Draft)

 The following definitions were proposed at the recent Dagstuhl workshop and will be incorporated in an upcoming Safecomp paper.

These below text is hereby placed in the public domain, with a specific objective of being incorporated into safety standards.

Friday, May 12, 2023

A Liability (Duty of Care) Approach for Automated Vehicles in Three Parts

I'm delighted that months of collaboration with co-author and law professor William Widen have resulted in a trio of papers that together provide a framework for resolving the vast majority of automated vehicle legal questions. Product liability will still be a thing, but that should be reserved for its more usual role, and not be the sole means of recourse for everyday Computer Driver road mishaps that will displace the everyday Human Driver road mishaps. A tort law approach based on assigning a duty of care (negligence) is a far better fit and will require far less disruption to existing legal and regulatory systems while providing a fair basis for compensation for anyone harmed by this novel technology.

The three parts are in three separate SSRN papers intended to be used as a set, although each paper is self-contained. Below are very simplified summaries to give an overview.

25 minute video with overview of the concepts:  https://youtu.be/i0ZGSEFHwE8 or https://archive.org/details/l-139-computer-driver

Podcast discussion and summary to warm up with:  https://ojoyoshidareport.com/podcast-lets-talk-about-av-liability/

These topics and many more based on what we have learned since these papers were written are discussed in my books:  How Safe Is Safe Enough (2022), and Embodied AI Safety (2025)

(1) Computer Driver: Define the concept of synthetic negligence for a Computer Driver. A Computer Driver should be held to the same standards of negligence for harm it causes as a Human Driver. The manufacturer should be the responsible party for any negligent behavior on the part of a Computer Driver because they are the ones who should be incentivized to produce safe automated driving systems. The behavioral standard is not an "average driver" but rather a "reasonable driver."

Winning the Imitation Game: Setting Safety Expectations for Automated Vehicles, 25 Minn. J.L. Sci. & Tech. 113 (2023)  https://scholarship.law.umn.edu/mjlst/vol25/iss1/5/

Also see this shorter summary paper of the same material from WAISE 2023 for a more general and technical audience: Koopman, P. & Widen, W., "A Reasonable Driver Standard for Automated Vehicle Safety," Safecomp WAISE workshop, Sept. 2023

Also see this Jurist piece on how this might work with criminal law, especially for a Level 3 vehicle in which the driver has been told it is OK not to watch the road: Widen, W. & Koopman, P., Level 3 Automated Vehicles and Criminal Law, Jurist, Aug. 2023

Video about why using product liability for computer drivers is likely to break the court system: https://www.youtube.com/watch?v=WhtxTDRvTOE

(2) Liability Transfer Rules: Define the rules of transfer of liability between the Human Driver and the Computer Driver depending on the operational mode per the summary figure below. Shared responsibility (Human Driver supervises safety of Computer Driver) requires special attention to avoid the person being used as a moral crumple zone. Two key rules come into play regarding the need for effective driver monitoring and the obligation of a person to intervene when it is reasonable that they would know to do so.

The Awkward Middle for Automated Vehicles: Liability Attribution Rules When Humans and Computers Share Driving Responsibilities
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4444854
https://www.americanbar.org/groups/science_technology/publications/jurimetrics/2024/jurimetrics-fall-2023/

(3) Definitions and Statute Outline: Create a set of definitions and statute-oriented rules to make the first two papers more actionable. We envision this as a robust starting point for state legislatures that find this approach useful.

Liability Rules for Automated Vehicles: Definitions & Detail
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4444848
https://scholar.smu.edu/scitech/vol27/iss1/5/





Tuesday, March 21, 2023

A Liability-Based Regulatory Framework for Vehicle Automation Technology

State liability laws might be the way out of the automated vehicle regulatory dilemma. From phantom braking to reckless public road testing to permitting using human drivers as moral crumple zones, vehicle automation regulation is a hot mess. States are busy creating absurd laws that assign safety responsibility to a non-legal-person computer, while the best the feds can do under the circumstances is play recall whack-a-mole with unsafe features that are deployed faster than they can investigate.

What has become clear is that attempting to regulate the technology directly is not working out. In the long term it will have to be done, but we will likely need to see fundamental changes at US DOT before we see viable regulatory approaches to automated vehicles. (As a start, they need to abandon the use of SAE Levels for regulatory purposes.) That process will take years, and if history is any guide, one or more horrific tragedies before things settle out. Meanwhile, as companies aggressively exploit the "Level 2 loophole" it is the wild west on public roads. Various companies are taking safety with different levels of seriousness, but there is a dramatic lack of transparency and accountability across the industry that will only get worse with time.


As a short- to mid-term approach we should revisit how liability laws work at the state level to buy time to let the technology mature while avoiding needless harm to constituents. There are three fundamental things that have changed that make the current tort system unworkable in practice for automated vehicle technology:

#1: Machine learning-based technology is inherently unsuitable to traditional software safety analysis. The current legal system which puts the burden of showing technology is defective on victims is simply not viable when even the engineers who designed a system can't necessarily explain why the computer driver did what it did.

#2: Asymmetric access to information makes it easy for car companies to know what happened in a crash (or even if automated driving was activated), but it is very difficult for victims to access, much less interpret such information.

#3: The litigation cost of pursuing a claim against software with non-deterministic defects that require source code analysis is huge, depriving all but the largest cases from having an effective ability to prove a product defect claim, if one is justified.


In response to these realities, a (rebuttable) presumption of liability and burden of proof should be shifted to manufacturers in situations for which it is unreasonable to expect a civilian human driver to be able to ensure safety. The attached summary sketches an approach, with more detail to come.


Read the one-pager policy summary here: https://archive.org/details/2023-03-av-liability-one-pager-published-v-1-00



Sunday, January 8, 2023

The case for AVs being 10 to 100 times safer than human drivers

There is a case to be made that at-scale AV deployments should be at least ten times safer than human drivers, and perhaps even safer than that. The rationale for this large margin is leaving room for the effects of uncertainty via incorporating a safety factor of some sort.[1]

Busy intersection at night

Consider all the variables and uncertainty discussed in this chapter. We have seen significant variability in fatality and injury rates for baseline human drivers depending on geographic area, road type, vehicle type, road user types, driver experience, and even passenger age. All those statistics can change year by year as well.

Additionally, even if one were to create a precise model for acceptable risk for a particular AV’s operational profile within its ODD, there are additional factors that might require an increase:

·        Human biases to both want an AV safer than their own driving and to over-estimate their own driving ability as discussed in a previous section. In short, drivers want an AV driving their vehicle to better than they think they are rather than better than they actually are.

·        Risk of brand tarnish from AV crashes which are treated as more newsworthy than human-driven vehicle crashes of comparable severity. Like it or not, AV crashes are going to be covered by news outlets as a consequence of the same media exposure that created interest in and funding for AV developers. Even if AVs are exactly as safe as human drivers in every respect, each highly publicized crash will call AV safety into question and degrade public trust in the technology.

·        Risk of liability exposure to the degree that AV crashes are treated as being caused by product defects rather than human driver error. For better or worse (mostly for worse), “driver error” is attributed to a great many traffic fatalities rather than equipment failure or unsafe infrastructure design. Insurance tends to cover the costs. Even if a judicial system is invoked for drunk driving or the like, the consequences tend to be limited to the participants of a single mishap, and the limits of personal insurance coverage limit the practical size of monetary awards in many cases. However, the stakes might be much higher for an AV if it is determined that the AV is systematically prone to crashes in certain conditions or is overall less safe than a human driver. A product defect legal action could affect an entire fleet of AVs and expose a deep-pockets operator or manufacturer to having to pay a large sum. Being seen to be dramatically safer than human drivers could help both mitigate this risk and provide a better argument for responsible AV developer behavior.

·         The risk of not knowing how safe the vehicle is. The reality is that it will be challenging to predict how safe an AV is when it is deployed. What if the safety expectation is too optimistic? Human-driven vehicle fatalities in particular are so rare that it is not practicable to get enough road experience to validate fatality rates before deployment. Simulation and other measures can be used to estimate safety but will not provide certainty. The next chapter talks about this in more detail.

Taken together, there is an argument to be made that AVs should be safer than human drivers by about a factor of 10 (being a nice round order of magnitude number) to leave engineering margin for the above considerations. A similar argument could be made for this margin to be an even higher factor of 100, especially due to the likelihood of a high degree of uncertainty regarding safety prediction accuracy while the technology is still maturing.

The factor of 100 is not to say that the AV must be guaranteed to be 100 times safer. Rather, it means that the AV design team should do their best to build an AV that is expected to be 100 times safer plus or minus some significant uncertainty. The cumulative effect of uncertainties in safety prediction, inevitable fluctuations in operational exposure to risky driving conditions, and so on might easily cost a factor of 10 in safety.[2] That will in turn reduce achieved safety to “only” a factor of 10 better than a baseline human driver. That second factor of 10[3] is intended to help deal with the human aspect of expectations being not just a little better than the safety of human drivers, but a lot better, the risk of getting unlucky with an early first crash, and so on.

Waiting to deploy until vehicles are thought to be 100 times safer than humans is not a message investors and design teams are likely to want to hear. But it is, however, a conservative way to think about safety that leaves room for the messiness of real-world engineering to deploy AVs. Any AV deployed will have a safety factor over (or under) Positive Risk Balance (PRB).

The question is whether the design team will manage their PRB safety factor proactively. Or not.


[1] Safety factors and derating are ubiquitous in non-software engineering. It is common to see safety factors of 2 for well understood areas of engineering, but values can vary. A long-term challenge for software safety is understanding how to make software twice as “strong” for some useful meaning of the word “strong.” Over-simplifying, with mechanical structures, doubling the amount of steel should make it support twice the load. But with software, adding twice the number of lines of code just doubles the number of defects, potentially making the system less reliable instead of more reliable unless special techniques are applied very carefully. And even then, predicted improvement can be controversial.
See:
https://en.wikipedia.org/wiki/Factor_of_safety    
https://en.wikipedia.org/wiki/Derating          
and
https://en.wikipedia.org/wiki/N-version_programming

[2] For better or worse – but given the optimism ingrained in most engineers, probably not for better.

[3] Some good news here – by the time you have a safety factor of 10 or more, nuances such as driver age and geofence zip codes start being small compared to the safety factor. If someone says they have a safety factor of 10, it is OK not to sweat the small stuff.

Sunday, November 13, 2022

Book: How Safe is Safe Enough? Measuring and Predicting Autonomous Vehicle Safety

How Safe Is Safe Enough for Autonomous Vehicles? 
The Book


The most pressing question regarding autonomous vehicles is: will they be safe enough? The usual metric of "at least as safe as a human driver" is more complex than it might seem. Which human driver, under what conditions? And are fewer total fatalities OK even if it means more pedestrians die? Who gets to decide what safe enough really means when billions of dollars are on the line? And how will anyone really know the outcome will be as safe as it needs to be when the technology initially deploys without a safety driver?

This book is written by an internationally known expert with more than 25 years of experience in self-driving car safety. It covers terminology, autonomous vehicle (AV) safety challenges, risk acceptance frameworks, what people mean by "safe," setting an acceptable safety goal, measuring safety, safety cases, safety performance indicators, deciding when to deploy, and ethical AV deployment. The emphasis is not on how to build machine learning based systems, but rather on how to measure whether the result will be acceptably safe for real-world deployment. Written for engineers, policy stakeholders, and technology enthusiasts, this book tells you how to figure out what "safe enough" really means, and provides a framework for knowing that an autonomous vehicle is ready to deploy safely.

Currently available for purchase from Amazon, with international distribution via their print-on-demand network. (See country-specific distribution list below.)

See bottom of this post for e-book information, from sources other than Amazon, as well as other distributors for the printed book.

Media coverage and bonus content:

Chapters:

  1. Introduction
  2. Terminology and challenges
  3. Risk Acceptance Frameworks
  4. What people mean by "safe"
  5. Setting an acceptable safety goal
  6. Measuring safety
  7. Safety cases
  8. Applying SPIs in practice
  9. Deciding when to deploy
  10. Ethical AV deployment
  11. Conclusions
368 pages.
635 footnotes.
On-line clickable link list for the footnotes here: https://users.ece.cmu.edu/~koopman/SafeEnough/

Koopman, P., How Safe Is Safe Enough? Measuring and Predicting Autonomous Vehicle Safety, September 2022.
ISBN: 9798846251243 Trade Paperback
ISBN: 9798848273397 Hardcover   (available only in marketplaces supported by Amazon)

Also see my other recent book: The UL 4600 Guidebook

For those asking about distribution -- it is served by the Amazon publishing network. Expanded distribution is selected, so other distributors might pick it up in 6-8 weeks to serve additional countries (e.g., India) or non-Amazon booksellers, especially in US and UK. How that goes is beyond my control, but in principle a bookstore anywhere should be able to order it by about mid-November 2022. Alternately, you can order it direct from Amazon in the closest one of these countries for international delivery: US, UK, DE, FR, ES, IT, NL, PL, SE, JP, CA, AU.


You can also buy it from some Amazon country web sites via distributors. A notable example is:

Your local bookstore should also be able to order it through their US or UK distributor.

E-book available from distributors as they pick it up over time: 

Friday, November 11, 2022

Shiny vs. Critical Software

Coverage of Lucid software problems (cars bricked; wrong direction of travel) might be written off to growing pains for a new company. But I think this is just yet another story about a deeper industry-wide problem. (The article notes other more established companies have problems too.) This weeks story: https://www.businessinsider.com/electric-vehicle-startup-lucid-struggling-production-reveal-insiders-owners-2022-11

abstract oil and water photo
Shiny and critical software and developer skills
mix as oil and water.

All software is not created equal. For cars I am seeing three types:

  • Shiny Infotainment and other software that provides shiny customer features might be less reliable and still sell cars. There are limits to tolerance for problems, but more forgiveness if the features are shiny enough. Apparently "coding" is enough to build valuable companies, as is slapping "beta" on the label as a pretext for further reducing quality expectations for a product sold retail. Maximizing lines of code per day has made lots of founders rich.
  • Critical deeply embedded control firmware has to be rock solid or you're going to get serious malfunctions. "Coding" without software engineering invariably leads to deeper problems, some of which feature in harm to people. Maximizing lines of code per day at the cost of impaired quality and skipped safety engineering practices has made customers dead.
  • "AI" software based on machine learning, which is being asked to do safety critical work but often without using the foundational skills and processes of the critical software experts.
(You can argue that cloud services are yet another type, but in my experience that divides up into shiny services software and critical infrastructure support software.)

Journalists should differentiate when reporting. If you must call a shiny software problem a "glitch" so be it. But critical software failures are due to *defects* reflective of an important lapse in engineering, not glitches due to being in a hurry to deploy the new hotness.


Companies get in trouble, sometimes very seriously, via several mechanisms:

  • Treating all software the same. Software needs to be thought of as either shiny or critical. They are as oil and water. (Maybe this could be different, but in the world we live in this is the only pragmatic approach.)
  • Treating "software staff" as fungible. Developers for shiny vs. critical software are deeply different. The skill sets, mindset, and work flows are quite different. So is the training required. While some can do both, few can do both well. (This is not about being "smart." It is about being different.) To a first approximation, anyone talking about "coding" is in the shiny software business, especially if they indicate that knowing how to code is equivalent to being a software engineer.
  • Mixed components and features. We see an endless parade of NHTSA recalls for malfunctioning backup cameras. The usual story is that a critical function (backup camera; by definition safety critical per FMVSS) is hosted on a platform optimized for shiny (infotainment display and OS). The only surprise is that car companies persist in thinking that plan will work out well.
  • We're still sorting out how to fit AI software into the mix. A lot of that will end up forcing a choice between the shiny bin or the critical bin, with a human/machine interface suitable to the choice. Making AI software shiny can be a reasonable choice -- but only if we don't pretend shiny AI it is fit for purpose as critical software. (Critical machine learning might be done, but there is a significant gap to overcome in skills, work flows, etc. that the industry is only beginning to wrestle with.)
Cost is pushing companies to mix shiny with critical more than they should. That pressure will continue to generate news stories. Instead of just pretending they mix well, companies should be rethinking their software architectures to maintain separation of technical aspects, staff skills, and cultural aspects in a way that is harmonious. Pretending these differences don't exist will continue to lead to bad outcomes.


Saturday, November 5, 2022

Why Car-to-Bike Safety Communications Won't Solve Safety

This nicely thought out article by David Zipper breaks down the problems with C-V2X: in this case using direct wireless messaging connectivity between cars and bikes to warn of potential collisions. https://www.fastcompany.com/90801870/audis-new-technology-is-designed-to-keep-bikers-safe-it-wont


Might the technology help? Sure it might help some, but it will just as surely not be a complete solution. In a complex world it is possible the net outcome will be worse than other approaches (not because of the technology per se, but because of the complexities).

While it is great to see innovation to improve safety we need to be mindful of these pitfalls:

  • Equity issues: Not everyone can afford or will want to burden themselves with a C-V2X transponder. (Not everyone has a high-end cell phone, and not everyone wants one even if they can afford it.) This burdens other road users rather than owners of expensive cars.
  • Potential for risk homeostasis: If the transponders get reliable, will that teach drivers not to look for vulnerable road users if they don't hear a transponder warning?
  • Victim blaming: What if someone says a kid walking to school deserved to die because they should have known to not let the battery run out on their cell phone/transponder? Or that parents should have bought their 7-year-old a smart phone to keep them safe.
  • Allocation of societal resources: There is only so much attention and funding available. Arguably it would be a better net outcome to make roads inherently safer rather than spend those resources on C-V2X.
In short, this sounds like a high-tech version of "pedestrians should wear bright colors so they don't get hit by drivers who are not paying close enough attention." Which often shows up as an "education" message that displaces solving deeper systemic safety issues. (Might wearing a bright yellow rain coat help? Sure, that's what I do. But proposing that to deflect attention from deeper systemic issues is a problem.)

It is important to avoid running afoul of evergreen research advice by Prof. Mary Shaw, which I'll paraphrase as: if your idea only works if everyone in the whole industry adopts it, then you need a different idea.

Wednesday, November 2, 2022

Video: How Safe Is Safe Enough for Autonomous Vehicles

Video lecture summarizing main topics covered in my book:

Abstract:

The most pressing question regarding autonomous vehicles is: will they be safe enough? The usual metric of "at least as safe as a human driver" is more complex than it might seem. Which human driver, under what conditions? And are fewer total fatalities OK even if it means more pedestrians die? Who gets to decide what safe enough really means when billions of dollars are on the line? And how will anyone really know the outcome will be as safe as it needs to be when the technology initially deploys without a safety driver?

In this talk I outline some key factors involved in measuring and predicting autonomous vehicle (AV) safety. This includes what people mean by "safe," setting an acceptable safety goal, measuring & predicting safety, deciding when to deploy, and ethical AV deployment. A framework for making a responsible deployment decision needs to include not just risk, but also deal with inevitable uncertainty, stakeholder inclusion, and an ethical governance model. The talk is a high level overview of my recently published book: How Safe Is Safe Enough? Measuring and Predicting Autonomous Vehicle Safety.


Friday, October 28, 2022

Talk: Autonomous Vehicles Standards & Open Challenges

 Here is my talk from the October 2022 ISO 26262/SOTIF conference.

Assuming you follow the relevant standards (ISO 26262, ISO 21448, ANSI/UL 4600) in practice teams are finding the following topics difficult:

  • Fail operational architecture
  • Building an accurate, predictive world model
  • Safety beyond the driving task (system safety, traffic system interactions)
  • Determining how safe is safe enough in an equitable way

Link to slides

(Slides only at this time)


Wednesday, October 5, 2022

Gatik Announcement -- Is it real safety? Or just AV safety theater?

Gatik just announced it has completed an extensive third-party safety review of its system as part of deploying fully driverless commercial operations in Canada. But the announcement raises many questions as to how much it really assures safety.

Gatik truck in Walmart livery

The autonomous vehicle safety arena is full of misinformation, disinformation, safety theater -- and players earnestly trying to do the right thing. Companies routinely employ ambiguous language, half-truths, and outright propaganda to deploy safety theater. But some companies use unambiguous statements of conformity to safety standards to show they are really doing safety. Which bucket does Gatik fall into?  Let's take a look at the signs from their press release.

Gatik claims that their third-party review covers safety and security. This was done with "a team of third-party experts." No mention of who these experts might have been, nor their qualifications. The gold standard is an accredited third party assessor such as TUV SUD (there are quite a few others as well).

For security they mention reasonable standards including SAE J3061, ISO/SAE 21434, and UNECE R155. It would be better to see them state "conformance" with these standards instead of just saying they were "covered" by the review. (Maybe they failed to conform as a result -- who knows?)  But at least this statement shows that the experts knew enough to look at these standards. So maybe OK, but hard to say.

For safety the only standard mentioned is SAE J3016 -- which is not a safety standard. In fact, only meeting the minimum requirements for the SAE Levels is not safe in practice (e.g., driver monitoring is not required, nor is any notification to the human driver that takeover is required after some types of failures). The safety analysis, such as it is, is clearly patterned after J3016, mentioning ODD and OEDR. 

There is a statement that "where they apply, the vehicle and ADS comply with safety relevant standards and best practices, such as those developed by SAE International and the International Organization for Standardization (ISO)."  No mention of ANSI/UL 4600, which was included by NHTSA as a highly relevant standard. Also, what do they mean by "where they apply" exactly? Other companies have gone on the record saying none of the AV-specific safety standards apply to their AV. So maybe Gatik means they aren't following safety standards at all.  Not even SAE J3018 for testing safety.

What I get out of reading the announcement is they hired some unidentified experts of unknown reputation, who likely had better credentials in security than safety. (Any bona fide safety experts would never pronounce that a system was "safe" based solely on testing results as indicated in the press release.) They took a look and say "sure, looks like it works." That's about it. (If there is more, we'd expect them to brag about it with some specificity, right?)  

If there is one thing I've learned in this industry is that companies will claim the strongest thing they think they can. A weak claim means a weak result. This is a very weak safety claim.

While I appreciate that Gatik publicly messages “Safety is at the heart of everything we do," this Gatik press release fairly screams safety theater. If they want us to believe their message is compelling, they need to do better. Some examples of ways they could provide a better statement of safety:

  • What exactly do you mean by "acceptable" safety?
  • Name the safety standards they "considered."   Were they ISO 26262, ISO 21448, ANSI/UL 4600, and SAE J3018 (all safety standards). These are the types of standards US DOT has already proposed for regulatory purposes, so they ought to be top of mind for any AV safety assessment.
  • Name the safety standards they actually conform to beyond "considering" and potentially not implementing.
  • Is there an Safety Management System (SMS)?  Didn't see it mentioned. This is safety 101, so you'd think they'd at least mention that.
  • Say who the external experts were so we can judge their reputation. Were they an accredited assessment organization? Were any of them actually qualified to opine on safety rather than security?
  • Explain how it is that a "rigorous suite of system as well as component level tests" can show safety. Because everyone would really like to know how you can do that for an AV. The safety standards are much more about engineering processes and safety engineering, with validation just being the tail of the safety dog. Certainly nothing I've seen indicates that validation-only safety assessment is possible for an AV.
Their announcement video talks about delivering against a value proposition. The only reason it gives for believing they are safe is ... saying they deliver safety and "manage risk."  That's it.  Gatik has not issued a VSSA, so no info to be had there.

Gatik -- your turn.  If you have a response I'll be happy to post it here for all to see:

... no response yet ...