Heat Treating Operations Software Problems: The 7 That Cost You Approvals, and How to Avoid Them

Why does the project start with quoting instead of pyrometry?

Ask a heat treat owner what hurts and the first answer is usually commercial: quotes take too long, the traveller is paper, invoicing lags shipping, and nobody can see the schedule. So the project gets scoped as a shop operating system, quoting first, and the pyrometry records stay in binders because they are, technically, working.

That order spends the budget on the cheaper risk. Slow quoting costs you margin and some work you did not win. A pyrometry non conformance can put a furnace out of service until the corrective action clears, and a lost approval closes a market. The commercial pain is louder because it is felt daily by the people commissioning the software, while the compliance exposure is felt rarely and catastrophically by the quality manager.

Build in the order of risk. A first release covering the furnace register with class, instrumentation type and qualified operating range, automatic scheduling and record keeping for system accuracy tests and temperature uniformity surveys, thermocouple usage and expiry tracking, and load records with the recorder chart attached runs $50,000 to $110,000 and ships in 10 to 16 weeks in Digital Heroes delivery experience. Quoting, order intake, scheduling across furnaces, customer recipes with revision control, outside processing, certificates and accounting integration take it to $140,000 to $300,000 across 5 to 10 months. Shops holding aerospace approvals should build in exactly this order, because it removes the highest cost risk first.

What goes wrong migrating equipment, sensor and load history?

There is less structured data than anyone expects and more judgement calls than anyone budgets.

The equipment register is straightforward but tedious: every furnace with its class, instrumentation type, qualified operating range, control and recording instruments, and the survey and test history that keeps it qualified. Expect disagreements about what a furnace is actually qualified for, because the answer lives across a survey report, an instrument calibration certificate and someone's memory.

The sensor register is where it gets uncomfortable. Thermocouple usage in most shops is a tally on a clipboard by the test bench, when it exists at all. Migrating that honestly means reconciling tallies against test records, and shops almost always find at least one sensor that was used past its permitted limits. That is a quality system matter to be handled through your own non conformance process, and the right time to discover it is during a migration you controlled rather than during an audit you did not.

Load history is the decision that saves or wastes months. Do not attempt to digitise years of paper charts. Bring the equipment register, the sensor register and open qualifications across first, then run load records forward from a chosen cut off date. Keep the paper archive for its retention period, and use the system for everything from go live so the traceable chain is complete going forward.

Why does recorder and controller integration break after launch?

This is the part of the project most likely to run long and the part vendors are vaguest about. Most shops run a mix of recorders and controllers accumulated over twenty years, in several makes, with different file formats, serial protocols and network interfaces. Each one is individual work.

The recurring breakages are mundane. A recorder writes its files to a shop computer that gets rebuilt and the export folder disappears. A serial connection through an adapter stops after a firmware or operating system update. An instrument is replaced during a repair with a newer model that formats output differently, and nobody tells the office because the furnace runs fine. A clock drifts, so a chart timestamp and a load record timestamp disagree by minutes in a way that is awkward to explain.

The fixes are operational discipline more than clever code. Monitor for silence: a furnace that has run loads but produced no chart data for two days should raise an alert, because an unnoticed gap in chart capture is exactly the gap an auditor samples into. Keep clock synchronisation as a standing check. Treat instrument replacement as a change that requires an entry in the equipment register, and make that part of your maintenance procedure rather than a hope. And ask any developer for the specific makes and interfaces they have pulled data from, because a general integration claim in this category means nothing.

What happens when qualification state and sensor limits are not enforced?

Recording a rule and enforcing it are different builds, and the difference is where the value sits.

Furnace qualification has to be a scheduling constraint, not a reference field. A job cannot be planned into equipment that will be out of qualification for the required temperature on the day it runs. That single rule prevents the most common serious finding in the category, and it also produces something operationally useful: a forward view of upcoming survey and calibration work that can be booked into low demand windows rather than emergency slots.

Sensor limits work the same way. A test recorded against a thermocouple beyond its permitted uses or past expiry should be refused at the point of entry, with the reason shown. Finding out afterwards is the expensive version of the same discovery, because by then the test has been used to qualify equipment that ran customer parts.

The third enforcement gap is the certificate. A certificate assembled by hand is where transcription errors enter the traceability chain, and it is the document your customer keeps and files. Generate it from captured data, and make the load record the object everything hangs from: parts, quantity, customer, recipe, racking, furnace, start and end times, operator, quench delay, load thermocouple placement, subsequent hardness or metallurgical results, and the recorder trace attached rather than filed by month.

Should you build custom or configure what you already own?

If you are a one or two furnace commercial shop doing commercial grade work with no aerospace or automotive approvals, do not build. Keep the binders, keep them tidy, and buy a recorder that stores digitally. The build case begins with approvals, with more furnaces than one person can track expiry dates for, or with a quality manager who spends more time assembling evidence than improving process.

Super Systems Inc is the deepest name in this space and its equipment and software genuinely handle the pyrometry side, meaning data acquisition from furnace instruments, survey support and compliant recording. Fluke Process Instruments Datapaq is the standard answer for through process temperature profiling where a system travels with the load. If your problem is capturing accurate temperature data and producing a trusted profile, those products are what they were built for and you should use them.

Neither is a shop operating system, and that is the honest gap. They hold the temperature truth. They do not hold the job that walked in this morning, the customer recipe and hardness requirement, the racking and load build, the quench delay limit, the outside processing that follows, the certificate or the invoice. The audit pain sits in the joins between systems rather than inside either one, which is why the sensible build often sits alongside them rather than replacing them.

How do hidden costs get into the quote?

• Instrument integration, counted by make. A mixed fleet is the most common cost driver in this category. Walk the floor and write down every recorder and controller by make, model and interface before asking for a price.
• Two approval regimes. Holding aerospace and automotive assessments together means additional record types, frequencies and checks. The architecture is the same, the requirement sets are not, and both need defining during design rather than after.
• Shop floor hardware. Terminals or tablets that survive heat, oil and gloves, mounted where the work happens, plus network coverage in a building designed to resist it.
• Operator time during changeover. Running the new load record alongside the existing paper traveller for a period is the right way to cut over, and it is real production time.
• Running costs and retention. Hosting, storage for chart data that grows permanently against retention obligations measured in years, and an engineering allowance for instrument changes.

What separates a build that works from one that fails here?

Test domain knowledge in the first conversation. Ask a prospective developer to explain, unprompted, why a furnace has a qualified temperature range and what happens to scheduling when a survey expires. If they treat furnace availability as a simple calendar, they will build you a scheduler that books jobs into non compliant equipment. Ask how a thermocouple's remaining permitted uses affects the validity of a test recorded with it. Someone who has worked in this space answers immediately, and someone who has not suggests a maintenance reminder, which is not the same thing.

Then ask what recorder and controller hardware they have actually pulled data from, by make and interface, whether that was a file drop, a serial protocol or a network read. This is the single most useful question in the whole vetting process.

On your side, the build succeeds when the operator's part of it is fast. If starting a load takes longer on a terminal than writing on a traveller, the traveller wins and the chart never gets attached to anything. Pilot on one furnace and one operator before rolling to the floor, and change the interface based on what that operator says rather than on what the office prefers.

Finally, settle ownership in writing before kickoff: the code, the repository, the cloud accounts and the historical records. At Digital Heroes the client owns all of it from the first commit. Pyrometry and load records carry retention obligations measured in years, and customers may request them long after any software relationship ends, so they cannot live anywhere that needs a vendor's cooperation to reach.