Digital subject matter expert system and alarm aggregation

Abstract

Here describes a process for interfacing with a control system coupled to one or more devices. The system comprises a first module configured to receive a first data representation of at least one input alarm from the control system and associated data tags corresponding to said one or more devices. A second module configured to process said first data representation using at least one language model, where said at least one language model is adapted to convert said first data representation into a second data representation based on the associated data tags; and a third module configured to output the second data representation in response to at least one input to the control system.

Description

DIGITAL SUBJECT MATTER EXPERT SYSTEM AND ALARM AGGREGATIONTechnical Field

[0001] The present application pertains to a system and methods for a digital expert system designed to enhance efficiency across diverse processes, especially in pharmaceutical operations and manufacturing.Background

[0002] Advancements in machine learning have opened new ways for processing natural language, prompting a growing demand for enhanced methods to facilitate machine-to-machine operations and improve automation processes. While the success of source code generation has been observed, an unmet need to automate control logic programming still exists, representing a significant gap in the utilization of machine learning for industrial automation.

[0003] Despite the considerable progress in language models' capabilities for general-purpose programming, their application in control engineering has remained largely underexplored. To bridge this gap, this application introduces a digital expert system along with methods aimed at enhancing the efficiency of various processes involving machine-to-machine operations, especially in the biotechnology sector.Summary

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter; variants and alternative features which facilitate the working of the invention and / or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention disclosed herein.

[0005] The present disclosure provides a tool or process for interfacing with a control system to process alarm data using language models. For example, the tool may connect and read data from a control system such as programmable logic controller (PLC) or distributed control system (DCS) either directly or via the control system. The tool processes the aggregated (alarm) data using one or more language models that are configured to parse and deliver a graphical representation of thedata with appropriate context to a user.

[0006] The language model is trained using the aggregated (alarm) data, whereby the data is consolidated into a data structure. The data structure is configured to store and / or manage alarms from the control system. The control system received sensor data from least one device. Obtaining the data structure involves receiving an alarm and its associated timestamps from the control system to be added to a queue in the data structure. The queue operates to hold multiple alarms linked to the device, ensuring accurate and time-ordered alarm tracking.

[0007] In a first aspect, the present disclosure provides a method (or a computer-implemented method for establishing a data structure of one or more alarms from a control system coupled to at least one device, comprising: receiving a first alarm from the control system and first timestamps associated with the first alarm as received by the control system; adding the first alarm to the data structure based on the first timestamps, wherein the data structure comprising a queue configured to hold said one or more alarms associated with said at least one device electronically coupled to the control system; receiving a second alarm from the control system and second timestamps associated with the second alarm as received by the control system; and adding the second alarm to the data structure based on the first timestamps and the second timestamps.

[0008] In a second aspect, the present disclosure provides a system for interfacing with a control system coupled to one or more devices, the system comprising: at least one first module configured to receive a first data representation of at least one input alarm from the control system and associated data tags corresponding to said one or more devices; at least one second module configured to process said first data representation using at least one language model, wherein said at least one language model is adapted to convert said first data representation into a second data representation based on the associated data tags; and at least one third module configured to output the second data representation in response to at least one input to the control system.

[0009] In a third aspect, the present disclosure provides a method of training a language model described herein. The method comprising: receiving a first data representation of at least one input alarm complied in a data structure from the control system and associated data tags corresponding to said at least one device, wherein the associated data tags comprising timestamps of said at least one input alarm; encoding the first data representation of at least one input alarm and the associated data tags using the language model; mapping the associated data tags to a learnedrepresentation of a plurality of aggregated alarm data; generating a second data representation based on said mapping; and decoding the second data representation in response to at least one input to the control system.

[0010] Methods described herein can be executed by software stored in a tangible medium, such as a computer program containing code designed to perform said methods when run on a computer. This program can be stored on various physical storage devices like disks, thumb drives, or memory cards, excluding propagated signals. The software can run on either parallel or serial processors, allowing the steps to be performed in any suitable sequence or simultaneously.

[0011] For example, one aspect of the disclosure may comprise one or more tangible non-transitory computer-readable storage media for storing computer-executable instructions executable by processing logic, the one or more tangible non-transitory computer-readable storage media storing one or more instructions to perform any one or more aspects of the processes or method described herein.

[0012] Moreover, this application acknowledges the value of firmware and software as distinct, separately tradeable assets. It intends to cover software that operates on or manages basic or standard hardware to fulfill specific functions. It is also intended to cover software that defines or outlines the setup of hardware, such as Hardware Description Language, utilized in designing silicon chips or configuring programmable chips to perform desired tasks.Brief Description of the Drawings

[0013] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0014] Figure 1 is a flow diagram showing a method for processing at least one input alarm from an aggregation of alarms;

[0015] Figure 2 is a schematic diagram of an example system for interfacing a control system coupled to one or more devices;

[0016] Figure 3 is a pictorial diagram illustrating device sensor data used to generate training data for a language model; and

[0017] Figure 4 is a schematic diagram of a computing device suitable for implementing aspects of the invention.

[0018] Common reference numerals are used throughout the figures to indicate similar features.Detailed Description

[0019] Embodiments of the present invention may be described as examples. These examples represent suitable modes of putting the invention into practice that are currently known to the Applicant, though they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating these examples. Different examples may be understood to potentially accomplish the same or equivalent functions and sequences as required by the invention. Some of these examples may be described in terms of optional features or options relating to one or more embodiments, which may be combined as appropriate with any of other optional features and / or embodiments of the invention, and as would be apparent to a skilled person.

[0020] An alarm refers to a signal or notification produced or transmitted by a control system described herein, whereby the alarm is generated from captured sensor data of abnormal or potentially problematic conditions of a device coupled to the control system. Alarms may be triggered when certain threshold values obtained from the sensors exceed a pre-determined value, predefined conditions are met, or specific events occur. Alarms would alert operators or another system about potential issues that require attention or intervention.

[0021] An input alarm refers to the specific instance of an alarm or alarm signal produced from or captured by a sensor of a device coupled to a control system. The input alarm comprises information associated with an alarm event, such as a hardware failure, software error, or environmental condition. This information includes but is not limited to the type of alarm, severity, timestamp, source, and any additional metadata or context provided by the originating device, which can provide crucial details of the alarm event and the problem underlying the alarm event and potential resolution as explained herein.

[0022] For example, an input alarm may include information such as timestamps that are crucial for tracking the alarm lifecycle and performing time-based analysis, where one timestamp would indicate when the alarm condition was initially detected, and subsequent timestamps mightrepresent updates or acknowledgments related to one or more alarm events. The alarm type specifies the nature of the issue, severity indicates its critical ity, and the source identifies the system or component generating the alarm. Metadata may include user comments, corrective actions, or related historical data, aiding diagnosis and resolution. The information included with the input alarm allows for comprehensive monitoring and management of the devices coupled to the control system, including tracking the duration of alarm states in respective of the timestamps, thereby ensuring their health and continued performance.

[0023] Duration (or alarm duration) in respective of certain timestamps refers to the amount of time that has elapsed between specified two or more timestamps, providing a measure of the time interval between alarm events. For example, the duration might be calculated between a start timestamp, indicating when an event began, and a stop timestamp, indicating when the event concluded. This interval can represent various periods, such as the runtime of a process, the duration of a user's session, or the time taken to complete a specific task. In some cases, multiple durations can be determined if there are multiple pairs of timestamps, offering a detailed view of time intervals between consecutive events or phases within a single event. The system may use a certain duration in performance analysis, tracking resource utilization, and identifying process bottlenecks or delays. The alarm duration is considered when the alarm is added to or removed from the data structure, which may be used to determine how long the alarm would be maintained.

[0024] Maintaining an alarm refers to retaining an alarm within a data structure according to the timestamps. This involves keeping track of the alarm's state, updates, and relevant information as part of the data structure once the alarm is added to the data structure. Adding an alarm to the data structure refers to inserting a new alarm entry, which includes details such as the type of alarm, severity, timestamps, source, and any associated metadata. Removing an alarm from the data structure involves deleting the alarm entry when the alarm condition is resolved or irrelevant based on the timestamps. For example, an alarm may be removed when the end time is reached, signified by the end timestamp. It is understood that effective management of alarms (adding alarm to or removing alarm from) the data structure allows for efficient analysis of alarm information, ensuring timely responses to critical events and maintaining the overall system.

[0025] Alarms are categorized as primary and non-primary alarms. Primary alarm refers to a critical or high-priority condition requiring immediate attention due to severe issues that impact system performance, safety, or functionality. Primary alarms are designed to alert operators or monitoringsystems for swift action, thus demanding urgent intervention. They are characterized by high severity, the necessity for an immediate response, and clear, prominent notifications, often including visual and auditory signals. Examples include equipment failures, system outages, and safety hazards.

[0026] Non-primary alarm refers to an alarm that indicates a less critical or lower-priority condition relative to primary alarms. These alarms are associated with issues that do not require immediate action but still need to be monitored and addressed to prevent potential future problems. Nonprimary alarms help maintain overall system health by highlighting minor issues, performance warnings, or maintenance needs. Characteristics of non-primary alarms include lower severity, delayed or scheduled response times, and less prominent notifications. Examples include routine maintenance alerts, minor performance degradation, and non-critical system warnings.

[0027] Both categories of alarms, primary and non-primary, may be identified by analyzing aggregated alarms or patterns within the system. For example, the primary alarm may be identified by recognizing a critical or high-priority alarm condition that requires immediate attention due to its potential to impact system performance, safety, or functionality significantly. On the other hand, identifying an alarm pattern based on the plurality of aggregated alarms refers to recognizing recurring sequences or combinations of alarms that may indicate underlying issues or trends within the system.

[0028] Alarm state refers to the current condition or status of an alarm, indicating whether it is active, triggered, acknowledged, or cleared. A prediction of the alarm state thereby involves forecasting or estimating the current or future state of an alarm based on various factors such as historical data, patterns, and contextual information. This prediction can assist operators and monitoring systems in anticipating potential issues, prioritizing response actions, and ensuring timely intervention to maintain system health and safety.

[0029] Alarm data encompasses the collective information, records, or datasets related to alarm events generated by monitoring systems over time. It may include various attributes and parameters associated with each alarm event, such as timestamps, alarm types, severity levels, sources, descriptions, and relevant contextual information or data tags. Alarm data is analyzed and processed by the system and processes described herein.

[0030] Aggregated alarm (s) data refers to pre-processed data compilation from individual alarmsclustered based on specific criteria identified by the control system, such as machine-level connectivity and database entries recorded by timestamps. This aggregation process is utilized to train the language model described herein, facilitating the recognition of alarm patterns and the analysis of multiple alarms simultaneously and in real-time.

[0031] Aggregated alarm(s) may be stored in one or more data structures as desired herein, where the alarms are organized systematically and managed to enable efficient access, modification, and usage. Such data structures would provide a means to organize data in a format that suits specific purposes and applications, facilitating operations such as searching, sorting, insertion, deletion, and traversal.

[0032] For example, the data structure may comprise a stack, which exhibits a Last-In, First-Out (LIFO) principle, meaning the last element added is the first to be removed. This stack would be configured to support fundamental operations such as push, pop, peek, is_empty, and size.Alternatively, or additionally, the data structure may comprise a queue that operates on a First-In, First-Out (FIFO) principle, where elements are added (enqueued) at the rear and removed (dequeued) from the front. The queue ensures that the first element added is the first one to be removed, making it ideal for scenarios like task scheduling, breadth-first search in graphs, and managing processes in operating systems. Queues can be implemented using arrays, linked lists, or other underlying formats, providing efficient access and management of data in sequential order. The data structure may be generated or proceeded by the control system or any system that interacts with the control system as described herein.

[0033] Control system refers to any infrastructure responsible for monitoring, managing, and controlling industrial processes, machinery, and equipment. For example, the control system may comprise a programmable logic controller (PLC), distributed control system (DCS), advanced process control (APC), programmable automation controllers (PAC), safety instrumented systems (SIS), supervisory control and data acquisition (SCADA), and any other infrastructure or system utilizing industrial communication protocols.

[0034] Data tags refer to unique identifiers assigned to specific data points or parameters within a system or used by a method described herein. Data tags may represent one or more metadata associated with an alarm, part of an input alarm, or one or more industrial processes being monitored and controlled. When analyzed, these data tags may provide context and meaning to theraw data the system receives. For example, data tags may include but are not limited to parameters such as temperature readings, pressure levels, flow rates, machine statuses, alarm codes, timestamps, equipment identifiers, and other relevant information. These data tags enable the present system to effectively interpret and process the input alarm, making the overall workflow efficient.

[0035] Data representation refers to information compiled in a structured format to be processed, stored, and transmitted by computer systems or other digital devices. For example, the data representation of an input alarm may include structured information or certain encoded metadata that describes the alarm event and provides context for its interpretation and handling within a system.

[0036] Language model refers to any trained statistical model that evaluates and predicts the structure and meaning of natural language within a given context. These models are trained using datasets of text data, utilizing machine learning techniques such as supervised learning or selfsupervised learning.

[0037] During training, the model is exposed to vast amounts of text data and learns the statistical patterns and dependencies present in the language. For example, the model may be trained on labeled datasets of aggregated alarm sequences where the input is a sequence of one or more alarms, and the output is a textual explanation of each alarm sequence based on any observable patterns learned by the model from the aggregated alarm data. In another example, the model may be trained to predict masked or corrupted alarm data within the input alarm sequence, allowing the model to learn the contextual relationships between different alarms without supervision.

[0038] It is understood that the model will adjust its internal parameters and updated data to minimize prediction error and improve its ability to capture the underlying structure of the aggregated alarm sequences. In effect, the training process enables the model to capture the statistical patterns and dependencies inherent in alarm data, facilitating its understanding of the temporal relationships between multi-alarm events.

[0039] During inference, the language model analyzes sequences of alarm events and predicts the likelihood of specific events occurring in a given context. This capability allows the model to generate insights, detect anomalies, and provide early warnings for potential issues based on observed patterns in the alarm data in real-time.

[0040] Examples of language models may include but are not limited to transformer-based architectures such as BERT (Bidirectional Encoder Representations from Transformers), which also include GPT (Generative Pre-trained Transformer) that allows for bidirectional input, as well as more fundamental models based on LSTM (Long Short-Term Memory) networks. These models have demonstrated promising results in tasks such as alarm aggregation described herein.

[0041] These models are parameterized using internal variables that the language model learns from the alarm / aggregated alarm data to make accurate predictions and decisions. These include weights and biases, which are adjusted during training to minimize the loss function and determine how input data is transformed through the network layers. Embeddings may serve as model parameters that represent alarms and their associated data tags as dense vectors in a continuous vector space, captures semantic relationships between different alarm types. Attention scores, particularly in models using attention mechanisms like Transformers, are also key parameters that decide the significance of each part of the input sequence in the context of other parts. These parameters collectively enable the model to capture complex patterns and relationships in the alarm data, facilitating accurate prediction and efficient processing.

[0042] It is understood that the aggregation weights determine how different alarms and timestamps are combined or prioritized, such as giving more significance to recent alarms or those from specific devices. Embedding vectors convert alarm types and associated metadata into dense representations, capturing their characteristics and relationships. Temporal features parameters adjust how the timing of alarms is factored into the aggregation, reflecting the importance of alarms occurring during critical periods. Contextual attention scores highlight the relevance of various alarms within a sequence, influencing predictions and pattern recognition. Aggregation functions define how raw alarm data is combined, such as through averaging or summation, while historical state representations maintain and update the context of past alarms to inform future predictions. Together, these parameters enable the language model to effectively aggregate and analyze alarm data, improving insights and operational efficiency based on the results described herein.

[0043] Hyperparameters for these models may include the learning rate, which determines the step size for weight updates during training, and the batch size, indicating the number of training examples processed in one iteration. For example, the learning rate, such as 0.001, determines the step size for updating model weights during training, balancing convergence speed and stability. Batch size, possibly set to 32 or 64, defines the number of alarm data samples processed in oneiteration, ensuring stable gradient estimates. The number of layers and neurons per layer specifies the model's depth and width, impacting its capacity to learn complex patterns. A dropout rate, like 0.5, is applied to prevent overfitting by randomly ignoring certain neurons during training. Sequence length defines how many alarms and associated data points the model processes at a time. The optimizer, such as Adam or SGD, affects the weight update mechanism. Additionally, the number of epochs, hidden size, and attention heads (e.g., 8 heads in a Transformer model) are tuned to balance performance and computational efficiency of the present implementation, enabling the model to focus on different parts of the input sequence simultaneously and process alarm data effectively.

[0044] The present implementation may use the herein described language model trained on sequences of alarm data within to enhance operational efficiency of another system, such as an EBeam system. By leveraging the language model to optimize timing and reduce jams, the EBeam system is projected to significantly improve both efficiency and productivity on the PFS line.

[0045] Machine-to-machine communication protocols are standardized protocols for communication and data exchange between devices and systems within an industrial automation environment. An example of a machine-to-machine communication protocol may be Open Platform Communications Unified Architecture (OPCUA), which may be defined as / by a set of standardized protocols for platform-independent communication between machines.

[0046] Herein provides a process for establishing a data structure to manage alarms generated by a control system. The process involves receiving alarms along with timestamps, adding them to a data structure, and organizing an aggregation of alarms based on timestamps. The method includes various steps, such as maintaining the alarms in the queue, adding and removing elements based on timestamps, and storing alarms for specific durations. Additionally, it describes the use of the data structure as input to a language model, which can identify primary alarms or alarm patterns. The language model is further involved in encoding, mapping, and decoding alarm data representations, as well as generating outputs and responding to queries related to input alarms. This method aims to efficiently manage and analyze alarm data for monitoring and decision-making purposes.

[0047] Aforementioned process may be integrated as part of a system described herein. The system comprises several interconnected modules to handle different aspects of alarm processing and response. The first module is responsible for receiving input alarms and their associated data tags from a control system coupled to at least one device, where the control system provides the initialalarm data for processing by the first module. The second module employs language models to process this input alarm data, converting it into a different representation based on the provided data tags. This transformed data is then passed to the third module, which outputs the processed information in response to inputs received by the control system. In addition to these core modules, the system may include further components such as a fourth module for displaying graphical representations of the control system's output alongside inputs, a fifth module for generating predictions of alarm triggers based on historical data, and a sixth module for updating language models using new input alarm data and associated tags. The control system itself is equipped with various circuits for data acquisition, processing, and response, enabling it to evaluate sensor data, generate timestamps for alarms, and trigger operations based on predefined thresholds. The system aims to efficiently process and analyze alarm data to facilitate real-time monitoring, prediction, and effective response to events within the controlled environment.

[0048] For example, the present system may interface with control systems like PLCs or DCSs coupled to another system such as an Electron Beam Sterilization (Ebeam). Ebeam may be deployed to perform sterilization using high-energy electrons to sterilize products, such as medical devices, packaging, or pharmaceuticals. This method is effective at killing bacteria, viruses, and other pathogens without the need for chemicals or heat, making it suitable for heat-sensitive products. However, Ebeam is prone to jams, interruptions or blockages that prevent the smooth flow of products through the Ebeam sterilization equipment. Jams can be caused by mechanical issues, misaligned products, or other factors that disrupt the normal operation of the line.

[0049] Present system may be configured to process alarm data collected from the Ebeam via PLCs or DCSs. This process may be accomplished using language models. The system may read data from the control system, process aggregated alarm data, and deliver a graphical representation with context. The language model may be trained using consolidated aggregate alarm data stored in a data structure, which manages alarms received from sensors on connected devices. The data structure's queue ensures, for example, accurate, time-ordered tracking of multiple alarms. These collectively enhance the reliability, efficiency, and predictive capabilities of the control system, leading to better operational performance and reduced risk of unexpected failures in the EBeam.

[0050] Ebeam may play a crucial role in various other products / devices, i.e., the PFS Pre-Filled Syringe) line as coupled to the Ebeam and monitored by the present system implementation for Jam detection, which involves placing sensors along the production line to monitor the flow of productsthrough the Ebeam sterilization process. These sensors provide real-time data to a monitoring system, which tracks product movement and identifies anomalies or disruptions that could indicate a jam. When a potential jam is detected, the system can automatically alert operators or trigger preprogrammed responses, such as stopping the line, adjusting speed, or clearing the jam. Additionally, data collected from the detection system can be analyzed by the present system to identify patterns or recurring issues, enabling process improvements and the prevention of future jams.Implementing Ebeam jam detection resulted in an increase in throughput from up to 145.2 tubs per hour. This significant improvement highlights the positive impact of Ebeam jam detection on the efficiency of the PFS line.

[0051] Specifically, comparing performance before and after the system's implementation. The baseline processing rate was 66.7 tubs per hour. After integrating the EBeam Jam Detection system, the average processing speed increased to 145.2 tubs per hour, marking a notable 120% improvement over the original rate. These findings underscore the effectiveness of the system and its methodology for processing alarm data using language models. The subsequent figures will provide additional details and insights into how the method and system of the present implementation and its integration with devices like the EBeam have achieved these performance gains.

[0052] Figure 1 is a flow diagram illustrating an example process 100 of providing a data structure of one or more alarms from a control system coupled to at least one device. The process comprises a method for establishing such data structure. This method involves managing alarms in a control system by systematically adding them to the data structure. When a first alarm is received along with its associated timestamps, it is added to a queue within the data structure designed to hold alarms from various devices connected to the control system. Subsequently, when a second alarm and its timestamps are received, it is added to the data structure, ensuring that the timestamps of both the first and second alarms are accounted for. This structured approach helps maintain an organized record of alarms and their occurrences, which can be used for further analysis and predictive maintenance.

[0053] By applying this structured approach, the system described herein can prioritize critical issues promptly while keeping track of less urgent alarms for routine maintenance and monitoring purposes. This structured approach helps maintain the synchronization of the EBeam, thereby reducing the risk of operational disruptions and improving efficiency.

[0054] In step 102, receiving a first alarm from the control system and first timestamps associated with the first alarm as received by the control system. The timestamps comprise a start timestamp that indicates when the first alarm was triggered based on sensor data collected by the control system. The first alarm may be a primary or non-primary alarm described herein.

[0055] In step 104, adding the first alarm to the data structure based on the first timestamps, where the data structure comprises a queue configured to hold one or more alarms associated with at least one device electronically coupled to the control system. More specifically, the first element is added to the queue, and then the first alarm is added to the first element for the duration of the first timestamps, typically from start to end. Each element of the queue may further comprise a stack, with each stack configured to hold one or more alarms. The added alarm is placed into the stack within the queue, and this may be done sequentially. The data structure is initiated and configured to store one or more alarms based on one or more timestamps associated with one or more alarms. One of these alarms of the stack may be a primary alarm.

[0056] For example, the primary alarm is added to the data structure, indicating critical EBeam equipment failures that require immediate attention. This primary alarm is placed in a queue with elements designed to hold every alarm from sensors, which monitor aspects of the EBeam, including the conveyor and paternoster apparatus. These sensors are electronically coupled to the control system and send alarm signals through the control system. The control system or interfacing system described herein aggregates these signals and manages them within the data structure, ensuring that all alarms, whether primary or secondary, are organized and accessible for timely analysis and response.

[0057] In step 106, receiving a second alarm from the control system and second timestamps associated with the second alarm as received by the control system. In the same way, the alarm is added to the data structure as the first alarm. The first and second alarms (and any further alarms) are organized in the queue according to one or more timestamps associated with each alarm. The second alarms and any further alarms are added sequentially to the data structure.

[0058] In step 108, adding the second alarm to the data structure based on the first timestamps and the second timestamps. More specifically, a second element is added to the queue. The first alarm in the second element is maintained for a duration of the first timestamps. The second alarm is added to the second element for the duration of the second timestamps. The first alarm and the secondalarm in the second element are maintained for the duration of the first timestamps and the second timestamps. In such a way, the alarms are organized and managed via the data structure. When one or more alarms are added to or removed from the data structure, an element is thereby added to the queue. The first timestamps and the second timestamps may each comprise a start timestamp and an end timestamp. Duration of the alarm may be calculated based on the start timestamp and the end timestamp.

[0059] The data structure may be further configured to remove the first alarm and second alarm according to the first timestamps and the second timestamps, respectively. The removal tends to occur when the end time of the alarm is reached, or the alarm event is no longer in effect.Moreover, the structure may be configured to store the first alarm for the duration in respective of the first timestamps; and where the data structure is configured to store the second alarm for the duration in respective of the second timestamps.

[0060] The data structure may add or remove alarms based on whether the alarm is primary or nonprimary. If the first alarm is a primary alarm and the second alarm is also a non-primary alarm, then an element would be added to the queue, and the first alarm or the second alarm would be added to the element. If the first alarm and the second alarm are both non-primary alarms, then an element would be added to the queue, and only the first alarm is added to the element.

[0061] The data structure not only maintains but stores these alarms, i.e., the first alarm and the second alarm are maintained in the data structure in respective of one or more elements of the queue based on the first timestamps and the second timestamps.

[0062] The alarms / alarm data stored in the data structure may be used as input to train a language model. More specifically, the data from the data structure is consolidated as a plurality of aggregated alarms data, and the training begins using the plurality of aggregated alarms. The language mode to be trained is configured to identify at least one primary alarm or at least one alarm pattern based on the plurality of aggregated alarms.

[0063] For example, consider a manufacturing facility using an EBeam conveyor and paternoster apparatus, where sensors monitor the system. Over time, the control system collects alarms indicating issues such as conveyor jams, synchronization errors, and sensor malfunctions. These alarms are stored in the data structure according to the timestamps. The next step involves consolidating this alarm data. Suppose we aggregate the alarms based on their occurrence withinspecific time windows, the types of sensors that triggered them, and the severity of each alarm.

[0064] By utilizing the aggregated data stored within the data structure as input, a language model configured to receive this structured data learns from the inherent patterns present within. The language model fed with the alarm data during training would be able to discern patterns and correlations that might not be readily discernible within the data. For instance, the model could uncover that a particular sequence of non-primary alarms frequently precedes a primary alarm, signaling a critical event in the operation of the EBeam apparatus. Through identifying such patterns, the language model gains the ability to forecast potential issues before they develop into severe problems, thereby aiding in proactive maintenance and operational optimization.

[0065] As a result, the trained language model can effectively identify primary alarms and discern alarm patterns based on the aggregated alarm data. This predictive capability allows operators to anticipate and address potential disruptions more proactively, enhancing the overall maintenance and operational efficiency of the manufacturing process. By leveraging historical alarm data to train the language model, the system becomes more adept at recognizing early warning signs and preventing significant downtime events.

[0066] In one example, the system receives a first data representation of at least one input alarm from the control system. This alarm is associated with specific devices in the EBeam apparatus, and it includes important metadata called data tags, which comprise timestamps indicating when the alarm was triggered.

[0067] Next, the system encodes the first data representation and the associated data tags using the language model. Encoding here means transforming the raw alarm data and its associated tags into a format that the language model can process. This transformation allows the model to understand and interpret the alarm data effectively.

[0068] Following the encoding process, the system maps the associated data tags to a learned representation of a plurality of aggregated alarm data. The language model has been trained on extensive alarm data, and through this training, it has developed a comprehensive understanding of various alarm patterns and their implications. The system aligns the new alarm data with previously identified patterns and trends by mapping the incoming data tags to this learned representation.

[0069] The next step involves generating a second data representation based on this mapping. Thissecond representation is a refined and contextually enriched version of the initial alarm data, enhanced by the insights and patterns recognized by the language model.

[0070] Finally, the system decodes the second data representation in response to at least one input to the control system. Decoding translates the enriched data back into a form that can be used to inform and guide the control system's responses. This could involve generating alerts, recommending actions, or adjusting operational parameters to mitigate potential issues identified by the language model.

[0071] In a further step, a trained language model can be utilized to analyze data and make predictions regarding the state of alarms in the EBeam system. By understanding patterns within the alarm data, i.e., the model can predict potential EBeam jams based on the alarm states. This allows for proactive maintenance and preemptive actions to prevent disruptions, thus minimizing downtime and enhancing operational efficiency. By integrating this advanced layer of intelligence, the EBeam system becomes more responsive and adaptive, improving overall workflow and reducing the frequency and severity of production interruptions. Effectively, these predictions may reduce the occurrence of jams related to the Ebeam process by improving timing, which is expected to lead to smoother operations and potentially higher throughput. The language model processes the aggregated data from the data structure, leveraging its learned patterns and correlations to generate insights and predictions as the system generates an output based on the language model, which comprises a prediction of an alarm state.

[0072] For example, the language model may process alarm data over time, identifying patterns that historically precede critical alarm states in the EBeam system. By leveraging these patterns, it predicts the likelihood of future alarms, including primary alarm triggers, within specified timeframes. Additionally, it recognizes sequences of non-primary alarms that typically lead to major system failures, enabling pre-emptive maintenance. The model would highlight areas of the EBeam system prone to operational disruptions (such as system downtime or reduced efficiency) based on historical trends and correlations in the data, aiding in proactive management and optimizing system performance.

[0073] The language model may also serve as a tool for processing queries related to the alarm data of the EBeam system, when receiving, by the language model, an input query in relation to at least one input alarm. In this case, the language model may be configured to constrain an output basedon the input query. When presented with the input query concerning the system's alarms, the language model would interpret the query and employ constraints to refine its output accordingly. These constraints help the model focus on specific aspects of the alarm data that are relevant to the query, ensuring that the generated output directly addresses the user's inquiry.

[0074] For example, if the query seeks information about the likelihood of primary alarms occurring within a certain timeframe, the language model considers historical data and time constraints to provide a probabilistic assessment. Similarly, if the query aims to identify patterns of non-primary alarms preceding major system failures, the model analyzes the data while adhering to the constraint of focusing on non-primary alarms. By tailoring its output based on the input query and associated constraints, the language model facilitates more precise and targeted insights into the alarm data of the EBeam system, aiding users in making informed decisions and optimizing system performance.

[0075] The constraints may comprise timeframe, alarm type, sensor-specific, threshold, patternbased, and correlative constraints. By applying these constraints, the system or system user can guide the language model's analysis and ensure that the generated output aligns with their specific informational needs and decision-making requirements regarding the alarms, i.e., from the EBeam system.

[0076] Figure 2 is a schematic diagram of an example system 200 for interfacing a control system coupled to one or more devices / apparatus. These devices and / or apparatus may be part of the same or another / different system, i.e., the same EBeam system(s) comprising a conveyor and paternoster apparatus. In the figure, the EBeam system or EBeam 208 comprises a conveyor / paternoster apparatus, with the position of tubs / containers along distinct conveyors and the sensor positions indicating the presence or absence of tubs / containers. EBeam 208 via the control system (not shown) regulates these sensors to govern the operation of two paternosters and two conveyors within the irradiation chamber. These elements are interconnected and operate in synchrony.Delays in their operational cycle could result in the pooling of tubs within the EBeam 208, causing a jam. As a result of the jam, the control system may produce alarms based on the sensor data representative of the jam. The sensor data / alarms are aggregated into a data structure and processed by one or more modules of the present system.

[0077] As shown, the EBeam 208 comprises various components, such as conveyors, sensors,pressure indicators, ozone and H2O2 monitors, and ventilation systems, which work together and are coupled to a control system. Conveyors (G17002, G17003, G17005, G18001, G18002, G19001, G19002) are used to transport tubs through the EBeam 208. Sensors (G17011, G17012, G17004, G19011, G19012) are positioned to monitor the presence of tubs and ensure proper flow. Pressure indicators (P05301, P05302, P05303) show the pressure levels within the system, which are crucial for maintaining proper operating conditions. Ventilation systems (F-05301, F-04303) ensure that the environment within the EBeam chamber is regulated. Ozone and H2O2 monitors (Q17001, Q08302, Q08301) display the concentrations of these substances, which are monitored to ensure safety and efficiency. The main drive (S18001) controls the speed of the tubs, ensuring they move at the correct pace through the EBeam chamber.

[0078] In operation, EBeam conveyor and paternoster apparatus may encounter operation disruptions due to synchronization errors. To alleviate these incidents, it is imperative to pinpoint, by the control system, alarm patterns and / or PLC sensor readings that anticipate such EBeam disruptions. The sensor readings are captured by sensors coupled to one or more devices / components of Ebeam 208, and processed by the PLC, control system. The recognition of specific alarms and their corresponding sensor patterns is vital in forecasting potential EBeam interruptions and facilitating alarm generation.

[0079] The example system 200 that interfaces the control system comprises modules that process alarm data provided by the control system derived from sensor data. The first module 202 receives alarm data and associated tags from the control system, followed by the second module 204 processing this data using language models to refine it into a more actionable representation. Subsequently, the third module 206 outputs this refined data in response to inputs to the control system. The language model is continuously trained on aggregated alarm data, adapting to patterns and correlations within the dataset over time, while timestamps associated with alarms aid in processing and analysis. A fourth module facilitates the graphical representation of the control system's output alongside the refined data. Additionally, or optionally, a fifth module generates alarm predictions based on historical sequences of alarms, predicting the likelihood of future alarm events. Additionally, or optionally, a sixth module updates the language model using both refined and raw alarm data, ensuring continuous improvement. Alarms are part of aggregated data compiled based on control system criteria, and the refined data is presented in a human-readable format. The control system itself includes circuits for data acquisition, processing, and response, with operations triggered by detected differences in time values or duration with respect totimestamps encoded as part of data tags.

[0080] First module 202 may be a data Reception Module. This module is responsible for receiving the initial alarm data from the control system. It gathers a first data representation of at least one input alarm, along with associated data tags. These tags provide contextual information about the alarms, such as timestamps and sensor identifiers. For example, at least one first module is configured to receive a first data representation of at least one input alarm from the control system and associated data tags corresponding to one or more devices.

[0081] Second module 204 may be a processing module. The module processes the received alarm data using one or more language models specifically tailored for EBeam 208. These language models are designed to understand the nuances of alarm data and convert the initial representation into a refined second data representation. This refined data is enriched with insights and patterns extracted from the associated data tags. For example, at least one second module is configured to process first data representation using at least one language model, where at least one language model is adapted to convert first data representation into a second data representation based on the associated data tags.

[0082] First module 206 may be an output module: The third module handles the output of the processed data. It takes the refined second data representation and outputs it in response to inputs received by the control system. This output can be in various formats, such as visualizations or reports, to aid operators in monitoring and managing the EBeam 208. For example, at least one third module is configured to output the second data representation in response to at least one input to the control system coupled to the Ebeam 208. The second data representation may comprise a human readable format corresponding to at least one input alarm.

[0083] The language model may be sequentially trained on a plurality of aggregated alarm data via the data structure. The plurality of aggregated alarm data corresponds to at least alarm. The plurality of aggregated alarm data may comprise a dataset corresponding to the associated data tags. For example, the associated data tags may comprise timestamps associated with at least one alarm. These associated data tags are processed by at least one second module in relation to one or more machine-to-machine communication protocols.

[0084] Further, the system may comprise additional modules that provide real-time graphical visualizations, predict potential future alarms based on historical data, and continuously update thelanguage model with new alarm data to enhance monitoring, predictive maintenance, and adaptive learning capabilities of the EBeam 208. For example, there may be at least one fourth module that is communicatively coupled to the control system, where at least one fourth module is adapted to display simultaneously a graphical representation of output from the control system in relation to the second data representation and at least one input to the control system. In another example, there may be at least one fifth module configured to generate at least one alarm prediction for one or more devices using at least one language model, where at least one prediction comprises a likelihood of an alarm trigger event based on a prior sequence of alarms from the control system within a time period. In a further example is at least one sixth module is configured to update at least one language model using the second data representation and the first data representation of at least one input alarm with respect to the associated data tags.

[0085] Furthermore, at least one input alarm is part of an aggregation of alarms compiled based on one or more criteria identified by the control system for each of one or more devices. The system aggregates input alarms based on specific criteria defined by the control system for each device involved. This means that rather than treating each alarm individually, the control system groups alarms according to certain rules or patterns. These criteria could include factors such as the type of alarm, the device or sensor generating the alarm, the time of occurrence, the severity of the alarm, or the sequence in which the alarms occur. By compiling alarms in this way, the system can analyze clusters of related alarms to identify underlying issues, trends, or patterns that might not be apparent when examining alarms in isolation. This aggregation helps provide a more comprehensive and contextual understanding of the system's performance and potential failure points.

[0086] A control system would incorporate several key components to effectively monitor and respond to sensor data. It comprises a data acquisition circuit that is coupled to one or more sensors, wherein the data acquisition circuit is configured to receive a plurality of time values from one or more sensors; a processing circuit configured to evaluate the plurality of time values, wherein the processing circuit comprising: a time circuit adapted to generate at least one signal; and a detection circuit adapted to determine a difference between at least one of the plurality of the time values and at least one signal from the time circuit; a response circuit configured to perform at least one operation in response to the difference meeting a threshold.

[0087] In effect, the data acquisition circuit that connects to multiple sensors collects various time values, representing the timing of events or conditions detected by these sensors. This data is thenprocessed by a processing circuit, which comprises a time circuit that generates signals and a detection circuit that calculates the difference between the collected time values and the signals from the time circuit. The processing circuit uses these differences to assess system performance and identify any timing discrepancies. Additionally, a response circuit within the processing circuit is responsible for performing operations when these differences meet a specific threshold, thus addressing any detected issues. The processing circuit also generates timestamps associated with each alarm, aiding in tracking, and analyzing alarm patterns over time. Based on the processed data, the system can add new alarms when new issues are detected or remove existing alarms when issues are resolved. This comprehensive approach ensures accurate monitoring and timely response to potential problems within the system.

[0088] For example, the control system for an EBeam 208 may include a data acquisition circuit connected to multiple sensors on one or more devices / apparatus of the EBeam 208. This circuit collects various time values from these sensors, which represent the timing of different events or conditions detected by the sensors. The collected data is then processed by a processing circuit that consists of a time circuit generating specific signals and a detection circuit that calculates the differences between the collected time values and the signals from the time circuit. If these differences meet a certain threshold, indicating potential issues, a response circuit within the processing circuit performs specific operations to address these discrepancies. This setup ensures precise monitoring and timely intervention for the EBeam 208.

[0089] The processing circuit is further designed to generate timestamps that are associated with each alarm. This means that whenever an alarm is triggered, the system records the exact time of the event. These timestamps are crucial for tracking the occurrence and duration of alarms, helping in the analysis of alarm patterns and the timing of events.

[0090] Moreover, the system can perform specific add or remove alarm operations based on the processed data and the generated timestamps. When a new issue is detected based on the evaluation of time values and signals, the system triggers a new alarm to be added. This operation alerts the operators to the new issue that needs attention. When an existing issue is resolved or no longer relevant, the system removes the corresponding alarm. This operation helps in keeping the alarm in the data structure updated and relevant, ensuring that the operators focus on active and unresolved issues.

[0091] An example system may involve an Ebeam used in a pharmaceutical manufacturing facility. The system is further equipped with sensors and alarms that monitor various parameters such as temperature, pressure, and beam intensity during the sterilization process, as similarly shown in the figure. Certain combinations of alarm triggers have preceded equipment malfunctions or jams, leading to production delays. By deploying the present system, the facility can analyze alarm data to identify patterns indicating potential jams before they occur using the language model. For instance, if a specific sequence of alarm triggers has previously correlated with beam misalignment or overheating issues, the language model can recognize this pattern and predict a potential jam before it escalates. This predictive capability enables the maintenance team to take proactive measures, such as adjusting equipment settings or scheduling preventive maintenance, thereby minimizing downtime and ensuring continuous production flow.

[0092] Figure 3 is a pictorial diagram illustrating a device (EBeam) sensor data 300 used to generate aggregated alarm data as a training dataset for a language model. EBeam sensor data is presented in a timeline view over an operational window (i.e.,40 minutes), highlighting sensor states and patterns to identify potential issues within the EBeam apparatus. Sensor data are collected from various sensors, including G17002 (infeed sensor 1), G17003 (infeed sensor 2), G17004 (tub stop sensor), G17005 (pull in sensor), Conv 1 to Conv 3, G18001 (emitter zone infeed), G18002 (emitter zone outfeed), G19001 (outfeed sensor), TRR infeed / discharge, and Tyvek / sheet removal stations. Some of these sensors are shown in Figure 2.

[0093] It is understood that specific sensors may exhibit abnormal timing patterns, which indicate potential issues with the device. These sensors may show a repetitive pattern of activation (ON state) and deactivation (OFF state), with a consistent duration of activation suggesting a recurring process. Sensor demonstrating a recurring activation pattern maintains consistent timing of its activations throughout the observation window. By analyzing the sensor data, especially the patterns, the system can identify and correct discrepancies, enhancing the operational efficiency and reliability of the conventional alarm process.

[0094] For example, as highlighted, if sensor G18001 (emitter zone infeed) remains "ON" for more than 10 seconds, it indicates a timing discrepancy with the conveyor, as its typical "ON" duration is under 5 seconds. If the lag between the "OFF" state of sensor G18002 (emitter zone outfeed) and the "ON" state of sensor G19001 (outfeed sensor) exceeds 45 seconds, a potential issue is suggested, and an alarm may be produced by the control system coupled to the EBeam.

[0095] Timing Relationship: Correlation analysis shows that the transition from sensor 18002's OFF state to sensor 19001's ON state should occur within a designated timing window (e.g., less than 45 seconds). The provided data indicates that these transitions follow each other almost instantaneously, suggesting a synchronized timing relationship.

[0096] Irregularities: Certain sections of the data show a prolonged OFF state for sensor 18002 or a delayed activation of sensor 19001. These irregularities may indicate potential issues with the conveyor system synchronization, which could lead to disruptions or operational inefficiencies.

[0097] Based on the data, sensors 18002 and 19001 visually exhibit a consistent pattern of operation with a typical transition window between their states. Deviations from this anticipated timing pattern may indicate underlying issues with the conveyor system synchronization and may require further investigation or intervention to prevent EBeam disruptions. This analysis offers a predictive capacity, via the present system, to identify potential issues and improve maintenance and operational efficiency. It is understood that by examining these patterns, the present system can detect and address timing discrepancies, enhancing the operational efficiency and reliability of the EBeam.

[0098] To achieve the desired predictive capacity, EBeam sensor data can be aggregated into a data structure suitable for training a language model. This data structure serves as input for training, beginning with the consolidation of sensor data into a plurality of aggregated alarm data. These aggregated alarms are used during the training process. The trained language model is then configured to identify primary alarms or specific alarm patterns based on the aggregated data. During inference, the language model applies its training to make predictions, determining whether the input contains a primary alarm with a specified pattern from sensor data deviating from normal operation and prior to historical interruptions.

[0099] The process for training a language model using a data structure of multiple alarms involves several steps. A first data representation of at least one input alarm from the control system is received, along with associated data tags that include timestamps. This data representation and its tags are then encoded using the language model. The associated data tags are mapped to a learned representation of aggregated alarm data, resulting in the generation of a second data representation based on this mapping. The second data representation is decoded in response to at least one input to the control system, facilitating improved predictive capabilities and operational efficiency.

[0100] Trained language model can analyze alarms occurring within a specific period using timestamps and make predictions based on alarm priority and recognizable patterns. This capability enables the system to enhance the operator's ability to identify potential issues with not only the EBeam apparatus but also any other device / apparatus coupled to the control system, thereby reducing significant downtime events and increase alarms utility. Moreover, the present system and process provides a robust framework for the swift and automated detection of sensor states and patterns, facilitating the prediction of device interruptions.

[0101] Figure 4 is a schematic diagram of a computing device 400 suitable for implementing one or more aspects of the data configuration system(s), apparatus, method(s), and / or process(es) combinations thereof, modifications thereof, and / or as described with reference to figure 1 to 3 and / or as described herein. Computing device 400 includes one or more processor unit(s) 401, an input / output unit 402, communications unit / interface 403, a memory unit 404 in which the one or more processor unit(s) 401 are connected to the input / output unit 402, communications unit / interface 403, and the memory unit 404. In some embodiments, the computing device 400 may be a server, or one or more servers networked together. In some embodiments, the computing device 400 may be a computer or supercomputer / processing facility or hardware / software suitable for processing or performing the one or more aspects of the data configuration system(s), apparatus, method(s), and / or process(es) combinations thereof, modifications thereof, and / or as described with reference to figures 1 to 3 and / or as described herein. The communications interface 403 may connect the computing device 400, via a communication network, with one or more services, devices, server system(s), cloud-based platforms, systems for implementing subject-matter databases and / or knowledge graphs for implementing the invention as described herein. The memory unit 404 may store one or more program instructions, code or components such as, by way of example only but not limited to, an operating system and / or code / component(s) associated with the data model configuration process(es) / method(s) as described with reference to figure 1 to 3, additional data, applications, application firmware / software and / or further program instructions, code and / or components associated with implementing the functionality and / or one or more function(s) or functionality associated with one or more of the method(s) and / or process(es) of the device, service and / or server(s) hosting the data model configuration process(es) / method(s) / system(s), apparatus, mechanisms and / or system(s) / platforms / architectures for implementing the invention as described herein, combinations thereof, modifications thereof, and / or as described with reference to at least one of figure 1 to 3.

[0102] In one aspect is a computer-implemented method for establishing a data structure of one or more alarms from a control system coupled to at least one device, comprising: receiving a first alarm from the control system and first timestamps associated with the first alarm as received by the control system; adding the first alarm to the data structure based on the first timestamps, wherein the data structure comprising a queue configured to hold said one or more alarms associated with said at least one device electronically coupled to the control system; receiving a second alarm from the control system and second timestamps associated with the second alarm as received by the control system; and adding the second alarm to the data structure based on the first timestamps and the second timestamps. In another aspect is a system for interfacing with a control system coupled to one or more devices, the system comprising: at least one first module configured to receive a first data representation of at least one input alarm from the control system and associated data tags corresponding to said one or more devices; at least one second module configured to process said first data representation using at least one language model, wherein said at least one language model is adapted to convert said first data representation into a second data representation based on the associated data tags; and at least one third module configured to output the second data representation in response to at least one input to the control system. In yet another aspect is a computer-implemented method of training a language model described herein. The method comprising: receiving a first data representation of at least one input alarm complied in a data structure from the control system and associated data tags corresponding to said at least one device, wherein the associated data tags comprising timestamps of said at least one input alarm; encoding the first data representation of at least one input alarm and the associated data tags using the language model; mapping the associated data tags to a learned representation of a plurality of aggregated alarm data; generating a second data representation based on said mapping; and decoding the second data representation in response to at least one input to the control system. In yet another aspect is a non-transitory machine-readable storage medium, comprising executable instructions that, when executed by a processor, facilitate performance of operations according one or more aspects herein described.

[0103] In relation one or more aspects described above, as an option, further comprising: initiating the data structure configured to store said one or more alarms sequentially based on one or more timestamps associated with said one or more alarms. As another option, wherein each element of the queue comprising a stack configured to hold at least one alarm of said one or more alarms. As another option, wherein said at least one alarm of the stack comprising at least one primary alarm.As another option, further comprising: adding an element to the queue when said one or more alarms are added to or removed from the data structure. As another option, wherein said one or more alarms are organized in the queue according to one or more timestamps associated with each alarm. As another option, wherein the data structure is configured to remove the first alarm and second alarm according to the first timestamps and the second timestamps respectively. As another option, wherein the first alarm and the second alarm are added sequentially to the data structure. As another option, wherein the data structure is configured to store the first alarm for a duration respective of the first timestamps; and wherein the data structure is configured to store the second alarm for a duration respective of the second timestamps. As another option, wherein the first timestamps and the second timestamps each comprising a start timestamp and an end timestamp. As another option, further comprising: maintaining the first alarm and the second alarm in respective of one or more elements of the queue based on the first timestamps and the second timestamps. As another option, wherein said adding the first alarm to the data structure based on the first timestamps, further comprising: adding a first element to the queue; and adding the first alarm to the first element for a duration of the first timestamps. As another option, wherein said adding the second alarm to the data structure based on the first timestamps and the second timestamps, further comprising: adding a second element to the queue; maintaining the first alarm in the second element for a duration of the first timestamps; adding the second alarm to the second element for a duration of the second timestamps; and maintaining the first alarm and the second alarm in the second element for a duration of the first timestamps and the second timestamps. As another option, wherein the first alarm is a primary alarm and the second alarm is a non-primary alarm; further comprising: adding an element to the queue; and adding the first alarm or the second alarm to the element. As another option, wherein the first alarm and the second alarm are nonprimary alarms; further comprising: adding an element to the queue; and adding the first alarm to the element. As another option, further comprising: applying the data structure as input to a language model. As another option, wherein said applying the data structure as input to the language model, further comprising: consolidating data from the data structure as a plurality of aggregated alarm data; and training the language model using the plurality of aggregated alarms, wherein the language model is configured to identify at least one primary alarm or at least one alarm pattern based on the plurality of aggregated alarms. As another option, further comprising: receiving a first data representation of at least one input alarm from the control system and associated data tags corresponding to said at least one device, wherein the associated data tags comprising timestamps of said at least one input alarm; encoding the first data representation of atleast one input alarm and the associated data tags using the language model; mapping the associated data tags to a learned representation of a plurality of aggregated alarm data; generating a second data representation based on said mapping; and decoding the second data representation in response to at least one input to the control system. As another option, further comprising: generating an output based on the language model, wherein the output comprising a prediction of an alarm state. As another option, further comprising: receiving, by the language model, an input query in relation to the said at least one input alarm, wherein the language model is configured to constrain an output based on the input query.

[0104] As yet another option, wherein said at least one language model is sequentially trained on a plurality of aggregated alarm data corresponding to said at least alarm. As another option, wherein the plurality of aggregated alarm data comprising a dataset corresponding to the associated data tags. As another option, wherein the associated data tags comprising timestamps associated with said at least one alarm. As another option, wherein the associated data tags are processed by said at least one second module in relation to one or more machine-to-machine communication protocols. As another option, further comprising: at least one fourth module communicatively coupled to the control system, wherein said at least one fourth module is adapted to display simultaneously a graphical representation of output from the control system in relation to the second data representation and said at least one input to the control system. As another option, further comprising: at least one fifth module configured to generate at least one alarm prediction for said one or more devices using said at least one language model, wherein said at least one prediction comprises a likelihood of an alarm trigger event based on a prior sequence of alarms from the control system within a time period. As another option, further comprising: at least one sixth module configured to update said at least one language model using the second data representation and the first data representation of at least one input alarm with respect to the associated data tags. As another option, wherein at least one input alarm is part of an aggregation of alarms compiled based on one or more criteria identified by the control system for each of said one or more devices. As another option, wherein the second data representation comprising a human readable format corresponding to said at least one input alarm. As another option, wherein the control system comprising: a data acquisition circuit that is coupled to one or more sensors, wherein the data acquisition circuit is configured to receive a plurality of time values from said one or more sensors; a processing circuit configured to evaluate the plurality of time values, wherein the processing circuit comprising: a time circuit adapted to generate at least one signal, and a detection circuit adapted todetermine a difference between at least one of the plurality of the time values and said at least one signal from the time circuit; and a response circuit configured to perform at least one operation in response to the difference meeting a threshold. As another option, wherein the processing circuit is configured to generate timestamps associated with said at least one alarm. As another option, wherein said at least one operation comprising: an add alarm operation and a remove alarm operation.

[0105] Herein described embodiments of may operate on a certain device comprising one or more processors, which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to gather and record routing information. For example, where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the process / method in hardware (rather than software or firmware). Platform software comprising an operating system, or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[0106] Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium or non-transitory computer- readable medium. Computer-readable media may include, for example, computer-readable storage media. Computer-readable storage media may include volatile, or non-volatile, removable or nonremovable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data.

[0107] Functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs). Complex Programmable Logic Devices (CPLDs), etc.

[0108] Although illustrated as a single system, it is to be understood that the computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by thecomputing device.

[0109] Although illustrated as a local device it will be appreciated that the computing device may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[0110] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, loT devices, mobile telephones, personal digital assistants and many other computing devices.

[0111] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.

[0112] Further, as used herein, the term "exemplary", "example" or "embodiment" is intended to mean "serving as an illustration or example of something". Further, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

[0113] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and / or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and / or the like. Still further, results of acts of the methods can be stored in a computer-readable medium, displayed on a display device, and / or the like.

[0114] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein.

[0115] Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0116] What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

CLAIMS1. A method for establishing a data structure of one or more alarms from a control system coupled to at least one device, comprising: receiving a first alarm from the control system and first timestamps associated with the first alarm as received by the control system; adding the first alarm to the data structure based on the first timestamps, wherein the data structure comprising a queue configured to hold said one or more alarms associated with said at least one device electronically coupled to the control system; receiving a second alarm from the control system and second timestamps associated with the second alarm as received by the control system; and adding the second alarm to the data structure based on the first timestamps and the second timestamps.

2. The method of claim 1, further comprising: initiating the data structure configured to store said one or more alarms sequentially based on one or more timestamps associated with said one or more alarms.

3. The method of claim 1 or 2, wherein each element of the queue comprising a stack configured to hold at least one alarm of said one or more alarms.

4. The method of claim 3, wherein said at least one alarm of the stack comprising at least one primary alarm.

5. The method of any preceding claim, further comprising: adding an element to the queue when said one or more alarms are added to or removed from the data structure.

6. The method of any preceding claim, wherein said one or more alarms are organized in the queue according to one or more timestamps associated with each alarm.

7. The method of any preceding claims, wherein the data structure is configured to removethe first alarm and second alarm according to the first timestamps and the second timestamps respectively.

8. The method of any preceding claim, wherein the first alarm and the second alarm are added sequentially to the data structure.

9. The method of any preceding claim, wherein the data structure is configured to store the first alarm for a duration respective of the first timestamps; and wherein the data structure is configured to store the second alarm for a duration respective of the second timestamps.

10. The method of any preceding claim, wherein the first timestamps and the second timestamps each comprising a start timestamp and an end timestamp.

11. The method of any preceding claim, further comprising: maintaining the first alarm and the second alarm in respective of one or more elements of the queue based on the first timestamps and the second timestamps.

12. The method of claims any preceding claim, wherein said adding the first alarm to the data structure based on the first timestamps, further comprising: adding a first element to the queue; and adding the first alarm to the first element for a duration of the first timestamps.

13. The method of any preceding claim, wherein said adding the second alarm to the data structure based on the first timestamps and the second timestamps, further comprising: adding a second element to the queue; maintaining the first alarm in the second element for a duration of the first timestamps; adding the second alarm to the second element for a duration of the second timestamps; and maintaining the first alarm and the second alarm in the second element for a duration of the first timestamps and the second timestamps.

14. The method of any preceding claim, wherein the first alarm is a primary alarm and the second alarm is a non-primary alarm; further comprising: adding an element to the queue; and adding the first alarm or the second alarm to the element.

15. The method of claims 1 to 13, wherein the first alarm and the second alarm are nonprimary alarms; further comprising: adding an element to the queue; and adding the first alarm to the element.

16. The method of any preceding claims, further comprising: applying the data structure as input to a language model.

17. The method of claim 16, wherein said applying the data structure as input to the language model, further comprising: consolidating data from the data structure as a plurality of aggregated alarm data; and training the language model using the plurality of aggregated alarms, wherein the language model is configured to identify at least one primary alarm or at least one alarm pattern based on the plurality of aggregated alarms.

18. The method of claim 16 or 17, further comprising: receiving a first data representation of at least one input alarm from the control system and associated data tags corresponding to said at least one device, wherein the associated data tags comprising timestamps of said at least one input alarm; encoding the first data representation of at least one input alarm and the associated data tags using the language model; mapping the associated data tags to a learned representation of a plurality of aggregated alarm data; generating a second data representation based on said mapping; and decoding the second data representation in response to at least one input to thecontrol system.

19. The method of claims 16 to 18, further comprising: generating an output based on the language model, wherein the output comprising a prediction of an alarm state.

20. The method of claims 16 to 19, further comprising: receiving, by the language model, an input query in relation to the said at least one input alarm, wherein the language model is configured to constrain an output based on the input query.

21. A system for interfacing with a control system coupled to one or more devices, the system comprising: at least one first module configured to receive a first data representation of at least one input alarm from the control system and associated data tags corresponding to said one or more devices; at least one second module configured to process said first data representation using at least one language model, wherein said at least one language model is adapted to convert said first data representation into a second data representation based on the associated data tags; and at least one third module configured to output the second data representation in response to at least one input to the control system.

22. The system of any preceding claims, wherein said at least one language model is sequentially trained on a plurality of aggregated alarm data corresponding to said at least alarm.

23. The system of claim 22, wherein the plurality of aggregated alarm data comprising a dataset corresponding to the associated data tags.

24. The system of claims 21 to 23, wherein the associated data tags comprising timestampsassociated with said at least one alarm.

25. The system of claims 21 to 24, wherein the associated data tags are processed by said at least one second module in relation to one or more machine-to-machine communication protocols.

26. The system of claims 21 to 25, further comprising: at least one fourth module communicatively coupled to the control system, wherein said at least one fourth module is adapted to display simultaneously a graphical representation of output from the control system in relation to the second data representation and said at least one input to the control system.

27. The system of claims 21 to 26, further comprising: at least one fifth module configured to generate at least one alarm prediction for said one or more devices using said at least one language model, wherein said at least one prediction comprises a likelihood of an alarm trigger event based on a prior sequence of alarms from the control system within a time period.

28. The system of claims 21 to 27, further comprising: at least one sixth module configured to update said at least one language model using the second data representation and the first data representation of at least one input alarm with respect to the associated data tags.

29. The system of claims 21 to 28, wherein at least one input alarm is part of an aggregation of alarms compiled based on one or more criteria identified by the control system for each of said one or more devices.

30. The system of claims 21 to 29, wherein the second data representation comprising a human readable format corresponding to said at least one input alarm.

31. The system of claims 21 to 30, wherein the control system comprising:a data acquisition circuit that is coupled to one or more sensors, wherein the data acquisition circuit is configured to receive a plurality of time values from said one or more sensors; a processing circuit configured to evaluate the plurality of time values, wherein the processing circuit comprising: a time circuit adapted to generate at least one signal, and a detection circuit adapted to determine a difference between at least one of the plurality of the time values and said at least one signal from the time circuit; and a response circuit configured to perform at least one operation in response to the difference meeting a threshold.

32. The system of claim 31, wherein the processing circuit is configured to generate timestamps associated with said at least one alarm.

33. The system of claim 32 or 33, wherein said at least one operation comprising: an add alarm operation and a remove alarm operation.

Images