Applicable objects: Class M and Class N vehicles equipped with Level 3 / Level 4 Automated Parking Systems (APS).
Document nature: Mandatory National Standard (GB), proposed and managed by the Ministry of Industry and Information Technology (MIIT), currently in the draft for comments stage.
Superior standards: GB 44721 "Intelligent Connected Vehicles - Safety Requirements for Automated Driving Systems", GB 44497 "Intelligent Connected Vehicles - Automated Driving Data Recording System", GB/T 45312 "Operational Design Domain for Automated Driving Systems", GB/T 47025 "Simulation Test Methods and Requirements for Automated Driving Functions".
This standard governs Automated Valet Parking (AVP), where the driver can exit the vehicle and the vehicle parks itself, rather than parking assistance where the driver sits in the car and steers. It applies the entire methodology of the mandatory vehicle-level automated driving standard GB 44721 to the closed scenario of parking.
I. Standard Structure Map
The full text consists of 11 chapters + 7 normative annexes:
| Chapter | Content |
|---|---|
| 1–4 | Scope, normative references, terms and definitions, abbreviated terms |
| 5 | APS technical requirements (DDT, HMI, intervention request, remote assistance, user notification) |
| 6 | Functional requirements (specific performance indicators for parking in, parking out, and parking cruising) |
| 7–8 | Assurance requirements and inspection, safety dossier inspection |
| 9–10 | Validation tests, determination of same type |
| 11 | Implementation of the standard |
| Annex A | Data recording requirements (DSSAP) |
| Annex B | Safety dossier |
| Annex C | Validation test methods and requirements for automated parking in test sites |
| Annex D | Validation test methods and requirements for automated parking on roads |
| Annex E | Validation test methods and requirements for automated parking simulation |
| Annex F | Child test object |
| Annex G | Dynamic selection tests based on safety dossiers |
II. Scope of Application and Classification Logic
Assessed in two tiers by vehicle type:
- Class M1, N1 (light passenger cars/commercial vehicles); Class M2, N2, M3, N3 (large and medium buses/commercial vehicles) — the time indicators for large vehicles are relaxed (see 80 s vs 180 s below).
Classified into two types of functions by automation level:
Level 3 APS: Subject to ODD (Operational Design Domain) limitations, requiring a designated "fallback-ready user" to take over;
Level 4 APS: Subject to ODD limitations, does not require a fallback-ready user, and the driver may not be in the vehicle.
Classified into three types of functions by action: Parking in, parking out, and parking cruising (finding a spot, navigating around, and passing through gates within the parking area autonomously).
A key exemption clause: If the vehicle is already equipped with an automated driving function of the same level (non-parking), and its ODC covers indoor/outdoor parking areas, the APS may only perform parking in and out, without performing parking cruising.
III. DDT Execution Requirements (Section 5.2) — The Core of Safety Logic
The standard divides parking scenarios into four categories, specifying how the system should operate in each:
1. Nominal scenarios (5.2.2)
-
- The safety level must be at least equivalent to that of a "competent and attentive driver currently performing the driving task"; when activated, it must identify four types of collision risks: motorized/non-motorized vehicles/sudden obstacles; adult/child/toddler pedestrians; parking facilities and obstacles;
Objects of unidentifiable types; it must anticipate risks, adjust speed according to risks, and maintain distance from other road users; there must be coping strategies for blind spots (areas obscured or invisible due to topology); for Level 4 functions: it must come to a safe stop when a passenger requests to stop; it must be able to continue parking after an obstacle on the path is removed; when the target parking space is occupied, Level 4 must be able to find a new space, and execute a fallback response if none is found.
2. Risk scenarios (5.2.3)
-
- When a collision is unavoidable, mitigate injuries based on the baseline of a "competent and attentive driver";
Once a collision is detected, the vehicle must be brought to a stop, except when the vehicle loses braking control.
3. Failure scenarios (5.2.4)
- The system must be able to detect faults affecting the DDT (Dynamic Driving Task); after a fault, it must either execute a fallback response (and prohibit the activation of other affected automated driving functions) or operate in a degraded mode according to the severity of the fault.
4. Non-compliant ODC scenarios (5.2.5)
- If non-compliant ODC conditions are encountered before activation, the function shall not be activated; if boundaries are exceeded during activation, execute a fallback response / MRM (Minimal Risk Maneuver).
Hard indicators (5.2.1.7, 5.2.6.3):
For Level 4 APS, under extreme conditions where "passengers may be standing and without restraint systems", the horizontal acceleration/deceleration command shall be ≤ 2.4 m/s², and the jerk (rate of change of acceleration/deceleration) shall be ≤ 5.0 m/s³; when executing MRM deceleration, the deceleration command under normal conditions shall be ≤ 4.0 m/s²; exceeding these limits is only permitted in special cases specified in the safety dossier, such as severe failures, severe vehicle failures, or imminent collisions.
IV. Human-Machine Interaction and Takeover (5.3, 5.4)
Intervention requests for Level 3 APS are quantified:
Requests must be issued in advance for planned takeover events, ensuring that even if no one takes over, the MRM can bring the vehicle to a stop before the event occurs; for unplanned events (such as sudden severe weather), requests must be issued immediately upon detection;
Intervention requests must be escalated no later than 4 seconds after being issued, and remain in the escalated state until termination;
The duration from the issuance of the intervention request to termination due to MRM execution shall be no less than 10 seconds, providing sufficient time for the fallback-ready user to take over.
"Handover check" before exiting manual driving (5.3.2.3.3): The system must confirm that the fallback-ready user has "hands on the steering wheel + eyes on the driving area for a sufficient duration" before considering them ready to take over; otherwise, it shall not hand over control.
Special rules for Level 4 APS (5.3.3):
- "Exiting to manual driving while in motion" is not allowed (there may be no one in the vehicle at all); risks such as unfastened seatbelts or passengers not seated must be responded to according to the strategies in the safety dossier; manual driving controls must be protected to prevent accidental touches from affecting the APS.
Control authority details: Door operations take priority over the APS; the APS does not activate automatically after each power system startup; the status must be continuously displayed during activation; after a collision, alerts must be provided to users inside the vehicle until the system exits.
V. Remote Assistance (5.5, Level 4 Only)
Trigger scenarios (5.5.1.4): Vehicle collisions, need for recovery, vehicle/APS failures, and other situations specified in the safety dossier; it shall not be triggered in other situations;
Communication requirements (5.5.2): It must be able to detect signal strength, network latency, and jitter; when poor communication leads to assistance failure, execute MRM or keep the vehicle stationary;
Information to be uploaded by the vehicle (5.5.3.2): Vehicle status (speed, failure, collision), APS status, surrounding environment (perceived objects, area conditions), and assistance information reception results; boundaries: remote assistance only accepts operational information such as trajectory guidance and parking, and does not include strategic decisions like "help me choose a better parking spot".
VI. User Notification and Usage Training (5.6)
This section is extremely lengthy, indicating that regulators are highly concerned about "whether users truly understand":
User manuals must be clearly written (5.6.2): Functional capabilities and level limitations, strategies for unavoidable collisions, differences between activation/exit/takeover/intervention/MRM, how user roles transition, how much time is left for Level 3 takeover, allowed non-driving activities and associated risks during activation, how to request a stop for Level 4, emergency response to accidents, maintenance, multi-user account logout, trailer adaptation requirements, etc.
Training and confirmation mechanism: After each power system restart, one of three methods — "completed training / biometric recognition / account login in a stationary state" — must be used to confirm that the driver has been trained; confirmation of having read the user manual requires a long press or double click, and is only allowed when stationary;
Reconfirmation is required after software upgrades; if not confirmed within 30 days at the latest, reconfirmation is required before the next activation.
VII. Functional Requirements (Chapter 6) — Indicators Directly Applicable to Test Benches
7.1 Parking In (6.1)
| Indicator | Class M1/N1 | Class M2/N2/M3/N3 |
|---|---|---|
| Maximum design operating speed | ≤ 10 km/h | ≤ 10 km/h |
| Time to complete parking in | ≤ 80 s | ≤ 180 s |
| Distance from the outer edge of the wheels to the parking space boundary upon activation | ≤ 15 m | ≤ 15 m |
Other requirements:
Perpendicular parking spaces must support at least the rear-in method; it must be able to park in spaces where the parking lock (ground lock) is lowered; after parking, it must engage the parking gear + parking brake, turn off the power, and lock the doors (except for situations specified in the safety dossier such as charging/battery swapping, loading/unloading);
Hard requirements for pose geometry
- Parking space with lines: The angle between the vehicle body and the line is ±3°, and the ground contact points of the outer edges of all four wheels must fall within the markings (Dfl/Dfr/Drl/Drr are all > 0); when the vehicle length is > 5.4 m, the front/rear distances Mf/Mr are relaxed to > −0.2 m; spatial parking space (enclosed by boundary vehicles): Df/Dr distance to the boundary vehicle ≥ 0.2 m; parallel parking space with a curb: tire distance to the curb is 0.05–0.35 m.
7.2 Parking Out (6.2)
Design speed ≤ 10 km/h; perpendicular parking spaces must support at least front-out; the time is also M1/N1 ≤ 80 s, large vehicles ≤ 180 s; after parking out, the distance from the outer edge of the wheels to the parking space boundary is ≤ 15 m.
7.3 Parking Cruising (6.3, Key Point)
Maximum design operating speed ≤ 30 km/h
-
- (Significantly higher than the 10 km/h for parking in/out); must possess: straight road passage, curve passage, parking lot intersection passage, obstacle avoidance, reversing, and U-turns;
Tiered gate handling
-
- Level 3 APS avoids collision with gates and executes a fallback response after coming to a stop; Level 4 APS must control the vehicle to pass through the gate;
Obstacle avoidance
-
- Triggered only under specific conditions such as stationary obstacles ahead, slow-moving pedestrians/non-motorized vehicles, and construction zones; when partially entering the opposite lane, sufficient distance and time to return to the original lane must be reserved;
Lane change control
- It must evaluate the rear safety distance and control the turn signals; for at least 2 seconds after completing a lane change, deceleration must not be increased (except in cases of imminent collision or MRM requirements).
VIII. Data Recording and Safety Dossier
DSSAP Automated Parking Data Recording System (5.7.1, Annex A): Vehicles equipped with APS must be equipped with DSSAP, classified into Type I and Type II; it must monitor, collect, and store data throughout the entire process from activation to exit;
Collision events must be "locked" and cannot be overwritten
- Recorded separately as collision events and timestamp events.
Safety dossier (Annex B): Remote assistance trigger conditions, switching strategies with other automated driving functions, ODD boundary descriptions, degradation strategies, etc., must all be clearly stated in the safety dossier; Annex G goes a step further:
Test scenarios are not fixed use cases, but are dynamically selected based on the safety dossier submitted by each company
- — This is the biggest difference from traditional type approval tests.
IX. Validation Test System (Annexes C/D/E/F/G)
| Annex | Test Type | Description |
|---|---|---|
| C | Site validation test | Site conditions for parking in/out/cruising, including pose, efficiency, and collision avoidance |
| D | Road validation test | Real road conditions |
| E | Simulation validation test | Refers to GB/T 47025 for simulation credibility assessment |
| F | Child test object | Lists child test object specifications separately, directly addressing parking accidents involving run-over children |
| G | Dynamic selection test based on safety dossier | Dynamically selects test scenarios according to the enterprise's safety dossier |
X. Key Implementation Points for Enterprises
1. This is a market access threshold, not a reference. To pass type approval, enterprises must simultaneously submit the safety dossier, DSSAP data records, and pass the three sets of validation tests: site + road + simulation.
2. Testing costs increase significantly. The time indicator for large vehicles (Class M2) is relaxed to 180 s, but functional items such as pose, collision avoidance, gate handling, and lane changing are not reduced at all.
3. Level 4 unmanned parking is a real threshold. Remote assistance, MRM (≤4.0 m/s²), prohibition of exiting while in motion, passenger stop requests, automatic gate passage — these must be fully implemented, not just PPT features.
4. The safety dossier becomes a core deliverable. The dynamic scenario selection test in Annex G means that regulators require enterprises to clearly demonstrate their ODD, risk scenarios, and degradation strategies themselves, and regulators will then select scenarios for verification based on this.
5. Integration with the in-service safety system. DSSAP, safety dossiers, MRM, and dynamic scenario selection are precisely the underlying components for future ISMR (In-Service Monitoring and Reporting) and Safety Cases.
This article is compiled based on the main chapters of the public text of the draft for comments of "Intelligent Connected Vehicles - Safety Requirements for Automated Parking Systems". The clause numbers and technical indicators are all cited from the original text. The standard is still in the draft for comments stage, and the specific content shall be subject to the officially released version.