DCC Export

calServer generates Digital Calibration Certificates (DCC) according to the specification of the Physikalisch-Technische Bundesanstalt (PTB), version 3.3.0. This section describes the technical implementation, the generation process, and the setup.

Basics

The DCC is a machine-readable XML format for calibration certificates, standardized by the PTB. It enables automated exchange of calibration data between laboratories and their customers. calServer implements:

• XML generation according to PTB DCC v3.3.0
• Embedding of the PDF calibration certificate as Base64 in the XML
• XSD validation of the generated XML
• Mapping of calServer database fields to DCC XML elements via a configurable JSON file

Architecture

The DCC generation comprises three components:

FrontendCalibration
        │
        ▼
DccXmlGenerator          ◄── dcc-mapping.json
        │
        ├── generate()          Build XML structure
        ├── embedPdf()          Embed PDF as Base64
        └── validate()          Validate against XSD
        │
        ▼
    DCC XML file

DccXmlGenerator

The class DccXmlGenerator (under httpdocs/protected/components/) is the central entry point. It:

• Reads the mapping configuration from dcc-mapping.json
• Loads the calibration record with relations (inventory, customer, results, standards)
• Creates a DOMDocument with the DCC namespaces
• Builds the administrativeData and measurementResults sections
• Optionally embeds the rendered PDF as Base64
• Validates the result against the PTB XSD schema

The key namespaces:

Namespace	URI
DCC	https://ptb.de/dcc
SI	https://ptb.de/si

DCC Mapping

The mapping between calServer fields and DCC XML elements is defined in a JSON file (dcc-mapping.json) that is delivered together with the report templates. This file describes which database fields are transferred to which XML elements.

The mapping is managed via the admin model AdminReportSetting:

• hasDccMapping() -- Checks whether a DCC mapping exists for a report template
• getDccMappingPath() -- Returns the path to the mapping file

ReportEngineManager

The class ReportEngineManager controls whether DCC generation is active:

// Check if DCC is globally enabled
Yii::app()->reportEngine->isDccPluginEnabled();

The feature flag enable_dcc_plugin is set system-wide in the application properties.

XML Structure

A generated DCC follows this structure:

<?xml version="1.0" encoding="UTF-8"?>
<dcc:digitalCalibrationCertificate
    xmlns:dcc="https://ptb.de/dcc"
    xmlns:si="https://ptb.de/si"
    schemaVersion="3.3.0">

    <dcc:administrativeData>
        <!-- Laboratory information, customer information,
             calibration object, calibration date -->
    </dcc:administrativeData>

    <dcc:measurementResults>
        <!-- Measurement results with SI units -->
    </dcc:measurementResults>

    <dcc:document>
        <!-- Embedded PDF (Base64) -->
    </dcc:document>
</dcc:digitalCalibrationCertificate>

refTypes

refType is the machine-readable anchor inside a DCC -- it is how a recipient finds the measured value, the standard, the measurement error. The XSD does not check it (refTypesType is a list of arbitrary strings); the binding reference is the DKD refType thesaurus (digilab.ptb.de/dkd/refType/vocab/). An invented identifier is therefore not a schema error but dead weight: no recipient can do anything with it, and a validation tool reports it as unknown.

The export writes these identifiers:

refType	Element	Meaning
basic_recalibrationDate	dcc:statement	date of the next calibration
basic_conformity	dcc:statement	conformity statement
basic_methodMeasurementUncertainty	dcc:usedMethod	uncertainty method (GUM, k = 2)
basic_calibrationMethod	dcc:usedMethod	calibration method of the laboratory
basic_temperature	dcc:influenceCondition	ambient temperature
basic_humidityRelative	dcc:influenceCondition	relative humidity
math_minimum / math_maximum	dcc:quantity	lower/upper bound of the influence condition
basic_referenceValue	dcc:quantity	value of the standard
basic_measuredValue	dcc:quantity	indicated value of the item
basic_measurementError	dcc:quantity	measurement error

Each one was checked against the thesaurus (state 2026-09-03). Replaced in the process: basic_recalibration -> basic_recalibrationDate, basic_uncertainty -> basic_methodMeasurementUncertainty and gp_method -> basic_calibrationMethod; the thesaurus has no gp_ namespace at all. gp_measuredQuantity on dcc:result was dropped without replacement -- the meaning sits on the dcc:quantity elements inside it. The min/max identifiers of the influence conditions used to be basic_temperatureMin and basic_humidityRelativeMin/-Max; which quantity is meant is already stated by the dcc:influenceCondition above them.

DccRefTypeVocabularyTest (httpdocs/protected/tests/) freezes the set and records where each identifier comes from; whoever adds one enters it there.

Own Identifiers

For the measurement conditions as free text the thesaurus has no term (basic_ambient describes the collecting node of ambient conditions, not a method). They therefore carry an own namespace and are explained in the certificate itself:

refType	Element	Meaning
calServer_measurementConditions	dcc:usedMethod	measurement conditions as free text (report variable)

dcc:administrativeData/dcc:refTypeDefinitions explains the identifier with namespace and link. The node only appears in a certificate that actually carries such an identifier -- refTypeDefinitionListType requires at least one entry.

An invented basic_... would look official without being official; a declared own identifier can be resolved by a recipient.

Generation Process

The complete workflow of a DCC generation:

1. The user triggers report generation for a calibration
2. The ReportEngineManager checks whether the DCC plugin is enabled
3. The report template is checked for an existing DCC mapping
4. The DccXmlGenerator is instantiated with the path to the mapping file
5. generate($ctag) loads the calibration data and generates the XML
6. embedPdf($pdfPath) embeds the rendered PDF report
7. validate() validates the XML against the XSD schema
8. The finished XML is saved and made available for download

Setup

Prerequisites

• calServer version with DCC support
• JasperReports template with associated dcc-mapping.json
• PTB XSD schema (optional, for validation)

Enable Feature Flag

The DCC plugin is enabled via the application properties:

Section: features > report_engine > enable_dcc_plugin = 1

Set Up Report Template

1. Upload the JasperReports template to the directory httpdocs/reports/calibrations/
2. Place the associated dcc-mapping.json in the same directory
3. Configure the report template under Administration > Report Management

Create Mapping File

The dcc-mapping.json defines the mapping of calServer fields to DCC XML elements. The file is created per report template and references the internal field names (C-series for calibration fields, I-series for inventory fields).

Languages

The DCC export supports German and English. The language selection is passed as a parameter when calling generate():

$generator = new DccXmlGenerator($mappingPath, $xsdPath);
$dom = $generator->generate($ctag, 'de'); // or 'en'

Troubleshooting

Problem	Cause	Solution
Failed to parse dcc-mapping.json	JSON file is malformed or missing	Check path and JSON syntax
Calibration not found	Invalid calibration ID	Check CTAG value
PDF file not found for DCC embedding	PDF was not generated	Check report generation, review Report Runner logs
XSD validation error	XML does not conform to the schema	Check mapping file and calibration data

Further Information

• Architecture -- Report Runner
• Data Model -- Calibrations
• PTB DCC Specification