Data-Driven Decisions with IoT and AI in Engineering

What is data-driven decision making for engineering projects?

Data-driven decision making for engineering projects, in this paper, means collecting live state from IoT devices, watching for abnormal status, then picking a schedule with artificial intelligence and operations research. The authors contrast that loop with choices based only on experience. The test is a door welding line. The journal is housing-focused. The method is a factory control loop that other engineering sites can still steal.

Kezhi Zhen, Jing Chen, Jifu Wang, Xin Yin, Zheng Qi, and Xu Li, all at China Tobacco Guizhou Industrial Co., LTD. in Guiyang, published the work on 4 August 2025 in the International Journal for Housing Science and Its Applications, volume 46, issue 3, pages 1314 to 1324. The research article is on HAL, and the same research article is on Academia.edu. The PDF lives on the journal site. ISSN 0146-6518. DOI 10.70517/ijhsa463102.

Three numbers from the abstract are the ones people quote, and they are worth keeping straight. Device delay sat randomly between 50 and 150 milliseconds. The gear answered 1,000 data requests with accurate values in the reported test. The AI control scheme moved at the 100th artifact, before a later sequence change, which is how the authors say they cut performance loss and avoided an inventory spike. The rest of the paper is the machinery behind those three facts.

"A mean forecast is too slow for a line that only gets one next state. The method picks a focus, then acts."

This piece translates that machinery. You will see how IoT sensing is wired, how “scenario-focus” handles uncertainty, how AI and operations research split the work, and what actually happened on the welding line. If you work in software delivery rather than metal, the useful transfer is the timing: act before the schedule rewrite, keep inventory from exploding, and measure delay in milliseconds, not in weekly reports.

Why is real-time IoT monitoring the first layer?

Real-time IoT monitoring is the first layer because a schedule that cannot see the line is a guess. Sensors, wireless links, and a local database turn stations into a live state vector. The paper argues that classic decision methods were built for slower data and cannot keep up with that stream. Online, in-line control is the requirement, not a nicer after-the-fact report.

The authors describe an IoT fabric of sensing devices, wireless communication, cloud or local compute, and analytics. In their lab test they put ten acquisition modules on ten devices, talked to PLCs over serial, and used Wi-Fi in STA mode. Software on a host stored the stream. That is not glamorous. It is the unglamorous work that makes a later model honest. If the module is offline, the AI is guessing in the dark.

They also name the hard part of IoT decisions. Data arrives unstructured and in bursts. Each terminal has to work with neighbors and people, not only with a central brain. Traditional scheduling assumed a limited collection range and a decision that could wait. In this setting a delay of a few hundred milliseconds is already a different problem than a daily plan. That is why they spend so many pages on delay, interval, and bit error before they talk about welding doors.

Those numbers are the paper's proof that the sensing layer is “smooth enough.” They are not a claim that every plant will see 84 ms. Wiring, protocol, and load will move the band. The design lesson is to measure delay and error as first-class tests, the way you would measure model accuracy. A brilliant optimizer on a 2-second-stale feed is not real-time control.

How does the method handle abnormal status?

The method treats the line as normal, abnormal, or in a messy in-between state, then reschedules when the state would stop the system. Abnormal here means a failure that needs an immediate new plan. Seasonality, cycles, and stacked factors make that call hard. IoT state is the input. The decision is whether to keep running or to rewrite the schedule now.

The authors call the core idea a data-driven anomaly perception method plus a “scenario-focus” decision step. Prediction gives a probability distribution over next states. Uncertainty handling then picks a focus: the next state that actually deserves attention, not the average of all of them. That matters on a line you cannot rerun a thousand times. A mean that never happens is a poor guide for a one-shot choice.

They define a “state to be collapsed” as a bundle of possible next states with probabilities. When time moves, only one of those states occurs. The prospect function assigns a value by combining outcomes with an attention vector. Attention is not the same as probability. A rare but catastrophic stop can get attention 1 even if its probability is small. A frequent but harmless wobble can get attention 0. That is how a decision purpose gets into the math.

If a choice is repeatable many times, attention can fall back to probability and the method looks like expected-value control. If it is not repeatable, or if one bad state is enough to force a rewrite, the focus is the extreme. The paper's oil-distribution interruption example is the intuition: you do not wait for the average leak. You act on the state that would stop the system. Welding-line disturbances play the same role in the later case study.

How do AI and operations research share the work?

AI and operations research share the work by splitting prediction from allocation. Machine learning and deep learning read the stream and the cameras. Operations research supplies planning theory, inventory theory, graphs, and linear models that search for a feasible schedule. The paper's claim is that neither half is enough on a live line. You need a forecast and a solver that can run online.

On the AI side they write a generic predictor Y = f(X) plus noise, and they mention trees, support vector machines, and random forests for equipment health, resource location, and efficiency. Deep learning is placed on environment and security monitoring, with a squared-error loss plus regularization. None of that is a new architecture. It is a map of which family of model sits where.

On the operations research side they list planning theory, network analysis, storage (inventory) theory, and project planning techniques. The scheduling model they write is a linear program: minimize cost of resources subject to Ax ≤ b and x ≥ 0. That is the language of capacity, output, and people. NP-hard shop problems are named as the reason you cannot always wait for a perfect optimum. A good-enough plan in limited time is the practical target.

Knowledge representation is the glue. The authors sketch a modeling stack that holds problem knowledge, event knowledge, model components, and algorithm knowledge, then auto-builds a plan when an event matches a rule. Figure 1 in the paper is a logistics-flavored version of that stack (vehicles, cargo, suppliers). The welding-line case later is the same idea with stations and buffers. If you build software, this is closer to a rules-plus-optimizer service than to a single neural net.

What happened on the automotive door welding line?

The welding line has seven stations and six buffers, with conveyors between them. Stations cover reinforcement plates, window frames, bumpers, gluing, curing, hinges, and testing. Mixed products share the line with fixture changeovers. RFID, sensors, and image tools watch material, position, and robot status. The AI scheduler's job is to keep that mix moving when a station hiccups.

Nine disturbance events are listed, with workstation, a change code, and durations from 320 seconds up to 1264 seconds. Processing times differ by product variety A through D across the seven stations. Changeover times between those varieties are also tabulated, some cells empty because that swap does not happen at that station. This is a real mixed-flow headache: the bottleneck drifts as the mix drifts.

Capacity-loss diagnosis compared MPS, Kanban, e-MPC, and the AI method across those nine events. Results were mixed. Sometimes only one method showed a permanent loss. The authors note that AI was a bit slower than Kanban when a disturbance lasted a long time, and they say responsiveness can improve if a modest work-in-process buffer is kept. That is a useful honesty. The AI is not magically best on every row.

The 100th-artifact result is the one to remember. Machining sequences II, III, and IV only change around workpiece 116 (for example A to C on pieces 116 to 135). The AI release plan already moved at piece 100. That is an ex ante control move. Waiting times across the four sequences stayed in a tight band, about 1974 to 2054 seconds, which is how the authors argue inventory stayed reasonable instead of spiking when the mix changed.

If you work in software rather than welding, map “artifact” to a build or a ticket batch. Acting at item 100 because item 116 will change is the same idea as reordering a sprint before the dependency lands. For a software-shaped version of that loop, see AI-driven transformation in software project management. For a wider machine-learning tour, see machine learning uses across fields.

What should an engineering team copy, and what should they not?

Copy the measurement order: prove the IoT loop, then the anomaly call, then the optimizer. Copy the idea of acting before a sequence change, not after inventory explodes. Do not copy the claim that AI always wins on wait time, because in this paper it did not. Do not skip a buffer policy. The authors themselves say a little WIP can make the AI more responsive.

The welding line is also a reminder that “engineering project” here is discrete manufacturing with RFID and robots. Housing science is the journal home. Construction and plant maintenance could use the same stack (sensors, focus-based uncertainty, a solver), but the constraints would change: weather, crews, and material lead times instead of fixture swaps. The method is portable. The tables are not.

Zhen and colleagues close by saying the delay band was stable, the requests were accurate, and the AI kept inventory from swinging hard when sequences changed. That is a narrower, more useful ending than “AI transforms engineering.” It is also closer to how you would defend a pilot to a plant manager. Show the milliseconds. Show the thousand requests. Show the 100th piece. Then talk about the model.

If your work is software models rather than shop-floor control, the companion piece on AI-based modeling in software engineering is a better next stop for how those models are specified and checked. The shared habit is the same. Put the data loop first. Put the decision rule second. Publish the cases where the new method is not the shortest wait.

Frequently asked questions

What is data-driven decision making in this engineering paper?

It is a method that collects live project state from IoT devices, watches for abnormal status, then uses artificial intelligence with operations research to pick a schedule. The authors contrast this with choices based only on experience. The test case is an automotive door welding line, not a housing site, even though the journal is housing-focused.

How fast is the IoT monitoring loop?

Response delay on the tested modules sat randomly between 50 and 150 milliseconds, with no obvious drift. Four devices averaged about 95, 95, 75, and 76 ms, or about 84 to 85 ms overall. One thousand data requests on each of four units came back with a 0 percent error rate in the reported bit-error test.

What happens around the 100th artifact?

The AI control scheme adjusted workpiece release around the 100th artifact, before the machining sequence itself changed at about the 116th piece. That early move is the point. The system tries to cut performance loss and avoid an inventory spike by acting before the schedule rewrite is visible on the line.

How does AI mix with operations research here?

IoT senses state. Machine learning and deep learning help with prediction and monitoring. Operations research supplies planning, inventory theory, and linear models for allocation. A “scenario-focus” step then picks which uncertain future to treat as the decision focus, so the system can act in real time instead of waiting for a mean that may never arrive.

Did the method beat Kanban and model predictive control?

On waiting time, Kanban averaged 3234 seconds, e-MPC 2243 seconds, and AI 2695 seconds. AI was not the shortest wait. The authors argue it held similar output with less work-in-process inventory and smaller swings when sequences changed. Capacity-loss diagnosis against MPS, Kanban, and e-MPC was mixed by disturbance event.

Related articles

• Machine learning uses in physics, service, earth science, and medicine
• AI-driven transformation in software project management
• AI-based modeling in software engineering