search.noResults

search.searching

saml.title
dataCollection.invalidEmail
note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
COVER STORY | LLMS & DIAGNOSTICS


diagnostics framework, in this case GPT-4, developed by OpenAI, was used. Given that an LLM is pretrained, any external knowledge – about the plant or diagnostics framework – must be provided to it in the form of context. Carefully managing an LLM’s context is imperative to align it with the requisite knowledge for the specific task. An acknowledged problem with LLMs is that their


knowledge is limited to the data they have been trained on and they are also susceptible to “hallucinating” inaccuracies and presenting them as facts. Thus, the authors attempt to address the hallucination issues by constraining the output of the LLM. To explain the PRO-AID diagnosis, the LLM needs the


background information of the physical system and real- time updates of the observations and diagnostic results in PRO- AID. More specifically, the background information consists of an inventory of physical and virtual sensors, all possible sensor and component faults, and residuals generated for the system. For each residual, details on its dependency structure are also provided. The real- time updates from PRO-AID include recent sensor data, an updated list of zero and non-zero residuals (fault symptoms), and updated diagnostic results. The data exchange between PRO-AID and the LLM can be done periodically using data files produced by a PRO-AID output module.


The METL experimental facility To demonstrate the diagnostics system’s capabilities, the proposed framework was applied to the purification loop of the Mechanisms Engineering Test Loop (METL) liquid sodium facility at the Argonne National Laboratory. The sodium purification system, consists of two electromagnetic (EM) pumps, an economiser, a cold trap, and a plugging meter. Each EM pump is equipped with a flow meter. The cold trap and the plugging meter are each equipped with a pair of pressure transducers at their inlet and outlet. Additionally, each piping segment of the system is equipped with a heater and a thermocouple – or two thermocouples for piping segments longer than 3 ft (1m) –mounted on the outer surface, under an insulation layer, for temperature control. During operation, the EM pump directs a small fraction of sodium from the main piping system to the cold trap, where the sodium flow is cooled to just above the freezing point. Due to the reduction of the solubility at lower temperatures, impurities precipitate out of the sodium flow and adsorb at the stainless-steel mesh filter within the jacket of the cold trap. An economiser acts as a counterflow heat exchanger to pre-cool the incoming sodium flow to the cold trap and pre-heat the purified outgoing sodium flow. Since direct measurements of the sodium temperatures


are not available, heat balance and heat transfer performance models of the economiser and using the thermocouples mounted on the outside piping surface at the inlet and outlet ports of the economiser were developed and implemented in PRO-AID. These models and the associated virtual sensors allow PRO-AID to detect and differentiate between component faults within the economiser and the surrounding sensor faults The experiment involved injecting a fault in the TC 117


thermocouple at the economiser’s hot-side outlet by adding a 10.0°C bias to the sensor output by the METL operators. Several residuals were activated about a minute


36 | July 2025 | www.neimagazine.com


after injecting the bias, the delay is due to statistical significance requirements to exempt measurement noise. Using logical inference, the residual signature corresponds to a unique fault diagnosis, in this case a fault for sensor TC 117.


Fault deductions Once the fault is introduced the Diagnostics Agent employs logical reasoning to deduce the fault diagnosis and then shares this diagnosis with the user. Notably, it accurately identified a sensor fault of TC 117. Additionally, the agent indicates the unique set of sensors responsible for triggering the various residuals listed. This information aids operators in closely examining each implicated sensor. In the outputs the fault signature was identified is ‘F6’ which corresponds to the fault ‘SensorFault- economizer.hot:temp:out’. In this system, each fault has a unique signature that is identified by a specific set of residuals. When a fault occurs, it triggers certain residuals while leaving others inactive. The active residuals form the fault signature. In this case various other potential sensor faults were ruled out because they did not match the fault signature ‘F6’. The other faults (here F1, F2, F3, F4, F7, F8, F9) did not match this signature and would have triggered a different set of residuals. After being provided with a list of potentially faulty


sensors, the operator can examine the actual data these sensors recorded. The function ‘query_sensor_data’ facilitates this by allowing access to the relevant sensor data such as the analysis for TC 117. The Agent highlights anomalies in both statistical and spectral metrics. To support this function, the system maintains a buffer of past sensor readings. An inbuilt function then analyses various metrics from the batched data, with the results interpreted by the Agent. To aid explainability, the Operator must also be able to query the Diagnostics Agent. This capability is available with the custom_query function and in this case the agent was asked to explain the exoneration process. The agent responded by explaining the exoneration process to the operator, in the context of fault F6 being activated. There is an option to save the Agent’s output in the context buffer.


Smarter explanation Explainability in diagnostic tools for complex systems is crucial, enabling operators to comprehend not only the presence of a fault but also its origins and implications. The authors argue that purely data-driven approaches may fall short in providing useful explainability, adding that physics-model-based diagnostic tools offer a more effective solution with their inherent causal relationship mapping. Incorporating an LLM enhances this by translating the technical details from the physics-based model into understandable explanations for operators, and accommodating arbitrary queries about the system. However, the authors are explicit saying that care must be taken to constrain the LLM to prevent the dissemination of inaccurate information. Nonetheless, using data from a molten salt facility, this study demonstrates that an AI diagnostic Agent can explain the relationships between faults and the sensors involved, respond to queries, and analyse historical sensor measurements to draw conclusions. ■


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45