Sechs Monate später
Ihr Kunde fragt nach Seriennummer 0042
Das Gerät hat Ihr Werk längst verlassen, und jetzt liegt die Frage auf dem Tisch: Was genau wurde an diesem Stück geprüft? Ein von Hand gepflegtes Protokoll gerät hier an seine Grenzen, die Antworten stehen verteilt in Tabellen, Mails und Köpfen:
- Lag der gemessene Wert, 4,7 V bei einem Grenzwert von 4,5 bis 5,0, wirklich im Fenster?
- Welcher Firmware-Stand war auf Seriennummer 0042, als sie geprüft wurde?
- Wer hat geprüft, und an welchem Platz?
- Ist überhaupt jeder Schritt abgearbeitet worden?
Bei einer Handvoll Geräten lässt sich das rekonstruieren. Bei 5.000 nicht mehr.
Unternehmen, die auf RX-Systems vertrauen
Kunden von RX-Systems aus unseren Testprojekten.
Woran es liegt
Der Testfall ist da. Die Ausführung fehlt.
In den meisten Embedded-Teams gibt es gute Anforderungen, erfahrene Systemingenieure und oft auch eine Liste mit manuellen Testfällen. Was fehlt, ist die Brücke dazwischen.
Denn ein Testfall als Text ist noch kein Test. Er muss Geräte ansteuern, Signale messen, Schnittstellen überwachen, Bedieneraktionen einbinden, Grenzwerte bewerten und Ergebnisse versioniert dokumentieren.
Dafür entsteht entweder viel manuelle Arbeit – oder jemand baut individuelle Python-, LabVIEW- oder Prüfstandssoftware. Beides kostet: Expertenzeit, Entwicklungsbudget und Release-Durchlaufzeit.
Die Freigabe hängt dann an einzelnen Personen. Bei einer Änderung weiß niemand sicher, welche Tests erneut laufen müssen. Also wird zu viel getestet, zu spät getestet – oder beides.
Die Lösung
Systemtest am echten Gerät: prüfen statt verwalten
Ein Prüfschritt sagt dem Bediener an, was zu tun ist, nimmt den Messwert entgegen und vergleicht ihn mit seinem Grenzwert – oder er liest den Wert selbst, wenn ein Gerät angeschlossen ist. Derselbe Schritt, dieselbe Bewertung.
Aus der Folge dieser Schritte entsteht eine Prozedur, die Sie durchklicken oder laufen lassen: Sie führen die Prüfung aus und belegen sie in einem Durchgang. Das Protokoll entsteht dabei, nicht danach.
Im Bericht ist für jeden Wert erkennbar, ob er gemessen, eingegeben, gesetzt oder abgeleitet wurde – mit Quelle, Zeitstempel und Testkontext. Übernimmt später ein Messgerät denselben Schritt, ändert sich nicht die Prüfung, sondern die Herkunft. Und die steht drin.
Konkret
Ein Prüfschritt ist ein Baustein, kein Skript
Ein Systemingenieur beschreibt, was geprüft werden soll:
Setze die Versorgung auf 24 Volt. Simuliere einen Sensorausfall. Prüfe, ob innerhalb von 100 Millisekunden der sichere Zustand erreicht wird. Zeichne Stromaufnahme und CAN-Signal auf. Der Bediener bestätigt anschließend die optische Warnanzeige.
Daraus entsteht keine undurchsichtige Codedatei, sondern eine lesbare Prozedur aus geprüften Bausteinen:
- Versorgung setzen — Geräteaktion
- Sensorfehler simulieren — Fehler-/Stimulusaktion
- CAN-Nachricht überwachen — Schnittstellenprüfung
- Zeitbedingung bewerten — Zeit- und Grenzwertprüfung
- Strom messen und aufzeichnen — Messung und Aufzeichnung
- Bedienerdialog anzeigen — Bedienerdialog
- Pass/Fail festhalten — Bewertung
- Report und Evidenz erzeugen — Dokumentation
Vor der Ausführung wird nicht Quellcode geprüft, sondern der Testprozess: Was wird gesetzt, gemessen, bewertet und dokumentiert?
Der Fachbereich prüft den Ablauf auf Prozessebene. XPressRT übernimmt die Ausführung auf Geräte-, Schnittstellen- und Prüfstandsebene.
Kontrolle
Wer prüft den Testfall, den die KI geschrieben hat?
Ein generierter Testfall, den niemand liest, ist kein Nachweis. Ein grüner Lauf belegt dann, dass der Code läuft – nicht, dass er das Richtige prüft. Im Audit kommt trotzdem die Frage, wer den Testfall geprüft und freigegeben hat.
Die KI schreibt keinen Code. Sie erzeugt keinen frei generierten Ausführungscode, sondern eine Abfolge definierter und versionierter Bausteine. Jeder Baustein ist ein Satz, den ein Mensch liest; XPressRT erzeugt daraus den ausführbaren Schritt. Fehlt ein Baustein für das, was ein Schritt braucht, hält die KI an und sagt welcher – sie baut sich keinen.
Die Freigabe ist an ihren Stand gebunden. Festgehalten wird, wer welchen Schritt freigegeben hat, mit dem Fingerabdruck der Bausteine und des daraus erzeugten Codes. Ändert sich danach ein Baustein oder der Ablauf, wird die Freigabe als nicht mehr gültig erkennbar und der Schritt muss erneut geprüft werden.
Gelesen wird von allen. Die Bausteine kann auch prüfen, wer nicht programmiert: Qualitätssicherung, Zulassung, der Auditor.
Was das im regulierten Umfeld bedeutet: Wer gibt einen KI-Testfall frei?
Umstieg
Ihre bestehenden Prüfabläufe wandern mit
Ihre Prüfanweisungen stehen in Word-Tabellen und Excel-Blättern. Geben Sie eine davon Ihrem KI-Assistenten – Claude, Copilot, was Sie ohnehin nutzen. In einem ersten Durchgang entsteht in wenigen Minuten ein strukturierter Prüfentwurf: Schritte, Grenzwerte, Datenpunkte. Ihr Team prüft ihn, ergänzt bei Bedarf und gibt ihn frei. Das ist zugleich das Review, das Ihr Prozess ohnehin verlangt.
XPressRT betreibt kein eigenes KI-Modell und verarbeitet Ihre Quelldokumente nicht auf unseren Systemen. Welcher KI-Dienst genutzt wird und welche Daten ihn erreichen, bestimmen Sie über Ihre eigene Unternehmensumgebung und die dort geltenden Richtlinien.
Die Quelldatei bleibt am importierten Testfall hinterlegt. Freigegebene Testfälle bleiben freigegeben, statt neu geschrieben zu werden.
Sie führen Ihre Prüfprotokolle heute in Excel? So lösen Sie sie ab.
Loslegen
Browser auf, und los
Die kostenlose Demo-Version von XPressRT läuft vollständig im Browser – die Oberfläche und der Testlauf selbst.
- Keine Installation. Nichts einzurichten, keine IT-Freigabe.
- Kein Konto. In der freien Version melden Sie sich nirgends an.
- Keine Cloud. Ihre Prüfabläufe und Ergebnisse liegen auf dem Rechner, an dem geprüft wird. Es gehen keine Daten an uns.
- Mit Git versionierbar. Ein Arbeitsbereich ist ein Ordner mit Textdateien.
git initgenügt, und jede Änderung an einer Prüfung ist nachvollziehbar.
Was Sie davon haben
Der Nutzen in vier Achsen
Spart sofort Zeit
Das Protokoll entsteht während der Prüfung. Der größte Zeitblock beim manuellen Prüfen ist das Nacharbeiten: Werte übertragen, Tabelle bauen, Bericht schreiben. Der entfällt. Ein neuer Prüfschritt braucht keinen Entwickler: Sie wählen aus und füllen aus, statt zu programmieren. Kein Warten auf den einen Kollegen, der Python kann.
Verhindert teure Fehler
Der ausgelassene Schritt, der geschätzte statt gerechnete Messwert, das Protokoll ohne Zuordnung, der Prüfling im Zustand des vorigen. Und der teuerste von allen: das stille Grün. Ein abgebrochener Schritt ist rot. Ein Lauf, in dem nichts ausgeführt wurde, meldet „nicht gelaufen“ statt „bestanden“.
Reduziert Ihr persönliches Risiko
Wer unterschreibt, muss sich nicht erinnern: Der Nachweis entsteht im Moment der Prüfung. Was auffiel, steht an dem Schritt, bei dem es passierte. Und der Bericht funktioniert ohne Sie: Qualitätssicherung, Kunde oder Auditor lesen ihn, ohne die Person zu fragen, die den Test gebaut hat.
Trägt die Freigabe
Je Gerät: jeder Schritt mit Ergebnis, Istwert gegen Grenzwert, Seriennummer, Produkt und Version, Prüfer, Prüfplatz, Zeitstempel. Daneben maschinenlesbar JUnit-XML und ein Rohprotokoll. Prüfpläne sagen, was für eine Freigabe geprüft sein muss und wie weit es ist; ein geschlossener Zyklus friert den Stand ein und bleibt zitierbar. Das unterstützt die nachvollziehbare Verknüpfung von Anforderungen, Risiken, Prüfschritten und Nachweisen – zum Beispiel im Rahmen eines Prozesses nach IEC 62304 oder IEC 61508.
Selbst bauen?
Für einen Test können Sie das selbst. Für zwanzig?
Ihr Team kann in wenigen Wochen einen Python-Prototyp bauen, Geräte über APIs ansprechen und einen ersten Report erzeugen. Das stimmt, und mit KI stimmt es mehr als früher.
Die Frage ist eine andere: Wollen Sie bei jedem Produkt, jeder Schnittstelle, jedem neuen Messgerät und jeder Release-Regression wieder eigene Testsoftware entwickeln, reviewen, qualifizieren und warten?
| Selbst gebaut | Mit XPressRT |
|---|---|
| Schnell für einen Anwendungsfall | Wiederverwendbar über Produkte und Releases |
| Testwissen steckt in Code und in einzelnen Köpfen | Ablauf ist fachlich lesbar und auf Prozessebene prüfbar |
| Jedes neue Gerät ist Entwicklungsaufwand | Standardisierte Anbindung |
| Reports und Auswertung projektweise ergänzt | Einheitlich von Ausführung bis Bericht |
| Wartung konkurriert mit der Produktentwicklung | Dafür gebaut |
| Änderungsauswirkungen manuell analysiert | Anforderungen, Tests und Regression verknüpft |
| Qualifizierung selbst aufbauen | Kontrollierte Bausteine, Versionierung, Review, Evidenz gehören dazu |
Für einen einzelnen, stabilen Prüfablauf ist ein Eigenbau oft sinnvoll. XPressRT wird interessant, sobald Prüfungen produktübergreifend, variantenspezifisch, wiederkehrend, nachvollziehbar oder regulatorisch relevant werden.
Warum jetzt
Die Nachweislast wächst schneller als die Prüfkapazität
Mehr Funktionen, dieselbe Prüfmannschaft
KI-gestützte Entwicklung erzeugt mehr Features pro Release. Geprüft werden müssen sie trotzdem, am echten Gerät, von Menschen. Der Engpass verschiebt sich vom Bauen zum Nachweisen.
Jedes Update ist eine neue Prüfung
Ab dem 11. Dezember 2027 verlangt der Cyber Resilience Act Sicherheitsupdates über den gesamten Supportzeitraum. Jedes davon ändert ein Gerät im Feld – und jedes braucht einen Nachweis. Wer den von Hand führt, kann sich Updates kaum leisten.
Word und Excel skalieren nicht mit
Bei einer Handvoll Geräten trägt ein Protokoll aus Tabellen. Bei Gerätevarianten, Firmwareständen und wiederkehrenden Prüfungen wird daraus Handarbeit, die niemand mehr überblickt – und die im Audit nicht mehr zusammenzusuchen ist.
Was XPressRT nicht ist
Ihr Anforderungssystem bleibt, wo es ist
Polarion, Codebeamer, Jama oder DOORS ersetzen wir nicht. Ihre Anforderungen bleiben dort, und wir schreiben nichts zurück. XPressRT legt die Ausführungs- und Nachweisebene darüber: Ein Testfall trägt seine Marken, ein Plan zeigt, was davon belegt ist.
Und ebenso klar: XPressRT liefert keine Instrumente und keinen Prüfstand. Wo Sie gegen echte Embedded-Firmware prüfen, ergänzt LoopCheck (Hardware-in-the-Loop) die Signalseite. Und wenn Sie den Prüfaufbau, die Testfälle und die Nachweise nicht selbst bauen wollen, übernehmen wir das als ganze Testumgebung.
Was gerade entsteht
Dieselben Testfälle, gleich an echter Hardware
Ein Schritt sagt, was zu tun ist; der Prüfstand sagt, womit. Die Naht dazwischen ist der Datenpunkt: eine benannte Größe mit Einheit und Bereich. Heute liest ein Mensch den Wert ab, morgen ein Gerät. Der Testfall bleibt derselbe. Am Runner, der diese Punkte an Hardware bindet, arbeiten wir.
Preis
Frei wird geprüft, bezahlt wird bewiesen
Kostenlos: XPressRT im Browser. Prozeduren anlegen, durchführen, protokollieren. Ohne Konto, ohne Installation, dauerhaft.
Lizenz: Betrieb im eigenen Netz, Anbindung von Messgeräten und Prüfständen, Support.
Ihre Prozeduren und Ergebnisse liegen als Dateien bei Ihnen. Auch ohne uns bleiben sie lesbar.
Anfangen zu prüfen, statt Prüfungen zu verwalten
Alles Schritt für Schritt: im XPressRT-Handbuch führt ein vollständiges Beispiel durch jede Funktion – von den Bausteinen bis zur Freigabe. Oder Sie öffnen die kostenlose Version und legen gleich eine Prozedur an.
Häufige Fragen zu XPressRT
Was ist XPressRT?
XPressRT ist eine Prüfsoftware, mit der Teams ihre Prüfabläufe am Gerät ausführen, statt sie nur abzulegen. Ein Testfall besteht aus Schritten; jeder Schritt fragt einen Messwert ab oder prüft ihn gegen seine Grenze. Am Ende steht je Prüfling ein prüffähiger Nachweis mit Wert, Grenze, Seriennummer und Prüfer.
Was kostet XPressRT?
Prüfabläufe anlegen, von Hand testen und dokumentieren ist kostenlos und ohne Konto. Bezahlt wird erst, wenn ein Unternehmen einem Dritten etwas nachweisen muss – mit Freigabe und Signatur, Rollen und Stationen, Kalibrierstatus und Normzuordnung – oder XPressRT als eigene Instanz betreiben will.
Gibt es eine kostenlose Demo-Version?
Ja. Die kostenlose Demo-Version läuft im Browser, ohne Installation und ohne Konto – und ist dauerhaft kostenlos, nicht zeitlich begrenzt. Bezahlt wird erst, wenn Sie gegenüber einem Dritten formal nachweisen wollen.
Braucht XPressRT eine Installation oder ein Konto?
Nein. XPressRT läuft vollständig im Browser – keine Installation, kein Konto, keine Cloud. Prüfabläufe und Ergebnisse bleiben auf dem Rechner, an dem geprüft wird.
Lassen sich manuelle und automatisierte Tests mischen?
Ja. Derselbe Testfall kann von Hand, teilautomatisiert oder voll am Prüfstand laufen – es ändert sich nur, wer die Werte liefert (Mensch oder Gerät). Der Testfall muss dafür nicht neu geschrieben werden.
Wofür eignet sich XPressRT?
Für Systemtests und End-of-Line-Prüfungen an Embedded-Geräten, bei denen je Gerät ein prüffähiger Nachweis entstehen muss – etwa in der Medizintechnik oder bei sicherheitsgerichteten Geräten.
Taugt der Nachweis für eine Verifikation nach IEC 62304?
XPressRT dokumentiert Prüfabläufe und Ergebnisse nachvollziehbar: Prüfling, Seriennummer, Software- bzw. Firmwarestand, Messwerte, Grenzwerte, Prüfer, Zeitstempel und Verknüpfungen zu Anforderungen. Damit unterstützt XPressRT die Evidenz für Ihren Verifikationsprozess. Ob ein erzeugter Nachweis für Ihren konkreten Verifikationsplan ausreicht und in welchem Umfang XPressRT in Ihrem QM-System qualifiziert oder validiert werden muss, hängt vom vorgesehenen Einsatz, Risiko und Systemkontext ab. Wir unterstützen Sie auf Wunsch mit den Unterlagen und einem passenden Vorgehen.
Wie kommt XPressRT an unsere Messgeräte?
Über einen Runner, der bei Ihnen im Labor läuft und die Instrumente anspricht. Ohne ihn führen Sie dieselben Prozeduren von Hand aus.
Was kann ich mit KI-Agenten in XPressRT machen?
Ihr KI-Assistent – Claude, Copilot, was Sie ohnehin nutzen – verbindet sich über MCP direkt mit Ihrem Arbeitsbereich und arbeitet an den Prüfabläufen mit: bestehende Word- und Excel-Abläufe in ausführbare Schritte übersetzen, neue Schritte anlegen, deren Logik als lesbare Bausteine schreiben und bauen, Hilfsdaten und Module ergänzen. Jeder Baustein ist ein Satz, den ein Mensch liest – kein undurchsichtiger Code. Fehlt ein Baustein für das, was ein Schritt braucht, hält der Agent an und sagt welcher, statt sich einen eigenen zu bauen.
Wo läuft der KI-Agent, und was darf er nicht?
Der Assistent läuft bei Ihnen, nicht bei uns – wir betreiben kein Modell und sehen Ihre Dokumente nicht. Und er arbeitet in klaren Grenzen: Freigeben kann nur ein Mensch, fertige Prüfergebnisse bleiben unveränderlich, und die Prüfabläufe selbst schreibt die Oberfläche. Der Agent schlägt vor und setzt Bausteine; die Unterschrift bleibt bei der Person, die gegenliest.
Gibt es ein Handbuch?
Ja. Das XPressRT-Handbuch führt durch jede Funktion, mit einem vollständigen Beispiel – nachzulesen unter xpress.rx-systems.de.