DCC-Export

calServer erzeugt Digitale Kalibrierscheine (DCC -- Digital Calibration Certificate) gemaess der Spezifikation der Physikalisch-Technischen Bundesanstalt (PTB), Version 3.3.0. Dieser Abschnitt beschreibt die technische Umsetzung, den Erzeugungsprozess und die Einrichtung.

Grundlagen

Der DCC ist ein maschinenlesbares XML-Format fuer Kalibrierscheine, das von der PTB standardisiert wird. Es ermoeglicht den automatisierten Austausch von Kalibrierdaten zwischen Laboren und deren Kunden. calServer implementiert:

• XML-Erzeugung nach PTB DCC v3.3.0
• Einbettung des PDF-Kalibrierscheins als Base64 im XML
• XSD-Validierung des erzeugten XML
• Mapping von calServer-Datenbankfeldern auf DCC-XML-Elemente ueber eine konfigurierbare JSON-Datei

Architektur

Die DCC-Erzeugung umfasst drei Komponenten:

FrontendCalibration
        │
        ▼
DccXmlGenerator          ◄── dcc-mapping.json
        │
        ├── generate()          XML-Struktur aufbauen
        ├── embedPdf()          PDF als Base64 einbetten
        └── validate()          Gegen XSD pruefen
        │
        ▼
    DCC-XML-Datei

DccXmlGenerator

Die Klasse DccXmlGenerator (unter httpdocs/protected/components/) ist der zentrale Einstiegspunkt. Sie:

• Liest die Mapping-Konfiguration aus dcc-mapping.json
• Laedt den Kalibrierdatensatz mit Relationen (Inventar, Kunde, Ergebnisse, Standards)
• Erzeugt ein DOMDocument mit den DCC-Namespaces
• Baut die Sektionen administrativeData und measurementResults auf
• Bettet optional das gerenderte PDF als Base64 ein
• Validiert das Ergebnis gegen das PTB-XSD-Schema

Die wesentlichen Namespaces:

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

DCC-Mapping

Das Mapping zwischen calServer-Feldern und DCC-XML-Elementen wird in einer JSON-Datei (dcc-mapping.json) definiert, die zusammen mit den Berichtsvorlagen ausgeliefert wird. Diese Datei beschreibt, welche Datenbank-Felder in welche XML-Elemente uebertragen werden.

Verwaltet wird das Mapping ueber das Admin-Model AdminReportSetting:

• hasDccMapping() -- Prueft, ob fuer eine Berichtsvorlage ein DCC-Mapping vorhanden ist
• getDccMappingPath() -- Gibt den Pfad zur Mapping-Datei zurueck

ReportEngineManager

Die Klasse ReportEngineManager steuert, ob die DCC-Erzeugung aktiv ist:

// Pruefen ob DCC global aktiviert ist
Yii::app()->reportEngine->isDccPluginEnabled();

Das Feature-Flag enable_dcc_plugin wird systemweit in den Anwendungseigenschaften gesetzt.

XML-Struktur

Ein erzeugter DCC folgt diesem Aufbau:

<?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>
        <!-- Laborinformationen, Kundeninformationen,
             Kalibrierobjekt, Kalibrierdatum -->
    </dcc:administrativeData>

    <dcc:measurementResults>
        <!-- Messergebnisse mit SI-Einheiten -->
    </dcc:measurementResults>

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

refTypes

refType ist die maschinenlesbare Sprungmarke im DCC -- daran findet ein Empfaenger den Messwert, das Normal, die Messabweichung. Die XSD prueft sie nicht (refTypesType ist eine Liste beliebiger Zeichenketten); verbindlich ist der refType-Thesaurus des DKD (digilab.ptb.de/dkd/refType/vocab/). Ein erfundener Bezeichner ist deshalb kein Schemafehler, sondern totes Gewicht: kein Empfaenger kann etwas damit anfangen, und ein Pruefwerkzeug meldet ihn als unbekannt.

Diese Marken schreibt der Export:

refType	Element	Bedeutung
basic_recalibrationDate	dcc:statement	Datum der naechsten Kalibrierung
basic_conformity	dcc:statement	Konformitaetsaussage
basic_methodMeasurementUncertainty	dcc:usedMethod	Verfahren zur Messunsicherheit (GUM, k = 2)
basic_calibrationMethod	dcc:usedMethod	Kalibrierverfahren des Labors
basic_temperature	dcc:influenceCondition	Umgebungstemperatur
basic_humidityRelative	dcc:influenceCondition	relative Luftfeuchte
math_minimum / math_maximum	dcc:quantity	untere/obere Grenze der Einflussbedingung
basic_referenceValue	dcc:quantity	Wert des Normals
basic_measuredValue	dcc:quantity	angezeigter Wert des Prueflings
basic_measurementError	dcc:quantity	Messabweichung

Jede davon ist gegen den Thesaurus geprueft (Stand 2026-09-03). Ersetzt wurden dabei basic_recalibration -> basic_recalibrationDate, basic_uncertainty -> basic_methodMeasurementUncertainty und gp_method -> basic_calibrationMethod; einen Namensraum gp_ fuehrt der Thesaurus gar nicht. gp_measuredQuantity am dcc:result ist ersatzlos entfallen -- die Bedeutung steckt an den dcc:quantity-Elementen darin. Die Min/Max-Marken der Einflussbedingungen hiessen frueher basic_temperatureMin und basic_humidityRelativeMin/-Max; welche Groesse gemeint ist, sagt bereits die dcc:influenceCondition darueber.

DccRefTypeVocabularyTest (httpdocs/protected/tests/) friert die Menge ein und haelt je Marke fest, woher sie kommt; wer eine hinzufuegt, traegt sie dort ein.

Eigene Marken

Fuer die Messbedingungen als Freitext fuehrt der Thesaurus keinen Begriff (basic_ambient beschreibt den Sammelknoten der Umgebungsbedingungen, nicht ein Verfahren). Sie tragen deshalb einen eigenen Namensraum und werden im Schein selbst erklaert:

refType	Element	Bedeutung
calServer_measurementConditions	dcc:usedMethod	Messbedingungen als Freitext (Report-Variable)

dcc:administrativeData/dcc:refTypeDefinitions erklaert die Marke mit Namensraum und Link. Der Knoten steht nur im Schein, wenn er eine solche Marke auch traegt -- refTypeDefinitionListType verlangt mindestens einen Eintrag.

Ein erfundenes basic_... saehe amtlich aus und waere keins; eine erklaerte eigene Marke kann ein Empfaenger aufloesen.

Erzeugungsprozess

Der vollstaendige Ablauf einer DCC-Erzeugung:

1. Der Benutzer loest die Berichtserzeugung fuer eine Kalibrierung aus
2. Der ReportEngineManager prueft, ob das DCC-Plugin aktiviert ist
3. Die Berichtsvorlage wird auf ein vorhandenes DCC-Mapping geprueft
4. Der DccXmlGenerator wird mit dem Pfad zur Mapping-Datei instanziiert
5. generate($ctag) laedt die Kalibrierdaten und erzeugt das XML
6. embedPdf($pdfPath) bettet den gerenderten PDF-Bericht ein
7. validate() prueft das XML gegen das XSD-Schema
8. Das fertige XML wird gespeichert und zum Download bereitgestellt

Einrichtung

Voraussetzungen

• calServer-Version mit DCC-Unterstuetzung
• JasperReports-Vorlage mit zugehoeriger dcc-mapping.json
• PTB-XSD-Schema (optional, fuer Validierung)

Feature-Flag aktivieren

Das DCC-Plugin wird ueber die Anwendungseigenschaften aktiviert:

Bereich: features > report_engine > enable_dcc_plugin = 1

Berichtsvorlage einrichten

1. Laden Sie die JasperReports-Vorlage in das Verzeichnis httpdocs/reports/calibrations/ hoch
2. Legen Sie die zugehoerige dcc-mapping.json im selben Verzeichnis ab
3. Konfigurieren Sie die Berichtsvorlage unter Administration > Berichtsverwaltung

Mapping-Datei erstellen

Die dcc-mapping.json definiert die Zuordnung der calServer-Felder zu DCC-XML-Elementen. Die Datei wird pro Berichtsvorlage angelegt und referenziert die internen Feldnamen (C-Serie fuer Kalibrierfelder, I-Serie fuer Inventarfelder).

Sprachen

Der DCC-Export unterstuetzt Deutsch und Englisch. Die Sprachauswahl wird beim Aufruf von generate() als Parameter uebergeben:

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

Fehlerbehebung

Problem	Ursache	Loesung
Failed to parse dcc-mapping.json	JSON-Datei fehlerhaft oder nicht vorhanden	Pfad und JSON-Syntax pruefen
Calibration not found	Ungueltige Kalibrier-ID	CTAG-Wert pruefen
PDF file not found for DCC embedding	PDF wurde nicht erzeugt	Berichtserzeugung pruefen, Report-Runner-Logs einsehen
XSD-Validierungsfehler	XML entspricht nicht dem Schema	Mapping-Datei und Kalibrierdaten pruefen

Weitergehende Informationen

• Architektur -- Report-Runner
• Datenmodell -- Kalibrierungen
• PTB DCC-Spezifikation