Converter Oxygen Lance Control Delay Causing Accidents? How Millisecond Response of Serial Port to Ethernet Adapters Enables Precise Process Control
February 18, 2022, a foundry in Brazil, 10:23 AM.
30 tons of molten steel still sat in the furnace. The operator needed to replace the oxygen lance.
According to procedure, he should have first pulled out the old leaking lance, connected the cooling water pipe to the new one, verified water flow, and then inserted it back into the furnace. But the operator skipped the cooling water test — with molten steel inside and furnace temperature exceeding 1600°C, he disconnected the water and installed the new lance directly.
The copper head joint slowly cracked under the extreme heat. The moment water was restored, the cooling water pressure blew the copper head off, and water flooded into the molten steel.
Then, someone mistakenly opened the oxygen lance valve. High-speed oxygen swept the water into the melt pool.
Explosion. 3 dead, 15 injured.
The subsequent investigation revealed that the plant's oxygen lance cooling water system was never interlocked with the automatic lance lifting device. When cooling water flow was abnormal, the lance did not automatically lift. When outlet water temperature exceeded the limit, there was no alarm. When the flow difference between inlet and outlet exceeded 15m³/h, the furnace did not stop tilting.
Every alarm that should have gone off didn't. Not because they weren't installed — they were installed but not connected.
And one of the core reasons for "not being connected" was data transmission delay — the sensor detected an anomaly, but the signal had to go through layer after layer of conversion before reaching the control system. By the time the control system reacted, the molten steel had already swallowed the water.
This is not an isolated case.
No interlock means a major accident hazard.
But the reality is, many steel enterprises' interlock systems still run on last-century technology architectures. PLC data has to go through protocol conversion before being uploaded. The delay during conversion ranges from hundreds of milliseconds to several seconds.
Several seconds. In front of a 1600°C converter, several seconds is the line between life and death.
Anyone who works in metallurgical automation knows a fact deep down: the equipment in the workshop doesn't speak the same "language."
The oxygen lance's cooling water flow meter uses Modbus RTU over RS485. The furnace tilt encoder outputs a 4-20mA analog signal. The sub-lance lifting mechanism runs on Profibus. The upstream MES system and safety interlock controller need TCP/IP.
Between these protocols lies a natural chasm.
What's the traditional approach? Buy an industrial PC, install a bunch of protocol conversion software, and connect devices one by one with serial cards. The result? The IPC crashes, the entire link goes down. The software crashes, all data is lost. Protocol versions don't match, two devices can't talk to each other.
Even more critical is the delay.
Industrial real-time control systems require response times of <1ms, with jitter controlled within <50μs. But a data link that goes through multiple layers of protocol conversion easily exceeds 100ms end-to-end delay, with jitter completely unguaranteed.
You think the data has arrived, but it's still on the way.
You think the interlock should have triggered, but the signal is still queued.
Running safety interlocks on this kind of architecture is like driving with your eyes closed — an accident is only a matter of time.
Many people misunderstand "real-time response" as simply being fast.
It's not. The core of a real-time system is not "fast" — it's "deterministic." Tasks must be completed within a guaranteed time window, and that window must be predictable and verifiable.
In industrial control theory, this is called "Hard Real-Time." Missing the deadline doesn't mean "a little late" — it means catastrophic failure.
The converter oxygen lance safety interlock is a textbook hard real-time scenario: cooling water flow drops below the set value → the lance must automatically lift within a specified time → stop oxygen blowing. This "specified time" isn't "the faster the better" — it's "must complete within X milliseconds, or it's an accident."
Achieving this deterministic response hinges on three elements:
First, interrupt priorities must be correct.A cooling water flow anomaly is the highest-priority event. It must be able to preempt all lower-priority tasks and trigger the interlock immediately. This requires hardware-level nested interrupt support, with interrupt latency controlled within 2–10μs.
Second, the scheduling algorithm must be hard.Rate Monotonic Scheduling (RMS) and Earliest Deadline First (EDF) are the two most common algorithms in industrial applications. RMS assigns priority by cycle period — shorter cycle, higher priority. EDF schedules dynamically — the task with the nearest deadline runs first. Either way, the core principle is the same: let critical tasks "cut in line," never allow them to be blocked by low-priority tasks.
Third, the data link must be short.The fewer protocol conversion layers, the more controllable the delay. The ideal architecture is: sensor → serial port to ethernet adapter → Ethernet → interlock controller. One step, end to end. No industrial PC in the middle, no protocol conversion software. Data travels from sensor to actuator along the shortest possible path.
This is why more and more metallurgical enterprises are turning to serial port to ethernet adapters for safety interlock data links — not because the adapter is feature-packed, but because it is simple, fast, and deterministic.
Let's go back to that core data link: flow meter / temperature sensor → serial port to ethernet adapter → interlock controller.
Take USR's N510 as an example. What this device does sounds simple — it converts RS485 serial data into TCP/IP network data and transmits it transparently.
But behind that "simplicity" lie several critical design choices:
ARM core, not a microcontroller.The N510 uses an ARM processor running an optimized TCP/IP stack. This means the processing delay from serial input to network output is measured in microseconds, not milliseconds.
Hardware watchdog, not software watchdog.If the device crashes, the hardware watchdog automatically reboots it — no need for someone to go to the site and press a reset button. In a metallurgical workshop, this means the data link never "fake-dies."
Built-in Modbus gateway.The N510 can directly parse Modbus RTU data from flow meters and convert it to Modbus TCP or custom JSON for reporting. No extra protocol conversion gateway needed. One fewer link in the chain means one less hop of delay.
Edge computing, local decision-making.The N510 supports preset collection rules — auto-polling and parsing on power-up, with selective reporting of abnormal data. Flow below threshold? No need to wait for the MES system to decide. The N510 can locally trigger alarm logic and proactively push alerts to the interlock controller via TCP Client.
Heartbeat keep-alive, instant link-loss detection.Network heartbeat packets probe every 15 seconds. The moment the link drops, you know immediately. No more "data was sent but the other side never received it" ghost situations.
String all these capabilities together, and the entire safety interlock data link becomes:
Flow meter detects abnormal cooling water flow → RS485 signal enters N510 → N510 parses data in microseconds → determines flow is below threshold → proactively pushes alert via TCP Client → interlock controller receives signal → oxygen lance automatically lifts → oxygen blowing stops
End-to-end link delay: controllable within milliseconds.
This is what an "interlock" should actually look like — not just having the device installed and calling it done, but ensuring data truly arrives within the required time and the actuator truly acts within the required time.
In the 2002 converter explosion accident, the chief furnace operator, Li, received wrong information — Gao had only gone up to the 15.8-meter platform, taken a casual look, and reported "the leak isn't serious." Based on this wrong judgment, Li ordered the furnace to tilt.
15 minutes later, accumulated water mixed with steel slag inside the furnace, and it exploded.
If there had been a reliable data link at the time, transmitting the real-time flow rate and temperature of the oxygen lance cooling water to the control room, Li wouldn't have seen Gao's "visual estimate" — he would have seen real data on the dashboard.
He wouldn't have tilted that heat.
Many accidents are not human error — they are data link errors.
TheSteelmaking Safety RegulationsAQ2001-2018 state clearly: when cooling water flow drops below the set value, when outlet water temperature exceeds the set value, or when the inlet-outlet flow difference exceeds the set value, the oxygen lance shall automatically lift and oxygen blowing shall stop.
Good regulations. But if the data can't arrive, arrives too slowly, or arrives wrong, the regulations are just a piece of paper.
A serial port to ethernet adapter — a device costing a few dozen yuan — can't carry an entire safety system. But it can carry the most critical link: making sure data arrives on time, when it's supposed to.
That's enough.
Millisecond response isn't a technology flex. It's the invisible lifeline in front of a 1600°C furnace.
