Prozedurvorlagen¶

Prozedurvorlagen sind versionierte Dokumente eines Kalibrierablaufs. Sie werden im Tab „Vorlagen" der Prozedur-Detailseite verwaltet und können in Kalibrierungen instanziiert werden.

Konzept¶

Eine Vorlage trägt entweder eine hochgeladene Datei (z. B. eine Kalibrieranweisung als PDF) oder einen serialisierten Prüfablauf im Format calserver.procedure (JSON), der aus den Prüfschritten einer Kalibrierung erzeugt wurde. Jede Vorlage durchläuft den Lebenszyklus Entwurf → Genehmigt → Freigegeben.

Vorlagenart und Messwertaufnahme¶

Die Art einer Vorlage bestimmt, welche Messwertaufnahme calServer an der Kalibrierung anbietet. Sie wird nicht gepflegt, sondern aus dem Dateityp abgeleitet:

Art	Dateitypen	Angebotene Messwertaufnahme
Eigene Messwertvorlage	`json` (`calserver.procedure`)	Interne Messwert-Runtime („Messwertaufnahme starten")
MET/CAL-Prozedur	`pxe`	„In MET/CAL starten" über das Startkommando des Dateityps
Excel-Messwertaufnahme	`xlsx`, `xlsm`, `xls`, `csv`	Excel-Bogen öffnen (Startkommando), sonst Download
Sonstige Vorlage	`pdf`, `doc(x)`, `md`, alles Übrige	Anleitung öffnen; Messwerte werden von Hand erfasst

Die Zuordnung Endung→Art liegt in config/procedure.php und lässt sich pro Installation erweitern (z. B. eine weitere MET/CAL-Endung).

Wo die Art auftaucht¶

Im Vorlagen-Tab der Prozedur steht die Art in der Spalte „Art"; der Dateityp selbst hängt als Hinweis am Eintrag.
Schritte bearbeiten gibt es nur bei einer eigenen Messwertvorlage — MET/CAL-Prozeduren, Excel-Bögen und Anleitungen tragen keinen editierbaren Ablauf.
„Vorlage laden" im Prüfschritte-Tab bietet ebenfalls nur eigene Messwertvorlagen an. Wird eine andere Art über die API geschickt, antwortet sie mit 422 und nennt die Art.

Was am Kalibrierschein passiert¶

Der Knopf oben rechts an der Kalibrierung zeigt eine vom System bestimmte Aktion. Sie ergibt sich aus dieser Kette:

Standardprüfprozedur des Geräts; hat das Gerät keine, die des Gerätetyps.
Deren maßgebliche Vorlage: die neueste freigegebene, ersatzweise die neueste überhaupt.
Deren Art — daraus folgt die Aktion aus der Tabelle oben.

Der Tooltip nennt Prozedur, Herkunft (Gerät oder Gerätetyp), Art und Version. Alternativen (Prüfablauf fortsetzen, Vorlage herunterladen, Messwerte von Hand erfassen) hängen im Menü daneben.

Steht eine Aktion nicht bereit, bleibt sie sichtbar und nennt beim Klick den Grund — etwa „noch nicht freigegeben" oder „für den Dateityp ist kein Startkommando (File Link) hinterlegt". Ein externer Start setzt immer eine freigegebene Vorlage voraus.

Ohne zugeordnete Standardprüfprozedur bleibt die manuelle Erfassung; hat die Kalibrierung bereits Prüfschritte, wird stattdessen das Fortsetzen des Prüfablaufs angeboten.

Startkommando für MET/CAL (File Link)¶

Das Startkommando je Dateityp wird in der Dateiverwaltung als File Link gepflegt. Für .pxe-Prozeduren startet es die MET/CAL Runtime über deren mcruntime:-URL-Protokoll (der MET/CAL-Client registriert es bei der Installation). Empfohlenes Kommando bei eingerichteter MET/TEAM- bzw. MET/CONNECT-Anbindung:

mcruntime: -w {nCallSheetUID} -locale "de-DE"

Das kommt ohne lokalen Dateipfad aus und ist damit benutzerunabhängig: calServer schreibt beim Anlegen des CallSheets die Prozedur-Referenz (nProcedureUID) mit, und die Runtime öffnet über den Serviceauftrag die hinterlegte Prozedur.

Voraussetzung: die MET/CAL-Prozedur muss vorhanden und benannt sein

Damit MET/CAL Gerät und Kalibrierung wirklich vorbelegt, müssen zwei Dinge stimmen — sonst öffnet die Runtime ein leeres Fenster:

In MET/TEAM gibt es eine Prozedur, deren Prozedurname die Instrument Line der kompilierten MET/CAL-Prozedur ist und deren Kategorie „MET/CAL" lautet. Wo die kompilierte Prozedur selbst liegt, hängt vom MET/CAL-Stand ab: klassisch im Prozedurverzeichnis der Workstation (procdir in der metcal.ini), auf neueren Ständen als Datei in MET/TEAM an der Prozedur. Neuere Runtimes starten nur noch, was in MET/TEAM gespeichert ist.
In calServer trägt die Prüfprozedur diesen Namen im Feld „MET/CAL-Prozedur" (Prozedur-Detailseite, Abschnitt „MET/CAL-Start"). Die Auswahl liest die echte Prozedurliste aus MET/TEAM und meldet, wenn ein gepflegter Name dort unbekannt ist.

Von sich aus legt calServer in MET/TEAM keine Prozeduren an. Fehlt die Referenz oder kennt MET/TEAM den Namen nicht, entsteht das CallSheet trotzdem — der Start meldet dann aber im Klartext, dass MET/CAL nichts vorbelegen kann. Der calServer-Anzeigename der Prüfprozedur spielt dabei keine Rolle; er darf ein ganz anderer sein.

Auf ausdrückliche Anweisung überträgt calServer eine freigegebene .pxe-Vorlage dorthin: die Datei landet in MET/TEAM, und die Prozedur darüber zeigt auf sie. Der Knopf dafür steht auf der Prozedur-Detailseite im Abschnitt „MET/CAL-Start", direkt unter dem Feld „MET/CAL-Prozedur"; für viele Prozeduren auf einmal gibt es den Befehl procedures:transfer-to-metteam (siehe MET/TEAM-Administration). War das Feld noch leer, trägt die Übertragung den verwendeten Namen dort ein — sonst fände der Serviceauftrag die neue Prozedur nicht. Was dabei entsteht, ist eine echte, startbare Prozedur; eine leere Zeile auf einen geratenen Namen legt calServer weiterhin nicht an.

Ist die Prozedur in MET/CAL nicht eingerichtet — etwa weil sie bisher nur als hochgeladene .pxe in calServer liegt —, hilft kein gepflegter Name: es gibt drüben nichts, worauf er zeigen könnte. Zwei Wege führen dann weiter: die Vorlage nach MET/TEAM übertragen (oben) oder die Datei der Runtime direkt übergeben. Der zweite Weg trägt nur auf Ständen, die -x noch annehmen — neuere tun das nicht mehr. Mit MET/TEAM-Anbindung zusammen mit dem Serviceauftrag:

mcruntime: -x "{documentfile}" -w {nCallSheetUID} -locale "de-DE"

Ohne Anbindung genügt der Dateipfad allein:

mcruntime: -x "{documentfile}" -locale "de-DE"

Beide -x-Formen laden die Vorlage vor dem Start in den Download-Ordner des Benutzers — sie hängen am Profilfeld „Standard-Download-Ordner" und sind damit benutzerabhängig. Dafür funktionieren sie auch dann, wenn in MET/CAL nichts eingerichtet ist. Fehlt die freigegebene Datei im Dokumentenspeicher, lehnt calServer den Start ab und sagt das, statt MET/CAL auf eine Datei zu verweisen, die es nicht gibt.

Der -x-Weg trägt nicht auf jedem MET/CAL-Stand

Er übergibt eine Datei aus dem Dateisystem. Aus dem Feld ist berichtet (28.08.2026), dass neuere MET/CAL-Stände das nicht mehr annehmen und nur noch starten, was in MET/TEAM gespeichert ist — die PXE muss dort an der Prozedur hängen, und die verwendete Kalibrierprozedur des Serviceauftrags muss darauf zeigen.

Dass MET/TEAM Prozedurdateien überhaupt speichern kann, ist belegt: Procedures.nProcedureFileUID zeigt auf Files.nFileUID, und Files.iFile trägt den Dateiinhalt. Geprüft gegen die Fluke-Beispieldatenbanken beider Produkte.

calServer überträgt die PXE noch nicht dorthin. Solange das so ist, bleibt auf betroffenen Ständen nur, die Prozedur in MET/CAL bzw. MET/TEAM von Hand einzurichten. Der Weg dahin steht in ADR 2026-08-28 („Die PXE-Vorlage ist die MET/TEAM-Prozedurdatei").

Pfad-Platzhalter gehören in Anführungszeichen

{documentfile}, {documentpath}, {standarddownloadfolder} und {downloadurl} setzt calServer roh ein, damit sie ihre eigene Schreibweise behalten — die Anführungszeichen gehören deshalb ins Kommando, so wie oben gezeigt. Nur Flag-Werte wie {nCallSheetUID} quotet calServer selbst.

Der erzeugte Dateiname enthält keine Leerzeichen (aus „Fluke 179 DMM" wird Fluke_179_DMM_<zeitstempel>.pxe) — sonst zerfiele ein unquotiertes -f {documentfilename} in mehrere Argumente.

Die Parameter der Runtime (aus der MET/TEAM-Integration ermittelt):

Parameter	Wert	Bedeutung
`-x "<pfad>"`	vollständiger lokaler Pfad inkl. Dateiname und `.pxe`	startet die Vorauswahl mit dieser Prozedurdatei
`-w "<uid>"`	CallSheet-UID (`CallSheets.nCallSheetUID`)	öffnet den Serviceauftrag; calServer legt das CallSheet bei Bedarf nach Rückfrage per Sync an
`-a "<uid>"`	Asset-UID (`Assets.nAssetUID`)	Vorauswahl des Geräts (in der Praxis unzuverlässig)
`-puid "<uid>"`	MET/TEAM-Prozedur-ID	Prozedur aus der MET/TEAM-Einrichtung statt Dateipfad
`-locale "<code>"`	z. B. `de-DE`	Sprache der Runtime

Platzhalter, die calServer beim Start füllt:

{nCallSheetUID} — erzwingt ein MET/TEAM-CallSheet (vorhandenes wird genutzt, sonst Rückfrage und Anlage per Sync, inklusive Prozedur-Referenz, sofern eine gepflegt und in MET/TEAM auffindbar ist — siehe Kasten oben). Flag-Werte setzt calServer automatisch in Anführungszeichen; {documentfile} braucht sie im Kommando, wie oben gezeigt.
{documentfile} — Standard-Download-Ordner des Benutzers + eindeutiger Dateiname (<vorlagenname>_<zeitstempel>.pxe). calServer lädt die freigegebene Vorlage vor dem Start unter genau diesem Namen über die API herunter; der Standard-Download-Ordner im Benutzerprofil muss dafür dem Download-Ordner des Browsers entsprechen (z. B. C:\Users\<name>\Downloads).
{documentfilename}, {documentpath}, {standarddownloadfolder} — die Bestandteile einzeln.
{CTAG}/{UUID} — Kalibrierungs-ID bzw. Asset-UID, {api_token} — API-Schlüssel des Benutzers.
{downloadurl} — API-URL der Vorlage. Für einen Aufruf durch MET/CAL derzeit nicht nutzbar: die Route verlangt eine Anmeldung über Kopfzeilen, und die kann die Runtime nicht mitschicken; der Abruf endet mit 401. Wer die Datei braucht, nimmt den -x-Weg oben, bei dem calServer sie vorab herunterlädt.

Prüfprozedur für eine einzelne Kalibrierung wechseln¶

Die Zuordnung am Gerät bzw. Gerätetyp ist eine Vorgabe, kein Zwang. Über „Prüfprozedur wechseln …" im Menü des Startknopfs läuft diese eine Kalibrierung mit einer anderen Prozedur:

Die Auswahl zeigt, was am Gerät und am Gerätetyp zugewiesen ist, mit Herkunft. Jede dem Gerätetyp zugeordnete Prozedur steht dort — auch eine ohne Standardmarkierung (Stern) und auch eine, die noch aus V1 stammt.
Die Standardprüfprozedur des Geräts bleibt unverändert — kommende Kalibrierungen sind nicht betroffen.
Bereits erfasste Prüfschritte bleiben unangetastet. Umstellen wählt, es lädt nicht. Wer die Schritte der neuen Prozedur übernehmen will, nutzt im Prüfschritte-Tab „Vorlage laden" — die Aktion ersetzt bestehende Schritte ausdrücklich.
„Standard wiederherstellen" nimmt die Wahl zurück; die Kalibrierung folgt wieder Gerät bzw. Gerätetyp.

Die Kette lautet damit: Kalibrierung → Gerät → Gerätetyp.

Prüfschritte beim Start¶

Startet eine noch leere Kalibrierung die interne Messwertaufnahme, stellt calServer ihr die Prüfschritte der maßgeblichen Vorlage — sonst öffnete der Prüfablauf ohne Schritte. Eine Meldung nennt Anzahl, Vorlage und Version.

Trägt die Kalibrierung bereits irgendeinen Prüfschritt, passiert nichts: erfasste Arbeit wird nie überschrieben.

Der Lauf merkt sich, aus welcher Vorlagenversion er gestartet ist.

Der Plan ist auch direkt abrufbar, ebenso der Wechsel:

GET    /api/v2/calibrations/{ctag}/capture-options
PUT    /api/v2/calibrations/{ctag}/procedure     # { "procedure_id": "..." }
DELETE /api/v2/calibrations/{ctag}/procedure     # zurück zur Vorgabe

Versionierung¶

Aktion	Effekt
Hochladen	Neue Vorlage mit Version 0.1 (Entwurf)
Neue Version	Minor-Erhöhung (0.1 → 0.2 → …); die vorherige Version verliert den „aktuell"-Status
Genehmigen	Major-Sprung (z. B. 0.3 → 1.0), Status Genehmigt; die genehmigte Datei wird unveränderlich übernommen. Bei einem Prüfplan mit Schritten zeigt der Dialog vorher die Änderungen am Skript seit der letzten Genehmigung (calScript)
Freigeben	Status Freigegeben (nur für genehmigte Versionen möglich)

Die Versionshistorie jeder Vorlage ist über das Historien-Symbol einsehbar; jede Version bleibt einzeln herunterladbar.

Name und Zuordnung ändern¶

Name und Prozedur einer Vorlage sind nachträglich änderbar — im Vorlagen-Tab der Prozedur ebenso wie in der übergreifenden Liste unter Prozeduren → Prüfpläne:

Symbol	Aktion	Wirkung
Etikett (`Umbenennen`)	Namen ändern	Gilt für alle Versionen der Vorlage; die abgelegten Dateien behalten ihren Dateinamen
Kette (`Zuordnen`)	Prozedur setzen, wechseln oder aufheben	Die ganze Versionskette wechselt mit; die Prüfschritte bleiben unverändert

Beides gilt für jede Vorlagenart, nicht nur für eigene Messwertvorlagen: auch ein hochgeladenes PDF trägt einen Namen, und der stammt sonst ungefragt aus dem Dateinamen.

Warum das zählt: Ein importierter Prüfplan und einer, der aus einer Kalibrierung gesichert wurde, kommen ohne Prozedur an und stehen in der Liste als „nicht zugeordnet". Ohne Zuordnung findet die Messwertaufnahme sie nicht. Über den Knopf in der Spalte „Prozedur" bzw. das Ketten-Symbol bekommen sie ihre Prozedur, ohne dass man sie löschen und neu anlegen müsste — was die Versionshistorie kosten würde.

Der umgekehrte Weg steht im Vorlagen-Tab der Prozedur: „Vorhandenen zuordnen" listet alle Prüfpläne, die nicht zu dieser Prozedur gehören, und hängt den gewählten hierher um. Hängt er noch an einer anderen Prozedur, sagt die Liste das vorher.

Einen neuen Prüfplan anlegen¶

Drei Wege führen zu einem neuen Prüfplan:

Ort	Aktion	Prozedur
Prozeduren → Prüfpläne	„Prüfplan erstellen"	Optional im Dialog wählbar; leer lassen ist erlaubt
Prozeduren → Prüfpläne	„Importieren"	Keine — der Plan kommt als „nicht zugeordnet" an
Vorlagen-Tab einer Prozedur	„Manuell erstellen"	Die Prozedur, in der man steht

Ein Prüfplan braucht keine Prozedur, um zu entstehen. Das ist Absicht: Wer einen Plan schreibt, weiß nicht immer schon, an welcher Prozedur er hängen soll, und ein Import weiß es nie. Ein Plan ohne Prozedur steht in der Liste als „nicht zugeordnet" und wird über das Ketten-Symbol eingehängt, wenn es soweit ist.

Zum Ausführen braucht es die Zuordnung dann allerdings: Die Messwertaufnahme findet einen Prüfplan über die Standardprüfprozedur des Geräts bzw. Gerätetyps, und ohne Prozedur steht er in keiner dieser Ketten.

Prüfplan als Paket teilen (ZIP)¶

Neben dem Export der nackten Prüfplan-Datei (JSON) gibt es für eigene Messwertvorlagen den Paket-Export: ein ZIP im Format calserver.procedure-package mit allem, was zum Plan gehört.

manifest.json        Manifest: Dateiliste mit SHA-256-Prüfsumme je Eintrag
README.md            Beschreibung (vorhandene Anlage oder generiertes Gerüst)
procedure.json       der Prüfplan, byte-identisch zur exportierten Version
images/…             Bilder (Anschlussbilder, Messanleitungen), optional
docs/…               Dokumente (Herstellerspezifikationen etc.), optional

Schritt-Bilder: Seit Dokumentversion 3 darf jeder Schritt in procedure.json ein Feld images tragen — eine Liste von Basenamen aus dem images/-Ordner des Pakets. Die Messwertaufnahme zeigt diese Bilder direkt am Schritt an (Anschlussbild am Gruppenkopf, Messanleitung oder Testbild am Prüfschritt), und auch der Probelauf im Prüfplan-Editor zeigt sie — eine importierte Vorlage lässt sich also samt Bildern begutachten, bevor sie je in eine Kalibrierung geladen wurde. Die Bilddateien selbst hängen als Anlagen am Prüfplan; der Schritt referenziert sie nur namentlich.

Skript als Quelle: Seit Dokumentversion 4 trägt procedure.json das Feld script mit dem Prüfplan als calScript. Das Skript ist die Quelle, test_steps sein Kompilat; der Export nimmt beides mit, der Import liest auch ältere Dokumente ohne Skript und leitet es beim nächsten Speichern ab.

Das Manifest macht das Paket revisionssicher: Jeder Eintrag steht mit Prüfsumme und Größe darin, und der Import lehnt ein Paket ab, dessen Inhalt vom Manifest abweicht — in beide Richtungen. Zusätzlich trägt das Manifest die Revisionslage der exportierten Version (plan: Major, Minor, Freigabestand) und die Formatversion des Pakets.

Beim Import (derselbe „Importieren"-Knopf, die Endung .zip entscheidet) entsteht immer eine neue Vorlage mit Version 0.1 — der Freigabestand des Quellsystems wird nie übernommen, nur als Hinweis angezeigt. Bilder und Dokumente aus dem Paket landen als Anlagen (Dokumentenverwaltung, Typ „Prüfplan-Anlage") am neuen Prüfplan; ein erneuter Paket-Export nimmt sie wieder mit.

Fertige Beispiel-Pakete (Fluke 23, Messschieber 150 mm) stehen auf der calServer-Reports-Download-Seite in der Kategorie „Prüfpläne" bereit; das maschinenlesbare Schema des Manifests liegt unter https://calhelp.github.io/calServer-reports/schema/procedure-package.schema.json.

Schritt-Editor¶

Über „Prüfplan erstellen", „Manuell erstellen" bzw. das Stift-Symbol einer Vorlage öffnet sich der Schritt-Editor als eigene Seite (/procedure/templates/new bzw. /procedure/templates/{id}/steps), nicht mehr als Popup; die Leiste mit „Speichern“ bleibt unten stehen. Wer die Seite mit ungespeicherten Änderungen verlässt, wird gefragt. Er kennt drei Ansichten, umschaltbar oben rechts; die Wahl wird pro Benutzer gemerkt:

Tabelle (Standard): eine Zeile je Messpunkt, Zellen direkt editierbar. Die Messspalten folgen MET/CAL: Range | Soll | Modifier | Toleranz, daneben berechnet Untergrenze, Obergrenze, Ablesungen und TAR. Tab übernimmt und springt zur nächsten Zelle, am Zeilenende in die nächste Zeile. Zeilen lassen sich am Griff ganz links umsortieren. Ein Klick auf eine Zeile zeigt ihre Felder im Seitenpanel rechts, mit den Reitern Einstellung und Anweisung; unter etwa 1280 px Breite kommt es als Schublade von rechts. Wer lieber aufklappt, schaltet das Panel mit dem Knopf neben dem Ansichtsumschalter ab; dann klappt der Pfeil rechts eine Detailzeile auf. Unter der Toleranz steht ein Grenzbalken mit Band und Guard Band, so wie die Erfassung ihn zeigt, und die Spalte Ablesungen zeigt bei Wiederholmessungen so viele leere Kästchen, wie eingegeben werden. Am Kopf einer Gruppe fügt eine Schnellleiste Messpunkt, Ja/Nein, Frage, Bewertung, Meldung oder eine Messpunktreihe am Ende dieser Gruppe ein. Ein leerer Plan bietet statt nur einer leeren Zeile drei Wege: erste Gruppe anlegen, MET/CAL importieren, KI-Entwurf.
Karten: ein aufklappbarer Block je Schritt mit dem vollständigen Feldsatz.

Nennt ein Punkt eine Rolle als Quelle oder Referenz (source cal, ref device dmm), steht über Tabelle und Karten die Karte Normale des Plans. Dort wählst du je Rolle den vorgesehenen Gerätetyp. Aus dessen Spezifikation (in ihrer Standardoption) rechnet die Spalte TAR dann mit der Genauigkeit des Normals (Spanne geteilt durch die doppelte Genauigkeit, wie MET/CAL) und zeigt darunter den geschätzten TUR aus Genauigkeit und Auflösung. Geschätzt, weil die Streuung der Wiederholungen und die CMC erst in der Prüfung bekannt sind. Ohne Gerätetyp bleibt es beim TAR aus der Unsicherheit des Schritts. Im Skript steht die Wahl als standard cal "…", siehe calScript. - Skript: derselbe Plan als calScript-Text, siehe dort.

Tastatur in Tabelle und Karten: Strg+Enter fügt einen Schritt unter der Zeile ein, in der der Cursor steht (der Knopf „Schritt hinzufügen" hängt am Ende an), Strg+D dupliziert die Zeile, Alt+↑/↓ verschiebt sie, Strg+S speichert. In der Tabelle hängt Tab in der letzten Zelle der letzten Zeile einen neuen Schritt an. Alle Kürzel stehen im Hilfe-Dialog unter „Tastatur".

Nicht zutreffende Felder werden ausgeblendet statt leer angeboten: ein Header-Schritt hat nur Beschreibung und Anweisung, ein Rating-Schritt statt der Toleranz ein Bewertungsraster. Vorhandene Werte bleiben beim Typwechsel erhalten.

Spezifikation eingeben wie im Datenblatt¶

Soll nimmt Zahl und Einheit in einer Zelle: 2.000 V, 570 mV, -0.5 µA. Vorsatz und Einheit landen in ihren Feldern; gleichen sie denen der Gruppe, bleibt die Gruppe ihre Quelle.
Auflösung kommt aus der Schreibweise: 2.000 zeigt in 0.001 an, Range 600.0 in 0.1, es gilt die feinere Stelle. Eine Ganzzahl ohne Punkt legt nichts fest. Wer die Auflösung in der Detailzeile von Hand setzt, behält sie; danach folgt sie der Schreibweise nicht mehr.
Toleranz nimmt Datenblatt- und MET/CAL-Form und speichert die calServer-Form: 0.05% + 3 dgt wird 0.05% 3D, 50 ppm wird 0.005%, 10 ppm r wird 0.001/, 0.003U bleibt, 3 mV an einem Schritt in V wird 0.003U.
Modifier ist die zweite Größe des Punkts wie MOD1 in MET/CAL (Frequenz, Anschluss), Ablesungen die Zahl der Wiederholungen.
Die Grenzen stehen in den Stellen der Auflösung und sind zum Sollwert hin gerundet, wie die Erfassung sie ablegt.
Den Bezug muss niemand wählen: ein neuer Punkt liest den Prüfling ab (UUT INDICATED), % gilt vom Ablesewert. Nur wenn das Normal misst und der Prüfling den Sollwert ausgibt, stellt man in der Detailzeile auf NOMINAL um. Dann gilt % wie in MET/CAL vom Sollwert, und +/- heißen weiter „der Prüfling darf so weit hoch/niedrig liegen“: das Normal darf dann entsprechend niedrig/hoch messen.

Felder¶

Feld	Bedeutung
Schritt-Nr.	Nummer im Kalibrierschein (z. B. `1.1`). Die Ausführungsreihenfolge ergibt sich aus der Zeilenposition, nicht aus diesem Feld.
Typ	Messung (`Manual Test`: Messung oder Ja/Nein), Bewertung (`Rating`: 1 bis 5), Gruppe (`Header`: Abschnitt mit Vorgaben), Meldung / Kommentar (`Message` / `Comment`: Hinweistext). Gespeichert wird der Code in Klammern.
Beschreibung	Überschrift des Schritts im Ausführungs-Wizard und im Kalibrierschein.
Anweisung	Formatierte Arbeitsanweisung, wird dem Prüfer während der Ausführung angezeigt.
Auswertung	Ergebnistyp und Toleranzbezug (siehe unten).
Sollwert / Vorsatz / Einheit	Nominalwert mit SI-Vorsatz (`m`, `k`, `µ` …) und Einheit; in der Tabelle eine Zelle („Soll“).
Modifier	Zweite Größe des Punkts (MOD1 in MET/CAL), wird nicht bewertet.
Ablesungen	Wiederholungen je Punkt; bewertet wird der Mittelwert.
Toleranz	Erlaubte Abweichung, siehe Legende.
Bereich	Messbereich des Prüflings; Bezug für Toleranzterme mit `/`.
Auflösung	Ein Digit des Prüflings; Bezug für Toleranzterme mit `D` und für die Stellen der Grenzen. Kommt aus der Schreibweise von Soll und Range.
Unsicherheit	Erweiterte Messunsicherheit; bildet das Guard Band.

Auswertung (`config`)¶

Der Code bestimmt, was die Messwertaufnahme mit dem Schritt macht (MET/CAL-Erbe, siehe auch das MET/CAL-Wiki):

NUMERIC,NOMINAL bzw. NUMERIC,UUT INDICATED — Messpunkt: die Messwertberechnung läuft (Grenzen, Toleranzausnutzung, Guard Band). NOMINAL = der Sollwert ist die Referenz, UUT INDICATED = die Anzeige des Prüflings.
NUMERIC,REFERENCE — Messpunkt mit mitmessendem Normal (calScript ref device|manual|camera <rolle>): die Grenzen liegen um die Ablesung des Normals, die Erfassung fragt sie neben dem Wert des Prüflings ab; ohne sie gibt es kein Urteil.
TEXT(Y=PASS) — Ja/Nein-Bestätigung: der Prüfer bestätigt den Schritt (Sichtprüfung, Funktionskontrolle), Ja gilt als bestanden. TEXT(N=PASS) kehrt die Richtung um (Nein = bestanden, z. B. „Fehlerbild sichtbar?").
leer — reiner Hinweis, keine Interaktion.

Achtung: Ein Manual Test ganz ohne Auswertung ist in der Messwertaufnahme ein toter Schritt — weder messbar noch bestätigbar. Der Editor warnt in diesem Fall; für eine Sichtprüfung gehört TEXT(Y=PASS) gesetzt.

Der Editor bietet die Angaben als Auswahlfelder an; ein Rohwert aus einer MET/CAL-Vorlage, der sich nicht darauf abbilden lässt, bleibt als Text erhalten und wird unverändert gespeichert.

Abschnitte mit Vorgaben (Vererbung)¶

Ein Schritt vom Typ Überschrift (Header) gliedert den Ablauf nicht nur optisch — er kann auch Vorgaben für seinen Abschnitt tragen. Alle Punkte bis zur nächsten Überschrift erben diese Werte überall dort, wo ihr eigenes Feld leer ist; ein Punkt mit eigenem Wert behält ihn.

Das spart die Hauptarbeit einer typischen Vorlage: Unsicherheit, Einheit, Bereich, Auflösung und Toleranz wiederholen sich über Dutzende Zeilen und mussten bisher in jeder einzelnen gepflegt werden.

Vorgabe	Wirkt auf
Unsicherheit	`uncertainty` jedes Punkts
Vorsatz, Einheit	`test_value_p`, `test_value_u`
Bereich, Auflösung	`range`, `resolution`
Toleranz	`tolerance`
Auswertung	`config`
k, Entscheidungsregel	nichts — siehe unten

Unsicherheit ist der wichtigste Wert

Die vier Konformitätszonen (Guard Band) entstehen nur, wenn ein Schritt eine Unsicherheit trägt. Einmal pro Abschnitt gesetzt, gilt sie für alle Punkte darunter — das ist der einfachste Weg zu einer Guard-Band-Bewertung.

k und Entscheidungsregel werden mitgeführt, aber nicht ausgewertet. Sie dokumentieren, warum die Unsicherheit so gewählt ist, und haben bewusst kein Zielfeld im Prüfschritt. Sie stehen in der Vorlage und bleiben dort.

Der Editor zeigt geerbte Werte als grauen Platzhalter („erbt: 0,01") bzw. kursiv in der Tabelle, damit leer und geerbt unterscheidbar bleiben. Am Abschnittskopf steht, auf wie viele Punkte eine Änderung wirkt.

Beim Laden wird eingefroren

Die Vererbung lebt nur in der Vorlage. Sobald eine Vorlage in eine Kalibrierung geladen wird — von Hand oder automatisch beim Start —, werden die effektiven Werte fest in die Prüfschritte geschrieben. Die Kalibrierung kennt danach keine Abschnittsvorgaben mehr, und der Prüfschritte-Editor einer Kalibrierung zeigt sie folgerichtig nicht an.

Umgekehrt heißt das: „Als Vorlage speichern" aus einer Kalibrierung erzeugt eine Vorlage ohne Abschnittsvorgaben. Das ist kein Verlust, sondern die Folge des Einfrierens — die Werte stehen dann eben an jedem Punkt.

Vorlagen ohne Abschnittsvorgaben (alle bisherigen) verhalten sich unverändert.

Toleranz-Syntax¶

Mehrere Terme werden durch Leerzeichen getrennt und addiert. Das Suffix bestimmt die Bezugsgröße:

Suffix	Bezug	Beispiel
`%`	Prozent vom Messwert (bei `NOMINAL` vom Sollwert)	`0.5%`
`/`	Prozent vom Bereich; ohne Bereich vom Sollwert	`0.1/`
`U`	absoluter Betrag in der Einheit	`2U`
`D`	Vielfaches der Auflösung (Digits)	`3D`

0.5% 2D ergibt also 0,5 % vom Messwert plus 2 Digits. Ohne Vorzeichen gilt ein Term symmetrisch; ein führendes + begrenzt ihn auf die obere, ein - auf die untere Grenze.

% bezieht sich auf den gemessenen Wert und löst sich deshalb erst bei der Messung auf — ein %-Term funktioniert auch ohne Sollwert in der Vorlage. D liest die Auflösung aus der Vorlage, / den Bereich; hat der Schritt keinen Bereich (ein Geber hat keinen, range ist kein Pflichtfeld), rechnet / vom Sollwert. Fehlt die Bezugsgröße ganz, rechnet der Term dauerhaft als 0. Der Editor blockiert deshalb das Speichern in genau diesen Fällen.

MET/CAL-Grenzen

MET/CAL verarbeitet höchstens drei Terme und 13 Zeichen. calServer rechnet längere Toleranzen korrekt, aber ein Rundlauf über MET/CAL verliert den Rest. Der Editor warnt, ohne zu blockieren.

Bei Rating-Schritten trägt dasselbe Feld ein Bewertungsraster in der Schreibweise 1-2:fail|3-5:pass.

Massen-Eingabe und Prüfungen¶

Messpunkt-Serie erzeugt mehrere Zeilen auf einmal:

Verteilung	Ergebnis
Gleichmäßig verteilt	`Von … Bis` in `Anzahl` Schritten
Dekaden (×10)	`1 … 1000` → 1, 10, 100, 1000; rückwärts, wenn „Bis" kleiner ist
Prozent vom Bereich	Vorgabe 0, 25, 50, 75, 100
Werteliste	frei eingetippt

Optional wird der absteigende Rückweg für Geräte mit Hysterese angehängt. Alle übrigen Felder erbt die Serie von der Ausgangszeile.

Über eine zweite Dimension (z. B. DC; AC 50 Hz) entsteht ein Kreuzprodukt: jeder Sollwert wird für jede Ausprägung angelegt. Für die zweite Dimension gibt es keine eigene Spalte — sie landet in der Beschreibung (Platzhalter {dim}) und wahlweise im MET/CAL-Freifeld auxalary. Auswerten oder filtern lässt sie sich damit nicht. - Duplizieren kopiert eine Zeile direkt darunter. - Auf alle Zeilen überträgt Einheit, Toleranz, Auflösung, Bereich oder Unsicherheit aus der aufgeklappten Zeile auf alle anderen. - Neu nummerieren vergibt die Schritt-Nummern nach der Reihenfolge.

Der Editor markiert Zeilen mit Hinweisen. Blockierend sind ungültige Zahlen und Toleranzterme mit / oder D ohne ihre Bezugsgröße. Als Warnung erscheinen: fehlende Messunsicherheit (kein Guard Band), ein Verhältnis von Toleranz zu Unsicherheit unter 4:1, ein %-Term ohne Sollwert, die MET/CAL-Grenzen sowie ein Sollwert, der nicht zur Auflösung passt — entweder mit mehr Nachkommastellen als die Auflösung hergibt (100,0000 bei 0,01) oder als Wert, der kein Vielfaches der Auflösung und damit am Prüfling nicht einstellbar ist.

Entwurf mit KI¶

Ein Prüfplan für ein frisch übergebenes Gerät ergibt sich meist aus zwei Angaben: der Gerätespezifikation und der Regel, nach der geprüft werden soll. Der Knopf „KI-Entwurf" im Schritt-Editor nimmt beides entgegen und erzeugt daraus einen Entwurf.

Geräteübergabe — vier Quellen, kombinierbar:

Quelle	Woher die Angaben kommen
Gerät dieser Kalibrierung	nur im Prüfschritte-Editor einer Kalibrierung; der Server löst Gerät und Gerätetyp selbst auf
Gerät aus dem Inventar	Gerätestammdaten plus die Spezifikationen des Geräts und seines Typs
Gerätetyp	Typstammdaten plus die Spezifikationen des Typs
Nur Beschreibung	alles, was (noch) nicht in den Stammdaten steht

Der Schalter „Hinterlegte Spezifikationen mitgeben" entscheidet, ob die Spezifikationsblätter mit ihren Messbereichen, Auflösungen und Genauigkeiten in die Anfrage gehen. Ohne sie kennt das Modell nur, was im Dialog steht.

Spezifikationsregeln — die Auswahl „Regelwerke" (DKD-R 6-1, VDI/VDE/DGQ 2622, ILAC-G8 …) benennt nur den Rahmen. Die Zahlen einer Richtlinie stehen nicht im System, und das Modell soll sie nicht rekonstruieren; was gelten soll, gehört ins Feld „Prüfvorgaben":

DC-Spannung in allen Bereichen, Messpunkte 10 / 50 / 100 % vom Bereichsendwert, Fehlergrenze ±(0,5 % vom Messwert + 2 Digit), erweiterte Messunsicherheit k = 2, Entscheidungsregel: einfache Annahme mit Guard Band.

Der Schalter „Am Messplatz ablesen" lässt den Entwurf die Messgruppen an die Rollen des Messplatzes binden (read device uut, source cal, function). Welches Gerät welche Rolle spielt, steht am Messplatz, nicht im Plan; ohne Schalter liest der Prüfer von Hand ab.

Der Entwurf ist ein calScript: Gruppen mit gemeinsamen Vorgaben, Serien für gleichartige Punkte (measure 2 10 19 "{value} V"), Wiederholmessungen, wo die Vorgaben sie verlangen. Liegen am Gerätetyp Spezifikationen mit Prüfpunkten, etwa aus einem MET/CAL-Import, übernimmt der Entwurf deren Punkte, Bereiche und Genauigkeiten. Die Vorschau zeigt das Skript und darunter die Schrittzeilen, die der Compiler daraus macht.

Im Vorlagen-Editor geht der Entwurf in die Skript-Ansicht: er ersetzt das Skript oder wird an das Skript angehängt (ohne zweiten Kopf). Aus Tabelle oder Karten wechselt der Editor dafür ins Skript. Im Prüfschritte-Editor einer Kalibrierung, der kein Skript kennt, werden die Schrittzeilen an die bestehenden Schritte angehängt oder ersetzen sie. Danach ist der Entwurf gewöhnlicher Inhalt des Editors: änderbar, mit denselben Warnungen wie Getipptes. Gespeichert wird nichts von selbst, erst „Als neue Version speichern" legt eine Version an.

Der Entwurf wird geprüft, nicht übernommen

Jedes Skript geht durch den calScript-Compiler, mit denselben Regeln wie beim Speichern. Lehnt er es ab, bekommt das Modell die Meldung mit Zeile und bessert nach, höchstens zweimal und nur, solange das Zeitbudget reicht. Kompiliert das Skript danach immer noch nicht, kommt es trotzdem: die Vorschau nennt den Fehler, und in der Skript-Ansicht steht er an seiner Zeile. Hinweise des Compilers (etwa %r ohne range) und ein SI-Vorsatz, den der Katalog nicht kennt (er rechnet als Faktor 1), stehen über der Vorschau. Korrigiert wird nichts still. Sollwerte, Toleranzen und Unsicherheiten bleiben Angaben eines Sprachmodells und sind vor der Freigabe fachlich zu prüfen.

Voraussetzungen: Der KI-Assistent muss unter Administration → KI-Assistent eingerichtet und die Funktion „Prüfplan-Entwurf aus Gerät und Spezifikationsregeln" eingeschaltet sein. Der Knopf erscheint mit ai_assistant_edit; der Entwurf selbst verlangt zusätzlich procedure_template_edit. Zeigt die konfigurierte KI-Adresse nach außen, weist der Dialog darauf hin, dass Gerätedaten die Installation verlassen.

Verlauf und Fehler¶

Der Dialog führt einen Verlauf mit — auch während der Entwurf entsteht. Er zeigt, wie weit der Server kam, und ist im Fehlerfall die eigentliche Auskunft:

Station	Was sie sagt
Anfrage an den Server	Wartezeit des Browsers; bricht er ab, endet der Verlauf hier
Anbindung geprüft	Anbieter, Modell, Zeitbudget — und ob die Adresse nach außen zeigt
Geräteübergabe gelesen	welche Quellen gezogen wurden, wie viele Spezifikationsblätter, wie groß die Beschreibung
Modell gefragt	Skriptzeilen in der Antwort, verbrauchte Token, Dauer
Skript gegen den calScript-Compiler geprüft	kompilierte Schritte und Hinweise, oder Zeile und Art des Fehlers
Skript nachgebessert	eine Runde nach einem Compilerfehler, höchstens zwei

Der Verlauf trägt nur Kennzahlen und Konfigurationsnamen — keine Gerätedaten, keine Prüfvorgaben, keine Modellantwort, auch keine Teile des Skripts.

Scheitert der Entwurf, nennt der Dialog den Fall statt „bitte erneut versuchen":

Fall	Bedeutung	Wer ist dran
Zeitüberschreitung im Browser	keine Antwort innerhalb des Zeitlimits	Betreiber: Zeitbudget oder Modell
Antwort kam nicht durch (502/504)	geantwortet hat der Reverse Proxy, nicht die Anwendung	Betreiber: Proxy-Frist
KI-Dienst nicht erreichbar / Fehlerstatus	Adresse, Schlüssel oder Modell stimmen nicht	Betreiber: Administration → KI-Assistent
Antwort abgeschnitten / leer	das Modell kam mit der Länge nicht durch	Prüfer: „Max. Schritte" senken, oder anderes Modell
Antwort passt nicht ins Format	Modell zu klein für strukturierte Ausgabe	Betreiber: größeres Modell
Skript kompiliert nicht	auch nach der Nachbesserung ein Fehler im Skript	Prüfer: Zeile in der Skript-Ansicht korrigieren
Kein verwertbarer Prüfplan	die Vorgaben tragen zu wenig	Prüfer: Messgrößen, Bereiche, Fehlergrenzen nennen

Zeitbudget unter die Frist der Umgebung legen

Der Entwurf ist ein Aufruf, der auf lokaler CPU Minuten dauert. Der Server gibt nach seinem Zeitbudget auf (ab Werk 240 s) und antwortet dann mit einer Diagnose. Läuft er länger als die kürzeste Frist auf dem Weg, antwortet stattdessen nginx, und zwar mit einer HTML-Seite ohne Fehlerobjekt. Dann bleibt nur „die Antwort kam nicht durch".

Ein Abbruch nach genau 1:00 min ist die Signatur der nginx-Vorgabe von 60 s. Die Direktive dahinter heißt fastcgi_read_timeout, wenn nginx direkt auf PHP-FPM zeigt — so wie im API-Image. proxy_read_timeout gilt nur für eine vorgelagerte Proxy-Schicht; wer nur dort nachsieht, findet einen hohen Wert und den Fehler trotzdem nicht. PHP-FPM begrenzt zusätzlich per request_terminate_timeout.

Im mitgelieferten Image stehen alle drei auf 300 s. Wer eine eigene nginx-Konfiguration betreibt, prüft dort dieselbe Zeile.

Abhilfe: entweder die Fristen der Umgebung anheben oder das Budget darunter legen.

# .env der API — Zeitbudget in Sekunden (30 bis 900)
AI_PROCEDURE_PLAN_BUDGET_S=55
docker exec calserver-api-v2 php artisan config:clear

Das Zeitlimit des Browsers leitet sich daraus ab (Budget + 20 s) — der Server soll zuerst aufgeben, denn nur seine Antwort erklärt, woran es lag.

GET  /api/v2/ai/procedure-plan/availability   # inkl. budget_s
POST /api/v2/ai/procedure-plan   # { "rules": "...", "standards": [...], "calibration_id"|"inventory_id"|"device_type_id"|"device_text" }

Beide Ausgänge tragen den Verlauf: der Erfolg unter data.trace, der Fehler unter error.trace neben error.ai_error und error.retryable.

Optimierung mit KI¶

Ein importierter Plan, etwa aus einer MET/CAL-Prozedur, ist fachlich richtig, aber schwer zu lesen: Copyright- und Sicherheitstexte als Dutzende Einzelmeldungen, Gruppen mit den Namen der Unterprozeduren, dieselben Vorgaben an jedem Punkt. Der Knopf „KI-Optimierung" im Vorlagen-Editor lässt den Plan überarbeiten, der gerade im Editor steht, auch ungespeichert.

Der Dialog fragt, was verbessert werden soll; die ersten fünf Ziele sind vorausgewählt:

Ziel	Was die KI tut
Hinweise bündeln	aufeinanderfolgende Meldungen zusammenfassen, Copyright-Hinweise auf einen kürzen, Anschlussanweisungen als `info` an ihre Gruppe, MET/CAL-Reste wie `[32]` entfernen; Sicherheitswarnungen behalten ihren Inhalt
Gruppen benennen und ordnen	Titel nach Messgröße und Bereich, Gruppen mit reinen Hinweisen zusammenlegen, gemeinsame Werte an die Gruppe heben
Serien bilden	gleichartige, aufeinanderfolgende Punkte als eine Serie
Vorgaben prüfen	Bereich, Auflösung und Toleranz je Gruppe; Auffälliges bekommt einen Kommentar `# Prüfen: …`
Hinweise des Editors auflösen	die Warnungen der Tabelle („40 mit Hinweis"), soweit das ohne erfundene Zahlen geht
Ablesung zuordnen (nicht vorausgewählt)	Punkte, die der Prüfer vom Display des Prüflings abliest, bekommen `read camera uut` (an der Gruppe, wenn alle Punkte so gelesen werden); wo eine Ablesung über die Schnittstelle möglich scheint, steht nur ein Kommentar `# Prüfen: …`, Befehle und Adressen erfindet die KI nicht (ADR 2026-11-01)

Dazu kommt ein freies Feld für weitere Anweisungen, etwa „Hinweise ins Deutsche übersetzen".

Zurück kommt ein Vorschlag mit Diff: jede Zeile, die sich ändern würde, die Liste der Änderungen und die Zahl der Messpunkte, Prüfungen und Hinweise vorher und nachher. „Vorschlag übernehmen" setzt ihn in die Skript-Ansicht, „Verwerfen" lässt den Plan, wie er ist. Gespeichert wird auch hier erst mit „Als neue Version speichern".

Messpunkte bleiben, und der Server zählt nach

Die KI darf Texte straffen und umordnen, aber keinen Messpunkt löschen oder hinzufügen und keinen Sollwert, keine Toleranz und keine Unsicherheit ändern. Der Server vergleicht danach die wirksamen Werte jedes Punkts (Gruppenvorgaben eingerechnet). Fehlt ein Punkt, ist einer neu oder hat sich sein Bereich oder seine Auflösung geändert, steht das rot über dem Diff, und das Übernehmen fragt nach. Eine fehlende Messunsicherheit füllt die KI nicht: sie kommt aus dem Budget des Normals.

Voraussetzungen wie beim Entwurf: dieselbe Funktion unter Administration → KI-Assistent, dasselbe Modell, ai_assistant_edit und procedure_template_edit. Übermittelt wird der Plan als calScript, die Hinweise des Editors und die Anweisung; Kunden- und Gerätestammdaten gehen nicht mit. Ein Plan, der nicht kompiliert, wird nicht optimiert: erst den Fehler beheben.

Große Pläne gehen abschnittsweise. Ein importierter Hersteller-Plan hat schnell 50.000 Zeichen und mehr; am Stück passt das weder in eine Anfrage noch in die Antwort des Modells. Über 12.000 Zeichen teilt der Server den Plan zwischen Gruppen in Abschnitte (eine Gruppe wird nie geteilt), der Dialog schickt sie nacheinander und zeigt, welcher gerade beim Modell ist. Danach setzt er die Abschnitte zusammen, und der Server stellt den ganzen Vorschlag gegen den ganzen Plan: Diff und Messpunktzählung gelten für den Gesamtplan. Kompiliert der Vorschlag für einen Abschnitt nicht, bleibt dieser Abschnitt unverändert, und die Änderungsliste sagt das. Das Zeitbudget gilt je Abschnitt. Der ganze Plan darf bis 400.000 Zeichen haben (ADR 2026-11-03 „MET/CAL-Import ohne Ballast“).

API¶

GET    /api/v2/procedure-templates                 # Liste (filter[procedure_id], latest_only=1)
POST   /api/v2/procedure-templates                 # Upload → Version 0.1
POST   /api/v2/procedure-templates/manual         # Name + Schritte → Version 0.1 (procedure_id optional)
POST   /api/v2/procedure-templates/{id}/new-version
POST   /api/v2/procedure-templates/{id}/approve
POST   /api/v2/procedure-templates/{id}/release
GET    /api/v2/procedure-templates/{id}/versions
GET    /api/v2/procedure-templates/{id}/download
GET    /api/v2/procedure-templates/{id}/export-package  # Prüfplan-Paket (ZIP) dieser Version
POST   /api/v2/procedure-templates/import-package  # Paket-Upload → neue Vorlage 0.1
PUT    /api/v2/procedure-templates/{id}           # { "name": "..." } und/oder { "procedure_id": ... }
POST   /api/v2/procedure-templates/{id}/assign     # { "procedure_id": "..." }
POST   /api/v2/procedure-templates/{id}/unassign
GET    /api/v2/procedures/{id}/unassigned-templates # Prüfpläne, die nicht zu dieser Prozedur gehören

Umbenennen und Zuordnen schreiben immer auf alle Versionen eines Prüfplans (alle Zeilen desselben hash): Name und Prozedur gehören dem Plan, nicht der einzelnen Version, und jede neue Version erbt beide ohnehin von ihrer Vorgängerin. procedure_id: null in PUT hebt die Zuordnung auf, wie /unassign.

Vorlage ↔ Kalibrierung¶

Im Prüfschritte-Tab einer Kalibrierung:

„Als Vorlage speichern" serialisiert die Prüfschritte der Kalibrierung in eine neue Vorlage (Version 0.1): POST /api/v2/calibrations/{id}/save-as-template
„Vorlage laden" instanziiert eine Vorlage in die Kalibrierung — bestehende Prüfschritte werden ersetzt: POST /api/v2/calibrations/{id}/load-procedure mit { "template_id": "..." }

Berechtigungen¶

Operation	Berechtigung
Ansehen, Herunterladen, Versionen	`procedure_template_view`
Hochladen, neue Version, Genehmigen, Freigeben, Umbenennen, Zuordnen	`procedure_template_edit`
Löschen	`procedure_template_delete`