Solutions · Test systems
The test rig interface and its measurement record
On a test rig the value is not in the measurement itself but in its record and its approval. Bella SCADA holds the test scenario as a recipe, writes measurements to the historian and gates the approval step behind an electronic signature.
On a test rig the problem is the record, not the measurement
Test rigs generally work: the instrument is connected, the value is read, the operator watches the screen. The trouble starts afterwards — which scenario was applied to which sample, which limits were in force that day, who approved the result, and where the record comes from when the customer asks.
A spreadsheet-based record answers none of those in an auditable way: the file is edited, nobody knows by whom, and versions multiply.
In Bella SCADA the test scenario is defined as a recipe and written to the rig in one action; the applied recipe is recorded. Measurements go to the historian and are compared period against period in the trend screen. The approval step can be gated by an electronic signature policy: a write to a policy-covered tag without a signature is rejected with HTTP 428, and the ledger holds user, reason and timestamp.
The audit log is hash-chained, so an entry edited after the fact breaks the chain.
Typical architecture
One installation per rig, or one server for the whole lab — both work.
1 · Measurement and control
The rig PLC, power supply, load cell, temperature and pressure instruments. Read directly over Modbus TCP, third-party measurement software through the OPC UA client, and networked devices over MQTT.
2 · Scenario
A test scenario is a recipe: setpoints, limits and durations collected into one parameter set. When the sample type changes the recipe is written in one action, and which recipe was applied when stays in the record.
3 · Record
Measurements go to the historian; logging interval and deadband are set per tag, so a fast-moving load signal and ambient temperature are not logged at the same rate.
4 · Approval and output
The approval step is bound to an electronic signature. Output is trend charts, alarm history and Excel/PDF reports, which can be sent on a schedule.
Protocols used in this vertical
On the laboratory side these drivers cover the ground.
| Protocol | Typical device | Direction | Field validation |
|---|---|---|---|
| Modbus TCP | Rig PLC, power supply, measurement modules | Read + write | Not done |
| OPC UA (client) | The OPC UA server of third-party measurement software | Read + write | Not done |
| MQTT | Networked sensors and data collectors | Read + write (publish) | Not done |
| Modbus RTU | Serial-port instruments | Read + write | Not done |
The drivers are verified by build and simulation tests; none has yet been tested against real field hardware. We say this at quotation stage: the first task in a pilot is a connection test against your own device. The current matrix lives on the protocols page.
What ships in the box
Rig screen
A test screen built in the editor: live measurements, setpoints, start and stop controls. It opens full screen (kiosk) on the panel next to the rig.
Recipes
A list of test scenarios; the selected one is written to the rig in a single action. The record holds which recipe was applied, when and by whom.
Trends and measurement history
Historical charts of measurements, with different tests compared on the same axis.
Electronic signature ledger
An append-only record of signed operations: user, reason, timestamp and the related operation reference. Which operations require a signature is set in the write policy screen.
Reports
Alarm history and trend reports as Excel or PDF on a schedule. There is no free-form designer for a test-certificate layout — that is a project line item.
Recommended package
Plant — unlimited tags, clients and screens; recipe management; historian; reporting and scheduled e-mail; scripting engine; REST API key. The price band is on the pricing page.
For a single rig with a handful of measurement points, Machine / Edge may be enough — but the reporting module is not in that package, so if the test record has to be reported you need Plant.
Before making a 21 CFR Part 11 claim in regulated industries we say this plainly: the electronic signature infrastructure and the write policy exist and are bound to the write path, but the product has not been through an audit on this. Any compliance claim should be assessed with your own auditor.
Frequently asked
Does the operator pick the test scenario, or is it applied automatically?
Today the operator selects and applies a recipe from the recipe screen, and the application is recorded. A fully automatic chain — the recipe writing itself when a sample is scanned — could be scripted, but the scripting engine is not yet persistable or event-triggered; it is a console you run by hand. Script persistence and triggers are on the roadmap.
Can you really lock the approval step?
Yes. Once a signature policy covers a tag or operation, a write request without a signature id is rejected with HTTP 428. The signature record holds user, reason and timestamp and references the audit log.
Can we pull measurement data into our own analysis tools?
Historical and live data can be read through the REST API key. Tags can also be exposed as variable nodes through the OPC UA server, or published over MQTT/UNS — both ship disabled and neither has been validated against a real external client.
How many channels can you log, and how fast?
We measured it: the historian sustained about 230 rows per second, roughly 20 million rows and 4.5 GB per day uncompressed. What we did not measure is the concurrent channel count — driven from a single machine the test hit our own API rate limiter, so the number would have reflected a deliberate protection rather than capacity. If you have a hard rate requirement we run a test on that scenario before the pilot.
Can a measurement record be deleted?
The signature ledger is append-only and the audit log is protected by a hash chain. On the historian side a retention policy can be defined — meaning data does age out by policy. If a record must never be dropped, retention is set accordingly.
Let us try it on your rig
Share the protocol your instruments speak and one typical test scenario; we will set that scenario up as a recipe and look at the measurement record together.