Unit-level traceability, factory provisioning and yield MES for electronics and IoT
Your line can't build an obsolete revision. And it can't ship the same MAC address twice.
Device Fabrik Link is a unit-level traceability, factory provisioning and yield MES for electronics and IoT manufacturers and their EMS partners. Your test benches claim the serial numbers, MAC addresses and firmware over a REST API, then post every result, measurement and log back against the unit that received them — including on a line you don't own.
- On your own infrastructure or a private cloud
- A REST API for the benches you already run
- Each partner sees only its own production
- Unit by unitSteps, measurements, retries, bench and timestamp
- MAC · DSN · ZigBeeAtomic allocation from your identifier pools
- ECO + firmwareAn unauthorised revision simply cannot be built
- 4 kinds of callThat is an existing test bench integrated
- 94.2%Completed without errors
- 3.1%Completed with rework
- 2.7%Uncompleted units
- 6 min 12Average operation time
- Clean run
- With rework
- Uncompleted
- Single pass
Illustrative view — sample data.
The problem
Your line produces data every second. You see almost none of it.
Between the test bench and the weekly report, the part that matters disappears: what was tested, what failed, what was reworked — and with which firmware.
-
A field return, and no answer
The device comes back from the field. Which firmware? Which bench? Which measured values? Without a unit-level history, the investigation stops at guesswork.
-
Identifiers managed by hand
MAC addresses, serial numbers and certificates live in shared spreadsheets. One duplicate is enough to bring a whole batch back.
-
A yield nobody measures
With no first pass yield, and no view of the steps that fail most, a drifting test costs weeks of production before anyone can even see it.
-
Revisions that drift apart
One bench does not run the same firmware as the one next to it, and the factory is still building the old revision. You find out at final QC. Or at the customer.
DFL closes the loop: the bench records, the platform keeps, and you answer in seconds instead of weeks.
How it works
Four steps between your test bench and the proof
Your benches stay yours. DFL adds the layer that records, allocates and proves.
-
Register your benches
Every test station gets a name, a secret token and, if you want it, a MAC address that binds it to one machine. A compromised token is revoked without touching the other stations.
Portal → Benches → New bench -
Describe the product
A pipeline defines the expected sequence of steps and which one counts as completion. An ECO freezes the revision, the authorised factory and the firmware that goes with it.
ACTIVE status = production allowed -
Produce
The bench requests an ASN for the unit, downloads the right firmware, draws its identifiers and posts every step with its result and its measurements. Retries are kept, not overwritten.
GET /v1/uuid → POST /v1/step -
Analyse and prove
First pass yield, a Pareto of failures by step, week-over-week and month-over-month comparison, and the full history of any unit in a single search.
Portal → Analytics · Library
The platform
Everything it takes to run an electronics production line
A web portal for your teams, a REST API for your benches, one database per product.
-
Unit-level traceability
Every unit gets its own record: steps, results, measurements, retries, bench and timestamp.
- Search by ASN or by factory serial number (FSN)
- Every attempt kept, not just the last one
- Custom columns driven by your product parameters
-
Identifier provisioning
MAC addresses, DSNs, ZigBee certificates and install codes are allocated atomically from your pools.
- Idempotent allocation: a retry burns no address
- Several MACs per device through a per-port sub-identifier
- Empty pool: a call returns an error instead of a duplicate
-
Analytics and yield
Clean run, with rework, uncompleted: three states that add up to 100% of your units.
- First pass yield per product and per period
- Ranking of the steps that fail most often
- Week-over-week and month-over-month comparison
-
ECO management
An ECO freezes a production configuration: revision, authorised factory, firmware, labelling data.
- CREATED → ACTIVE → CLOSED lifecycle, closing is final
- Only an ACTIVE ECO lets a bench produce
- The factory code limits who is allowed to build
-
Bench fleet
Every test station is registered, authenticated and monitored, wherever it sits in the world.
- One secret token per bench, optional MAC binding
- Last access and call counter to spot a silent bench
- Location, model, OS and maintenance date
-
Firmware distribution
Firmware is attached to the ECO: a bench downloads exactly the build intended for what it is producing.
- Version and checksum delivered with the binary
- Production firmware is immutable once published
- Replacement is limited to QA-type ECOs
-
Product kits
Group several products into one traceable assembly with its own serial number.
- Kit ASN derived from the kit code, year and week
- Traceability both ways between a kit and its units
- Created from the portal or from a bench
-
Roles and partitioning
One account per manufacturing partner: it only sees the products assigned to it.
- Admin, manufacturer and read-only roles
- Partitioning enforced on direct URL access too
- A separate database per product
-
REST API
Fourteen documented JSON routes, callable from whatever language your benches already speak.
- Bench token authentication on every single call
- A reference Python client shipped as a starting point
- History stays queryable by ASN or by FSN
Analytics
Yield, not just volume
Counting the units that came off the line says nothing about what they cost. DFL separates what passed on the first attempt from what needed rework, and from what was never finished — three states that add up to exactly 100% of the period's units.
The comparative view puts four weeks or four months side by side, with rates normalised per unit produced: a month with twice the volume cannot disguise itself as a quality problem.
- First pass yield, per product and per period
- Uncompleted units that were never retested, isolated from the rest
- The steps that fail most, ranked by units affected
- A cross-product dashboard, one row per product
- PDF export straight from the browser, no external service
| Metric | Wk-3 | Wk-2 | Wk-1 | This week | Trend |
|---|---|---|---|---|---|
| Completed, clean run | 1,204 | 1,318 | 1,402 | 1,511+1.8 pp | |
| Completed with rework | 96 | 88 | 71 | 62−0.9 pp | |
| Uncompleted units | 41 | 37 | 44 | 39−0.3 pp | |
| RF_TEST — errors | 63 | 58 | 71 | 44−1.6 pp | |
| FINAL_QC — errors | 12 | 9 | 14 | 22+0.5 pp |
Needs attention: FINAL_QC is up 0.5 pp. Improving: RF_TEST, −1.6 pp. Sample data.
Device identity
One identifier per device. Never the same one twice.
MAC addresses, serial numbers and ZigBee certificates live in pools you load up front. Every allocation is locked: two benches asking at the same instant get two different identifiers.
Allocation is idempotent. When a unit comes back to the bench after a dropped connection or a failed test, it gets its own address back instead of burning a new one — and a device with several ports gets one address per port.
- Pools of MAC (EUI-64), DSN, ZigBee certificates and install codes
- A retry never consumes an identifier
- Several identifiers per unit, one per declared sub-part
- Import and monitor pools from the portal
- Empty pool: the call returns an error instead of an address — treat that as a stop condition in your bench software
Latest allocated identifiers
- MAC70:B3:D5:2A:11:04allocated
- DSNDSN-24W31-000428allocated
- ZIGBEEcertificate + install codeallocated
Illustrative view — sample data.
ECO and firmware
The factory can only build what you authorised
An ECO describes one production configuration: product, revision, authorised factory, firmware, labelling data. Until it is ACTIVE no bench can use it, and once it is closed it does not reopen.
Firmware is attached to the ECO, not to the bench. A station cannot flash a build it kept locally, and production firmware cannot be quietly replaced.
- CREATED → ACTIVE → CLOSED lifecycle, closing is irreversible
- A bench call carrying a non-active ECO is rejected
- Firmware is delivered with its version and checksum
- Only QA-type ECOs accept a firmware replacement
- The factory code restricts who is allowed to produce
- ProductUBRIDGE-200 rev. C
- Authorised factoryFCT-02
- Firmwareub200-1.8.4 · sha256
- Benches attached6
A bench can only produce with an ECO in ACTIVE status.
Illustrative view — sample data.
On video
See the platform before we talk about it
Four short walkthroughs: what a production manager sees, what a test engineer sees, and what a bench actually does.
-
soon
-
soon
-
soon
-
soon
Would you rather see your own products and your own numbers? Book a guided demo
For your engineering team
A test bench connects in four kinds of call
The API is JSON over HTTPS: call it from Python, C#, LabVIEW or whatever script already runs on your stations. No agent to install, no hardware to replace.
Every request carries the bench identity and the ECO in use. If the ECO is not active the call is rejected — the production rule is enforced by the server, not by operator discipline.
- Fourteen documented routes under /v1/, JSON responses
- Bench token on every call and optional MAC verification
- A reference Python client shipped as a starting point
- History queryable by ASN or by factory serial number
# 1. The unit arrives on the bench: get its ASN
curl -X GET https://your-instance/v1/uuid \
-H "Content-Type: application/json" \
-d '{
"bench": { "name": "DFL-PB-0022", "token": "..." },
"eco": { "ecoID": "ECO-2417" },
"asn": { "fsn": "SN-240731-0428" }
}'
# -> 200 { "asn": "UB200-24W31-0428", "productRevision": "C" }import requests
BENCH = {"name": "DFL-PB-0022", "token": TOKEN}
ECO = {"ecoID": "ECO-2417"}
# 1. A unique serial number for the incoming unit
asn = requests.get(f"{DFL}/v1/uuid", json={
"bench": BENCH, "eco": ECO, "asn": {"fsn": fsn},
}).json()["asn"]
# 2. A MAC address, allocated atomically and idempotently
mac = requests.get(f"{DFL}/v1/provisioning/mac", json={
"bench": BENCH, "eco": ECO, "asn": {"asn": asn}, "subId": "eth0",
}).json()["eui64"]
# 3. Every test step is posted with its measurements
requests.post(f"{DFL}/v1/step", json={
"bench": BENCH, "eco": ECO,
"step": {"asn": asn, "stepName": "RF_TEST",
"stepResult": "PASS",
"stepData": {"rssi_dbm": -41.2, "channel": 36}},
})Illustrative excerpt — the full reference ships with the platform.
Security and deployment
Your production data stays with you
DFL installs on your own infrastructure or in a private cloud. No production data needs to leave your perimeter.
-
HTTPS end to end
Both the portal and the bench API only start over TLS, with your own certificates.
-
One token per bench
Each station holds its own secret; it can be bound to the machine's MAC address and revoked on its own.
-
Restricted to your networks
The bench API is a standard HTTPS service: restrict it to your factory networks at your own firewall or reverse proxy.
-
ECO gate
A non-active ECO blocks production: the rule is enforced server side, on every call.
-
Per-product isolation
Every product has its own database, and manufacturer assignment partitions who sees what.
-
On your servers, no lock-in
Portal, API and database run on your own machines; configuration secrets are encrypted at rest.
By role
One platform, four different readings
The same record serves production, quality, test engineering and your manufacturing partner.
-
Production
See the line without waiting for a report
- Today's volume and today's yield
- Silent benches spotted through their last access
- Direct comparison between weeks or between months
-
Quality
Prove it, don't claim it
- A complete record for every unit when one comes back
- The most failure-prone steps, ranked by units affected
- Reference units excluded from the statistics
-
Test engineering
Instrument once, use everywhere
- Free-form measurements attached to every step
- Every attempt kept, retries included
- A stable API instead of a homegrown export
-
Manufacturing partner
Ship the proof with the boxes
- Access limited to the products entrusted to you
- Your customer sees exactly the numbers you see
- No weekly report to rebuild by hand
Demo
Let's see what this would look like on your line
Thirty minutes over a video call: you describe your line and your benches, we show the platform on a product close to yours, and we tell you plainly what would need development on your side.
We answer quickly, usually within a couple of business days. No automated sales sequence.
Frequently asked questions
What manufacturers ask us
Traceability, integration, deployment, data: straight answers.
What exactly is Device Fabrik Link?
How is this different from an ERP or a shared spreadsheet?
Do we have to replace our existing test benches?
Can we host it on our own servers?
What is an ECO and why does it gate production?
How are MAC addresses, serial numbers and certificates handled?
Can our manufacturing partner use the platform without seeing our other products?
What happens if the network goes down during production?
Can we export or re-query the data?
What does it cost, and how long does it take to start?
Take back control of what your factory builds
A thirty-minute demo is enough to know whether DFL fits your production. If it does not, we will say so.