IndTrace

Every part, every station, on the record.

IndTrace records what happens to each serialized part as it moves through a PLC-connected production line, and checks every arrival against the part's routing. Your machines and operators stay in charge. IndTrace keeps the history and flags what should not have happened.

  1. WS100Label print
  2. WS200Assembly
  3. WS300Leak test
  4. WS400Vision check
  5. WS500Final pack

Part L1AL100003 reports in at each station. WS200 and WS300 are legal next steps, so IndTrace records them. When the part shows up at WS500 without passing WS400, IndTrace records the arrival as rejected and reports it back to the line.

It tracks. It does not control.

Most problems in traceability come from systems that try to run the line. IndTrace does not. The equipment decides where a part goes; IndTrace decides whether that move was legal, and keeps the evidence.

The line decides

  • The PLC and the operator move the part and run the process.
  • Each station judges its own cycle: pass or fail.
  • When a part reaches a station, the PLC reports it in.

IndTrace records and validates

  • Stores the barcode, station, cycle result, process values and time.
  • Checks the arrival against the product's routing: is this station a legal next step?
  • Answers the PLC with an acknowledgement and a validation result.

It never sends a "go to machine X" command.

What it does, operation by operation

Route card: IndTraceRev. community edition
OpWhat IndTrace doesWhere you see it
010Identify the partRegisters one principal barcode per part. Component and adjacent labels are stored with it, so genealogy is a lookup, not a hunt.BarCode, Reports
020Validate each arrivalChecks every reported arrival against the legal successors in the product's routing, and against the previous station's result.Monitor, Results
030Record the cycleKeeps cycle results, OK and NOK part status, flow status and the process variables each station reports.Reports
040Configure the routingProducts, workflows, machines and PLCs are data, edited in the Configuration screens, not code.Configuration
050Watch the line liveStation status, parts and results stream to the browser over SignalR as they are reported.Dashboard
060Find and export historyFilter by date, product, customer, shift or state, open a part's full history, and export it.Reports

The screens

Captured from the community edition running on a demo database. All companies, products and part numbers in it are fictitious.

Reports. Every serialized part with its status, filtered by date, product, customer, shift or state, ready to export.
Routing. Each workflow row says which machine may follow which, per product. This is what arrivals are checked against.
Line dashboard. One card per station, updated live from the PLC gateway.
Machines. The stations of a line and the role each plays in the routing.
Products. Internal and customer part numbers, per customer.

Walkthroughs

Recorded on the community edition with a simulated line and fictitious demo data. No audio.

A part's journey

Five simulated stations report a part's arrivals; each one is validated. A second part skips the vision check and its arrival at final pack is refused as an illegal successor.

Define a routing

Create a product, add its five stations, connect them in order and mark the first and last station. The new route appears in the configuration.

Trace a part

Find one barcode and open its history: every station, cycle time, result and recorded value.

How it is built

A hexagonal .NET 10 solution. Vendor drivers sit behind a small device contract, so the core never depends on a PLC brand.

IndTrace architecture Line equipment reports to the gateway through the device contract. The gateway calls the application layer, which stores data in SQL Server, and publishes events to the SignalR hub, which feeds the Blazor monitor. Line equipment PLCs, barcode readers Device contract (IndTrace.Devices) Gateway Receives reports, validates, acknowledges Application CQRS handlers, routing rules, Result<T> error flow SQL Server EF Core persistence Hub SignalR event stream Monitor Blazor UI report ack queries

Community edition

Ships an in-memory simulated PLC controller, so the whole stack runs without hardware.

Drivers plug in

Siemens S7 and Cognex DataMan drivers implement the same contract in the commercial edition.

Two dispatchers

PLC traffic and UI requests go through separate CQRS dispatchers, each with its own bounded context.

Built for a plant floor

A wrong record can stop a line or ship a bad part, so the codebase holds a strict gate on every change.

10,895automated tests run in CI on every pull request
0compiler warnings allowed; every warning is an error
Result<T>errors travel as values, never as exceptions across boundaries
AGPL-3.0free to use, study, change and share

Get started

  1. Install the .NET 10 SDK, then clone and build. The build treats warnings as errors.

    git clone https://github.com/Exxerpro/IndTrace.git
    cd IndTrace
    dotnet build Src/IndTrace.sln
  2. Run a test suite. Suites run on Microsoft Testing Platform, so use dotnet run.

    dotnet run --project Src/Tests/Core/Aggregation.BoundedTests/Application.AgregationTests.csproj
  3. Create a demo database and run the line. The getting-started guide starts SQL Server in a container, creates a demo database with a fictitious line, starts the hub, gateway and Monitor, and signs you in.

  4. Send a part down the line. In Simulate a part through the line you play the PLCs: a good part passes every station, a part that skips a station is refused on arrival, and a failed part is reworked.

Who builds it

IndTrace is designed and led by Abel Briones Ramírez at Exxerpro Solutions, after more than 25 years of building automation and traceability for automotive and manufacturing plants. It grew from a system built for one plant into a platform meant for many.