Missing one core document blocks laboratory test eligibility. That is not an exaggeration — auditors check completeness against a defined list, and a single gap stops the process. Documents fall into three distinct preparation phases: SUMS system audit, VTA physical vehicle testing, and CCC certificate application.
Phase 1: SUMS System Audit Documents
Category 1 — Enterprise Qualification Files
Stamped business license copy, production permit or existing CCC certificate, corporate organizational chart, legal representative identity document. The organizational chart must show the actual reporting chain for software upgrade management. A generic administrative org chart will not pass audit review.
Category 2 — Software Upgrade Management Policy and Manual
A software upgrade security management policy signed by senior management, with visible signature page and effective date. The manual must cover all nine mandatory processes, specifying input and output boundaries, responsible job titles, execution workflows, and abnormal disposal procedures for each one. References to "relevant departments" are not acceptable. Auditors require specific job titles.
A common misconception on signature authority: Only the software upgrade security management policy requires a senior management signature. The nine procedure documents, emergency response plans, and work instructions can be approved by corresponding department heads — they do not all require the legal representative's signature. Some companies mandate executive signatures on every document, generating substantial unnecessary workload.
Category 3 — Nine Mandatory Process Procedure Documents
Each of these must be a standalone formal specification, not a paragraph embedded in the system manual:
Unique identification of software and hardware information; access and update control of software identification codes; precise target vehicle recognition for upgrade deployment; configuration compatibility confirmation; cross-system impact assessment of upgraded ECUs; type approval impact evaluation for software and hardware changes; functional change risk assessment; safety system interference risk evaluation; end-user notification management.
Category 4 — Four Security Safeguard Documents
Technical anti-tampering scheme for upgrade packages; full-lifecycle end-to-end security protection measures; functional and code rationality verification workflow; comprehensive emergency incident response plan. The emergency response plan needs granular step-by-step disposal workflows for three scenarios: OTA upgrade failure, tampered firmware packages, and cross-version software conflicts.
Category 5 — Upgrade Activity Sample Records
Complete record chains for at least two full historical software upgrade cycles, covering risk assessment, test verification, release approval, and post-upgrade monitoring. Auditors will select one chain at random for on-site inspection and follow it end to end.
Two clarifications here that avoid common mistakes:
Brand-new platforms without any mass production upgrade history can substitute real production records with simulated full-process upgrade test records. There is no mandatory waiting period for actual production data.
Component software change ledgers — firmware versions and revision records for TBOX, MCU, and gateway ECUs — are required as supplementary audit evidence. They cannot replace full-vehicle upgrade traceability logs. If a company submits only component ledgers without complete vehicle-level upgrade approval, testing, and release records, auditors issue major non-conformities.
Category 6 — Annual Emergency Drill Records
Hands-on drills covering all three scenarios — OTA upgrade failure, package tampering, version conflict — at least once per year. Written meeting minutes from a desktop exercise do not qualify. Complete archives with operation screenshots, system logs, and closed-loop disposal records are required.
For imported vehicle manufacturers: A full set of overseas UN R156 system documents and equivalence assessment application materials are mandatory prerequisites for auditors to evaluate equivalence. These are not optional supplementary files.
Phase 2: VTA Physical Vehicle Testing Documents
Full Vehicle Technical Documents
Complete vehicle technical datasheet; full ECU list including supplier information and software versions; whole-vehicle network topology diagram; software upgrade system architecture diagram; technical description of ECU communication interaction relationships. All of these are mandatory with no exemptions.
Upgrade Technical Specifications
Upgrade package structure specification covering full and differential incremental updates; flash writing method and verification mechanism for each ECU; detailed encryption and signature verification scheme specifying algorithm and key management; comprehensive failure rollback logic and extreme-condition disposal strategies; full end-user notification solution.
The notification solution needs to be concrete: complete screenshots of infotainment UI, full APP push copy, and SMS template content — with word-for-word identical wording across all three channels.
Two supplementary documents specific to China's domestic requirements that are frequently missed: mechanical interior door unlock hardware design specification and power-off safety state engineering drawings. Laboratories request these before test initiation. Delayed preparation directly pushes back test start dates.
Pre-verification vs. formal testing — a critical distinction: Simplified documentation is acceptable for preliminary pre-verification testing. For formal VTA testing that generates CCC-filing reports, full technical drawings and cloud platform protocol documents are mandatory. Many manufacturers clear pre-testing under simplified document standards and assume the full testing phase is effectively done. It is not. Missing documentation at the formal testing stage triggers supplementary requests and delays.
Sample Vehicle Requirements
The submitted prototype must match mass production specifications in ECU model numbers, software versions, and communication module configuration. Vehicles with OTA functionality also require a working cloud test environment with backend server configuration and communication protocol docking documents.
Notes on GB 44495 Concurrent Submission
GB 44495 and GB 44496 are two independent mandatory national standards. There is no statutory requirement to submit them simultaneously. MIIT vehicle announcement guidelines recommend batch submission with shared test prototypes to reduce costs — that is operational guidance, not law. Separate sequential filing is fully legal and will not result in announcement rejection. The claim that split filing constitutes non-compliance is incorrect.
Phase 3: CCC Application Documents
For Brand-New Vehicle Models
Original SUMS compliance audit report; original VTA physical vehicle test report; vehicle technical datasheet; software upgrade chapters extracted from the user manual; production consistency control plan including software upgrade control clauses.
Additional Documents for Facelift Stock Vehicles (Change Filing)
Vehicle change difference statement and change risk assessment report are both required. The new model document checklist alone is incomplete for change filing applications.
On SUMS audit reports specifically: Only reports issued by officially recognised audit bodies are statutorily valid for vehicle announcement and CCC filing. Third-party commercial SUMS system certification certificates are auxiliary commercial documents — they work for bidding and customer internal audits but cannot substitute the official audit report for statutory filing. Submitting a commercial certificate instead of the official audit report results in direct document rejection.
Four Vehicle Categories With Reduced or Zero Document Requirements
L-class motorcycles, factory-exclusive off-road special vehicles, and vehicles supporting only local offline flashing without OTA remote upgrade capability do not require the full SUMS plus VTA document suite. These categories are frequently overlooked. Preparing full compliance documentation for non-applicable vehicle types wastes substantial engineering time.
Vehicles with factory-locked ECU firmware and zero software flashing channels also fall outside GB 44496 scope entirely.
What Component Suppliers Actually Need to Prepare
TBOX, MCU, and other component suppliers are not required to build standalone SUMS systems or prepare independent compliance documentation sets. The required deliverables are firmware change ledgers and standardized upgrade schemes delivered to vehicle OEMs, which are incorporated into the OEM's unified SUMS framework.
Component suppliers that position themselves as primary certification applicants and draft full compliance documentation sets are wasting resources that the standard does not require of them.
On annual CoP obligations: Certificate issuance is not the end of documentation work. Annual CCC factory surveillance audits require updated full upgrade records and drill archives. Companies that treat documentation preparation as a one-time exercise for initial certification will fail subsequent annual audits.
Common Document Rejection Patterns
A few types of documentation failure show up repeatedly at file intake. Knowing them upfront saves the rework cycle.
Signature authority gaps. The software upgrade security management policy must carry a senior management signature with a visible signature page and effective date. Digital approvals without a dated signature page get rejected. Department-level signatures on the policy generate the same rejection — the standard explicitly requires senior management sign-off for this document and this document alone.
Generic org charts. The organisational chart must show the actual reporting chain for software upgrade management with named roles. A broad corporate org chart with department names only — "R&D Department" rather than "Software Upgrade Director, R&D Department" — does not meet the specificity requirement.
Emergency plan that covers only one scenario. The emergency response plan needs step-by-step disposal workflows for three distinct failure categories: OTA upgrade failure, tampered firmware packages, and cross-version software conflicts. Plans covering only the OTA failure case (the most common approach) get returned for incomplete scope.
Missing mechanical door documents for OTA-capable vehicles. Vehicles with any OTA remote upgrade functionality must include the mechanical interior door unlock hardware design specification and power-off safety state engineering drawings. These two documents are exclusively required under Chinese domestic regulations — they do not appear in UN R156 checklists. Overseas OEMs filing through a China subsidiary routinely miss both.
Translated-only documentation. System documents and procedure files submitted in English without certified Simplified Chinese translations are rejected at intake. Internal working copies can be in any language, but the statutory filing package must be in Simplified Chinese.
BlueAsia conducts full document pre-submission review for GB 44496 certification, verifying clause-by-clause alignment of system documents, pre-matching laboratory requirements for test materials, and checking CCC application packages to prevent repeated rework from returned incomplete files. For enquiries, contact BlueAsia Compliance Consultant: +86 13534225140 (Benson)
相关新闻
