Reference architecture
DataBrain On-Prem Architecture
How test data moves from the furnace to a signed report when every component, including the language model, runs on a server inside the laboratory.
Proposed reference architecture, for discussion. It describes how DataBrain is intended to be deployed on premises; it is not a description of a delivered installation. Server sizing and interface options are engineering proposals to be confirmed per project.
Why on premises
Four constraints that decide the architecture
A fire testing laboratory is not an ordinary IT environment. Four properties of the work rule out a cloud-hosted analysis platform before any feature is discussed.
Specimen confidentiality
Specimens are pre-market products. Curves, photographs and failure times are a client's commercial secret and are frequently covered by NDA. They cannot be processed on infrastructure the laboratory does not control.
Traceability
An accredited laboratory must be able to show where a report's numbers came from and who approved them. A single, auditable store inside the laboratory is easier to defend than an external service.
The control loop is untouchable
Furnace control, alarms and interlocks are safety functions. Anything added for analysis must be strictly read-only, so it cannot influence a running test.
The test hall is not the office
A test runs for hours and cannot pause for a connectivity problem. The analysis layer must keep working with the internet uplink unplugged.
Figure 1
Zones and the data path
DataBrain sits on the laboratory network and reads from the control system. There is no return path: the PLC receives nothing from DataBrain, so the safety and control behaviour of the furnace is unchanged by its presence.
Figure 2
Inside the DataBrain server
Two kinds of input meet on the server: what the instruments measured, and what the laboratory knows, meaning its standards, its templates and its own approved test history. The language model reads only from that second set; it never sees anything the laboratory has not put there.
Figure 3
One test, end to end
The seven DataBrain steps mapped onto who does what during a single test. The top lane never changes: the furnace and its PLC behave exactly as they would without DataBrain installed.
Scope of the model
What the local model does, and does not do
Worth stating plainly in front of a technical buyer, because it is the first question an accreditation body will ask.
It does
- Draft report sections from the test record, in the laboratory's own template and wording.
- Retrieve comparable earlier tests: same specimen family, same standard, same furnace.
- Describe a deviation in plain language, with a link to the measured values behind it.
- Answer questions over the laboratory's own history, such as whether this behaviour has been seen before.
- Turn shorthand operator notes into structured, timed observations for review.
It does not
- Touch the furnace. It has no path to the PLC and no control function whatsoever.
- Decide pass or fail, or assign a classification.
- Alter measured data. Stores are append-only; drafts reference values, they do not rewrite them.
- Send anything outside the laboratory. No external inference, no telemetry of test content.
- Replace the reviewer. Every output is a draft until an authorized engineer approves it.
Integration
Interfaces
Existing furnaces are connected by whichever of these the installed control system already offers; none of them requires a change to the PLC programme.
- Source
- PLC / SCADA
- Interface
- OPC UA read-only client
- Direction
- in
- Carries
- live channel values, setpoints, actuator positions
- Source
- PLC / SCADA
- Interface
- Modbus TCP
- Direction
- in
- Carries
- live channel values where OPC UA is not available
- Source
- Historian / data logger
- Interface
- file export (CSV, XLSX)
- Direction
- in
- Carries
- per-minute tables after the test
- Source
- Cameras
- Interface
- RTSP or watched folder
- Direction
- in
- Carries
- stills and clips tied to the test clock
- Source
- Test engineer, reviewer
- Interface
- web UI over the lab LAN
- Direction
- in / out
- Carries
- observations, photographs, edits, approvals
- Source
- Laboratory library
- Interface
- file import
- Direction
- in
- Carries
- standards, procedures, report templates
- Source
- LIMS / QMS (optional)
- Interface
- file drop or REST
- Direction
- out
- Carries
- the approved report and its metadata
- Source
- STARKOS support (optional)
- Interface
- outbound VPN, per session
- Direction
- out
- Carries
- diagnostics and logs, on the laboratory's request
Hardware
Server sizing
One server per laboratory, in the laboratory's own rack. Two working points depending on how large a model the site wants to run; the rest of the platform is identical.
- Component
- Form factor
- Baseline
- 1U or 2U rack server
- Larger model
- 2U rack server
- Component
- CPU
- Baseline
- 16 cores
- Larger model
- 32 cores
- Component
- Memory
- Baseline
- 128 GB
- Larger model
- 256 GB
- Component
- Storage
- Baseline
- 2 × 2 TB NVMe, mirrored
- Larger model
- 2 × 4 TB NVMe, mirrored
- Component
- GPU
- Baseline
- 1 × 24 GB VRAM
- Larger model
- 1 × 48 GB VRAM
- Component
- Model class
- Baseline
- 8–14 B, quantized
- Larger model
- 30–70 B, quantized
- Component
- Network
- Baseline
- laboratory VLAN, no inbound route from the internet
- Larger model
- same
- Component
- Power
- Baseline
- on the laboratory UPS
- Larger model
- same
A laboratory that prefers not to run a GPU can deploy the same platform without the model: analysis, comparison, the observation timeline and template-based report assembly all work without it. The model adds drafting and retrieval, not the measurement chain.
Operations
Running it
- Installation.
- Commissioned with the furnace, or retrofitted alongside a control-system modernization on an existing furnace of another make.
- Updates.
- Software and model files are delivered as signed packages and applied offline; no update requires an internet connection on the server.
- Backup.
- The stores are backed up to the laboratory's own target. Test records are append-only, so a restore reproduces the record as it stood at sign-off.
- Retention.
- Set by the laboratory. The retrieval index rebuilds from whatever remains, so a retention policy is a laboratory decision rather than a platform constraint.
- Support.
- The outbound tunnel is opened by the laboratory for a session and closed afterwards; STARKOS never holds a standing route into the laboratory network.
- Failure behaviour.
- If the DataBrain server is offline, the furnace continues to run and record on its own control system. Nothing about the test depends on it.
Before this goes to a customer
Open points
- Which model family and licence STARKOS standardizes on, and whether the laboratory may substitute its own.
- Whether the read path is an OPC UA client, a historian export, or both, and which is offered as standard.
- Whether a hardware data diode is offered for laboratories that require a physically one-way link.
- Whether the report template is imported from the laboratory or supplied by STARKOS as a starting point.
- Which parts of this architecture are implemented today and which are roadmap. The site makes no claim of an installed base.
This page is a proposal and is not indexed by search engines. Confirm the open points before sending it to a customer.
DataBrain
Discuss DataBrain for Your Laboratory
Tell us about your laboratory, your furnaces and your reporting workflow. DataBrain is scoped together with a new furnace or a control-system modernization.