What Is IVI Data? Initial Vehicle Information and XML

IVI means Initial Vehicle Information in electronic Certificate of Conformity workflows. It represents the initial vehicle dataset used for electronic conformity information. Here, IVI does not refer to an in-vehicle infotainment system. For manufacturer teams, the practical task is to turn approved vehicle information into the structured record required by the receiving service.

How IVI relates to an electronic CoC

An electronic CoC carries conformity information in a structured form. IVI specifications describe the message used for that information. The EUCARIS terminology guide distinguishes the initial dataset from Actual Vehicle Information, or AVI, used for subsequent datasets with possible changes. Avoid treating later vehicle changes as permission to silently overwrite the initial record.

For a manufacturer, it helps to separate three questions: which approved facts belong to the vehicle, how those facts map into the required message and what the receiving service reports after submission. One team may own the technical source while another operates the submission. Both need to refer to the same vehicle and the same released file.

What belongs in the preparation record?

Begin with the VIN, approval references and applicable technical characteristics for the vehicle being represented. The exact fields, value lists and conditions depend on the selected specification and vehicle scope. Use the relevant XSD together with its message documentation; a generic example file is not enough to establish all requirements for every vehicle category.

A working mapping sheet should identify the source of each value, its destination field, any unit conversion and the person responsible for resolving uncertainty. When a source is missing, flag the omission instead of inventing a plausible value. A file can appear complete while carrying the wrong mass, approval reference or variant information, so completeness must be reviewed separately from accuracy.

IVI 2.0 is more than a changed version label

EUCARIS describes IVI 2.0 as structurally different from the 1.x series. Treat a migration as a mapping and validation task. Select the specification accepted by the target service, review the changes that affect your records and generate representative samples. The EReg Topic Group XII resources provide the official starting point for IVI documentation.

Do not assume that replacing a namespace or version string converts an older file. Review the actual generated structure and the meaning of populated fields. Keep the mapping version with the validation result so that a later investigation can establish which rules produced the file. Our IVI 2.0 XML validation workflow covers the checks before release.

Why passing an XSD check is only one step

Schema validation checks whether the XML meets the structural constraints expressed by the selected XSD. It cannot establish every fact about the physical vehicle or prove that the selected approval record is the correct one. A useful review therefore also compares the output with its source and considers relationships between values. Any additional receiving-service rules must be assessed against that service’s documentation.

Consider a file containing a permitted numeric value taken from the wrong variant. A structural check may have no reason to reject it, yet the record is unsuitable for the intended vehicle. The correction belongs in the source selection or mapping logic. Editing only the final XML would leave the same problem waiting to recur when the next file is generated.

From validated XML to a receiving response

Once the record is approved for release, apply the signature or seal required by the selected route and retain the exact artifact sent. Follow the receiving service’s account and environment requirements. The eCoC XML signing guide explains how to frame the signing step; the NAP submission guide covers the handover and response.

Check the returned status before marking the vehicle record complete. Distinguish a connection failure, a validation rejection and a successful receiving response. If the status is uncertain, investigate before retrying blindly. A usable operating record includes the submitted version, attempt reference, response and the person responsible for the next action.

Build a pilot around representative vehicles

Choose samples that reflect the variation in your production data. Include different relevant configurations and, where applicable, stages of manufacture. Add a deliberately invalid example so that the team can verify whether an error is understandable and traceable. The objective is a repeatable process that operators can explain, including how to correct a record and resubmit it under the receiving service’s rules.