Konzept: Prüfplan, Treiber und Ablesung¶

calScript beschreibt, was an einem Prüfling gemessen und wie es bewertet wird. Es beschreibt nicht, womit gemessen wird und wie ein Gerät angesprochen wird. Diese Trennung ist die wichtigste Idee hinter calScript, dem calServer Runner und den Treiberprofilen. Diese Seite erklärt sie, zeigt die drei Wege, auf denen ein Messwert in calServer ankommt (von Hand, über einen Treiber am Messplatz, über die Kamera), und sagt offen, wo sich Treiberlogik und Messwertaufnahme heute noch berühren.

Wer gleich schreiben will: die Sprache steht unter Prüfpläne als calScript, die Geräteseite unter Treiberprofile und Dialekte.

Das Problem: Prozeduren, die alles auf einmal sind¶

Eine klassische Kalibrierprozedur, etwa aus MET/CAL, ist ein Programm, in dem vier Dinge ineinanderlaufen:

Die Prüfaufgabe: welche Punkte, welche Sollwerte, welche Toleranz, welche Messunsicherheit, wann bestanden.
Die Gerätesteuerung: welcher Kalibrator welchen Befehl bekommt, in welchem Bereich das Multimeter steht, wie lange gewartet wird.
Die Ablesung: ob ein Mensch einen Wert eintippt, ein Gerät über den Bus gelesen wird oder beides nacheinander.
Die Rechnung dazwischen: Werte umrechnen, Register setzen, verzweigen, wiederholen.

Das funktioniert, solange Prozedur, Gerätepark und Messplatz zusammenpassen. Steht ein anderer Kalibrator am Platz, ist das Multimeter ein Nachfolgemodell oder soll ein Handmultimeter ohne Schnittstelle mit der Kamera abgelesen werden, muss die Prozedur angefasst werden, obwohl sich an der Prüfaufgabe nichts geändert hat. Und weil Befehle und Bewertung im selben Text stehen, lässt sich schwer prüfen, ob eine Änderung an der Gerätesteuerung die Bewertung berührt.

Die Antwort: fünf Fragen, fünf Orte¶

calServer verteilt diese Dinge auf getrennte Orte. Jeder beantwortet genau eine Frage:

Frage	Ort	Wer pflegt es	Ändert sich, wenn …
Was ist verlangt (Toleranz je Punkt)?	Spezifikation des Typs oder Geräts, je Kalibrierung eine Option (Hersteller, Norm, Kunde, Verwendung)	wer Datenblätter und Normen pflegt, freigegeben je Revision	sich ein Datenblatt, eine Norm oder eine Kundenvereinbarung ändert
Was wird gemessen, in welcher Reihenfolge, mit welchem Bezug?	Prüfplan (calScript)	Prüfplaner, freigegeben wie jeder Plan	sich das Verfahren ändert
Welches Gerät spielt welche Rolle?	Lauf (Kalibrierung, Vorlauf, Messplatz)	ergibt sich je Kalibrierung	ein anderes Normal oder ein anderer Prüfling dran ist
Wie spricht man mit diesem Gerätemodell?	Treiberprofil (in calServer gepflegt, im Runner ausgeführt)	Messplatzverantwortliche	ein neues Gerätemodell dazukommt
Wer liest den Wert ab?	Ablesequelle des Messpunkts	steht im Plan, wird am Platz erfüllt	ein Punkt automatisiert oder an die Kamera gegeben wird

 Prüfplan (calScript)          Lauf                         Messplatz
 ─────────────────────         ───────────────────────      ──────────────────────────
 measure 10 "10 V"             uut = Inventar der           calServer Runner
   read device uut      ──►      Kalibrierung        ──►      Profil "keysight-34461a"
   source cal                  cal = Normal aus dem             Dialekt scpi.dmm
   function "VDC"                Vorlauf                      Profil "fluke-5522a"
                               Option der Spezifikation         Dialekt fluke.55xx
                                 „Hersteller, 1 Jahr“                │
                                                                     ▼
                         ◄──────────── Messwert mit Herkunft "device" ─┘
 Bewertung gegen die Toleranz der Option, Messunsicherheit, Kalibrierschein:
 immer in calServer

Drei Regeln halten das zusammen:

Verlangt ist, was die Spezifikation sagt. Der Plan beschreibt das Verfahren und trägt im Normalfall keine Toleranz. Beim Laden kommt sie aus der Option, die die Kalibrierung gewählt hat; steht doch eine im Plan, gewinnt sie und heißt auf dem Schein „Plan“. Findet sich keine, gibt es kein Urteil statt eines geratenen.
Die Bewertung bleibt in calServer. Kein Treiber, kein Runner und keine Kamera entscheidet über bestanden oder nicht bestanden. Sie liefern einen Wert mit Herkunft; Toleranz, Messunsicherheit und Konformitätsaussage rechnet calServer, egal auf welchem Weg der Wert kam.
Treiber ist Treiber. Ein Treiberprofil sagt, was ein Gerätemodell kann (je Funktion: Werte geben, Werte messen oder beides) und wie man es anspricht. Es sagt nicht, ob das Gerät Normal oder Prüfling ist. Das entscheidet der Lauf. Derselbe Fluke 5522A ist heute Normal (cal) und wird morgen mit demselben Profil selbst kalibriert (uut).

Warum Spezifikation, Verfahren und Ablesung getrennt sind¶

Jede der drei Seiten hat einen anderen Eigentümer und ändert sich aus einem anderen Grund: die Spezifikation mit Datenblatt, Norm oder Kundenvereinbarung, das Verfahren mit dem Aufbau des Labors, die Ablesung mit dem Messplatz und dem Tag. Stünden sie in einem Dokument, verlangte ein neues Datenblatt einen neuen Prüfplan, ein Kunde mit engeren Grenzen eine Kopie, ein Platz ohne Schnittstelle eine dritte Fassung, und jede Kopie alterte für sich.

Für die Validierung ist die Trennung die Voraussetzung: Die Spezifikation wird je Revision gegen ihre Quelle freigegeben, das Verfahren einmal mit Testfällen validiert, unabhängig von der Option, gegen die später bewertet wird, und der Eingabeweg für sich geprüft (Mitschnitt, Beweisbild, Person). Eine neue Option braucht keine neue Verfahrensvalidierung, solange sie nur Toleranzen ändert, und ein anderer Eingabeweg ändert weder Grenze noch Urteil. Ein Fehler in einer Grenze ist so ein Fehler der Spezifikation, einer im Ablauf einer des Verfahrens, ein falsch gelesener Wert einer der Eingabe. Die Herkunft der Toleranz je Punkt auf dem Schein macht das nachprüfbar. Ausführlich: ADR 2026-11-02 Eine Spezifikation mit Optionen.

Rollen statt Geräte im Plan¶

Ein Plan nennt nie ein Gerät, eine Adresse oder einen Befehl, sondern Rollen: uut für den Prüfling, cal oder einen frei gewählten Namen wie dmm für Normale. Erst der Lauf löst sie auf:

uut ist das Gerät am Messplatz, dessen Inventareintrag kalibriert wird.
Jede andere Rolle ist das Gerät, dessen Inventareintrag der Vorlauf dieser Rolle als Normal zugeordnet hat.
Ein Gerät am Messplatz trägt deshalb keine Rolle, nur Anschluss, Treiberprofil und Inventareintrag.

„Am Messplatz ausführen“ zeigt vor dem Start, welches Gerät welche Rolle spielt. Eine Rolle ohne Gerät bleibt mit Grund offen, und ihre Punkte misst der Runner nicht. So läuft ein freigegebener Plan auf jedem Platz, an dem passende Geräte stehen, ohne dass jemand den Plan anfasst.

Optional nennt eine Kopfzeile den vorgesehenen Gerätetyp einer Rolle (standard cal "Fluke 5522A"). Das dient der Vorschau (TAR, geschätzter TUR) im Editor; die Prüfung rechnet mit dem Normal, das der Lauf tatsächlich zuordnet.

Drei Wege zum Messwert¶

Jeder Messpunkt hat eine Ablesequelle. Sie steht im Plan, an einer Gruppe als Vorgabe für alle Punkte darunter oder an einem einzelnen Punkt. Derselbe Messpunkt, dreimal:

Von HandTreiber am MessplatzKamera mit KI

group "Gleichspannung"
  result numeric
  unit V
  tol 0.5% + 2 D
  measure 10 "10 V"

Keine Ablesequelle heißt read manual: der Prüfer stellt das Normal ein, liest die Anzeige und tippt den Wert in die Erfassungstabelle.

group "Gleichspannung"
  result numeric
  unit V
  tol 0.5% + 2 D
  read device uut
  source cal
  function "VDC"
  settle 2
  measure 10 "10 V"

Der Runner stellt über das Profil der Rolle cal 10 V ein, wartet zwei Sekunden, liest über das Profil der Rolle uut den Wert und schickt ihn an calServer.

group "Gleichspannung"
  result numeric
  unit V
  tol 0.5% + 2 D
  read camera
  capture confirm
  measure 10 "10 V"

Der Prüfer stellt das Normal ein, die Webcam im Browser sieht die Anzeige, ein Vision-Modell liest den Wert, der Prüfer bestätigt mit einem Klick.

Toleranz, Einheit, Sollwert und Bewertung sind in allen drei Fassungen gleich. Nur die Zeilen, die sagen, wer abliest, unterscheiden sich.

Im Vergleich¶

	Von Hand	Treiber am Messplatz	Kamera mit KI
Im Plan	nichts oder `read manual`, optional `source <rolle>`, `function`, `settle`	`read device <rolle>`, dazu `function`, optional `source <rolle>`, `settle`	`read camera [rolle]`, `capture confirm` oder `auto`, optional `source <rolle>`, `function`, `settle`
Wer stellt das Normal ein	Prüfer, mit `source` der Runner (ab Runner 0.19.0, wartet bis zur Eingabe)	Runner über das Profil der `source`-Rolle, sonst Prüfer	Runner über das Profil der `source`-Rolle (ab Runner 0.18.0, wartet bis zur Kamera-Übernahme), sonst Prüfer
Wer liest ab	Prüfer	Runner über das Profil der `read`-Rolle	Vision-Modell, Prüfer bestätigt (oder `capture auto`)
Braucht	nichts	Messplatz mit calServer Runner, Geräte mit Schnittstelle, aktive Treiberprofile	Webcam im Browser, KI-Routine „Kamera-Ablesung“ mit Vision-Modell
Herkunft am Wert	`manual`	`device`	`camera` oder `camera_auto`, dazu ein Beweisbild
Treiberlogik	keine	im Treiberprofil und im Dialekt des Runners	keine; an ihrer Stelle Bildausschnitt, Modell und Ampel
Typischer Einsatz	Sichtprüfung, mechanische Prüfmittel, Einzelstücke	Tischmultimeter, Kalibratoren, Serienkalibrierung	Handmultimeter, Anzeigen ohne Schnittstelle, Geräte mit Schnittstelle ohne Profil

Die Wege lassen sich in einem Plan mischen: eine Gruppe liest über den Messplatz, der Nullpunkt darin von Hand (measure 0 "Nullpunkt" read manual). Steht erst am Tag der Messung fest, wer abliest, stellt read device uut | camera | manual die drei Wege zur Wahl, und der Prüfer wählt im Vorlauf; Toleranzen und Punkte stehen dabei nur einmal im Plan (Ablesung im Lauf wählen). Die Beispielpläne zeigen alle Kombinationen.

1. Von Hand¶

Der einfachste Weg und die Rückfallebene der beiden anderen. Was der Plan an Prüfanweisung braucht (info, md, image), steht beim Punkt; der Prüfer arbeitet die Erfassungstabelle ab. Es gibt keine Treiberlogik, also auch nichts, was sich vermischen könnte. Auch bei read device und read camera bleibt die Handeingabe jederzeit möglich.

2. Treiber per Schnittstelle (calServer Runner)¶

Am Messplatz läuft der calServer Runner. Er holt den Plan des Laufs, die Rollenzuordnung und die aktiven Treiberprofile aus calServer, fährt die Gerätepunkte ab und schickt jeden Wert sofort zurück. Er rechnet keine Bewertung.

Die Arbeit ist dreigeteilt:

Der Plan sagt: dieser Punkt, diese Funktion (VDC, VAC, ADC, AAC, OHM, OHM4, CAP, FREQ, TEMP), diese Rolle gibt, jene liest, so lange einschwingen.
Das Treiberprofil sagt: dieses Modell kann VDC geben bis 1020 V, meldet sich auf *IDN? mit dieser Kennung, braucht diesen Abschluss und dieses Zeitlimit, liest VDC mit dieser Befehlsfolge in diesen Bereichen.
Der Dialekt im Runner sagt: so spricht man die ganze Gerätefamilie an, einschließlich Betrieb/Standby, Fehlerschlange und Sicherheitsabschaltung am Ende jedes Laufs.

Neue Geräte kommen über ein neues Profil dazu, nicht über einen neuen Plan. Einzelheiten: Treiberprofile und Dialekte.

Wo trotzdem jemand handeln muss (Messleitungen umstecken, den Drehschalter eines Handmultimeters stellen, eine Frage beantworten), hält der Runner an der Meldung, und die Prüflauf-Seite zeigt „Messplatz wartet auf dich“ mit dem Knopf Weiter. So entstehen halbautomatische Pläne, ohne dass die Meldung Teil des Treibers wird.

Jeder Wert geht zuerst in das Journal des Runners und erst dann an calServer. Fällt das Netz weg, sendet der Runner später nach. Seit Runner 0.22.0 trägt jeder Eintrag den Zeitpunkt, an dem gemessen wurde, die Treiberprofile des Laufs und den Hash seines Vorgängers. calServer prüft die Kette beim Ankommen, hält Mess- und Ankunftszeit getrennt fest und zeigt beide an der Ablesung, wenn der Wert spürbar später ankam. Ein Eintrag, der nicht zu seinem Hash oder seinem Vorgänger passt, kommt nicht an; ein fehlender Vorgänger (etwa ein abgewiesener Wert) wird als Lücke vermerkt. Das Journal einer Kalibrierung liefert GET /api/v2/calibrations/{ctag}/capture-journal.

Autark am Messplatz (ab Runner 0.23.0)¶

Steht am Messplatz kein Browser oder kein Netz, wird die Kalibrierung ausgecheckt: Im Dialog Am Messplatz ausführen wählst du Auschecken (autark) und den Messplatz. calServer prüft vorher, ob der Platz den Lauf ohne Server zu Ende bringen kann, und nennt, was fehlt:

Der Vorlauf muss durch sein, der Lauf offen.
Jede Rolle des Plans braucht ein Gerät an diesem Platz.
Der Plan darf nicht auf ein Urteil verzweigen (if pass|fail), denn das Urteil fällt nur in calServer. if yes|no geht, die Antwort gibt der Prüfer am Platz.
Ein Sammellauf geht als Ganzes (siehe unten), nicht ein Mitglied allein.

Der Messplatz muss dafür nicht online sein. Der Runner holt die Kalibrierung beim nächsten Abgleich in seinen Arbeitsvorrat (Reiter im Runner-Fenster) und misst dort, auch ohne Verbindung. Meldungen, Bestätigungen, Fragen, Bewertungen und Handwerte fragt er selbst ab; die Anzeige nennt den Sollwert, nicht die Grenzen. Ein Kamerapunkt wird am Platz von Hand eingegeben, weil die KI-Ablesung calServer braucht. Wird der Lauf angehalten, macht der nächste Start dort weiter, wo er stand.

Jeder Wert geht mit Messzeitpunkt ins Journal und wird gesendet, sobald calServer erreichbar ist. Ist alles angekommen, gibt der Runner die Kalibrierung zurück, und der Browser erfasst wieder.

Solange ausgecheckt ist, zeigt die Prüflauf-Seite den Stand und die Werte, erfasst aber nicht: Tabelle und Abschließen sind gesperrt, die API antwortet mit 423. Mit Zurückholen gibst du das Erfassen im Browser wieder frei. Werte, die der Messplatz noch nicht gesendet hat, kommen danach trotzdem an.

Ohne Fenster geht dasselbe im Terminal:

calserver-runner queue              # Arbeitsvorrat abgleichen und zeigen
calserver-runner queue --run <id>   # einen Eintrag am Platz messen

queue --run nicht neben dem laufenden Runner in der Taskleiste starten: beide schrieben in dasselbe Journal. Entscheidung und Grenzen: ADR Autarker Lauf am Messplatz.

Sammellauf autark (ab Runner 0.25.0). Im Dialog Sammellauf wählst du nach dem gemeinsamen Vorlauf statt Senden den Weg Auschecken (autark). calServer prüft jedes Mitglied wie oben und dazu, ob jeder Prüfling, den ein Gerätepunkt liest, einen Kanal oder ein eigenes Gerät hat; ein Befund nennt den Prüfling. Ausgecheckt wird der ganze Sammellauf an seinen Messplatz, ebenso zurückgeholt: Zurückholen im Dialog oder auf der Laufseite eines Mitglieds gibt alle Prüflinge an den Browser zurück.

Am Platz steht der Sammellauf als ein Eintrag „Sammellauf (n)“ im Arbeitsvorrat. Eine Meldung erscheint einmal für alle, Bestätigungen und Fragen je Prüfling (der Dialog nennt ihn), und if yes|no gilt je Prüfling. Ein Hand- oder Kamerapunkt öffnet die Ablesetabelle: alle Prüflinge der Zeile mit Sollwert und Feldern; eine leere Zeile überspringt diesen Prüfling. Liest ein Gerät das Normal, liegt die Referenz vor den Ablesungen im Journal, auch ohne Netz; mit Referenz klammern liest der Runner es nach der Tabelle noch einmal. Jeder Prüfling geht zurück, sobald seine Werte angekommen sind; nach dem letzten steht der Sammellauf auf „fertig“. Im Terminal: calserver-runner queue --run batch-<id>. Entscheidung und Grenzen: ADR Sammellauf autark am Messplatz.

3. Kamera mit KI¶

Für Anzeigen ohne Schnittstelle, oder solange ein Gerät noch kein Profil hat, liest die Webcam im Browser. Der Prüfer zieht einmal einen Rahmen um die Anzeige; nur dieser Ausschnitt geht an das Vision-Modell. Das Modell kennt Einheit und Auflösung des Punkts, nie den Sollwert und nie die Toleranz, damit es keinen erwarteten Wert „sehen“ kann. calServer rechnet aus seiner Antwort eine Ampel:

rot: wird nie übernommen (kein Wert, Überlauf, mehrere Werte, falsche Größe, Modell unsicher);
gelb: steht als Vorschlag im Feld, der Prüfer übernimmt mit Klick oder tippt um;
grün: mit capture confirm per Klick, mit capture auto ohne Klick, wenn zwei Lesungen hintereinander grün sind und übereinstimmen.

Zu jedem Kamerawert speichert calServer die Herkunft und genau den Bildausschnitt, den das Modell gesehen hat. Hier gibt es keinen Treiber im engeren Sinn: an die Stelle von Profil und Dialekt treten Rahmen, Modell und Ampelregeln. Einzelheiten: Mit der Kamera ablesen.

Wo sich Treiberlogik und Messwertaufnahme berühren¶

Die Trennung ist kein Dogma. An einigen Stellen muss der Plan dem Treiber etwas mitgeben, oder der Treiber trifft eine Entscheidung, die die Messung beeinflusst. Diese Stellen sind bewusst klein gehalten und benannt.

Berührungspunkt	Was passiert	Warum es so ist
Funktion (`function "VDC"`)	Der Plan nennt die Messfunktion, der Treiber setzt sie in Befehle um.	Die Funktionsliste ist der Vertrag zwischen Plan und Profil. Eine SCPI-Schreibweise wie `"VOLT:DC"` landet auf derselben Funktion.
Frequenz bei Wechselgrößen	Der Modifier des Punkts (`@ 50 Hz`) wird zur Ausgabefrequenz des Kalibrators.	Die Frequenz gehört zum Sollwert, nicht zum Gerät. Fehlt sie, scheitert der Punkt; geraten wird nicht.
Bereich (`range`)	Ein Präzisionsmultimeter misst im Bereich des Schritts, sonst im kleinsten Bereich des Profils, der den Sollwert aufnimmt.	Fester Bereich ist eine Eigenschaft der Messung, die Bereichsliste eine des Geräts.
Einschwingzeit (`settle`)	Der Plan sagt, wie lange nach dem Einstellen gewartet wird.	Hängt vom Messpunkt ab, nicht nur vom Gerät.
Grenzen (`max_voltage_v`, `limits`)	Das Profil trägt die Grenzen des Modells; darüber sendet der Runner nichts.	Sicherheit gehört zum Gerät, nicht zum Plan. Ein Plan kann sie nicht aufheben.
Fähigkeit	Verlangt der Plan von einer Rolle etwas, das ihr Gerät nicht kann (geben mit einem Multimeter), scheitert der Punkt vor dem ersten Befehl.	Lieber ein klarer Fehler als ein falscher Befehl am Gerät.
Handmultimeter mit Drehschalter (Fluke 287/289)	Funktion und Bereich stellt der Mensch, der Runner liest über IR und prüft, ob die Einheit zur Funktion passt.	Das Gerät lässt sich nicht fernsteuern. Der Halt an der Meldung macht daraus einen sauberen halbautomatischen Ablauf.
Umrechnung (`scale`)	Ein Profil darf einen festen Faktor auf den gelesenen Wert anwenden (etwa Anzeige in mV, Plan in V).	Ein fester Faktor ist Gerätewissen. Eine Rechnung mit Laufzeitwerten ist es nicht, siehe unten.
Kamera	Kein Treiber, aber auch hier liegt Wissen über die Anzeige vor (Einheit, Nachkommastellen) und eine Regel, wann ein Wert übernommen wird.	Die Ampel ist Teil der Messwertaufnahme, nicht der Bewertung. Bewertet wird danach wie jeder andere Wert.

Was bewusst nicht in den Treiber geht¶

Bewertung und Messunsicherheit. Bleiben in calServer.
Entscheidungen im Ablauf (ask, if yes, if fail). Gehören zum Plan, der Runner folgt nur dem Zweig, den die Antwort wählt.
Prüfanweisungen an den Menschen. Meldungen stehen im Plan, der Runner hält daran an.

Was beim MET/CAL-Import passiert¶

Eine importierte MET/CAL-Prozedur bringt die Vermischung mit. Der Import löst sie auf, soweit das sicher geht:

Liest die Prozedur den Prüfling über den Bus, wird der Messpunkt read device uut, und die Busbefehle gehen in einen Treiberprofil-Entwurf für das Prüflingsmodell, nicht in den Plan. Der Entwurf wird inaktiv gespeichert und erst nach der Abnahme am Gerät aktiv gesetzt.
Stellt ein Setup-Schritt den Kalibrator auf denselben Nennwert, wird daraus source cal; die Einstellmeldung entfällt.
Automatisch wird nur, was sicher ist. Rechnet die Prozedur mit dem gelesenen Wert, stecken Laufzeitwerte in einem Befehl, oder widersprechen sich Bereiche, bleibt der Punkt Handablesung, und der Importbericht nennt den Grund.
Punkte, die der Prüfer von einer Anzeige abliest, kann der Import auf Wunsch auf die Kamera stellen.

Offen: Rechnung und Kontrollfluss im Treiber¶

Manche Geräte lassen sich nur mit etwas Logik zwischen den Befehlen lesen: einen Wert umrechnen, abhängig von einer Antwort einen anderen Befehl senden, abfragen, bis das Gerät bereit ist. In MET/CAL-Prozeduren steht diese Logik mitten in der Prüfaufgabe. Wie viel davon ein Treiberprofil oder ein Dialekt selbst ausdrücken darf, ohne dass Bewertung oder Ablauf in den Treiber wandern, wird gerade ausgearbeitet. Bis dahin gilt: ein Profil kennt feste Befehlsfolgen, Bereiche und einen festen Faktor; alles, was mit Laufzeitwerten rechnet, bleibt beim Import Handablesung. Diese Seite wird ergänzt, sobald die Entscheidung steht.

Weiterlesen¶

Prüfpläne als calScript: die Sprache, der Editor, der MET/CAL-Import, die Beispielpläne.
Treiberprofile und Dialekte: was in einem Profil steht, welche Dialekte der Runner kennt, wie ein neues Gerät dazukommt.
Hintergrund in den Architekturentscheidungen: Runner am Messplatz, Gerätebindung im Plan, Fähigkeiten statt Rollen, Geräte ohne Rolle, Kamera-Ablesung, Busbefehle als Profilentwurf.

MET/CAL ist ein Produkt und eine Marke der Fluke Corporation. calScript und der calServer Runner sind davon unabhängig; Kompatibilität wird sachlich benannt.