Benutzerhandbuch
Kalman FAT Suite — Workflow und Benutzerhandbuch
Praxisleitfaden für Projekteinrichtung, Rollen, mehrphasige Sitzungen, unabhängige Teilnehmerentscheidungen und kontrollierte FAT-/SAT-Durchführung.
Die Kalman FAT Suite organisiert industrielle Abnahmetests, ohne dass mehrere Personen eine gemeinsame Entscheidung überschreiben müssen.
Die Kernstruktur lautet Projekt → Testbereich → Testpaket → Prüfpunkt. Eine Sitzung ergänzt Phase, Status, Teilnehmer und die unabhängige Antwort jeder Person.
Dieses Handbuch beschreibt den aktuellen Produktstand und kennzeichnet die derzeitige Grenze der Teilnehmerberichterstattung ausdrücklich.
In sechs Schritten zum ersten Projekt
Folgen Sie diesem Ablauf. Jede Karte führt zur passenden Anleitung.
- Projekt vorbereitenVorlage herunterladen, Prüfpunkte und Verfahren in Excel ausfüllen und importieren. Später können Sie sie auf der Website ändern.
- Verantwortung zuweisenMitglieder einladen und den Zugriff je Phase festlegen.
- Testsitzung öffnenPhase wählen und Teilnehmer vor dem Öffnen prüfen.
- Eigene Antwort erfassenStatus und technischen Kommentar speichern; Bestätigung prüfen.
- Abweichungen bearbeitenBefunde klären, Maßnahmen verfolgen und erneut prüfen.
- Prüfen und übergebenGemeinsame Ergebnisse bestätigen und PDF erstellen.
Funktionen im Überblick
Checklisten und ExcelPrüfhierarchie, Standardvorlagen, Import und Export.Mehrere TestphasenInternal, FAT, SAT und Retest mit getrennten Aufzeichnungen.Zusammenarbeit mit RollenProjekt- und Phasenrollen, unabhängige Antworten und Zählung.Mängel und NachweiseTechnische Befunde, Schweregrad, Verantwortung und Maßnahmen.Abnahme und BerichteKritikalität, Abnahmehindernisse, Berichtsprofile und PDF.Lokales Speichern und WiederherstellenLokale Entwürfe gemeinsamer Daten und Synchronisierung.
Durchgängiger Workflow
- Beginnen Sie mit Excel. Laden Sie die Excel-Vorlage über die Schaltfläche oben im Handbuch oder im Projekt-Dashboard herunter.
- Tragen Sie Prüfpunkte, Prüfverfahren und erwartete Ergebnisse in Excel ein. Behalten Sie die Blattnamen und Spaltenüberschriften der Vorlage bei.
- Erstellen Sie im Projekt-Dashboard ein leeres Projekt und öffnen Sie es. Wählen Sie als Owner oder Admin Data tools → Import Excel und Ihre ausgefüllte Datei. So übernehmen Sie die Checkliste, ohne jeden Prüfpunkt von Hand einzutragen.
- Prüfen Sie die importierte Checkliste. Owner und Admin können jederzeit direkt auf der Website Prüfpunkte hinzufügen, Prüfverfahren festlegen und vorhandene Prüfpunkte oder Verfahren ändern. Ein erneuter Import ist dafür nicht nötig. Sie können ein Projekt auch manuell aufbauen oder den Ablauf im Demo-Projekt kennenlernen.
- Unter Project settings Projektinformationen, Berichtseinstellungen, Referenzen und dauerhafte Prüfhierarchie kontrollieren.
- Unter Access management Mitglieder per E-Mail einladen und Owner, Admin, Tester oder Viewer zuweisen.
- Unter Test execution eine Phase Session als Draft erstellen; Phase, Teilnehmer und erforderliche Antwortende wählen.
- Teilnehmerliste prüfen und Sitzung öffnen. Die Liste kann nur im Draft geändert werden.
- Jeder Teilnehmer erfasst am Prüfpunkt eigenen Status und Kommentar; Status sofort, Kommentar nach kurzer Pause.
- Passed-, Rejected-, Blocked- und Pending-Zahlen prüfen und Abweichungen nach dem vereinbarten Projektprozess klären.
- Nach Abschluss des Reviews Sitzung schließen und später archivieren; geschlossene Antworten sind schreibgeschützt.
- Vor dem aktuellen PDF das gemeinsame Legacy-/konsolidierte Ergebnis separat bestätigen.
Projekt- und Teststruktur
| Projekt | Dauerhafter Container für Umfang, Mitglieder, Referenzen, Berichtseinstellungen und alle Phasen. |
|---|---|
| Testbereich | Übergeordnete Anlagen-, System- oder Disziplingruppe. |
| Testpaket | Handhabbare Gruppe zusammengehöriger Prüfungen. |
| Prüfpunkt | Einzelprüfung, z. B. IO, HMI, Alarm, Sequenz, Kommunikation, Schaltschrank, Cybersecurity oder Dokument. |
| Phase Session | Kontrollierte Testrunde mit eigener Phase, Teilnehmern, Lebenszyklus und Antworten. |
| Teilnehmerantwort | Entscheidung einer Person zu einem Prüfpunkt in einer Sitzung; getrennt von anderen und vom gemeinsamen Legacy-Ergebnis. |
Phasen und Sitzungslebenszyklus
| Phasentypen | Internal, Pre-FAT, FAT, SAT, Punch Retest, Final Acceptance und Custom beschreiben Zweck und Zeitpunkt. |
|---|---|
| Draft | Owner/Admin bereitet Name, Phase und Teilnehmer vor; Antworten sind gesperrt. |
| Open | Zugewiesene Teilnehmer können eigene Antworten abgeben; die Teilnehmerliste ist gesperrt. |
| Closed | Review beendet, Antworten schreibgeschützt; erneutes Öffnen ist nicht möglich. |
| Archived | Sitzung bleibt in der Historie. Ablauf: Draft → Open → Closed → Archived; Draft kann ebenfalls archiviert werden. |
Phasenspezifischer Zugriff
| Projektrolle | Die dauerhafte Rolle Owner, Admin, Tester oder Viewer steuert Projekteinstellungen, Struktur, Import und Mitglieder. Sie bestimmt nicht automatisch die Rolle in jeder Phase. |
|---|---|
| Phasen-Admin | Verwaltet Zugriffsliste und Lebenszyklus dieser Phase und kann eine eigene unabhängige Antwort speichern. Die Rolle verleiht keine dauerhaften Projekt-Adminrechte. |
| Phasen-Tester | Öffnet die Phase und speichert oder ändert ausschließlich die eigene Entscheidung je Prüfpunkt; fremde Antworten bleiben geschützt. |
| Phasen-Viewer / Kein Zugriff | Viewer lesen die Phase, antworten nicht und zählen nie als Pending. Kein Zugriff verbirgt Phase und Antworten. Der Projekt-Owner behält einen Governance-Notfallzugriff. |
| Required responder | Nur Phasen-Admin oder Tester können erforderlich sein. Bis zur gespeicherten Entscheidung bleiben sie Pending; Viewer zählen nicht zur Fertigstellung. |
Zugriff, Rollen und Verantwortung
Projektzugriff wird per E-Mail zugewiesen und in der Datenbank durchgesetzt.
Projektmitgliedschaft und Phasenzugriff sind getrennt: dieselbe Person kann in Pre-FAT Admin, in FAT Viewer und in SAT ohne Zugriff sein.
Rollen
| Owner | Projektersteller mit Vollzugriff; ein Admin kann den Owner nicht entfernen oder herabstufen. |
|---|---|
| Admin | Verwaltet Struktur, Einstellungen, Berichte und Mitglieder; löscht weder Projekt noch Owner. |
| Tester | Führt zugewiesene Tests aus und erfasst nur die eigene Teilnehmerantwort. |
| Viewer | Nur Lesezugriff auf Projekt und Bericht; keine Ausführung oder Datenänderung. |
Zugriffsverwaltung
- Owner/Admin verwaltet Mitglieder und dauerhafte Rollen unter Project settings → Access management.
- Im Draft weist der Phasen-Admin jedem Projektmitglied Admin, Tester, Viewer oder Kein Zugriff zu.
- Required responder kennzeichnet eine erwartete Antwort; es erzeugt oder konsolidiert keine Entscheidung automatisch.
- Owner ist geschützt und Zugriffsänderungen sind nachvollziehbar.
Sicherheitsregeln
- Teilnehmer erstellen oder ändern ausschließlich die eigene Sitzungsantwort.
- Ein Tester kann Entscheidung und Kommentar eines anderen Testers nicht bearbeiten.
- Owner/Admin verwaltet Sitzungen und prüft erlaubte Antworten; die Urheberschaft bleibt getrennt.
- Die Sichtbarkeit fremder Antworten folgt der Zugriffspolitik; unberechtigte Nutzer öffnen das Projekt auch nicht per Direkt-URL.
Offline- und widerrufener Zugriff
- Zuvor autorisierte Projektdrafts können im selben Browser offline vorhanden bleiben.
- Ein Widerruf löscht Browserdaten nicht sofort, aber der Server weist eine spätere Synchronisierung ab.
- Teilnehmerantworten benötigen derzeit eine erfolgreiche Online-Speicherung.
Unabhängige Entscheidungen und Zählung
- Antworten sind nach Projekt, Sitzung, Teilnehmer und Prüfpunkt-ID getrennt.
- Ein Teilnehmer bleibt Pending, bis er einen Status speichert; danach wird das Ergebnis sofort gezählt.
- Die Status-Schaltflächen heißen Pending, Passed, Rejected, Blocked und N/A. Mit Pending markieren Sie Ihre Antwort wieder als noch nicht geprüft.
- Status speichert sofort, Kommentare nach etwa 800 ms oder beim Verlassen des Felds.
- Bei einem Fehler wird der letzte serverbestätigte Wert wiederhergestellt.
- Tester dürfen fremde Antworten bei entsprechender Sichtbarkeit lesen, aber niemals verändern.
Teilnehmerstatus
| Pending | Noch keine Entscheidung im aktiven Session gespeichert. |
|---|---|
| Passed | Teilnehmer akzeptiert das Prüfergebnis. |
| Rejected | Ergebnis nicht akzeptiert; Korrektur oder Retest erwartet. |
| Blocked | Voraussetzung, Dokument, Konfiguration oder Bedingung fehlt. |
| N/A | Prüfpunkt in dieser Sitzung nicht anwendbar. |
Gemeinsame Prüfkritikalität
Criticality gehört zum gemeinsamen Projektprüfpunkt und zur etablierten Readiness-/Berichtslogik.
| Standard | Normaler FAT-/SAT-Prüfpunkt. |
|---|---|
| Important | Wichtig für Betrieb, Qualität, Dokumentation oder Übergabe. |
| Critical | Failed/Blocked im gemeinsamen Ergebnis blockiert finale Berichtsbereitschaft. |
| Safety Related | Funktionale Sicherheit, z. B. ESD, PSD, F&G, Trip oder Interlock. |
| Cybersecurity Critical | OT-Sicherheitsprüfung, die vor finaler Bereitschaft akzeptiert sein muss. |
Die Testkritikalität dient der praktischen FAT-/SAT-Priorisierung und Readiness-Steuerung. Sie ersetzt weder HAZOP, LOPA, SRS, SIL-Bestimmung, IEC-61511-Verifizierung noch IEC-62443-Konformitätsbewertung.
Ergebnisse und Berichte
- Prüfpunktpanel und Zeilenzusammenfassung zeigen Teilnehmerzahlen der aktiven Sitzung.
- Antworten werden getrennt nach Phase und Person mit Revision History gespeichert.
- Der aktuelle PDF-Bericht nutzt weiterhin das gemeinsame Legacy-/konsolidierte Ergebnis; Teilnehmermatrix und phasengefilterte PDFs sind noch nicht enthalten.
- Owner/Admin bestätigt vor Ausgabe das gemeinsame Ergebnis, ohne die Quellantworten zu verändern.
- Empfohlene Druckeinstellungen: A3, Querformat, eine Seite pro Blatt, Hintergrundgrafiken aktiviert.
Speichern, Verbindung und Wiederherstellung
- Gemeinsame Legacy-Projektänderungen verwenden den vorhandenen Local-first-Workflow.
- Teilnehmerstatus benötigt offene Sitzung, Zuweisung, Ausführungsrecht und erfolgreiche Serverantwort.
- Vor dem Verlassen auf Saved warten; bei Fehler Verbindung und Zugriff prüfen.
- Site-Daten nicht vor Wiederherstellung unsynchronisierter Projektänderungen löschen.
Prüfkonfiguration und technische Unterlagen
Passen Sie die Checkliste an den Anlagenumfang und die freigegebenen Unterlagen an.
- Legen Sie Prüfverfahren, Referenzen, sichtbare Detailfelder, Reihenfolge und Berichtsauswahl der Pakete fest. Erfassen Sie Dokumentnummer, Revision und Verfügbarkeit. Anhänge sind auf Bereichs-, Paket- und Prüfpunkt-Ebene möglich.
- Nutzen Sie Felder für Sicherheitsfunktion, SIL-Bezug und OT-Sicherheit sowie das Modul Cybersecurity FAT/SAT für Zugriffssteuerung, Netzsegmentierung, Härtung und Wiederherstellung. Es ersetzt keine IEC-62443-Zertifizierung. Suche, Filter und Next open / Next failed / Next punch erleichtern die Bearbeitung.
- Prüfen Sie Fortschritt, Kritikalität und Cybersecurity-Zusammenfassungen. Berichtsprofile, Logos, Notizen und Anwesenheits-/Unterschriftsfelder unterstützen die Übergabe; die Unterschriftsfelder sind Projektdaten und kein zertifizierter digitaler Signaturdienst.
Excel importieren und exportieren
Bereiten Sie Prüfpunkte und Prüfverfahren in der Excel-Vorlage vor und importieren Sie die Datei. So entfällt die manuelle Eingabe jedes Prüfpunkts. Owner und Admin können die Punkte und Verfahren danach jederzeit auf der Website ergänzen oder ändern.
- Vorlage oben herunterladen, Blatt- und Spaltenstruktur beibehalten und Daten ergänzen. Owner/Admin importiert über Data tools → Import Excel. Vor einem Import in ein bestehendes Projekt eine Sicherung exportieren; danach Hierarchie, Anzahl, Referenzen und Kriterien prüfen.
- Export workbook enthält den aktuellen gemeinsamen Datenstand und Punch_List, keine Teilnehmermatrix. Die Datei ersetzt weder PDF noch eine vollständige Sicherung der Anhänge; sie enthält deren Namen.
Mängel, Nachweise und Wiederholungsprüfung
Dokumentieren Sie jeden Befund so, dass die nächste Person ihn nachvollziehen kann.
- Bei Rejected oder Blocked Tag, Prüfbedingungen, Soll-/Ist-Werte und Referenz angeben. Im gemeinsamen Datensatz Nachweis, Schweregrad, Verantwortlichen und Termin ergänzen. Rejected aktualisiert weder das gemeinsame Ergebnis noch dessen Mängeleintrag automatisch.
- Nach der Korrektur eine Punch-Retest-Sitzung erstellen und das neue Ergebnis dort erfassen. Ursprüngliche Antworten erhalten; Mängelliste und exportierte Punch_List vor Übergabe abgleichen.
Praxisbeispiel: ein Prüfpunkt, zwei Tester
Zwei erforderliche Tester prüfen einen Hochdruckalarm während des FAT.
- Eine Person speichert Passed; die andere stellt eine zu große Verzögerung fest und speichert Rejected mit Begründung. Beide haben geantwortet, der technische Widerspruch ist aber noch offen.
- Das Team klärt den Befund und bestätigt das gemeinsame Ergebnis nach dem vereinbarten Verfahren. Die Wiederholungsprüfung erhält eine neue Sitzung. Der aktuelle PDF-Bericht verwendet das gemeinsame Ergebnis und keine Matrix dieser Antworten.
Häufige Probleme beheben
Zuerst aktive Phase, Berechtigung und Speicherbestätigung prüfen.
- Antworten sind nur mit Rolle Admin/Tester in einer offenen Sitzung möglich. Viewer lesen nur. Teilnehmer nur im Draft ändern; Closed lässt sich nicht erneut öffnen. Ein Kommentar ersetzt keinen gespeicherten Status.
- Bei Speicherfehler Verbindung, Anmeldung und Projekt-/Phasenrechte prüfen, Antworten aktualisieren und erneut speichern. Gemeinsame Statuswerte: Not Started, Passed, Failed, Punch, Blocked, N/A; individuelle Antworten: Passed, Rejected, Blocked, N/A. Mit Pending markieren Sie Ihre Antwort wieder als noch nicht geprüft.
- Keine kritischen Blocker bedeutet nicht, dass alle Tests und Pflichtantworten vollständig sind. PDF und Teilnehmerzahlen getrennt prüfen. Bei abgeschnittenen Drucktabellen A3, Querformat, eine Seite pro Blatt, Hintergrundgrafiken und Skalierung kontrollieren.
- Lokale Entwürfe bleiben an Browser, Gerät und Website gebunden. Vor dem Wechsel zu kalmanfat.com offene gemeinsame Änderungen unter der alten Adresse synchronisieren oder exportieren. Teilnehmerantworten benötigen eine erfolgreiche Online-Speicherung.
Projektkontrollen und Best Practices
- Phase, Abnahmekriterien und erforderliche Antwortende vor dem Öffnen definieren.
- Pro identifizierbarer Testrunde eine Sitzung; Retest in neuer Sitzung statt Historie zu überschreiben.
- Jeder Teilnehmer dokumentiert eigenes Urteil und begründet Rejected/Blocked.
- Vor dem Schließen Pending-, Rejected- und Blocked-Zahlen kontrollieren.
- Gemeinsame Finalentscheidung und unabhängige Quellantworten getrennt halten.
- Importdaten, Referenzen, Criticality und Berichtseinstellungen vor formellem FAT/SAT prüfen.