According to the Ministry of Industry and Information Technology (MIIT), on July 30, 2026, the mandatory national standard "Intelligent Connected Vehicles - Safety Requirements for Automated Driving Systems" (GB 44721—2026), organized and formulated by the MIIT, was approved and released by the State Administration for Market Regulation (SAMR) and the Standardization Administration of China (SAC). It is scheduled to officially take effect on July 1, 2027.
So, what does the release of this standard mean? What are its requirements for autonomous driving products? What needs to be implemented in product development? What are the potential difficulties? And what impact will it have on the development of autonomous driving?
This article interprets the GB 44721-2026 standard from the perspective of an autonomous driving industry practitioner, hoping to provide some information and insights.
First of All, the Nature of the Matter Has Changed
Actually, there was an older version of the L3/L4 regulations called GB/T 44721—2024. The "/T" stands for "recommended." Translated into plain language: the government is telling you "it is recommended to do this," but it is fine if you don't. Now, the new version has removed the "/T".
Translated into plain language: if you claim your car is L3/L4, you must comply with this GB national standard. If you don't, the car cannot be listed in the official announcement. This is the essential difference. Over the past two years, local L3 road tests, including the conditional access approvals obtained by Changan SL03 in Chongqing and Arcfox Alpha S in Beijing in 2025, were all based on that "recommendation."
Starting from July 2027, it becomes a hard threshold. This also indicates that from July next year, cars can legitimately claim to be L3/L4 autonomous driving vehicles. From the perspective of regulatory thinking, the requirement of this regulation is:
In the past, it was "you prove the car can drive"; now, it is "you prove the car won't crash, and you must prove that you have the capability to continuously prove this."
The second half is where the real difficulty lies. We will discuss this later. Scope of application: passenger cars and trucks equipped with L3 and/or L4 systems. Automated parking is not included.
So What Exactly Is Required?
The standard is 61 pages long; I will break it down into several parts.
Part One: The Car Must Know How to Drive (Chapter 5)
This chapter is the "passing line," written somewhat abstractly. The core message is just one sentence: "The safety level of the ADS should at least reach the level of a qualified and attentive driver."
Pay attention to this wording—it is not the "average driver," but a "qualified and attentive driver." That means someone who hasn't been drinking, isn't looking at their phone, has sufficient driving experience, and is in good condition. This benchmark is set quite high. Then, the requirements are expanded according to four situations: when everything is normal (nominal scenarios), when encountering danger (risk scenarios), when the system fails (failure scenarios), and when driving out of the operational design domain (non-compliant with ODC).
Among them, there are three points that practitioners need to pay special attention to:
① You must worry about the unseen areas. (5.1.2.4) The standard explicitly requires that for "unobservable areas"—the inherent blind spots of sensors, blind spots blocked by other vehicles, and blind spots hidden by curves and slopes—there must be reasonable control strategies. Simply put: if a large truck blocks your right front, you cannot pretend there is nothing there. This directly writes the occlusion reasoning, which academia has discussed for many years, into the regulation.
② Police cars and traffic police: L4 has no way out. (5.1.2.10, 5.1.2.11) When encountering police cars, fire trucks, or ambulances on duty, or traffic police gesturing at intersections—L3 can choose to "yield, or ask the driver to take over," but L4 can only yield and must follow the traffic police's gestures. There is no option of "I don't understand, you do it," because L4 fundamentally does not have a "you." This is a typical long-tail perception task, written as a mandatory item.
③ Stop once, and you must restart the ignition. (5.1.6.1) If the L3 system executes an MRM (Minimum Risk Maneuver, meaning "I really can't drive anymore, I'll pull over and stop"), after the car stops, the power system must be restarted to reactivate autonomous driving. It cannot just stop, recover, and then continue driving automatically. Currently, L2++ systems already do this, so there is no significant difficulty in making changes.
Part Two: L3 on Highways, Down to the Decimal Point (Appendix B)
These 12 pages contain the most engineering details in the entire document. The previous parts were relatively abstract; here, it is all about numbers. Let's talk about how far perception needs to reach first. The standard makes a very smart and rigid design: the faster you want to go, the further you need to see. And to exceed 60 km/h, there is a prerequisite—the car must have a deceleration capability of over 5 m/s².
What is the concept of 130 meters? At 120 km/h, 130 meters is the position you will reach in 3.9 seconds. That is roughly 30 cars lined up bumper to bumper. But more critically is the definition of "detection range." The standard is very clear: it is the distance at which the sensor can still reliably identify targets and generate control signals based on them, considering the aging and degradation of the sensor over the vehicle's lifespan due to time and usage.
Translated: it is not the "maximum detection distance of 200 meters" on your spec sheet. It is the distance you dare to use for decision-making after that lens has gathered dust, been used for eight years, and its coating is somewhat scratched. Additionally, if your system changes lanes, it also requires a range of at least 9 meters to the left and right from the centerline of the vehicle body, with full coverage in the forward, lateral, and rearward directions. 9 meters is roughly two and a half lanes, meaning you must also see the car in the adjacent lane.
Let's talk about lane changing. This is the part I think is the most headache-inducing for the large model data team or the rule-based planning and control team. You want to change lanes to the left on the highway. You glance to the left rear, and it's empty.
Can you change lanes? The standard says: you cannot think this way.
It requires you to assume—the car behind you that you didn't see is right at the very edge of your rearward perception capability, and it is driving 30 km/h faster than the speed limit of this road. (B.1.2.3.2.2) You must calculate based on this assumption. After calculating, you must also ensure: after you change lanes, the other driver does not need to brake with more than 3 m/s², and always maintains a following distance of more than 1 second from you.
Where is the lethality of this rule? It welds "whether you can change lanes" and "how far you can see behind" together. If your rearward perception is not far enough, you do not have the qualification to change lanes on this road. You either add hardware or honestly lower the maximum vehicle speed in the ODC. This is a clear cost/capability trade-off point, and the earlier the decision is made, the better.
By the way: turning on the turn signal 3 seconds in advance can reduce your safety distance requirement from 1.4 seconds to 0 seconds. This is a clear "good boy reward" given by the standard, which is very worth utilizing in planning and control. There are also a few scattered but mandatory requirements: the additional lateral acceleration during lane changing must not exceed 1 m/s² (centrifugal force in curves is not counted); the deceleration command during lane changing must not exceed 2 m/s²; if the distance to the rear car is already tight, you are not allowed to increase the braking force within2 seconds after changing lanes.
Cutting In Front of Others, and Being Cut Off.
In the original draft for comments, the standard provided a formula to define "under what circumstances you must avoid colliding with a cut-in vehicle." The final draft merged and deleted these two clauses, replacing them with a qualitative requirement: "For situations such as a vehicle cutting in front or an unoccluded pedestrian crossing, the DDT execution capability of the ADS should at least reach the level of a qualified and attentive driver currently undertaking the driving task to minimize risk." TTC > V rel/12 + 0.35. The 12 is 2×6, implying a braking capability assumption of 6 m/s².
The starting point for TTC timing is defined very precisely: the exact moment the outer edge of the front wheel of the cut-in vehicle crosses the outer edge of the lane line by 0.3 meters. Moreover, it requires its lateral movement to have an identifiable time of at least 0.72 seconds—ghost-like sudden cut-ins are not your responsibility. The pedestrian rule is unconditional. (B.1.1.9) An unoccluded pedestrian crossing at a speed not exceeding 5 km/h (which is normal walking speed), with the pre-collision point within 20 centimeters to the left and right of the exact center of your car's front—must avoid collision. No "if," no "unless."
The Rhythm of Takeover Requests.
The timing design here is very interesting and worth a close look: if it is a predictable takeover event (e.g., the highway exit is approaching, exiting the ODD), how early should the intervention request be? Early enough that "even if the driver completely ignores you, the MRM can stop the car before the event occurs."
This requirement is quite aggressive. After the request is issued, it must be escalated (louder, more urgent) no later than 4 seconds. If the car is still moving after the escalation, continuous or intermittent vibration alerts must be added. From the issuance of the request to termination due to MRM, at least 10 seconds must be given to allow time for reaction. However, in case of severe failure, it is allowed to execute MRM directly without issuing a request—because it is already too late. MRM deceleration must not exceed 4.0 m/s², and the hazard lights must be turned on and kept flashing (during the lane-changing phase, the turn signal replaces it, and it switches back to hazard lights after the lane change is complete).
Part Three: L3 Cars Must Monitor the Driver (Appendix A)
This section has only three short subsections, but each one could directly force you to change your hardware BOM.
① Seatbelts cannot rely solely on the buckle switch. (A.2.1) The standard requires: to determine that the driver has fastened the seatbelt, there must be at least one method "other than the buckle." Why? Because everyone knows that the latch can be inserted independently while the person sits on it. So you need to use a camera to check, or add tension sensors, or pressure sensors. This is a new material. However, nowadays this is mostly handled through in-cabin cameras. The final draft deleted this; non-buckle detection is no longer a requirement.
② If the person is not in the seat for more than 1 second, a takeover request must be issued. (A.3.2)
③ This one is the harshest: at least two indicators, each judged independently, with a 30-second cycle. (A.4.1) The standard requires you to use at least two valid indicators, independently confirming that the driver had the capability to take over in the previous 30-second cycle. Indicators can be eye movement, head movement, body movement, specific interactive operations, voice, physiological features, etc. The key is in the second half: if there are fewer than two monitorable indicators, it also counts as "lacking capability." Think about when this would be triggered: the driver is wearing sunglasses (eye tracking is disabled), nighttime infrared is interfered with, the face is covered, hands are off the steering wheel while the head is also still... Anytime your DMS drops to only one signal channel, the system must consider the person unreliable.
④ From "prompt" to "takeover request," a maximum of 15 seconds. (A.4.2) If the person's state is found to be abnormal, issue a prompt immediately (and this prompt must be distinctly different from all other alert sounds in the car). The prompt lasts until the person recovers, or it is escalated to a takeover request—this escalation must not be later than 15 seconds.
Adding another rule from Chapter 5: to determine that "the person is ready to take over," at least two conditions must be met simultaneously: hands on the steering wheel + gaze in the driving-related area for a sufficient duration. Both are required. Moreover, if gaze monitoring is temporarily unavailable, you must clearly state in the safety case what is used as a substitute.
Part Four: Extra Homework for L4 (Appendix C)
The capability list is mandatory. If the ODD only includes highways and urban expressways, it must at least be capable of: lane cruising, lane changing, and borrowing lanes to avoid obstacles. If the ODD also includes other roads (i.e., urban areas), it must at least be capable of: lane cruising, lane changing, intersection navigation, borrowing lanes to avoid obstacles, reversing, and U-turns. Reversing and U-turns are written into the mandatory list, indicating that the regulators are thinking about truly unmanned operations, not just highway shuttles.
If standing passengers are allowed on the vehicle (think Robobus), acceleration and deceleration must not exceed 2.4 m/s², and the rate of change must not exceed 5.0 m/s³. This constraint will significantly affect operational efficiency; those working on bus scenarios should take note. The remote assistance part is written very meticulously.
Three core sentences: Do not rely on remote assistance to execute driving tasks (C.2.1.2)—remote assistance can only be "lending a hand," not "taking over the wheel." During remote assistance, the steering wheel is still turned by the ADS, and the car is still driving itself, rather than the remote system directly accessing the accelerator pedal.
The communication status must be self-detected (signal strength, latency, jitter), and it must be able to execute MRM on its own when disconnected. This rule actually eliminates an entire category of business models—the "remote cockpit fallback" approach cannot be used as the basis for safety justification under this standard. There is another easily overlooked rule: after stopping, the car is not allowed to move again on its own before confirming that "the reason that made me stop has been eliminated." (C.1.4.3)
Part Five: You Need a "System" (Chapter 6)
This chapter does not talk about the car; it talks about the system for autonomous driving. It requires you to establish and operate an SMS (Safety Management System), with all seven modules present: safety policy, risk management, safety assurance, safety improvement, design and development management, production management, and post-deployment safety management. There must also be KPIs to measure the effectiveness of the system, supply chain agreements, and regular independent internal audits and external inspections. Then there is 6.2.1. I think this section is the most underestimated part of the entire document.
It talks about "simulation test conditions." But what it does is not ask if your simulator is easy to use, but why your simulator is credible. Requirements include: code verification (static analysis, dynamic analysis, convergence analysis), numerical error estimation (discretization error, rounding error, iterative convergence error), sensitivity analysis (which inputs have the greatest impact on the results), statistical consistency proof between simulation outputs and real-world vehicle results, uncertainty quantification, and even requires you to clearly separate aleatory uncertainty (inherently random things, like road adhesion coefficients) and epistemic uncertainty (things you don't fully understand, like errors caused by model simplification).
Also: if your simulation uses random numbers, you must be able to deterministically reproduce the exact same run; if you cannot, you must prove that this uncertainty does not affect credibility. The qualifications and training records of the people who develop the simulator, evaluate the simulator, and use the simulator for testing must all be archived. The prototype of this system is not from the automotive industry.
It is more like NASA's model and simulation credibility standards. The simulation platforms of domestic passenger vehicle teams are mostly at the stage of "being able to run scenarios." From "being able to run scenarios" to "being able to serve as admission evidence," the gap is measured in man-years. And buying commercial software cannot solve this—the standard is not testing the tool, but your understanding and justification of the tool. Suppliers cannot write the sensitivity analysis conclusions for you.
Part Six: Safety Case — A Thesis Defense (Appendix D)
This is the longest appendix in the entire document, 17 pages. Its structure is actually very much like a Ph.D. thesis defense: you make a bunch of claims, each claim is paired with arguments, each argument is paired with evidence, and you must be able to trace from "a specific requirement in the standard" all the way to "a specific piece of data from a specific test," with bidirectional traceability.
There are a few numbers to note.
① ASIL rating is hard-coded. (Table D.1) The standard directly lists 11 types of vehicle-level hazards and their corresponding ASIL levels. ASIL D is the highest level of automotive functional safety, meaning the strictest development process, the highest diagnostic coverage, and usually also implies redundant hardware.
Look at it another way—these 11 types of hazards are not abstract; grouped by physical nature, they are actually distributed in the four directions of the car:
Those that get ASIL D include: unintended lateral movement, unintended loss of lateral control, unintended acceleration, and loss or degradation of active deceleration capability. Additionally, L4's "loss or error of MRM" is also D (L3 only requires B); L3's "failure to respond to driver intervention" is D (L4 can be unassigned, because it fundamentally does not expect the driver).
Accompanied by two architectural red lines, which seem simple but come at a high cost: any single-point failure in the electrical/electronic system must not cause you to completely lose active steering, active braking, and active parking capabilities (D.2.4.2.5). Any single-point failure in L3 must not cause you to completely lose the alerting capability (D.2.4.2.7)—the three channels of sound, light, and vibration cannot be knocked out by the same failure simultaneously, meaning the alert channels must also be redundant.
② The threshold for residual risk, this is the most critical number in the entire document. (D.2.3.1.3)
Then the standard provides a reference algorithm: to prove that "the collision accident rate is less than one in ten thousand per hour," you need to accumulate 16,000 hours of driving without an incident, giving you 80% confidence that the standard is met. 16,000 hours sounds okay? A car driving 10 hours a day, 1,600 days, four and a half years.
Deploy a fleet of 50 cars, and it can be done in four months. But 16,000 hours corresponds to the most lenient tier. You also need to prove that the fatal accident rate is less than one in ten million per hour. Calculated with the same statistical logic, the magnitude jumps directly to tens of millions of hours. What is the concept of ten million hours? 1,000 cars running 24/7 for over a year. And—every time you change a version of the algorithm, theoretically, you have to start over. So this path is mathematically a dead end.
The standard itself knows this, so it leaves a loophole elsewhere: simulation, data-driven, shadow mode (D.2.6.4.9). You can use simulated mileage to convert to real-world mileage. But on what basis is the conversion ratio calculated? Based on how credible your simulation is. Thus, it loops back to 6.2.1. This forms a circular dependency, which I believe is the deepest threshold in the entire standard:
Your simulation credibility → determines your equivalent mileage conversion ratio → determines whether you can pass the residual risk → determines whether you can get admission.
Whoever builds this closed loop first will have an order-of-magnitude faster admission speed. This is not a competition of algorithm capability, but a competition of engineering systems.
③ The list of scenarios that must be covered. (Table D.2)
The standard lists a "minimum you must test these" checklist. Here are a few interesting ones: no lane lines, broken lines, faded lane lines, lane count changing from more to fewer or fewer to more, construction zones, gantries, toll booths, height limit barriers, irregular targets (water trucks, roadblock vehicles), low-contrast targets, overturned or tilted targets, pedestrians with umbrellas, electric two-wheelers wearing raincoats, and a whole category of "user misuse": accidental activation, misuse after activation, failure to take over, accidental takeover, accidental exit. It is evident that this table grew out of real accidents and real complaints. Those who have worked on perception will smile knowingly at the pedestrians with umbrellas and electric two-wheelers in raincoats.
④ There is another quite interesting requirement. (D.4) Before type approval, you must conduct an independent review, and the records must clearly state "identified defects, parts with low confidence, and unclear parts." In other words, the standard requires you to write your weaknesses into the file and submit them. Hiding them is actually a risk.
Part Seven: Three Checkpoints (Chapters 7, 8, 9)
The new standard's inspection system has three layers, looking not only at the product but also at the system documents: Check the system—see if your company's SMS is reliable, and if your simulation/proving ground/road test conditions are up to standard. The SMS inspection report is valid for 3 years. Check the file—see if your safety case is complete (whether the claim-argument-evidence chain can be traced bidirectionally), and robust (whether the residual risk is low enough, and whether the evidence can be reproduced). Spot check and retest—a third party re-tests using simulation, proving ground, and road methods on their own. Moreover, the inspectors can require you to assist in reproducing the evidence you submitted. The third point is worth paying attention to.
This means you cannot just submit a bunch of "beautiful data run back in the day" and call it a day—you must be able to rerun the exact same results at any time with the same software version, the same tool version, the same scenarios, and the same parameters. This is a solid test of engineering archiving capabilities.
Part Eight: Change a Little, Retest Everything (Chapter 10)
This chapter has the greatest lethality for product and project management.
The standard lists a long series of things that must be "exactly the same" to be considered the same type: sensor type, manufacturer, model, quantity, installation location; ECU manufacturer, model, quantity; electrical/electronic architecture; ADS software architecture features (explicitly including end-to-end model frameworks); human-machine interaction methods; MRM strategy; ODC; L3 takeover monitoring components, indicators, thresholds... Software versions are allowed to differ, but with a condition: "provided it does not affect ADS performance."
These nine words are the largest gray area in the entire standard, and also the hottest battlefield in the industry over the next two years. Because—does retraining an end-to-end model count as "affecting ADS performance"? No one can answer that right now. Enterprises need to build a change classification ledger: which level of change is "does not affect performance" and can be directly OTA'd; which level triggers supplementary inspection; and which level requires re-type approval. This judgment criterion can only be hammered out through repeated negotiations with inspection institutions. It is recommended to start accumulating now, don't wait until 2027.
Another rule: ODC can only be shrunk, not expanded. (10.2) Road types can only be reduced, operating hours can only be reduced, maximum vehicle speed can only be lowered, weather conditions can only be stricter, and lane types can only be reduced. Want to expand the ODD? Go through the inspection process again. This rule directly hits the industry's habitual rhythm. The usual play is "open one city first, run it through, then open ten cities, releasing a new firmware version every month to gradually open up." Under the new standard, every "opening up" is a compliance event.
Timeline
July 1, 2027 — Newly applied models for type approval must comply. August 1, 2028 — Older models that have already obtained type approval must comply (the 13th month). There are 11 months left until the first deadline. Safety case plus SMS inspection, at a normal pace, takes 12 to 18 months. If it hasn't started yet, objectively speaking, it is already late.
So What Exactly Needs to Be Implemented?
For companies internally planning to do L3/L4, divided by team, here is my understanding of the responsibility list:
System Architecture — Redundant steering, braking, parking (single-point failures cannot disable everything); ASIL D decomposition plan; L3 three-channel redundant alerting; architectural justification for "a single perception failure does not cause harm."
Perception Hardware — Deduce detection range based on target vehicle speed (120 → 130 meters); lane-changing capability corresponds to 9 meters omnidirectional coverage on both left and right; rearward detection distance (it directly determines whether you have the qualification to change lanes); calibration of usable range after aging and degradation; installation angle tolerances must be written into specification documents.
Planning and Control — Rearward safety distance evaluator, including the worst-case assumption branch for "not seeing the rear car"; lane-changing A/B parameter logic; cut-in vehicle TTC formula; MRM state machine (including MRM lane changing, switching between turn signals and hazard lights, MRC locking); preconditions gate for cross-lane-line collision avoidance; recognition and yielding to police cars and traffic police gestures.
DMS / Cabin — Non-buckle seatbelt determination (new hardware); in-seat monitoring 1-second threshold; dual-indicator 30-second cycle capability judgment; 15-second timing from insufficient capability to takeover request; 4-second escalation and vibration channel; dual-condition exit judgment of hands on steering wheel + gaze.
Product / HMI — Takeover request icon (must have a graphic of hands and a steering wheel); red flashing during MRM; and a whole set of user training and confirmation processes:
Every time the power is turned on, it must be confirmed that the driver has completed training (choose one of three methods: on-site training and confirmation / biometric recognition / account login + password in a stationary state); a confirmation method for "have read and understood the manual" must be provided, which can only be confirmed when the car is parked, and must be a long press or at least two intentional operations (e.g., double click); if the manual content is changed via OTA, it must be re-confirmed before the next activation; if not confirmed for a maximum of 30 days, it must be forcibly re-confirmed before the next activation.
To be honest, compliance with this stuff is rigid, but the user experience is extremely counter-intuitive. If done poorly, it will be very annoying, but if not done, ADS activation is not allowed. Product colleagues must get involved early; this is not something that can be glossed over by "adding a pop-up before launch."
Testing / Simulation — Complete V&V package for the simulation toolchain (as mentioned earlier, this is the biggest chunk); calibration records for proving ground and road test equipment; toolchain archiving for evidence reproducibility. Functional Safety / SOTIF — HARA and ASIL justification for Table D.1; verification coverage for all trigger conditions in Table D.2; layered quantitative justification for residual risk; confidence justification for unknown hazard scenarios. Quality / Process — Full SMS; post-deployment safety monitoring process (event reporting → investigation → risk assessment → countermeasures → effectiveness feedback); change impact analysis and regression strategy. Legal / Admission — Safety case (8 types of submitted documents + 6 types of reference documents); independent internal audit records before type approval; change boundary ledger for the same type. Cloud — Data return link (functional and performance requirements for collection, processing, transmission, annotation, and mining must all be written into the file); shadow mode; L4 remote assistance platform.
A Few Pitfalls, Ranked by Pain Level
1. Residual risk justification — A mathematical dead end. As mentioned earlier, 16,000 hours is only enough for the most lenient tier; the fatal accident rate tier requires tens of millions of hours. The only way out is simulation conversion, but the legitimacy of the conversion ratio relies on the credibility of the simulation. This is a circular dependency, and also the deepest moat of this standard.
2. The "evidence qualification" of the simulation toolchain. "Being able to run scenarios" ≠ "being able to serve as evidence." The validation of sensor models requires statistical significance compared to real vehicles, uncertainty must be quantified, and aleatory and epistemic uncertainties must be separated—these are basically blank in the context of domestic passenger vehicles. This item is recommended to be listed as the highest priority, because it is a prerequisite for item 1.
3. The chain reaction caused by "calculating the worst case even if the rear car is not seen." The hypothetical rear car at speed limit +30 km/h, the 3 m/s² deceleration limit, and the 1-second time gap, deduce a quite aggressive rearward detection distance. The rear-lateral perception of many existing platforms (especially pure vision solutions) cannot support highway lane changing. Either add hardware or lower the ODC vehicle speed. This is a decision that needs to be made immediately.
4. The direct conflict between same-type determination and OTA rhythm. "Same software architecture features" + "ODC can only shrink" + "version must not affect performance," stacked together, the conventional retraining of end-to-end models is highly likely to fall into the gray area. The industry's habitual iteration rhythm and this set of rules are in a head-on collision.
5. Productization of the user training process. A pure product design challenge. Compliance requirements are rigid, user experience rigidly resists, and a balance must be found in the middle.
6. This essentially tests organizational capability, not technical capability. SMS + safety case + triple inspection tests "whether your company has an auditable safety governance system." This has a structural bias towards enterprises with a high degree of self-research and mature processes.
Enterprises that rely on assembling external solutions will discover an embarrassing fact: suppliers will not give you the process evidence, and your file simply cannot be written completely.
What Will This Industry Become?
First, the era of conceptual marketing is over. Ambiguous rhetoric like "NOA," "L2+," and "quasi-L3" will lose space. The ODC must clearly state road types, time periods, vehicle speeds, weather, and lane types according to GB/T 45312, and then be written into the safety case.
This is both a constraint and the confirmation of responsibility boundaries. For enterprises that are genuinely willing to take L3 responsibility, it is actually a good thing—finally, there is a line that can be pointed to and said, "Within this line is my responsibility, outside is not." The dimension of competition has changed. What determines who gets L3 admission first is no longer primarily the takeover mileage data, but: whether the simulation toolchain is qualified to serve as evidence, whether the safety case can pass the bidirectional traceability review, and whether the SMS can prove robustness.
This is a reordering from "demo capability" to "engineering system." It will clearly distinguish a batch of companies, and the way of distinction is quite different from what everyone has been competing on over the past two years. The BOM is pushed upwards by the standard in reverse. 130 meters forward, 9 meters lateral, rearward perception deduction, redundant steering and braking, non-buckle seatbelt monitoring, multi-modal redundant alerting—costs rise rigidly.
Therefore, in the short term, L3 will first be implemented in highway and urban expressway scenarios, and in mid-to-high-priced vehicle models. This also perfectly explains why Appendix B only covers high-speed and expressways. The supply chain relationship needs to be reconstructed. The standard requires you to sign development interface agreements with all participating parties, evaluate the suppliers' SMS, and audit their processes.
Tier 1s shift from "selling parts" to "must deliver auditable safety process evidence." Suppliers who can provide complete file support materials will get a premium, and those who cannot will be squeezed out of L3 projects. Admission changes from "one-time" to "lifetime."
Post-deployment safety management requires continuous monitoring, event reporting, risk assessment, OTA fixes, and effectiveness verification. This essentially establishes a "post-market surveillance" system similar to pharmaceuticals for high-level autonomous driving. Cloud security operations are henceforth part of admission, not an option.
The last one is a strategic variable that is easily overlooked.
Officials explicitly mentioned that this standard has been coordinated with the UN ADS GTR. If the alignment is indeed high, then the safety case produced domestically could potentially be reused for export in the future. This is the commercial rationale for investing in this "seemingly heavy" system—not just to get certified domestically, but to get a certificate that can be used in the future. The following is the advertising section: Want to buy a book? About autonomous driving, jointly published by Vehicle and China Machine Press. High-paying positions in the automotive industry, essential book reference materials for future embodied intelligence, as well as pictures.
- "Intelligent Connected Vehicles - Safety Requirements for Automated Driving Systems" (GB 44721—2026) PDF
*Reprinting and excerpting are strictly prohibited without permission - To obtain the reference materials for this article: join our Knowledge Planet to download massive reference materials from the official account, including the above reference materials.