Level 2 Automated Vehicle Safety
What does it take to create safe supervised driving automation?
By Phil Koopman
A Level 2 vehicle automation feature lets a human driver supervise a driving automation system that controls both speed and steering. The key to Level 2 automation safety is making sure the human supervisor is able to effectively intervene when they need to. This is easier said than done.
There can be a strong incentive for manufacturers to confuse the issue of whether a vehicle supports a fully automated (Level 4) driverless system, rather than Level 2 supervised automation. That confusion causes safety problems when drivers fail to appreciate the importance of maintaining continuous attention to the driving supervision task if they believe the automation in their vehicle is more capable than it really is.
What do we mean by Level 2 and Level 2+?
So-called SAE Level 2 driving automation features have the ability to automatically control both speed and steering on a sustained basis.1 This is often implemented as a combination of two features: adaptive cruise control (maintaining speed & keeping distance to a leading vehicle), and lane centering (following lane markings to keep in the center of a lane). If your car can follow a lane around a curve and adjust its speed to follow a leading vehicle at the same time, you have a Level 2 automation feature. This feature is common in high-end newer cars.
A key aspect of Level 2 automation is that a human supervisor2 is required to keep track of what is happening on the roadway, and intervene when necessary to assure safe driving. The automation is not required to warn the supervisor of a problem — the supervisor is supposed to notice a problem and jump in to prevent a crash. In practice, the supervisor is often presumed to be responsible for any crash that might occur, even if automation is doing the steering and speed control.
A Level 2 automation feature might have additional capabilities, such as making turns at intersections, stopping for red traffic lights, and so on. While these capabilities do not affect the automation feature’s Level 2 status, such advanced features might informally be said to provide “Level 2+” capabilities,3 indicating that they automate many more driving capabilities than a baseline Level 2 behavior of following a marked travel lane.
The distinguishing characteristic of a Level 2 system is that the manufacturer says that a human supervisor is responsible for safety. An advanced Level 2+ system might be indistinguishable from a fully automated robotaxi (Level 4) on a practical basis, but still be Level 2 for regulatory purposes because the manufacturer says that a human supervisor is still responsible for driving safety.4
Simply saying that the human supervisor is responsible for safety does not automatically guarantee safe outcomes. There are limits to human performance that must be respected if we want to have safe Level 2 automation.
A person’s Perception-Response Time (PRT) is the time it takes between when a situation in the real world can be perceived (often visually while driving) and the start of a response action. A best-case situation has a PRT of a fraction of a second — but not zero. PRT varies significantly across different people, demographics, and operational environments. More complex situations that require thoughtful responses rather than reflexive actions can easily have a PRT in the tens of seconds.
Humans have limits to how fast they can sense, process, and react to events in the real world. Asking a person to react with their brains and muscles at near-instantaneous speeds is unreasonable. Any need to intervene to ensure safety must leave enough room for the driver’s PRT.
A safe Level 2 automation feature depends on a human supervisor, but must respect the limits to human performance.
The ironies of automation
We have known since about 1950 that even trained operators have trouble paying attention to boring tasks.5 This includes supervising automated driving. After a relatively short period of diligent supervision of well-behaved automation, human supervisors will be lulled into automation complacency, in which they over-trust the automation and are slower to react to problems that arise.
Human supervisors generally struggle to supervise anything automated. And, according to the principles of the Ironies of Automation,6 the better the automation is, the worse people are at supervising it. Fairly quickly, people have trouble noticing that intervention to mitigate an automation malfunction is needed, because they have come to expect the automation will work properly. People’s PRT will slow down when they are not mentally prepared to make a quick intervention. And people’s skills might well be degraded for making an accurate, safe intervention because they have become out of practice at driving due to substantial reliance on automation.
As a concrete, but hypothetical example, consider a Level 2+ driving feature that is advertised to stop at stop signs. If a driving feature only stops at half the stop signs, human supervisors will probably not trust it, and be ready to stop at every stop sign (perhaps even turning off the feature as being too unreliable). But if the driving feature successfully stops at 999 stop signs in a row, it is difficult to believe any human supervisor will be ready to hit the brakes quickly when their vehicle unexpectedly tries to fly through the thousandth stop sign. That human supervisor will long since have stopped paying attention to stop signs as a result of automation complacency.
Asking human supervisors to be able to instantly react to infrequent misbehaviors of an automated driving feature is, in effect, asking those people to be superhuman. It is unreasonable to ask supervisors to monitor highly-capable Level 2 automation unless there is a solid basis for ensuring they are sufficiently attentive to situations in which they need to intervene, and have the skills necessary to react quickly enough to mitigate risks that arise when the automation needs human help. Exhorting drivers to pay attention will not be enough.
A safe Level 2 system must be purposefully designed to be resilient in the face of the ironies of automation.
Driver monitoring
An automated driving session can go from being fine to a fatal crash in a matter of a handful or two of seconds. But supervisors who have mentally tuned out to the driving environment can easily take tens of seconds to regain situational awareness. That reaction time disparity motivates a need to ensure that supervisors are paying adequate attention to intervene when needed.
One way to support safe Level 2 operation is to provide a robust Driver Monitoring System (DMS) to ensure that the supervisor is providing the attention required to safety operate the automated driving feature. Capable DMS technology includes camera-based tracking of driver’s eye movements, detecting potential distractions such as mobile phone use, and monitoring other relevant behaviors. The DMS goal in a Level 2 system is ensuring that the supervisor is paying adequate attention to the road situation and is mentally alert enough to intervene when needed.
Due to the inevitability of automation complacency with more advanced Level 2+ systems, the DMS ultimately needs to progress to not just monitoring, but rather become an attention management system. The automation system should actively help the human supervisor remain attentive, and prohibit use of the driving automation features if that human supervisor is not paying sufficient attention to ensure safety.
It is all too easy, and common, to simply say that the human supervisor should know they are responsible for safety, and therefore should pay attention. In that framing, any mishap is said to be due to insufficient supervisor attention, and therefore the supervisor is at fault for crashes. However, unconditionally allocating blame to a supervisor for failing to pay attention flies in the face of what we know about automation complacency.
Denying a fundamental characteristic of human nature in the form of automation complacency is not a plan for safety. Blaming supervisors for a lack of sufficient attention when using advanced Level 2 systems without also taking measures to support attention management will not result in good safety outcomes.
When a Level 2 automation crash is attributed to supervisor inattention, we should be asking two questions:
Did the DMS detect the supervisor was not paying sufficient attention given the Level 2 feature’s concept of operations? If not, that amounts to a shortcoming with the DMS, which has contributed to the occurrence of the crash.
Does a DMS alert cause the automation to execute a risk reduction response? The supervisor should be alerted if the DMS detects insufficient attention. Additionally, the driving automation feature should transition to a safer motion profile until the supervisor can regain attention, and if the supervisor does not respond adequately, bring the vehicle to a contextually safe stop.7
A Level 2 feature which has poor DMS effectiveness can be expected to experience safety problems.
While a Level 2 feature is not required to ensure safety with an inattentive supervisor, it should be designed to support the supervisor with a robust DMS, and make at least best effort responses to improve safety when the supervisor is not able to pay sufficient attention.
A safe Level 2 system needs effective supervisor monitoring.
ODD enforcement
Level 2 driving automation features have a so-called Operational Design Domain (ODD), which is the operational environment they are designed to work in. For example, some Level 2 features might be designed only to work in daylight on well-marked limited-access highways, while others might be designed to work on a wider variety of roads and weather conditions.
Every Level 2 driving automation feature should be designed to enforce the limits of its own ODD. If the vehicle is outside the ODD (on the wrong type of road, or in the wrong type of weather), the automation should refuse to engage, or should gracefully disengage in the case of departing the ODD while driving.
Numerous severe crashes have occurred that were ultimately attributed to a human supervisor leaving a Level 2 feature engaged outside of the ODD. The reasons for this might vary. A human supervisor might not fully understand the ODD. Or human nature might lead to assuming that a driving automation feature that is said to be extremely safe would accurately enforce its ODD. Or a human supervisor might think that the ODD description is unnecessarily conservative due to success at operating outside the ODD in the past.
Determining whether the actual driving environment meets the ODD constraints might be impractical for a human supervisor in marginal conditions. For example, how faded can road marking paint be before it is no longer good enough for an driving automation camera to track? And how is a human supervisor supposed to know exactly when that threshold has been crossed if the computer does not tell them?
Regardless of the reason, blaming a human supervisor for not rigorously enforcing an ODD is a poor way to achieve operational safety.
ODDs should be enforced automatically.
Setting expectations
One of the tricky aspects to ensuring Level 2 automation safety is setting human supervisor expectations for potential failures. Supervisors need to be mentally prepared to detect possible problems and react to them in time to mitigate the risk of a mishap. But they cannot do that without a robust mental model of what constitutes “normal” behavior, and routine practicing of responding to expected misbehaviors for their automation feature.
We might hope that new supervisors will use whatever training they have received when they purchase a vehicle to set expectations.8 As a practical matter, supervisors will tend to be attentive at first when using a new feature, and then settle into comfort (or complacency) based on what the operational behavior of the feature itself teaches them. Unusual behaviors will take longer to respond to, because supervisors will lose proficiency in responding to them.
We should expect that drivers will be more attentive to features that seem to work poorly, and become complacent with capabilities that seem to work well. If a Level 2 feature detects red traffic lights the first 20 or 50 or 100 times in a row, they will learn that it is reliable at detecting traffic lights and become complacent on that topic. If the feature gets confused at stops signs, they will learn to pay attention to stop signs and be ready to intervene. If lane keeping struggles with exit ramp splits, they will learn that. And so on.
The catch is that people’s Perception-Response Time (PRT) can be expected to degrade with complacency. When a feature that a supervisor has learned is reliable fails, we should expect them to take longer to respond. It does not matter if the user manual (if they have even read it) has big font, bold face warnings about the risk from a failure of a particular feature. If supervisors have become accustomed to that feature working, they will struggle to respond quickly and accurately to intervene when it fails. This issue is a direct consequence of the Ironies of Automation.
We should expect supervisors to respond with poor speed and reduced accuracy to failures of capabilities they have come to expect to be reliable.
Limitations vs. misbehavior
An important consideration when asking a human supervisor to intervene when driving automation fails is whether that supervisor is mentally prepared to intervene quickly and accurately. If an automation failure is something that supervisor expects and has practiced reacting to, and the required reaction is comfortably within cognitive and physiologic limits, then we might reasonably expect good safety outcomes. But if the failure is surprising, or requires superhuman reflexes to mitigate, we should expect to see mishaps.
Automation failures can be characterized as limitations and misbehaviors. Limitations are predictable, evident boundaries of system operation that the human operator understands and can react to comfortably. If a Level 2 feature does not even attempt to detect traffic lights, the driver can be expected to realize that is a limitation and manage traffic light state detection as a supervisor.
However, some limitations are difficult for a supervisor to understand, or enforce even if the concept of the limitation is understood. A limitation that a perception system can handle vertical traffic light stacks but not horizontal traffic light stacks might be difficult for an ordinary driver to appreciate. Moreover, vague statements of limitations such as “might not detect all traffic lights” are not readily actionable by a supervisor because they do not explain what exactly to look for.
Even a clearly stated limitation might be impractical to enforce if people are not equipped to make the relevant measurements with precision. Consider a feature that requires road markings to be visible, or does not work in fog. How scuffed or worn might road markings be before they are no longer “visible”? How dense does a tenuous haze or cloud wisp in a mountain pass need to be before it becomes “fog”? Limitations are seldom starkly defined, and it will be difficult for a human supervisor to know where the dividing line is.
Limitations that are out of the system design scope need to be clear-cut and readily appreciated by a non-technical human supervisor. Limitations that are a matter of degree should be enforced by the automation rather than by the supervisor. A car that automatically stops at most (but not quite all) traffic lights is arguably more dangerous than one that stops at no traffic lights automatically, because the supervisor will not be confused about the nature of the limitation if traffic lights are simply out of scope for the system. A car that alerts the supervisor when fog is detected and initiates an orderly automation disengagement process is better than one that starts driving dangerously if the supervisor does not figure out that the boundary between a heavy haze and a light fog has been crossed.
A related issue is that of misbehaviors that we cannot reasonably expect an ordinary human supervisor to mitigate. Examples of level 2 misbehaviors are sudden swerving, sudden dramatic acceleration, and unexpected braking that occurs faster than an ordinary driver can compensate for. At some point, even a professional driver will struggle to compensate for sudden, dramatic vehicle misbehaviors. Those are not limitations — they are dangerous design defects. Supervisors should not be blamed for lacking superhuman abilities to react to surprise, dangerous misbehaviors.
Safe Level 2 features should have clear-cut, readily appreciated limitations, using notifications to ensure the supervisor is aware a limitation is being encountered. Misbehaviors and limitations beyond the reasonable ability of an ordinary supervisor to mitigate should be considered design defects.
Misuse and abuse
It is inevitable that some people will attempt to misuse or abuse Level 2 automation features, such as by fooling driver monitoring systems.
A perennial problem with steering wheel torque-based DMS approaches was supervisors using purpose-made devices or found objects to fool those sensors into detecting hands-on-wheel when the driver was not paying attention to driving at all.9 Dodges for camera-based systems have included wearing sunglasses to block gaze tracking, and holding cell phones above the steering wheel to fool gaze-tracking into thinking the driver is watching the road.
A more dramatic problem with misuse is the apparent trend of purchasing a Level 2+ system with the planned intent to use it to support drunk driving.10 It seems that some people using a Level 2+ automation system to drive themselves home after a night of drinking might genuinely believe that is a safe(r) transportation alternative. However, supervising while impaired is clearly an unsafe abuse of Level 2 technology. DMS capabilities should be designed to detect and disable automation features when the supervisor is impaired.
While it is tempting to blame people for misuse and abuse of automation features, that blame will not stop the next crash from the next incident of abuse. Manufacturers should make efforts to mitigate reasonably foreseeable risks of misuse and abuse, especially when such trends become widespread.
Scolding drivers and “education” campaigns will have limited effect when there is an incentive to misuse automation technology. Worse is when Level 2/2+ automation technology is sold on the basis of freeing the driver from the driving task, with messaging that the computer is better than a human driver — while still blaming the supervisor for crashes due to not paying enough attention.
It is impossible to prevent all forms of sophisticated misuse and abuse. But that should not be an excuse for not making a reasonable effort to prevent avoidable crashes.
Safe Level 2 features should be designed to mitigate risks from reasonably foreseeable misuse and abuse.
Robotaxis and the Level 2 Loophole
If it looks like a duck, swims like a duck, and quacks like a duck, it should be regulated as a duck.11
Using a purported Level 2 status to evade autonomous vehicle regulations has become a significant policy issue. As a practical matter, it is difficult to distinguish between a Level 4 test vehicle with a safety driver and a Level 2 vehicle with supervisor. Both cars have a person watching what the automation does. Both cars have a person who is supposed to intervene when something goes wrong. The root cause of the confusion is that the difference between Level 2 and Level 4 is essentially in the mind of the manufacturer12 rather than a readily observable property of the technology.
Numerous state laws regulate autonomous vehicle technology based on whether it is designated as SAE Level 3, 4, or 5. Level 2 vehicles are unregulated by such laws. There is a tremendous incentive for a company seeking to evade regulations to self-proclaim that their robotaxi technology is unregulated Level 2 because there is a driver involved.13 They might even message that the driver is not actually doing anything other than being present for legal purposes. What they might not say out loud is that those legal purposes are maintaining a Level 2 status that enables the manufacturer to blame the human in the vehicle for a crash.
Things get even more interesting if the supervisor is remote rather than inside the vehicle. A robotaxi vehicle with no driving controls might have a remote supervisor watching it operate, and that might still be said to be a Level 2 feature because of remote human supervisor oversight. That supervisor might be watching ten vehicles at the same time, but the manufacturer might still evade regulation by arguing it qualifies as a Level 2 feature due to remote continuous human remote supervision.
The ability to evade autonomous vehicle regulation by self-proclaiming a Level 2 feature status has come to be known as the Level 2 Loophole. Any car company can evade autonomous vehicle regulation by somehow involving a person in vehicle operations and claiming that makes their system Level 2, and thus exempt from autonomous vehicle regulations.
The solution to the Level 2 loophole is to modify regulations to additionally regulate Level 2+ robotaxi wannabe automation features. That should include regulating any vehicle with a remote connection that permits direct or indirect control over vehicle motion as if it that were an autonomous vehicle, regardless of any manufacturer’s claim of Level 2 status. In particular, a vehicle marketed as a robotaxi that has no driver in the vehicle and no in-vehicle driver controls should be regulated as a robotaxi, even if there is a remote person with a steering wheel who is acting as a driving supervisor.
Regulators might elect to have different regulatory regimes for remotely supervised vs. unsupervised driving automation features. But arguing that a highly automated vehicle with remote operators is Level 2 should not be a get-out-of-regulation-free ticket.
If it quacks like a robotaxi, it should be regulated as a robotaxi.
Making Level 2 Vehicles Safe
Revisiting the themes in this discussion, creating a safe Level 2 automation feature requires attentiveness to several factors:
A safe Level 2 automation feature respects the limits to human performance.
A safe Level 2 system must be purposefully designed to be resilient in the face of the ironies of automation.
A safe Level 2 system should have effective supervisor monitoring.
A safe Level 2 feature should automatically enforce use only within the ODD.
We should expect supervisors to respond with poor speed and accuracy to failures of capabilities they have come to expect to be reliable.
Safe Level 2 features should have clear-cut, readily appreciated limitations, using notifications to ensure the supervisor is aware a limitation is being encountered. Misbehaviors and limitations beyond the reasonable ability of an ordinary supervisor to mitigate should be considered design defects.
Safe Level 2 features should be designed to mitigate risks to a reasonable degree from foreseeable misuse and abuse.
If a Level 2+ feature is easily confused with a Level 4 feature, or involves a remote operator, it should be covered by autonomous vehicle regulations.
Achieving all these goals will require continued maturation of both driving automation capabilities and driver attention management technology. For that reason, reliable data collection from incidents and mishaps to drive continuous improvement will be a critical piece of any successful Level 2 feature deployment campaign.
There is room on the road for Level 2 driving automation features of various levels of capability and sophistication. However, achieving acceptable safety requires respecting the abilities and limitations of real-world human drivers as they play a role as supervisors of driving automation features.
Phil Koopman has been working on self-driving car safety for about 30 years, and embedded systems for even longer. For more on applying AI, see his new book: Embodied AI Safety.
This post is part of a collaboration between Phil Koopman & Junko Yoshida on AV Safety. Please subscribe for free if you’d like to receive future posts.
The Level 2 terminology comes from the SAE J3016 terminology document. A Level 2 feature depends on continuous human supervision for safety, whereas a Level 4 feature requires no human driver to operate. For a deep dive into this terminology, see: https://users.ece.cmu.edu/~koopman/j3016/index.html
Somewhat confusingly, the human in the driver seat is often called a “driver” when they are passively watching the automation perform the mechanics of steering and speed-keeping. While that person is still responsible for vehicle safety, they are doing something much different than traditional “driving.” I use the term “supervisor” instead of “driver” to reflect when the human-in-command is overseeing automation rather than physically steering the vehicle.
SAE J3016 makes it clear that “+” designations are prohibited. Nonetheless “Level 2+” has persisted as a commonly used term.
A Level 2 vehicle that can complete a coast-to-coast journey with absolutely no driver intervention is still Level 2 if the manufacturer’s design intent is to have a human supervisor there to intervene if needed. Getting lucky that no intervention happened to be needed in any particular driving experience does not make the vehicle Level 4, and the human supervisor remains responsible for intervening if and when needed.
For a more detailed discussion, see: Koopman, The Ironies of Automation for Self-Driving Vehicles
Use of a DMS, much less these safety response actions, are not required for Level 2 features. They should be.
This expectation is problematic in light of someone using a rental vehicle and friends borrowing cars.
As just one example, see “Tesla Steering Wheel Weights (The Full Guide)”: https://teslord.com/tesla-steering-wheel-weights/
For some examples, see: https://electrek.co/2026/04/07/tesla-autopilot-drunk-driver-vacaville-passed-out-dui/
See the Duck Test: https://en.wikipedia.org/wiki/Duck_test
Specifically, the difference between Level 2 and Level 4 automation has to do with the “feature’s production design intent.” See: https://users.ece.cmu.edu/~koopman/j3016/index.html#myth10
In Europe, Regulation UNR171 applies. However, that is still quite different than the regulations applying to Level 3/4/5 automation.
Agree that asking people to be continuously vigilant is unreasonable and likely impossible. Another aspect is fatigue… staying highly vigilant for extended periods is taxing and likely counterproductive if able to be done at all.
One option would be to only require an immediate reaction at certain times when the automation is closer to ODD limits and/or the consequences are more severe. Outside those times the reaction time could extend, allowing a slightly lower level of vigilance. Aviation offers one way to consider this: automation generally gives pilots a few seconds of reaction time before anything truly dangerous develops. And during the phases where that buffer shrinks (automated landings, for example) crews shift to more active monitoring, with procedures and redundancy that support immediate intervention if necessary.
ODD has measurable dimensions, so where boundaries are measurable warnings should activate before they’re crossed. These warnings could allow more reaction time for the supervisor to take over as needed.