Knowledge from practice

The transport index (TI) tells a carrier how much radiation a package gives off. It is the highest dose rate at one metre from the package, in mSv/h, multiplied by 100 and rounded up to one decimal. Together with the dose rate at the surface it decides the label: I-WHITE, II-YELLOW or III-YELLOW.

In NDEX, which we built for an isotope producer, the conveyor stops each package in front of the dose detectors, which are read several times. The detectors report in µSv/h, so a factor of 0.1 gives the TI; a mistaken unit would put it a factor of 1000 off. The software converts the reading from the detector's distance to one metre, corrects it for decay up to the planned transport time, rounds it up and compares it with the planned TI.

A package within the agreed range continues; otherwise the operator chooses to measure again, change the transport time or take the package out. A lane without a valid calibration is locked, and every measurement is stored with its time and user.

An inspector asks not only what a value is, but where it comes from: which source or person, measured when, with which instrument, recorded by whom, and what changed afterwards.

We built SourceSafe around that question. Every source has one record: its nuclide, its container, where it is, the permit that covers it and the workers allowed to handle it. Every event, from receipt and use to a leak test or disposal, is registered as a transaction with who held the source and where, and a correction stays visible next to what it corrects. Every user signs in with a role, so you can show who registered what, and when.

Dose registration asks the same of your software: a value you can trace back to the person, the instrument and the moment it was measured, and to whoever recorded it.

Qualification goes smoothly when the documentation is written along with the software, not afterwards. With us, source code, configuration, test scripts and documentation are under version control. Every change is registered as a task, and a design decision gets its own written record.

Every change takes the same route: reported, planned, built, reviewed, tested, accepted and, where needed, qualified. We draft the IQ and OQ protocols, your quality department approves them, and we carry out and document the checks. PQ takes place in your own process, with the support we agree.

For our main systems, automated screen tests operate the real screens and write the test document as they run, with screenshots. Every release carries its build date and checksums, so you can verify what was installed.

Windows, Android and iOS change every year, and so do the tools software is built with. We build our applications on one shared foundation, Loki, and each application uses a fixed version of it. An adjustment for a new operating system goes into the foundation once; each application moves to that version after its own build and tests. When Android 16 changed how apps fill the screen, for example, the adjustment went into the shared foundation once, for every phone app built on it.

We work this way ourselves every day. Our own tasks, hours, releases and customer portal run on Gaia, the set of applications we build on that same foundation, and every piece of work has a task there. So a change to the foundation reaches our own daily work too.

Many measuring instruments offer a serial port (RS-232 or RS-485), and some offer nothing else. A serial line is a good choice when it is the instrument's own interface and the instrument sits next to the computer that reads it. It is a weaker choice when the distance grows, when several systems need the same data, or when the software should run on a server rather than at the instrument.

In NDEX the dose-rate meters are read over RS-232, because that is what they offer, while the conveyor controller and the RFID reader are on the network. Our dosimeter readers and handheld barcode scanners use serial lines too. One lesson from practice: a USB hub between the conveyor interface and the PC lost signals, and connecting it directly solved it. For each piece of equipment we look at which interfaces it offers and how data can be exchanged reliably.

An activity or dose rate measured on a reference date is not today's value. Decay correction calculates it for the moment you need: A = A₀ · e^{−ln 2 · t / T½}. Keep the elapsed time and the half-life in the same unit, and record the reference date and time with every measurement.

CalCon controls a calibration system for radiation meters and ships with the system it belongs to. The reference source's dose rate is stored with its distance and reference time, and before a meter is calibrated against it, CalCon corrects that value for decay, distance, air absorption, pressure and temperature, with half-lives in seconds. Its results were compared with those of an earlier version and of a separate calculator.

A check calculation you can always do: after exactly one half-life the result is half the starting value, and after ten half-lives about one thousandth. In our Loki foundation, decay, the inverse-square law and the conversion between activity and dose rate are part of the core, so a new application starts from them.

Radiation is not only found in a laboratory. On average a person in the Netherlands receives about 2.8 mSv a year (RIVM), a large part of it from natural sources: cosmic radiation, radon in the home, and the potassium in our own bodies.

A banana contains about 15 becquerels of potassium-40 (source). Brazil nuts take radium up from deep soil, up to about 444 Bq per kilogram. Granite worktops contain traces of uranium and thorium and can add a little radon to the air indoors. None of this is a reason for concern. It does show why a measured value means little without its unit, its background and its limit, and that is what our software keeps together.