Description:TECHNICAL FIELD
The present disclosure relates to Internet of things (IoT). In particular, the present disclosure relates a system and a method for managing at least one asset type.
BACKGROUND
In recent years, Internet of Things (IoT) has seen rapid advancements, with use cases expanding across various industries revolutionizing industries across the globe by connecting devices, assets, and systems to share data and improve decision-making. However, the industries still largely rely on traditional protocol standards that have been in place for decades. The traditional protocol standards lack flexibility and scalability needed to support growing complexity of modern IoT ecosystems. As IoT devices proliferate, there is a pressing need for efficient ways to manage and control the IoT devices, ensure seamless configuration of the IoT devices, and manipulate data efficiently between the IoT devices.
The traditional protocol standards, though effective for simple, point-to-point communications, struggle to meet the demands of contemporary IoT systems. As the IoT systems grow in size and complexity, they encounter significant challenges in terms of scalability, configuration, and data management. The traditional protocol standards typically focus on the individual devices or the assets transmitting data independently, leading to inefficiencies in data management and data transmission across the IoT systems. Furthermore, the traditional protocol standards are unable to leverage advanced capabilities of the modern IoT devices, such as enhanced processing power, connectivity, the scalability and real-time analytics in an efficient way, which results in fragmented data streams and a lack of seamless integration across the IoT systems and platforms.
SUMMARY
The present disclosure seeks to provide a novel system and method for managing at least one asset type that enhances operational efficiency, scalability, and ease of integration, while reducing the complexity typically associated with IoT systems. The aim of the present disclosure is achieved by a system and a method as defined in the appended independent claims. Advantageous features are set out in the appended dependent claims.
A primary objective of the present disclosure is to offer an asset management solution that generates a universal digital twin for each asset type, utilizing a standardized set of parameters to ensure efficient data management, prioritization, and transmission.
Another objective of the present disclosure is to enable seamless data exchange between plurality of models of the at least one asset type through an optimized gateway, facilitating real-time monitoring and performance assessment without the need for multiple gateways.
Yet another objective of the present disclosure is to categorize parameters into standardized classes, which enhances the efficiency of asset management and streamlines overall operation of the system.
Yet another objective of the present disclosure is to aggregate one more data packets associated with the at least one asset type, to form a single transmission packet for broadcasting. Further, individual sampling and transmission intervals can be defined for each asset type of the at least one asset types, allowing for dynamic switching between the one or more models of the at least one asset type. Thus, the approach significantly reduces number of gateways required, making the system more scalable for large-scale deployments. Furthermore, reducing the number of devices needed to handle asset communication, decreases system complexity, and improves data flow by maximizing packet size.
An additional advantage of the present disclosure is the simplified method for field configuration of the one or more models, at least one asset type, and sites, ensuring scalability across various deployment categories. The method simplifies field configuration, debugging, and error identification. The method receives configuration packets that define asset parameters, acquisition systems, and specific hardware protocols, enabling the method to decode the network and transmit data according to defined intervals. Moreover, the method captures health parameters and telemetry errors, broadcasting all data in a single packet, ensuring efficient monitoring and error-free operation.
Throughout the description and claims of this specification, the words "comprise", "include", "have", and "contain" and variations of these words, for example, "comprising" and "comprises", mean "including but not limited to", and do not exclude other components, items, integers or steps not explicitly disclosed also to be present. Moreover, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.
BRIEF DESCRIPTION OF DRAWINGS
The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those skilled in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.
Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:
FIG. 1 illustrates a block diagram of a system for managing at least one asset type, in accordance with an embodiment of the present disclosure;
FIG. 2 illustrates a block diagram of an exemplary hierarchical one or more standardized classes of the universal set of parameters, in accordance with the embodiment of the present disclosure;
FIG. 3A illustrates a schematic illustration of an implementation scenario of the system implemented utilizing a single gateway for data transmission for the at least one asset types, in accordance with the embodiment of the present disclosure;
FIG. 3B illustrates a schematic illustration depicting a drilling compressor vehicle onboarding plurality of integrated models, in accordance with an embodiment of the present disclosure;
FIG. 4 illustrates a block diagram depicting different modes of data exchange between one or more sensors and the at least one asset type through one or more gateways, in accordance with the embodiment of the present disclosure; and
FIG. 5 illustrates a flowchart depicting steps of a method for managing at least one asset type, in accordance with an embodiment of the present disclosure.
In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non-underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.
DETAILED DESCRIPTION
The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.
In the first aspect, the present disclosure provides a system for managing at least one asset type, the system comprising:
at least one processor configured to:
receive a set of parameters associated with a plurality of models of each asset type from amongst the at least one asset type;
generate a universal digital twin for each asset type from amongst the at least one asset type, wherein the universal digital twin comprises a universal set of parameters for each asset type, based on the received set of parameters;
categorize the universal set of parameters into one or more standardized classes, wherein the one or more standardized classes are generated based on standardization of the universal set of parameters;
prioritize transmission of at least one critical parameter from amongst the universal set of parameters, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes;
determine a mode of data exchange for the universal digital twin of each asset type from amongst the at least one asset type to exchange data with at least one sensor via at least one gateway;
generate a standardized configuration protocol for the at least one asset type; and
receive an asset status update from the each asset type from amongst the at least one asset type.
In the second aspect, the present disclosure provides a method for managing at least one asset type, the method comprising:
receiving a set of parameters associated with a plurality of models of each asset type from amongst the at least one asset type;
generating a universal digital twin for each asset type from amongst the at least one asset type, wherein the universal digital twin comprises a universal set of parameters for each asset type, based on the received set of parameters;
categorizing the universal set of parameters into one or more standardized classes, wherein the one or more standardized classes are generated based on standardization of the universal set of parameters;
prioritizing transmission of at least one critical parameter from amongst the universal set of parameters, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes;
determining a mode of data exchange for the universal digital twin of each asset type from amongst the at least one asset type to exchange data with at least one sensor via at least one gateway;
generating a standardized configuration protocol for the at least one asset type; and
receiving an asset status update from the each asset type from amongst the at least one asset type.
The present disclosure provides the aforementioned system and method designed to enhance asset monitoring and performance optimization. The disclosed system and method seeks to address the challenges of the conventional internet of things (IoT) systems by proposing a novel system that utilizes advanced processing capabilities to seamlessly receive and process a set of parameters from multiple models of each asset type. By generating a universal digital twin for each asset type, the system and method creates a standardized set of parameters that can be categorized into predefined classes. Further, the system and method aims to improve operational efficiency and provide a reliable, dynamic framework for ongoing asset performance assessment.
Referring to FIG. 1, illustrated is a block diagram of a system 100 for managing at least one asset type (depicted as a first asset type 102), in accordance with an embodiment of the present disclosure. The system 100 comprises at least one processor 104 configured to receive a set of parameters associated with a plurality of models (depicted as a first model 106A, a second model 106B, and a third model 106C) of each asset type from amongst the at least one asset type 102. Moreover, the at least one processor 104 is configured to generate a universal digital twin 108 for each asset type from amongst the at least one asset type 102. The universal digital twin 108 comprises a universal set of parameters (depicted as a first parameter 110A, a second parameter 110B, up to an nth parameter 110N) for each asset type, based on the received set of parameters. Furthermore, the at least one processor 104 is configured to categorize the universal set of parameters 110A-N into one or more standardized classes (depicted as a first standardized class 112A, a second standardized class 112B, a third standardized class 112C, up to an nth standardized class 112N), wherein the one or more standardized classes 112A-N are generated based on standardization of the universal set of parameters 110A-N. Furthermore, the at least one processor 104 is configured to prioritize transmission of at least one critical parameter from amongst the universal set of parameters 110A-N, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes 112A-N. Furthermore, the at least one processor 104 is configured to determine a mode of data exchange for the universal digital twin 108 of each asset type from amongst the at least one asset type 102 to exchange data with at least one sensor (depicted as a sensor 114) via at least one gateway (depicted as a gateway 116). Furthermore, the at least one processor 104 is configured to generate a standardized configuration protocol for the at least one asset type 102. Furthermore, the at least one processor 104 is configured to receive an asset status update from the each asset type from amongst the at least one asset type 102.
Notably, the at least one processor 104, communicably coupled to the at least one asset type 102, and configured to manage at least one asset type 102. The at least one processor 104 serves as a centralized unit or hub to manage and synchronize all connected devices, namely the at least one asset type 102. Herein, the term "processor" 104 refers to a computational element that is operable to execute the software framework. It will be appreciated that the "at least one processor" refers to "one processor" in some implementations, and "a plurality of processors" in other implementations. Examples of the at least one processor 104 include, but are not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or any other type of processing circuit. Furthermore, the at least one processor 104 may refer to one or more individual processors, processing devices and various elements associated with a processing device that may be shared by other processing devices. Additionally, one or more individual processors, processing devices and elements are arranged in various architectures for responding to and processing the instructions that execute the software framework. Herein, the at least one processor 104 interfaces with the at least one asset type 102, enabling precise control of power delivery to the plurality of models 106A-C. The at least one processor 104 can dynamically adjust power supply based on user commands, automation routines, or sensor inputs. For instance, the at least one processor 104 may signal to power down certain models of the plurality of models 106A-C when not in use, improving energy efficiency.
Herein, the at least one processor 104 is communicably and operatively coupled to the at least one asset type 102 and/or the plurality of models 106A-C via a communication network. The term "communication network" refers to a network of interconnected programmable and/or non-programmable components that are configured to facilitate data communication between one or more electronic devices, whether available or known at the time of filing or as later developed. Furthermore, the communication network may include, but is not limited to, one or more peer-to-peer network, a hybrid peer-to-peer network, local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANS), wide area networks (WANs), all or a portion of a public network such as the global computer network known as the Internet, a private network, a cellular network and any other communication system or systems at one or more locations.
Throughout the present disclosure, the term "asset type" 102 as used herein refers to an entity that is designed to perform a specific function or operation. It will be appreciated that "the at least one asset type" refers to "one asset type" in some implementations, and "a plurality of asset types" in other implementations. For example, in an industrial system, the at least one asset type 102 is a pump, a motor, or a compressor. Similarly, in a fleet management system, the at least one asset type 102 is a truck or a delivery van. Optionally, the at least one asset type 102 is a building, an electrical device, or other equipment. The at least one asset type 102 encompasses a range of individual models (referred as "the plurality of models" 106A-C throughout the present disclosure) that perform similar roles, are subject to similar operational parameters, or have comparable physical properties, regardless of specific differences between the plurality of models 106A-C for the at least one asset type 102. According to one embodiment of the present disclosure, the at least one asset type 102 serves as the basis for creating the universal digital twin 108 that reflects the universal set of parameters 110A-N for the plurality of models 106A-C of the at least one asset type 102.
Herein, the term "universal digital twin" 108 refers a comprehensive digital representation designed to standardize and unify the monitoring, analysis, and management of the at least one asset type 102. The universal digital twin 108 serves as a dynamic, real-time model that captures and reflects the operational parameters, performance metrics, and diagnostic data of the at least one asset type 102, regardless of their specific models or configurations. Notably, the universal digital twin 108 encompasses data from the plurality of models 106A-C of the at least one asset type 102, enabling consistent tracking and analysis of conditions of the plurality of models 106A-C of the at least one asset type 102. The universal digital twin 108 is not limited to a single model of the at least one asset type 102 but can integrate data from the plurality of models 106A-C, ensuring a holistic view of performance of the at least one asset type 102. The universal digital twin 108 supports functionalities such as predictive maintenance, operational optimization, and lifecycle management by consolidating and processing real-time data streams for the at least one asset type 102. By leveraging the universal digital twin 108, the system 100 can efficiently manage each asset type from amongst the at least one asset type 102 across different environments, ensuring data completeness, redundancy, and real-time visibility into health and performance associated with the at least one asset type 102.
Throughout the present disclosure, the term "set of parameters" refers to a collection of or variables that are associated with one or more of: operational, performance, diagnostic, and environmental aspects of a plurality of models 106A-C of the at least one asset type 102. Notably, the set of parameters for each model from amongst the plurality of models 106A-C of the at least one asset type 102 is different. The set of parameters serves as the foundational data required for accurate monitoring, analysing, and managing the performance and status of each asset type in the system 100.
According to an embodiment of the present disclosure, the set of parameters may include at least one of: a first set of parameters 118A-D associated with the first model 106A from amongst the plurality of models 106A-C, a second set of parameters 120A-D associated with the second model 106B from amongst the plurality of models 106A-C, and a third set of parameters 122A-D associated with the third model 110 of the plurality of models 106A-C. Each parameter of the set of parameters corresponds to specific characteristics, operational data, and diagnostic information relevant to the respective model from amongst the plurality of models 106A-C. For example, the first set of parameters 118A-D may encompass data such as operational status, performance metrics, fault conditions, and environmental parameters relevant to the first model 106A. Similarly, the second set of parameters 120A-D may include parameters related to efficiency metrics, resource consumption, and maintenance schedules specific to the second model 106B. The third set of parameters 122A-D could represent diagnostic data, real-time monitoring values, and asset health indicators pertinent to the third model 106C. Optionally, the set of parameters may include at least one of: data relating to health, performance, status, features, error associated with the plurality of models 106A-C of the each asset type. In this regard, health data may include metrics such as temperature, vibration levels, battery condition, or wear-and-tear indicators that reflect the physical condition of the at least one asset type 102. The performance data may comprise throughput rates, efficiency ratios, energy consumption, or processing speed, enabling assessment of how effectively the at least one asset type 102 operates under various conditions. The status data may refer to the current operational state, such as active, idle, standby, or maintenance mode for the at least one asset type 102. The features may include model-specific capabilities, configurations, or firmware versions that differentiate performance characteristics among models. The error may capture failure logs, and alert histories indicating malfunction patterns or critical issues in the at least one asset data type 102. A technical effect is that the inclusion of diverse parameters such as health, performance, status, features, and errors facilitates a holistic evaluation of asset conditions across the plurality of models 106A-C, which facilitates more accurate monitoring, early detection of potential issues, and data-driven insights for optimizing performance, reliability, and maintenance strategies for the at least one asset type 102.
The set of parameters further utilized by the at least one processor 104 to generate the universal digital twin 108 for each asset type 104 by normalizing the received set of parameters from the plurality of models 106A-C. The normalization facilitate the generation of the universal set of parameters 110A-N. Throughout the present disclosure, the term "universal set of parameters" 110A-N refers to the parameters that are normalized by combining or consolidating one or more common operational characteristics that are shared across the set of parameters for the plurality of models 106A-C and one or more parameters of the set of parameters that are available for only one model and/or two models from amongst the plurality of models 106A-C and/or that are not shared among all models of the plurality of models 106A-C. The consolidation ensures that both common and unique parameters are represented in the universal set of parameters 110A-N that reflects the complete operational profile of each asset type of the at least one asset type 102. For example, in an industrial system, parameters related to engine performance, fuel consumption, and sensor diagnostics may be common across the plurality of models 106A-C, thus categorized under one or more standardized classes 112A-N such as "performance metrics", "energy efficiency parameters", and "health diagnostics". Optionally, the at least one processor 104 is further configured to generate at least one feature associated with the plurality of models 106A-C based on the universal set of parameters 110A-N. The at least one feature may indicate one or more parameters associated with one or more specific models of the plurality of models 106-A-C. Meanwhile, the parameters unique to specific models, such as specialized emission control data or advanced telemetry readings, are also standardized within specialized classes to maintain data integrity and relevance based on the generation of the at least one feature associated with the plurality of models 106A-C. A technical effect is that the at least one processor 104 enables to generate the at least one feature across the plurality of models 106A-C by deriving the at least one feature based on the universal set of parameters 110A-C, which facilitates consistent representation and comparison of data of the at least one asset type 102, regardless of vendor or model differences.
Furthermore, the at least one processor 104 is configured to categorize the universal set of parameters 110A-N into the one or more standardized classes 112A-N. In this regard, the one or more standardized classes 112A-N are generated based on standardization of the universal set of parameters 110A-N. Throughout the present disclosure, the term “standardized classes” 112A-N refers to organized groupings or categorization of the one or more parameters derived from the universal set of parameters 110A-N. The one or more standardized classes 112A-N may comprise an n number of standardized classes including the first standardized class 112A, the second standardized class 112B, the third standardized class 112D and the nth standardized class 112N, where n is any natural number. For example, for “n = 3”, the one or more standardized classes 112A-N may include three standardized classes: the first standardized class 112A, the second standardized class 112B, and the third standardized class 112C.
For example, in the case where the at least one asset type 102 is a car (vehicle), the one or more standardized classes 112A-N may include, but are not limited to, at least one of: a speed class comprising one or more parameters related to a speed of the vehicle. a global positioning system (GPS) class comprising one or more parameters associated with location tracking features of the vehicle, including parameters such as a GPS location and accelerometer data, an engine parameter class comprising one or more parameters related to engine performance of the vehicle, such as engine (Revolutions Per Minute) RPM, fuel efficiency, throttle position, fuel level, and engine load, and a diagnostic data class comprising one or more parameters related to critical diagnostic information of the vehicle, such as coolant temperature, engine oil pressure, transmission fluid temperature, misfire counts, and diagnostic trouble codes (DTCs) for identifying potential faults or issues within the operational systems of the vehicle. The classification of the one or more parameters of the universal set of parameters 110A-N into the one or more standardized classes 112A-N facilitates streamlined data management, enhances performance analysis across the plurality of models 106A-C, and supports efficient generation and operation of the universal digital twin 108 for the at least one asset type 102.
Furthermore, the at least one processor 104 is configured to prioritize transmission of the at least one critical parameter from amongst the universal set of parameters 110A-N. The at least one critical parameter is dynamically identified for immediate transmission based on the at least one prioritizing mechanism assigned to the one or more standardized classes 112A-N. The at least one prioritizing mechanism may include, but is not limited to, predefined thresholds, real-time data analysis, contextual relevance, or urgency of the one or more parameters based on operational conditions of the at least one asset type 102. For an example, in the case where the at least one asset type 102 is the car (vehicle), the at least one processor 104 may prioritize transmission of the at least one critical parameter such as engine oil pressure and/or coolant temperature, that are categorized under the diagnostic data class, when the at least one critical parameter exceed a critical threshold indicating a potential risk of engine failure. The critical threshold may be a preset value (that is determined by the system 100 or provided by a user). Notably, the dynamic identification of the at least one critical parameter facilitates the system 100 to adapt to changing operational environments by continuously evaluating the status of the universal set of parameters 110A-N within the universal digital twin 108. The prioritizing mechanism assigned to the one or more standardized classes 112A-N ensures that parameters critical to asset safety, performance, and operational efficiency are transmitted without delay, thereby enabling real-time monitoring, rapid response to critical events, and optimized data communication across the system 100.
Furthermore, the at least one processor 104 is configured to determine the mode of data exchange for the universal digital twin 108 of each asset type from amongst the at least one asset type 102 to exchange data with the at least one sensor 114 via the at least one gateway 116. Throughout the present disclosure, the term "mode of data exchange" refers to a particular configuration that is used by the universal digital twin 108 of the given asset type to exchange the data with the at least one sensor 114. The mode of data exchange may vary based on the number of gateways in the at least one gateway 116 utilized for data collection and the communication requirements between the universal digital twin 108 and the plurality of models 106A-C. For example, the system 100 may employ a single gateway configuration for aggregating data from multiple sensors associated with different models within the plurality of models 106A-C, which simplifies the data flow, reduces hardware complexity, and is suitable for scenarios where the data transmission load is moderate, and the communication range is centralized. In such cases, the universal digital twin 108 receives data from the single gateway (from amongst the at least one gateway 116), which acts as an intermediary between the sensors (from amongst the at least one sensor 114) and the universal digital twin 108, ensuring efficient data consolidation and streamlined processing. Alternatively, the system 100 may utilize more than one gateway (from amongst the at least one gateway 116) to enable parallel data collection and transmission from the plurality of models 106A-C, which is particularly beneficial in complex environments where different models are distributed across various locations or require independent data channels due to high data volume or specific latency requirements. The determination of the appropriate mode of data exchange is dynamically managed by the at least one processor 104 based on factors such as the number of sensors, data transmission frequency, network architecture, and the criticality of the data being monitored.
Optionally, the at least one processor 104 is configured to:
analyse the set of parameters associated with the plurality of models 106A-C of each asset type;
transmit the set of parameters associated with the plurality of models 106A-C of each asset type; and
perform at least one of: a cross-model comparison amongst the plurality of models 106A-C of each asset type, a cross-asset comparison amongst the at least one asset type 102, based on an evaluation of the set of parameters associated with the plurality of models 106A-C of each asset type.
In this regard, the analysis may involve processing real-time and historical data collected from the plurality of models 106A-C of the at least one asset type 102 to detect patterns, trends, and deviations that may indicate potential issues or opportunities for optimization. Furthermore, the at least one processor 104 is configured to transmit the set of parameters associated with the plurality of models 106A-C of each asset type, ensuring seamless data communication between the at least one sensor 114, the at least one gateway 116, and the universal digital twin 108. The transmission may include assigning unique identifiers to each data packet to maintain data integrity and facilitate accurate mapping of information to specific models of the at least one asset type 102. Additionally, the at least one processor 104 is configured to perform at least one of: the cross-model comparison amongst the plurality of models 106A-C of each asset type, the cross-asset comparison amongst the at least one asset type 102. The cross-model comparison enables the evaluation of performance metrics across different models within the same asset type, allowing for benchmarking, performance optimization, and identification of best-performing configurations. In contrast, the cross-asset comparison involves analysing data across different asset types to assess their relative efficiency, operational status, and overall performance, supporting data-driven decision-making to improve asset management strategies. A technical effect is that the at least one processor 104 enables comprehensive performance evaluation and asset management by analysing parameters from a plurality of models 106A-C of each asset type, which supports the identification of anomalies, detection of patterns, and derivation of insights related to asset health, efficiency, and reliability.
Optionally, the at least one processor 104 is further configured to facilitate at least one of: a benchmarking, an anomaly detection, an optimization for the at least one asset type based on the cross-model comparison performed. In this regard, the cross-model comparison involves analysing real-time as well as historical data collected from the plurality of models 106A-C of each asset type to detect patterns, trends, and deviations indicating potential issues or opportunities for performance improvement amongst the plurality of models 106A-C. Herein, through the benchmarking, the system 100 evaluates performance metrics across the plurality of models 106A-C within the same asset type, allowing for the identification of best-performing configurations and setting performance standards for the at least one asset type 102. Moreover, the anomaly detection leverages the comparative analysis to identify irregularities or deviations from expected operational behaviour of the plurality of models 106A-C, which may signal emerging faults or inefficiencies. Further, the optimization is achieved by using insights derived from data associated with the cross-model comparison to recommend adjustments in operational parameters, maintenance schedules and the likes, which supports data-driven decision-making, enabling organizations to improve asset management strategies, enhance operational efficiency, and reduce downtime across diverse assets and models. A technical effect is that the performance and reliability of the at least one asset type 102 is improved by enabling benchmarking, anomaly detection, and optimization through cross-model comparison, which supports early issue detection, identifies best-performing models of the plurality of models 106A-C, and drives data-driven optimizations, enhancing operational efficiency and informed decision-making across the at least one asset type 102.
Optionally, the at least one prioritizing mechanism comprises the evaluation of the set of parameters, and wherein the evaluation is performed utilizing at least one of: a default threshold, a user threshold, a bench-marking threshold. In this regard, the term "default threshold" refers to a pre-configured value that serves as a baseline for evaluating the set of parameters, helping to identify critical data that falls outside normal operational ranges and requires immediate attention. Throughout the present disclosure, the term "user threshold" refers to a threshold value that allows for customization, enabling the system 100 to set specific criteria based on a unique operational need or performance goals of the plurality of models 106A-C, ensuring that the prioritization mechanism aligns with the system 100 expectations. Throughout the present disclosure, the term "benchmarking threshold" refers to a threshold value that is derived from performance data based on the cross-model comparisons, setting performance standards that reflect optimal operational efficiency. The parameters from amongst the set of parameters that deviate from the benchmarking threshold may be prioritized for further action or transmission, as they may indicate underlying issues or areas for optimization. A technical effect is that the at least one prioritizing mechanism improves the accuracy and efficiency of the at least one asset type 102 by evaluating the set of parameters using at least one of: the default threshold, the user threshold, the benchmarking threshold.
Optionally, the at least one processor 104 is further configured to:
generate an alert message for a given asset type when the asset status update of the given asset type is indicative of an error in the given asset type; and
send the alert message to a user associated with the given asset type.
In this regard, the error may be identified based on the evaluation of a predefined attributes associated with the operational status, performance metrics, or diagnostic indicators of the given asset type. Throughout the present disclosure, the term "alert message" refers to a message that is used to warn the user regarding the presence of the error in the given asset type. Furthermore, the at least one processor 104 may be configured to send the alert message to the user associated with the given asset type. based on the evaluation of the set of parameters. A transmission for the alert message may be executed through one or more communication channels, such as email, SMS, push notifications, or integrated system dashboards, based on predefined user preferences or criticality thresholds determined from the evaluation of the set of parameters. A technical effect is to enable proactive monitoring and real-time error notification for diverse asset types within the system 100, to facilitates improved decision-making for users, enabling swift corrective actions to maintain optimal asset performance across different vendors and models.
Referring to FIG. 2, illustrated is a block diagram 200 of an exemplary hierarchical one or more standardized classes 112A-N of the universal set of parameters 110A-N, in accordance with the embodiment of the present disclosure. The hierarchical structure allows for comprehensive tracking and management of the data of the at least one asset type 102, with a clear organization of various aspects of asset health, performance, and status. The use of the one or more standardized classes 112A-N for the parameters enables to monitor multiple asset types efficiently, regardless of the specific asset type, by ensuring that each asset type's data is consistently categorized and easily accessible. As depicted, the one or more standardized classes 112A-N include a first set of headers 202-208, a second set of headers 210-216N, a third set of headers 218-224, and a fourth set of headers 222A-222G.
The first set of headers 202-208 may include (not limited to) a fixed header 202 that comprise static or unchanging information relevant to the at least one asset type 102. The fixed header 202 serves as a foundational reference point for the system 100. Moreover, the first set of headers 202-208 include a variable header 204 adapted based on dynamic system conditions. The variable header 204 is further subdivided into one or more components including an asset data header 206 and a device health header 208. The asset data header 206 stores information pertaining to the at least one asset type 102, including data that is critical for managing at least one asset type 102, while the device health header 208 encapsulates the health status of the at least one asset type 102 in the system 100.
Moreover, the second set of headers 210-216N provides additional information associated with the at least one asset type 102. The second set of headers 210-216N may be associated with the asset data header 206. The second set of headers 210-216N includes a location parameter header 210, which stores location-related information about the asset, and an asset count header 212, detailing number of models of the at least one asset type 102. The asset count header 212 is flexible and capable of representing "N" assets, where "N" is a natural number reflecting the total number of assets under consideration. Additionally, individual asset headers such as the asset-1 header 214, asset-2 header 216, and up to the Nth asset header 216N, are included, which store data specific to each individual asset type, and the number of asset headers corresponds to the quantity of asset types being tracked.
Further, the third set of headers 218-224 comprise details about each asset type. For example, the asset-1 header 214 is broken down into several sub-headers, including a timestamp header 218, which logs the time at which the data was recorded; an asset identification (ID) header 220, which uniquely identifies the asset type; an asset data header 222, which houses the primary operational data for the asset type; and an asset diagnostic header 224, which contains diagnostic information regarding the asset’s performance or health. Notably, the asset data header 222 is subdivided into specific parameter categories, as seen in the fourth set of headers 222A-222G. The subdivision includes asset operational status 222A, ambient conditions 222B, asset utility parameters 222C, asset performance parameters 222D, asset health parameters 222E, asset maintenance parameters 222F, and asset fault parameters 222G, which are categorized into standardized classes 112A-N, ensuring that the data is consistently organized for ease of analysis, comparison, and decision-making.
Referring to FIG. 3A, illustrated is a schematic illustration of an implementation scenario of the system 100 implemented utilizing a single gateway 302 for data transmission for the at least one asset type 102, in accordance with the embodiment of the present disclosure. As depicted, the system 100 includes a flow meter asset 304A, a valve asset 304B, and a motor asset 304C, communicably coupled to a flow meter 306, a valve 308, and a motor 310, via the single gateway 308. Herein, the system 100 provides a configuration of multi-system, multi-asset data transmission through the single gateway 308, effectively reducing a number of data packets to be transmitted while maximizing a size of the data packets. The configuration optimizes network efficiency and minimizing data transmission overhead.
Optionally, the at least one processor 104 is further configured to assign a unique asset identification (asset ID) and a timestamp to at least one data packet transmitted from each asset type. In this regard, the term "at least one data packet" refers to a unit of data transmission that contains information associated with the at least one asset type 102. The at least one data packet includes the unique asset identification and the timestamp, along with other data parameters associated with the at least one asset type 102. Throughout the present disclosure, the term "unique asset identification (asset ID)" refers to a distinct identifier assigned to each asset type from amongst the at least one asset type 102. The unique asset identification ensures that each asset type can be uniquely recognized within the system 100, enabling precise association of data with the corresponding asset type. Throughout the present disclosure, the term "timestamp" refers to a temporal marker assigned to the at least one data packet transmitted from each asset type. The timestamp records the exact time at which the at least one data packet is generated or transmitted, providing a chronological context for the data. A technical effect is that the data management and transmission efficiency is enhanced within the system 100.
Optionally, the at least one processor 104 is further configured to aggregate one or more data packets from amongst the at least one data packet into a single transmission packet. In this regard, the term "single transmission packet" refers to a consolidated data packet that is generated by aggregating the one or more data packets from amongst the at least one data packet. The single transmission packet serves as a unified structure for transmitting data associated with multiple data packets, thereby reducing the number of individual transmissions required. Notably, aggregating the one or more data packets involve collecting the data packets generated by the at least one asset type 102 and organizing them into a unified format for transmission. A technical effect is that the data transmission efficiency is enhanced within the system 100, by reducing the number of individual transmissions required
Referring to FIG. 3B, illustrated is a schematic illustration depicting a drilling compressor vehicle 312 and a plurality of models 314A-C of the drilling compressor vehicle 312, in accordance with an embodiment of the present disclosure. The drilling compressor vehicle 312 may include a drilling compressor 314A, a fuel tank 314B and a vehicle engine 314C (combinedly referred as, plurality of integrated models 314A-C). Herein, the drilling compressor 314A, the fuel tank 314B and a vehicle engine 314C are the plurality of models 314A-C of the drilling compressor vehicle 312. In this regard, the set of parameters associated with the drilling vehicle compressor 312 are monitored based on the received parameter from the plurality of models 314A-C. For example, the set of parameters associated with the drilling vehicle compressor 312 comprises a discharge air pressure and an inlet temperature, fuel readings or the like. The set of parameters associated with the drilling vehicle compressor 312 are monitored utilising the one or more sensors in the plurality of models 314A-C. For example, the vehicle engine 314C may capture engine parameters, emission data, GPS (global positioning system) parameters, while the fuel sensor associated with the fuel tank 314B measures fuel level in the fuel tank 314B. Each model is connected via dedicated gateway devices, enabling seamless data transmission to the drilling compressor vehicle digital twin 316. The drilling compressor vehicle digital twin 316 consolidates data from the compressor, engine 314A, the fuel tank 314B and the vehicle engine 314C, providing a comprehensive virtual representation of the drilling compressor vehicle 312. Thus, the system may be implemented for the plurality of integrated models coexisting within a single asset type (for example, the drilling compressor vehicle 312, herein), with each model contributing unique data that collectively defines asset’s operational status.
Referring to FIG. 4, illustrated is a block diagram depicting different modes of data exchange between one or more sensors and the at least one asset 102 through one or more gateways, in accordance with an embodiment of the present disclosure. As shown, in an embodiment, the mode of data exchange is a one-sensor one-gateway one-asset configuration 400A. The one-sensor one-gateway one-asset configuration 400A comprises a first sensor 402A and a first gateway 404A to transmit data to a first asset type 406A. In another embodiment, the mode of data exchange is a multi-sensors one-gateway one-asset configuration 400B. The multi-sensors one-gateway one-asset configuration 400B comprises the first sensor 402A and a second sensor 402B connected to the first gateway 404A, which aggregates data before transmission to the first asset type 406A. In yet another embodiment, the mode of data exchange is a multi-sensors multi-gateways one-asset configuration 400C. The multi-sensors multi-gateway one-asset configuration 400C comprises the first sensor 402A, the second sensor 402B, and a third sensor 402C connected to the first gateway 404A and a second gateway 404B, which aggregates data before transmission to the first asset type 406A. In still another embodiment, the mode of data exchange is a multi-sensors multi-gateways multi-asset configuration 400D. The multi-sensors multi-gateway multi-asset configuration 400D comprises the first sensor 402A, the second sensor 402B and the third sensor 402C connected to the first gateway 404A and the second gateway 404B, which aggregates data before transmission to the first asset type 406A and a second asset type 406B.
Referring to FIG. 5 illustrated is a flowchart depicting steps of a method for managing at least one asset type, in accordance with an embodiment of the present disclosure. At step 502, a set of parameters associated with a plurality of models of each asset type from amongst the at least one asset type is received. At step 504, a universal digital twin is generated for each asset type from amongst the at least one asset type, wherein the universal digital twin comprises a universal set of parameters for each asset type, based on the received set of parameters. At step 506, the universal set of parameters is categorized into one or more standardized classes, wherein the one or more standardized classes are generated based on standardization of the universal set of parameters. At step 508, transmission of at least one critical parameter from amongst the universal set of parameters is prioritized, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes. At step 510, a mode of data exchange for the universal digital twin of each asset type from amongst the at least one asset type is determined to exchange data with at least one sensor via at least one gateway. At step 512, a standardized configuration protocol is generated for at least one asset type. At step 514, an asset status update from each asset type from amongst the at least one asset type 102 is received.
, Claims:CLAIMS:
I/We claim:
1. A system (100) for managing at least one asset type (102), the system comprising:
at least one processor (104) configured to:
receive a set of parameters associated with a plurality of models (106A-C, 314A-C) of each asset type from amongst the at least one asset type;
generate a universal digital twin (108) for each asset type from amongst the at least one asset type, wherein the universal digital twin comprises a universal set of parameters (110A-N) for each asset type, based on the received set of parameters;
categorize the universal set of parameters into one or more standardized classes (112A-N), wherein the one or more standardized classes are generated based on standardization of the universal set of parameters;
prioritize transmission of at least one critical parameter from amongst the universal set of parameters, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes;
determine a mode of data exchange for the universal digital twin of each asset type from amongst the at least one asset type to exchange data with at least one sensor (114) via at least one gateway (116);
generate a standardized configuration protocol for the at least one asset type; and
receive an asset status update from the each asset type from amongst the at least one asset type.
2. The system (100) of claim 1, wherein the at least one processor (104) is further configured to:
analyse the set of parameters associated with the plurality of models (106A-C, 314A-C) of each asset type;
transmit the set of parameters associated with the plurality of models of each asset type; and
perform at least one of: a cross-model comparison amongst the plurality of models of each asset type, a cross-asset comparison amongst the at least one asset type (102), based on an evaluation of the set of parameters associated with the plurality of models of each asset type.
3. The system (100) of claim 2, wherein the at least one processor (104) is further configured to facilitate at least one of: a benchmarking, an anomaly detection, an optimization for the at least one asset type (102) based on the cross-model comparison performed.
4. The system (100) of claim 1, wherein the at least one prioritizing mechanism comprises the evaluation of the set of parameters, and wherein the evaluation is performed utilizing at least one of: a default threshold, a user threshold, a bench-marking threshold.
5. The system (100) of claim 1, wherein the set of parameters includes at least one of: data relating to health, performance, status, features, error associated with the plurality of models (106A-C, 314A-C) of the each asset type.
6. The system (100) of claim 1, wherein the at least one processor (104) is further configured to assign a unique asset identification (asset ID) and a timestamp to at least one data packet transmitted from each asset type.
7. The system (100) of claim 1, wherein the at least one processor (104) is further configured to aggregate one or more data packets from amongst the at least one data packet into a single transmission packet.
8. The system (102) of claim 1, wherein the at least one processor (104) is further configured to generate at least one feature associated with the plurality of models (106A-C, 314A-C) based on the universal set of parameters (110A-N).
9. The system (100) of claim 1, wherein the at least one processor (104) is further configured to:
generate an alert message for a given asset type when the asset status update of the given asset type is indicative of an error in the given asset type; and
send the alert message to a user associated with the given asset type.
10. A method for managing at least one asset type (102), the method comprising:
receiving a set of parameters associated with a plurality of models (106A-C, 314A-C) of each asset type from amongst the at least one asset type;
generating a universal digital twin (108) for each asset type from amongst the at least one asset type, wherein the universal digital twin comprises a universal set of parameters (110A-N) for each asset type, based on the received set of parameters;
categorizing the universal set of parameters into one or more standardized classes (112A-N), wherein the one or more standardized classes are generated based on standardization of the universal set of parameters;
prioritizing transmission of at least one critical parameter from amongst the universal set of parameters, wherein the at least one critical parameter is dynamically identified for immediate transmission based on at least one prioritizing mechanism assigned to the one or more standardized classes;
determining a mode of data exchange for the universal digital twin of each asset type from amongst the at least one asset type to exchange data with at least one sensor (114) via at least one gateway (116);
generating a standardized configuration protocol for the at least one asset type; and
receiving an asset status update from the each asset type from amongst the at least one asset type.