Patent Description:
Usually, any technical installations, such as a manufacturing plants or other automation facilities have a wealth of asset data represented as files, databases and real time automation data. However, such asset data from the manufacturing plants and other automation facilities use different data structures, communication protocols, languages and platforms which has led to great complexity in information technology infrastructure of a typical business enterprise. Different business processes within the typical business enterprise may use completely different computer applications, each computer application being developed and optimized for the particular business process, rather than for the enterprise as a whole. For example, a business enterprise may have a particular computer application for designing the technical installation and another computer application for carrying out engineering on the technical installation. A number of companies have recognized and addressed the need for sharing of asset data across these different computer applications in the business enterprise. Thus, enterprise application integration, has emerged as a strategy for addressing asset data integration from disparate data sources.

In current systems, knowledge graphs have been widely used in order to efficiently integrate such asset data from different computer applications, asset data from the manufacturing plants or asset data from the other automation facilities. Knowledge graphs are used to process planning, task scheduling, diagnostics, product design, capability analysis, resource allocation, analyzing production scenarios, and so forth associated with the technical installation. Knowledge graphs are increasingly becoming the industry choice to aggregate data from different sources in a way that facilitates more complex queries and retrieval of facts over typical data lakes and warehouses where asset data is scattered, siloed, and having heterogeneous schemas. Knowledge graphs permit integrating such asset data into a shared joint asset data space.

However, such asset data being input to the knowledge graphs permit any third-party users to access the asset data and modify the asset data. This asset data modification by a third-party user may tamper the asset data used by the knowledge graph and cause false, unverified information to be generated by such knowledge graphs. In order to ensure that the asset data used by the knowledge graphs are tamper proof and authentic, right access control rules and transparency of operations performed are essential. Industrial tools such as Siemens PLM Software store asset data in a graphical form. For example, a bill of material with linked documents is represented as a tree consisting of equipment data along with link to additional documents. It is of utmost interest that this asset data is consistent, and that released versions of designs by such tool are not changed in any way, example by modifying linked additional documents. Conventionally, any operations performed on the asset data are assigned and verified manually, rather than with inbuilt system verification.

Document <CIT> describes a method for managing a digital representation of a physical asset. This method comprises writing data of respective electronic files associated with a digital representation of a physical asset as entries to a blockchain ledger accessible to a network of two or more blockchain participants; monitoring written entries of the blockchain ledger to detect satisfaction of one or more conditions defined in a smart contract associated with the digital representation of the physical asset; and performing an action on the digital representation based on detecting that the one or more conditions defined in the smart contract are satisfied.

Document <CIT> describes a system for providing data security and protection using distributed ledgers to store validated data in a global knowledge graph for fraud detection is disclosed. The system may comprise a data access interface, a processor, and an output interface. The data access interface may receive data associated with an individual from a data source. The processor may convert the data into knowledge graph data by: extracting entities from the data; extracting relations from the data; and translating the data into knowledge graph triples to generate the knowledge graph data. The processor may validate the knowledge graph data using a cryptographic validation, such as blockchain or distributed ledgers, on the knowledge graph data to provide secured contents to update a global knowledge graph. The processor may then determine a fraudulent activity level associated with the individual based on the updated global knowledge graph. The output interface may transmit to a report associated with the fraudulent activity level to a report requestor at a computing device.

Document <CIT> describes systems and methods for managing a contextual digital twin. In one example, the method may include storing a digital twin template as a graph model in a database, the digital twin template configured to instantiate a virtual representation of an asset, receiving a request to execute a behavior in association with an instance of a digital twin corresponding to the digital twin template, determining a position within the graph model of the digital twin template at which the behavior is bound to the digital twin template, and executing the behavior based on the position within the graph model at which the behavior is bound to perform an action with respect to the instance of the digital twin. The context can provide information about operations of the asset as well as insight into the operations of the asset and other related assets.

In light of above, there is a need for a method and system for securing asset data in a computing environment which efficiently handles the access control on the asset data and provides tamper proof, reliable asset data to computing systems.

Therefore, it is an object of the present invention to provide a method and system for securing asset data in a cloud computing environment.

The object of the present invention is achieved by a method for securing asset data in a computing environment. The method comprises receiving a request for modifying asset data. The request comprises one or more parameters associated with the one or more assets deployed in a technical installation and one or more parameters associated with a requestor profile. The asset data comprises asset design and maintenance information, asset configuration information, asset physical block information, test data set, asset alarms and the like. In an embodiment, the content of the asset data comprises, among others, engine serial numbers, module serial numbers, material numbers, and document identifiers.

In an embodiment, the asset comprises servers, robots, switches, automation devices, electrical devices, power devices, gas turbines, programmable logic controllers (PLC)s, human machine interfaces (HMIs), input output modules, motors, valves, pumps, actuators, sensors and other industrial equipment(s). The requestor profile is associated with a reputation score indicating one or more privileges associated with the requestor. In an embodiment, a requestor may be a user on a user device triggering the request. The one or more parameters associated with the one or more assets deployed in the technical installation comprises asset identifier, asset part identifier, modification type identifier, a responder identifier, timestamp information and digital endorsement of the one or more approvers. The one or more parameters associated with requestor profile comprises requestor identifier, transaction identifier, requestor privileges, a reputation score, requestor role, and an encryption key.

The method comprises validating the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets deployed in the technical installation and the pre-stored one or more parameters associated with the requestor profile using blockchain validation method.

The method comprises modifying the pre stored asset data to generate a modified asset data based on the validated request. The modified asset data comprises modified one or more parameters associated with the asset and modified one or more parameters associated with the requestor profile. The one or more modifications comprises any change in the asset data. For example, addition of any information, deletion of any information, update or change to any parameter of the asset.

The method further comprises generating a digital representation model of the modified asset data using a knowledge graph. The digital representation model of the modified asset data comprises dynamic linking between the one or more parameters associated with the one or more assets deployed in the technical installation and the one or more parameters associated with the requestor profile. In an embodiment, the digital representation model of the modified asset data may be a digital twin of the one or more assets. Specifically, the digital representation model of the modified asset data may be a digital twin knowledge graph. In an exemplary embodiment, the digital representation models are generated using RDF triples that represent this graph. The source for the information is manifold, e.g. existing database systems, documents, or the like. The process of creating these RDF triples is realized using ETL (extract-transform-load) tooling, and potentially (for some data) virtual data integration (also called ontology-based data access). These triples are either added to the graph database, such as database <NUM>, triple by triple, or is stored into e.g. a file (one typical file name suffix would be. TTL), and then loaded into the graph database in a batch operation. Any update to the initial knowledge graph would then be conducted by means of SPARQL queries (typically of types CREATE GRAPH, INSERT, DELETE). SPARQL as a pure query language does not modify data - it can therefore "only" be used to retrieve data from the existing knowledge graph (the original one, or a modified one).

The method further comprises outputting the generated digital representation model of the modified asset data on a user interface.

In a preferred embodiment, in validating the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets deployed in the technical installation and the pre-stored one or more parameters associated with the requestor profile using the blockchain validation, the method comprises executing one or more data semantic based rules on the one or more parameters associated with the one or more assets deployed in the technical installation. The data semantic rules comprises both generic (e.g. (<NUM>) expressing that a bill of material must always be tree-shaped, i.e. each part may have at most one parent part, or (<NUM>) each person must have exactly one age value of datatype integer), or use-case specific (e.g. a regular expression defining a pattern for valid serial numbers). In a preferred embodiment, these rules is expressed using SPARQL queries (e.g. ASK queries looking for (sub-)graphs violating the constraints), or SHACL/SHEx constraints (that define how valid (sub-)graphs must be structured. Further, the method comprises determining the one or more parameters associated with the requestor profile upon executing the one or more data semantic based rules. The one or more parameters associated with the requestor profile is determined by parsing the request. Further, the method comprises determining one or more pre-defined transaction management conditions applicable to the one or more parameters associated with the requestor profile. The one or more predefined transaction management conditions comprises privileges associated with the participants of a transaction, transaction identifier, role of participants, asset values and parameters, required endorsements for the transaction, gamification, reputation score associated with the participants and the like.

Further, the method comprises verifying whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions. Further, the method comprises outputting results of verification of the one or more parameters associated with the requestor profile. The results of verification indicate whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions or not. The verification results comprise a success or failure state. A success state indicates that the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions. A failure state indicates that the one or more parameters associated with the requestor profile does not satisfy with the one or more pre-defined transaction management conditions. In case if the verification results indicate failure state, then a notification/alert message is displayed on the user interface of the user devices indicating the failure state.

In an aspect of the preferred embodiment, in verifying whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions, the method comprises rejecting the request for modifying the asset data if the verification of the one or more parameters associated with the requestor profile fails to satisfy the one or more predefined transaction management conditions.

In another preferred embodiment, in modifying the pre stored asset data to generate a modified asset data based on the validated request, the method comprises determining whether the request is successfully validated based on the results of verification of the one or more parameters associated with the requestor profile. Further, the method comprises identifying part of the pre-stored asset data requested to be modified based on the one or more parameters associated with the one or more assets. In an embodiment, part of the pre-stored asset data may comprise for example, configuration parameters associated with the asset, for which the requestor is allowed to modify. Further, the method comprises determining type of modification to be performed on the identified part of the pre-stored asset data based on pre-stored data table. The type of modification comprises classical CRUD operations on data such as creation of a new attribute value, update of an existing value, and deletion of an existing value. The method further comprises modifying the part of the pre-stored asset data based on the determined type of modification to generate the modified asset data.

In another preferred embodiment, the method comprises obtaining confirmation message associated with modification performed on the pre-stored asset data upon modifying the pre-stored asset data. In an embodiment, the confirmation message is received from a responder to whom the request to modify the asset data was sent by the requestor. Upon modifying the asset data, the confirmation message is obtained by the requestor from the responder. The confirmation message comprises additional parameters associated with the modification performed on the pre-stored asset data. The additional parameters associated with the modification comprises responder identifier, transaction identifier, list of parts associated with the asset which are modified, time stamp information, a digital signature of the responder, and optionally additional evidence. Further, the method comprises validating the confirmation message comprising the additional parameters associated with the modification performed on the pre-stored asset data based on pre-defined conditions. The pre-defined conditions comprise valid transaction identifier, valid responder identifier, modification request identifier, asset identifier, asset part identifier, acceptable evidences, type of medication and the like.

In yet another aspect of the embodiment, in generating the digital representation model of the modified asset data using the knowledge graph, the method comprises generating the digital representation model of the modified asset data using the knowledge graph based on the validation of the confirmation message associated with the modification performed on the pre-stored asset data.

In still another preferred embodiment, in generating the digital representation model of the modified asset data using the knowledge graph, the method comprises determining one or more dynamic linkings between the one or more parameters associated with the modified asset data based on the generated modified asset data. The dynamic linking indicates the relationship between the one or more parameters associated with the modified asset data in the form of one or more nodes linked in a tree form. In an embodiment, the dynamic linking is determined based on standard knowledge graph methods. Further, the method comprises validating the one or more dynamic linking between the one or more parameters associated with the modified asset data based on the pre-stored data table. In an embodiment, the pre-stored data table may be a look up table comprising the detailed structure of one or more parameters associated with the modified asset data with corresponding dynamic links with which those one or more parameters could be linked. Furthermore, the method comprises generating the digital representation model of the modified asset data using the knowledge graph.

In still another embodiment, in outputting the generated digital representation model of the modified asset data on the user interface, the method comprises displaying the generated digital representation model of the modified asset data on the user interface. The generated digital representation model is a knowledge graph.

In still another embodiment, the method comprises storing the generated digital representation model in a database.

The object of the present invention is also be achieved by a computing system for securing asset data in a computing environment. The computing system may comprise one or more processors and a memory coupled to the one or more processors. The memory comprises an asset data management module stored in the form of machine-readable instructions and executable by the one or more processors. The asset data management module is configured for performing the method described above.

The object of the present invention is also achieved by a computing environment.

The computing environment comprising a computing system, a technical installation comprising one or more assets capable of communicating asset data associated with the one or more assets to the computing system. The computing environment comprises at least one user device communicatively coupled to the computing system and the technical installation via a network.

The object of the present invention is also achieved by a computer-program product having machine-readable instructions stored therein, that when executed by one or more processor(s), cause the one or more processor(s) to perform method steps as described above.

The above-mentioned and other features of the invention will now be addressed with reference to the accompanying drawings of the present invention. The embodiments are intended to illustrate the invention.

Various embodiments are described with reference to the drawings, wherein like reference numerals are used to refer the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide thorough understanding of one or more embodiments.

<FIG> is a schematic representation of a computing environment <NUM> capable of securing asset data, according to an embodiment of the present invention. Particularly, <FIG> depicts a computing system <NUM> which is capable of delivering remotely hosted applications (for example. , cloud applications) for managing a technical installation <NUM> comprising one or more asset(s) 108A-N. As used herein, "computing environment" refers to a processing environment comprising configurable computing physical and logical resources, for example, networks, servers, storage, applications, services, etc., and data distributed over a platform (such as a cloud platform). The computing environment <NUM> provides on-demand network access to a shared pool of the configurable computing physical and logical resources. In an embodiment, the computing environment <NUM> may be a cloud computing environment, and the computing system <NUM> may be a cloud computing system.

The computing system <NUM> is connected to one or more asset(s) 108A-N in the technical installation <NUM> via a network <NUM> (e.g., Internet). The one or more asset(s) 108A-N may include servers, robots, switches, automation devices, programmable logic controllers (PLC)s, turbines, human machine interfaces (HMIs), input output modules, motors, valves, pumps, actuators, sensors, gas turbines, and other industrial equipment(s). In a preferred embodiment, the computing system <NUM> is a cloud computing system. The computing system <NUM> may be a public cloud, a private cloud, and/or a hybrid cloud configured to provide dedicated cloud services to its users. Although, <FIG> illustrates the computing system <NUM> connected to one technical installation <NUM> via the network <NUM>, one skilled in the art can envision that the computing system <NUM> can be connected to several technical installations <NUM> located at different locations via the network <NUM>.

Further, the computing system <NUM> is also connected to user devices 122A-N via the network <NUM>. The user devices 122A-N can access the computing system <NUM> for securing asset data associated with the asset 108A-N deployed in the technical installation <NUM>. In an embodiment, the user devices 122A-N comprises an engineering system capable of running an industrial automation application. The user devices 122A-N can be a laptop computer, desktop computer, tablet computer, smartphone and the like. The user devices 122A-N can access remote applications (such as enabling authorized users to access the asset data based on requirement) via a web browser.

The computing system <NUM> comprises a platform <NUM>, an asset data management module <NUM>, a server <NUM> including hardware resources and an operating system (OS), a network interface <NUM>, a database <NUM> and an application program interfaces (APIs) <NUM>. The network interface <NUM> enables communication between the computing system <NUM>, the technical installation <NUM>, and the user device(s) 122A-N. The communication interface (not shown in <FIG>) may allow the engineers at the one or more user device(s) 122A-N to access asset data stored at the computing system <NUM> and perform one or more actions on the asset data as same instance. The server <NUM> may include one or more servers on which the OS is installed. The servers <NUM> may comprise one or more processors, one or more storage devices, such as, memory units, for storing data and machine-readable instructions for example, applications and application programming interfaces (APIs) <NUM>, and other peripherals required for providing cloud computing functionality. The remote platform <NUM> is a platform which enables functionalities such as data reception, data processing, data rendering, data communication, etc., using the hardware resources and the OS of the servers <NUM> and delivers the aforementioned remote services using the application programming interfaces <NUM> deployed therein. The remote platform <NUM> may comprise a combination of dedicated hardware and software built on top of the hardware and the OS.

The database <NUM> is configured for storing information associated with the one or more assets 108A-N in one or more data format. The database <NUM> is, for example, a graph database such as Amazon Neptune, Ontotext GraphDB, CSI AnzoGraph, or any other database capable of storing and representing knowledge graphs. The database <NUM> is configured as remote database implemented in the computing environment <NUM>, where computing resources are delivered as a service over the remote platform <NUM>. The database <NUM>, according to another embodiment of the present invention, is a location on a file system directly accessible by the asset data management system <NUM>. In another embodiment, the database <NUM> may be external data sources each having different schema and different file formats. The database <NUM> is configured to store asset data, one or more parameters associated with the asset 108A-N, one or more parameters associated with the requestor profile, semantic rule checks, pre-stored data table, pre-stored transaction management conditions, digital representation models, validation results, user privileges, access control rules, and the like. The database <NUM> also maintains versions of the digital representation models.

<FIG> is a block diagram of a computing system <NUM>, such as those shown in <FIG>, in which an embodiment of the present invention can be implemented. In <FIG>, the computing system <NUM> includes a processor(s) <NUM>, an accessible memory <NUM>, a storage unit <NUM>, a communication interface <NUM>, an input/output unit <NUM>, and a bus <NUM>.

The processor(s) <NUM>, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor unit, microcontroller, complex instruction set computing microprocessor unit, reduced instruction set computing microprocessor unit, very long instruction word microprocessor unit, explicitly parallel instruction computing microprocessor unit, graphics processing unit, digital signal processing unit, or any other type of processing circuit. The processor(s) <NUM> may also include embedded controllers, such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, and the like.

The memory <NUM> may be non-transitory volatile memory and non-volatile memory. The memory <NUM> may be coupled for communication with the processor(s) <NUM>, such as being a computer-readable storage medium. The processor(s) <NUM> may execute machine-readable instructions and/or source code stored in the memory <NUM>. A variety of machine-readable instructions may be stored in and accessed from the memory <NUM>. The memory <NUM> may include any suitable elements for storing data and machine-readable instructions, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read only memory, a hard drive, a removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like. In the present embodiment, the memory <NUM> includes an asset data management module <NUM> stored in the form of machine-readable instructions on any of the above-mentioned storage media and may be in communication with and executed by the processor(s) <NUM>.

When executed by the processor(s) <NUM>, the asset data management module <NUM> causes the processor(s) <NUM> to secure asset data in a computing environment <NUM>. In an embodiment, the asset data management module <NUM> causes the processor(s) <NUM> to receive a request for modifying asset data. The request comprises one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM>. and one or more parameters associated with a requestor profile. The asset data comprises asset design and maintenance information, asset configuration information, asset physical block information, test data set, asset alarms and the like. In an embodiment, the content of the asset data comprises, among others, engine serial numbers, module serial numbers, material numbers, and document identifiers.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to validate the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the pre-stored one or more parameters associated with the requestor profile using blockchain validation method.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to modify the pre stored asset data to generate a modified asset data based on the validated request. The modified asset data comprises modified one or more parameters associated with the asset 108A-N and modified one or more parameters associated with the requestor profile. The one or more modifications comprises any change in the asset data. For example, addition of any information, deletion of any information, update or change to any parameter of the asset 108A-N. In an exemplary embodiment, modifications are performed within the digital representation as part of the SPARUL queries.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to generate a digital representation model of the modified asset data using a knowledge graph. The digital representation model of the modified asset data comprises dynamic linking between the one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the one or more parameters associated with the requestor profile. In an embodiment, the digital representation model of the modified asset data may be a digital twin of the one or more assets 108A-N. Specifically, the digital representation model of the modified asset data may be a digital twin knowledge graph. In an exemplary embodiment, the digital representation models are generated using the SPARUL data query.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to output the generated digital representation model of the modified asset data on a user interface.

In validating the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the pre-stored one or more parameters associated with the requestor profile using the blockchain validation, the asset data management module <NUM> causes the processor(s) <NUM> to execute one or more data semantic based rules on the one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM>. The data semantic rules comprises both generic (e.g. (<NUM>) expressing that a bill of material must always be tree-shaped, i.e. each part may have at most one parent part, or (<NUM>) each person must have exactly one age value of datatype integer), or use-case specific (e.g. a regular expression defining a pattern for valid serial numbers). In a preferred embodiment, these rules are expressed using SPARQL queries (e.g. ASK queries looking for (sub-)graphs violating the constraints), or SHACL/SHEx constraints (that define how valid (sub-)graphs must be structured. Further, the asset data management module <NUM> causes the processor(s) <NUM> to determine the one or more parameters associated with the requestor profile upon executing the one or more data semantic based rules. The one or more parameters associated with the requestor profile is determined by parsing the request. Further, the method comprises determining one or more pre-defined transaction management conditions applicable to the one or more parameters associated with the requestor profile. The one or more predefined transaction management conditions comprises privileges associated with the participants of a transaction, transaction identifier, role of participants, asset values and parameters, required endorsements for the transaction, gamification, reputation score associated with the participants and the like.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to verify whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions. Further, the asset data management module <NUM> causes the processor(s) <NUM> to output results of verification of the one or more parameters associated with the requestor profile. The results of verification indicate whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions or not. The verification results comprise a success or failure state. A success state indicates that the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions. A failure state indicates that the one or more parameters associated with the requestor profile does not satisfy with the one or more pre-defined transaction management conditions. In case if the verification results indicate failure state, then a notification/alert message is displayed on the user interface of the user devices 122A-N indicating the failure state.

In verifying whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions, the asset data management module <NUM> causes the processor(s) <NUM> to reject the request for modifying the asset data if the verification of the one or more parameters associated with the requestor profile fails to satisfy the one or more predefined transaction management conditions.

In modifying the pre stored asset data to generate a modified asset data based on the validated request, the asset data management module <NUM> causes the processor(s) <NUM> to determine whether the request is successfully validated based on the results of verification of the one or more parameters associated with the requestor profile. Further, the asset data management module <NUM> causes the processor(s) <NUM> to identify part of the pre-stored asset data requested to be modified based on the one or more parameters associated with the one or more assets 108A-N. In an embodiment, part of the pre-stored asset data may comprise for example, configuration parameters associated with the asset 108A-N, for which the requestor is allowed to modify. Further, the asset data management module <NUM> causes the processor(s) <NUM> to determine type of modification to be performed on the identified part of the pre-stored asset data based on pre-stored data table. The type of modification comprises classical CRUD operations on data such as creation of a new attribute value, update of an existing value, and deletion of an existing value. The asset data management module <NUM> causes the processor(s) <NUM> to modify the part of the pre-stored asset data based on the determined type of modification to generate the modified asset data. The pre-stored data table is specific to type of asset stored and the corresponding asset data available.

Further, the asset data management module <NUM> causes the processor(s) <NUM> to obtain confirmation message associated with modification performed on the pre-stored asset data upon modifying the pre-stored asset data. The confirmation message is received from a responder to whom the request to modify the asset data was sent by the requestor. Upon modifying the asset data, the confirmation message is obtained by the requestor from the responder. The confirmation message comprises additional parameters associated with the modification performed on the pre-stored asset data. The additional parameters associated with the modification comprises responder identifier, transaction identifier, list of parts associated with the asset which are modified, time stamp information, a digital signature of the responder, and optionally additional evidence. Further, the asset data management module <NUM> causes the processor(s) <NUM> to validate the confirmation message comprising the additional parameters associated with the modification performed on the pre-stored asset data based on pre-defined conditions. The pre-defined conditions comprises valid transaction identifier, valid responder identifier, modification request identifier, asset identifier, asset part identifier, acceptable evidences, type of medication and the like.

In generating the digital representation model of the modified asset data using the knowledge graph, the asset data management module <NUM> causes the processor(s) <NUM> to generate the digital representation model of the modified asset data using the knowledge graph based on the validation of the confirmation message associated with the modification performed on the pre-stored asset data.

In generating the digital representation model of the modified asset data using the knowledge graph, the asset data management module <NUM> causes the processor(s) <NUM> to determine one or more dynamic linking between the one or more parameters associated with the modified asset data based on the generated modified asset data. The dynamic linking indicates the relationship between the one or more parameters associated with the modified asset data in the form of one or more nodes linked in a tree form. In an embodiment, the dynamic linking is determined based on standard knowledge graph methods. Further, the method comprises validating the one or more dynamic linking between the one or more parameters associated with the modified asset data based on the pre-stored data table. In an embodiment, the pre-stored data table may be a look up table comprising the detailed structure of one or more parameters associated with the modified asset data with corresponding dynamic links with which those one or more parameters could be linked. Furthermore, the asset data management module <NUM> causes the processor(s) <NUM> to generate the digital representation model of the modified asset data using the knowledge graph.

In outputting the generated digital representation model of the modified asset data on the user interface, the asset data management module <NUM> causes the processor(s) <NUM> to display the generated digital representation model of the modified asset data on the user interface. The generated digital representation model is a knowledge graph.

Also, the asset data management module <NUM> causes the processor(s) <NUM> to store the generated digital representation model in a database.

In an exemplary embodiment, knowledge graph technology is used for dynamically mapping the asset data with corresponding asset data extracted from other external data sources. Knowledge graphs provide "schema on read" capabilities. Due to this capability, the computing system <NUM> efficiently handles asset data extraction and integration in the context of heterogeneous and potentially changing data source (such as data base <NUM>) schemas. Further, Knowledge graphs expose different schemas for the same underlying knowledge graph (which is the digital representation), thereby meeting the needs of different consumer systems. Despite this flexibility, Knowledge Graphs (at least if expressed using the RDF formalism) has formalized and standardized syntax and semantics. This makes the chosen approach largely independent of concrete tools and allows for an easy extension/integration with other systems or digital twins.

The storage unit <NUM> is configured for storing the asset data associated with one or more asset(s) 108A-N. The storage unit <NUM> comprises a library of digital representation models associated with the asset data. The storage unit <NUM> comprises a knowledge base <NUM> for storing the generated digital representation models. Also, the knowledge base <NUM> is responsible for updating the versions of the digital representation models as and when they are modified.

The communication interface <NUM> is configured for establishing communication sessions between the one or more user device 122A-N and the computing system <NUM>. The communication interface <NUM> allows the one or more engineering applications running on the user devices 122A-N to import/export digital representations into the computing system <NUM>. In an embodiment, the communication interface <NUM> interacts with the interface at the user devices 122A-N for allowing the engineers to access the digital representations of the asset information based on the user privileges and access control rules and perform one or more actions on the digital representations stored in the computing system <NUM>.

The input-output unit <NUM> may include input devices a keypad, touch-sensitive display, camera (such as a camera receiving gesture-based inputs), etc. capable of receiving one or more input signals, such as user commands to process asset data. Also, the input-output unit <NUM> may be a display unit for displaying a graphical user interface which visualizes the asset data and also displays the status information associated with each set of actions performed on the asset data. The set of actions may include data entry, data modification or data display. The bus <NUM> acts as interconnect between the processor <NUM>, the memory <NUM>, the storage unit <NUM> and the input-output unit <NUM>.

Those of ordinary skilled in the art will appreciate that the hardware depicted in <FIG> may vary for particular implementations. For example, other peripheral devices such as an optical disk drive and the like, Local Area Network (LAN), Wide Area Network (WAN), Wireless (e.g., Wi-Fi) adapter, graphics adapter, disk controller, input/output (I/O) adapter also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present disclosure is not being depicted or described herein. Instead, only so much of a computing system <NUM> as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described. The remainder of the construction and operation of the computing system <NUM> may conform to any of the various current implementation and practices known in the art.

<FIG> is a block diagram of an asset data management module <NUM>, such as those shown in <FIG> and <FIG>, in which an embodiment of the present invention can be implemented. The asset data management module <NUM> comprises a request handler module <NUM>, a validation module <NUM>, asset data modifier module <NUM>, a digital representation model generation module <NUM>, a database <NUM>, and an output module <NUM>. The validation module <NUM> comprises a semantic rule checker module <NUM> and a blockchain network module <NUM>.

The request handler module <NUM> is configured for receiving a request for modifying asset data. The request comprises one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the one or more parameters associated with the requestor profile. The requestor profile is associated with a reputation score indicating one or more privileges associated with the requestor. The reputation score is associated with each participant in the computing system <NUM>, which rises with streaks of successful issue and subsequent validation of the requests. Endorsement policies is a function of the reputation a participant has. For example, a supervisor with a high reputation score would need less endorsements to propose a modification than a newly appointed supervisor at the same level of the supervisor hierarchy. This ensures a significant time saving in the resolution of modifications. The reputation scores decide which floor engineer is assigned a modification instruction that is considered high-risk. Optionally, floor engineers may also be required to perform a certain number of modifications (scheduled maintenance or supervisor instructed modifications) defined in a service level agreement with the factory. Meeting or exceeding the minimum number of modifications performed enhances the reputation of the floor engineer, while failure in completing the assigned number of modifications result in a lowering of the reputation score.

The one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> comprises asset identifier, asset part identifier, modification type identifier, a responder identifier, timestamp information and digital endorsement of the one or more approvers. The one or more parameters associated with requestor profile comprises requestor identifier, transaction identifier, requestor privileges, a reputation score, requestor role, and an encryption key.

The validation module <NUM> is configured for validating the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the pre-stored one or more parameters associated with the requestor profile using blockchain validation method. Specifically, the validation module <NUM> comprises a semantic rule checker module <NUM> and a blockchain network module <NUM>. The semantic rule checker module <NUM> is configured for executing one or more data semantic based rules on the one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM>. In an exemplary embodiment, the semantic rule checker module <NUM> performs rule-based sanity checks on received asset data. The rule based sanity checks determines the semantic correctness of the received asset data. If the asset data is validated across the semantic based rules, then the semantic rule checker module <NUM> feeds the semantically sound asset data to the blockchain network module <NUM>.

The blockchain network module <NUM> is configured for determining the one or more parameters associated with the requestor profile upon executing the one or more data semantic based rules. For example, the one or more parameters such as requestor roles and privileges, and requestor reputation score are determined. If the requester is allowed to proceed with the request based on assessing the roles and privileges of the requestor, then the blockchain network module <NUM> is configured for determining one or more pre-defined transaction management conditions applicable to the one or more parameters associated with the requestor profile. The one or more predefined transaction management conditions comprises, for instance, whether the requestor has required roles to access/ modify the asset, whether the transaction is viable given the asset state (e.g. assets might be protected against modification), and others. Further, the blockchain network module <NUM> is configured for verifying whether the one or more parameters associated with the requestor profile satisfy with the one or more pre-defined transaction management conditions. The verification is performed using for example comparison of relative order in a lattice, or etc, or any other methods known in the art.

Every request received by a requestor is considered as a transaction by the blockchain network module <NUM>. Each transaction is then assigned a transaction ID with a time stamp information by the request handler module <NUM>. However, in order for a transaction to be valid, the transaction must be approved based on the one or more pre-defined transaction management conditions. In an exemplary embodiment, when a requestor initiates a request, considered as a transaction, number of approvals required to process the transaction is determined based on the one or more pre defined transaction management conditions. Based on such determination, such transactions are sent as transaction proposals to those approvers. The approvers receive the transaction, validate the transaction received based on prestored data in the database <NUM>, approve the transaction by endorsing the transaction and share the approved transaction back to the requestor. Hence, a transaction is considered valid if transaction is approved as per the one or more predefined transaction management conditions. This is achieved by leveraging blockchain smart contracts which automatically enforce endorsement policies. The contract may be consider hierarchy of approvers for each kind of transactions. For example, a factory policy may define that floor supervisors, who are lower in the hierarchy, require at least five endorsements from five approvers, with two endorsements necessarily from a approver higher in the hierarchy.

In an embodiment, in addition to supporting existing hierarchies of approvers and requestors, when a requestor rises in the hierarchy based on previous successful transactions, the one or more predefined transaction conditions may be modified to revise the required number of approvals needed if this requestor initiates the transaction. Therefore, a reputation score is associated with each participant in the computing system <NUM>. A higher value of reputation score indicates more number of successful transaction handling. Further, the one or more predefined transaction management policies, such as endorsement policies is a function of the reputation a participant has. For example, a supervisor with a high reputation score require less number of endorsements to propose a modification than a newly appointed supervisor at the same level of the supervisor hierarchy. This ensures a significant time saving in the resolution of modifications. These reputation scores decide which responder is assigned the request with high-risk of carrying out the instructions in the request or causing significant potential for damage in case of errors. Optionally, the responders are required to perform a number of modifications (scheduled maintenance or supervisor instructed modifications) defined in a service level agreement with the factory when once the request is assigned to them. Meeting or exceeding the minimum number of modifications enhances the reputation score of the responder, while failure to do so result in a lowering of the reputation score.

In an exemplary embodiment, for validating the request by the blockchain network module <NUM>, permissible roles and privileges associated with various participants of the computing system <NUM> are defined. The various participants comprises a requestor who requests modification of the asset data, one or more approvers who approve the requests and one or more responders who actually perform the modifications of the asset data. For example, in case of a factory environment, a factory administrator may act as a blockchain network administrator to register other participants onto a blockchain network. The factory administrators are also responsible for creating the digital assets on ledger corresponding to the physical assets 108A-N in the factory (such as technical installation <NUM>), i.e. the digital twin of the one or more assets 108A-N. In digital representation models (for example knowledge graph ontology), these digital assets are turbines, their respective parts, and permissible modification types to these parts (i.e., which parts added or removed constitute an atomic 'modification' to the turbine). Once the digital assets are created, floor supervisors and floor engineers initiate transactions related to for example modification request/transaction task assignment and modification task completion. These requests or transactions are initiated with appropriate digital signatures from the employee's blockchain wallet (as described below). Therefore, the factory administration initiates transactions to modify asset data, for example to deploy new turbines, add new machine parts, and create new modification types.

Further, a floor supervisor may act as an approver responsible for ensuring that modifications to the current asset data are necessary and valid. Therefore, a floor supervisor issues a transaction that instructs a floor engineer to perform a modification on a turbine. This transaction is only committed to the ledger when other supervisors confirm through endorsements that the modification instruction is required and well-formed. In addition, a supervisor is also responsible for verifying the modification performed by the floor engineer, which is done by reviewing the confirmation message received by the floor engineer. The confirmation message comprises evidence of performing the modification.

Furthermore, floor engineers, may act as responders responsible for performing modifications to asset data, such as turbines based on modification instructions issued to them by their supervisors. Once the operation is completed, the floor engineers intimate the same to the supervisors through the confirmation message.

In an embodiment, the blockchain network module <NUM> ensures that the blockchain network is permissioned and private. The validity of a transaction is established through votes, or endorsements, from the required participants. Acknowledgment on these valid transactions is achieved either through ordering nodes running traditional consensus algorithms which are Byzantine fault-tolerant (in the Hyperledger Fabric case), or proof-of-stake-based mining (in the Ethereum case). For example, since there is no mining of transactions and all computational hardware costs are borne by a factory up-front, there is no monetary incentivization scheme necessary for mining transactions. This is different from traditional proof-of-work based mining which would require transaction fees and block mining rewards.

The blockchain network module <NUM> comprises a mobile application which helps in remotely securing the asset data, in addition to the computing system <NUM>. The mobile application may be running on the user devices 122A-N. Such mobile applications when downloaded onto the user devices 122A-N creates a blockchain wallet (private-public key pair) for the user by default. This blockchain wallet enables the users on the user devices 122A-N to post transactions signed with their private key for the blockchain network module <NUM> to verify and validate with the corresponding public key. If the user is a floor supervisor, the application in communication with the blockchain network module <NUM> checks against directory to validate user credentials before issuing a wallet ID. This is essential to ensure separation of roles in the computing system <NUM>, as transactions are scoped to the role of the participant. For example, floor supervisors are responsible for delegating tasks, while floor engineers can only share confirmation messages confirming that the proposed modification has been completed.

Further, the blockchain network module <NUM> is configured for outputting results of verification of the one or more parameters associated with the requestor profile. The results of verification indicate whether the requestor is permitted to conduct the requested action on the knowledge graph.

Further, the blockchain network module <NUM> is configured for rejecting the request for modifying the asset data if the verification of the one or more parameters associated with the requestor profile fails to satisfy the one or more predefined transaction management conditions. For example, a requestor who is unauthorized to send a request for modification triggers a request or transaction, the blockchain network module <NUM> rejects the request from such requestor with a message 'unauthorized' to the requestor.

Furthermore, the blockchain network module <NUM> is configured for obtaining confirmation message associated with modification performed on the pre-stored asset data upon modifying the pre-stored asset data. The confirmation message comprises additional parameters associated with the modification performed on the pre-stored asset data. For example, the confirmation message is received from a responder in response to the request forwarded by the computing system <NUM> to him after receiving all intended approvals on the request. Further, the blockchain network module <NUM> is configured for validating the confirmation message comprising the additional parameters associated with the modification performed on the pre-stored asset data based on pre-defined conditions. The pre-defined conditions comprises for instance, checking the return codes signifying the success/failure of the operation requested, but can also include checking the number of modified triples against some operation-dependent expectation. Since, each modification made to the asset data is validated, the quality of the data is maintained and data corruption from unauthorized users is avoided. Also, by manning the asset data being ingested to the knowledge graph using a blockchain filter, the blockchain network module <NUM> ensures that only valid modifications are made to the knowledge graph. A user is restricted to a predefined set of assets that can be instantiated on the knowledge graph thus ensuring that no unauthorized nodes are created on the knowledge graph. Further, the blockchain network module <NUM> makes it feasible to trace the modifications performed on the asset data as the modifications are recorded on the blockchain for all transactions. Also, details about the participants involved in this transaction are maintained to ensure traceability.

The blockchain network module <NUM> feeds the validated request and the received asset data to the asset data modifier module <NUM> for further processing.

The asset data modifier module <NUM> is configured for modifying the pre stored asset data to generate a modified asset data based on the validated request. For example, the knowledge graph consists of nodes, relations, and attributes. Nodes are created or deleted, relations are created or deleted (maybe also be updated), and attributes are created, updated, and deleted. The one or more modifications may comprises create, delete, add, update either nodes, relations and attributes of the knowledge graphs. The asset data modifier module <NUM> is configured for determining whether the request is successfully validated based on results of verification of the one or more parameters associated with the requestor profile. Further, the asset data modifier module <NUM> is configured for identifying part of the pre-stored asset data requested to be modified based on the one or more parameters associated with the one or more assets 108A-N. For example, if the asset data is for an entire factory, then the part of the pre-stored asset data requested to be modified may be a turbine configuration data or a new turbine details or the like which are to be modified. The parameters determining such part of the asset data requested to be modified may be maintenance data of the factory, health data of the factory or the like.

Further, the asset data modifier module <NUM> is configured for determining type of modification to be performed on the identified part of the pre-stored asset data based on pre-stored data table. The one or more types of modification comprises node modification, attribute modification or relation modification. The pre-stored data table is a lookup table. For example, such look up table comprises mapped asset data for each of the one or more assets 108A-N. For example, an asset A has asset data such as asset ID, asset type, asset configuration information, asset communication information, asset faults, asset current status and the like. Also, the asset A has type of modification and user identifiers of participants who can perform modifications to such asset data. Also, the asset A may have list of user privileges assigned to it.

Further, the asset data modifier module <NUM> is configured for modifying the part of the pre-stored asset data based on the determined type of modification to generate the modified asset data. The modified asset data comprises modified one or more parameters associated with the asset and modified one or more parameters associated with the requestor profile. The one or more modifications comprises any change in the asset data. For example, addition of any information, deletion of any information, update or change to any parameter of the asset.

In an exemplary embodiment, once the validation of the request is complete, the asset data modifier module <NUM> translates the valid transactions or requests into RDF triples and ingest the asset data to the existing asset data stored in the form of a knowledge graph. The ingestion can be achieved using for example REST APIs.

The digital representation model generation module <NUM> is configured for generating a digital representation model of the modified asset data using a knowledge graph. The digital representation model of the modified asset data comprises dynamic linking between the one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the one or more parameters associated with the requestor profile. <FIG> depicts an exemplary digital representation model.

The digital representation model generation module <NUM> is configured for determining one or more dynamic linking between the one or more parameters associated with the modified asset data based on the generated modified asset data. Further, the digital representation model generation module <NUM> is configured for validating the one or more dynamic linking between the one or more parameters associated with the modified asset data based on the pre-stored data table. Also, the digital representation model generation module <NUM> is configured for generating the digital representation model of the modified asset data using the knowledge graph.

In an embodiment, the digital representation model generation module <NUM> is configured for generating the digital representation model of the modified asset data using the knowledge graph based on the validation of the confirmation message associated with the modification performed on the pre-stored asset data. The generation of digital representation model using knowledge graphs may be achieved via any known knowledge graph mechanism. The asset data in the knowledge graph follows specific ontology which allows the end-user to create only data which strictly adheres to the ontology structure and rules. The data can be ingested from several sources into the knowledge graph keeping in line with the structure and rules of the ontology. This ensures data consistency in knowledge graphs.

The database <NUM> is configured to store the generated digital representation model.

The output module <NUM> is configured for outputting the generated digital representation model of the modified asset data on the user interface. In a preferred embodiment, the output module <NUM> is configured for displaying the generated digital representation model of the modified asset data on the user interface using the W3C stack. This stack provides standard semantics for operators, and dedicated components (inference engines) which may be used to add additional information associated with the asset 108A-N. For example, using inference, additional, specific information (e.g. type labels) may be added on nodes based on user-defined rules. This helps domain experts get a better understanding of the asset data outputted on the user devices 122A-N, without having them to specify this data manually on each information item. The generated digital representation model is a knowledge graph. The output module <NUM> provides an user interface (UI) for displaying the generated digital representation model.

<FIG> is a process flowchart illustrating an exemplary method <NUM> of securing asset data in a computing environment, according to an embodiment of the present invention. At step <NUM>, a request for modifying asset data is received. The request comprises one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and one or more parameters associated with a requestor profile. The requestor profile is associated with a reputation score indicating one or more privileges associated with the requestor. The one or more parameters associated with the one or more assets (108A-N) deployed in the technical installation (<NUM>) comprises asset identifier, asset part identifier, modification type identifier, a responder identifier, timestamp information and digital endorsement of the one or more approvers. The one or more parameters associated with requestor profile comprises requestor identifier, transaction identifier, requestor privileges, a reputation score, requestor role, and an encryption key.

At step <NUM>, the request for modifying the asset data is validated based on pre-stored one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the pre-stored one or more parameters associated with the requestor profile using blockchain validation method.

At step <NUM>, the pre stored asset data is modified to generate a modified asset data based on the validated request. At step <NUM>, a digital representation model of the modified asset data is generated using a knowledge graph. The digital representation model of the modified asset data comprises dynamic linking between the one or more parameters associated with the one or more assets 108A-N deployed in the technical installation <NUM> and the one or more parameters associated with the requestor profile. At step <NUM>, the generated digital representation model of the modified asset data is outputted on a user interface.

<FIG> is a schematic representation of an exemplary digital representation model, according to an embodiment of the present invention. In <FIG>, a class level ontology for asset such as turbines and the respective parts of the asset 108A-N along with their locations is depicted. The ontology is a digital representation model. The ontology keeps track of modification made for adding or removal of any parts associated with the asset, such as turbine. The part is a class which have several sub-classes such as nuts, vane, and the like. Every individual part has a specific part number which is the unique identity for part with a Boolean property of it being serialized or not. Thus, validating every modification at the servicing facility using the blockchain validation technique keeps track of every modification without the possibility of data in the knowledge graph getting corrupted. The asset data in the digital representation model such as knowledge graph helps to keep track of parts being used and replaced with a proper pipeline to validate the data at the technical installation <NUM> level.

<FIG> is a flow diagram illustrating an exemplary method <NUM> for securing asset data in a computing environment <NUM>, according to an embodiment of the present invention. In <FIG>, a supervisor <NUM> device <NUM> and supervisor <NUM> device <NUM> act as approvers of a request or a transaction, requestor device <NUM> is the one who initiates a request or the transaction, a responder device <NUM> is a person who acts on the request or transaction and <NUM> may be a computing system, such as computing system <NUM>. In operation, at step <NUM>, a requestor device <NUM> initiates a request or transaction to modify asset data, for example, in this case to modify a part of turbine. This request is first verified by an administrator based on the requestor profile. Once such request is approved by the administrator (although not shown), at step 614a and 614b, the request is broadcasted by the computing system <NUM> as a modification instruction endorsement request to one or more supervisor devices <NUM> and <NUM>, authorized to endorse the request. For example, in this case, the supervisor <NUM> and supervisor <NUM> receives the modification instruction endorsement request. For example, supervisor device <NUM> endorses the request and then at step <NUM>, sends the endorsed request to supervisor device <NUM> for his endorsement. Later, at step <NUM>, the supervisor device <NUM> responds to supervisor device <NUM> with his endorsement on the request. When once both the supervisor devices <NUM> and <NUM> have endorsed the request, at step <NUM>, any one of the supervisor device <NUM> or <NUM> generates a modification instruction transaction message and shares the modification instruction transaction message back to the computing system <NUM> via the requestor device <NUM>. For example, the modification instruction transaction message is broadcasted by a floor supervisor to instruct a floor engineer to make a specific modification to a specific set of parts in a turbine. It is issued upon receiving votes of approval from other floor supervisors in the form of endorsements. Once the necessary endorsements are collected, the transaction is posted with a digital signature of the issuing supervisor. The transaction payload comprises:
{Txn_ID, Supervisor_ID, Engineer_ID, Modification_ID, Part_ID[], Turbine_ID, Timestamp, Sign}.

Where, TXD ID is the transaction identifier, supervisor ID is the supervisor identifier, engineer ID is the floor engineer or responder identifier, modification ID is type of modification identifier, part ID is related to unique identifier of specific part of asset, turbine ID is the asset identifier, timestamp information, and a digital signature.

The computing system <NUM> upon receiving the modification instruction transaction message, at step <NUM>, generates a modification instruction event message and transmit this message to responder device <NUM>. The responder device <NUM> upon performing the instructions mentioned in the modification instruction event message, at step <NUM>, generates the modification completion or confirmation message and transmits the modification completion or confirmation message to the computing system <NUM>. For example, the modification completion message is broadcasted by the floor engineer. Upon being assigned a modification instruction message in the previous transaction, the engineer performs the modification to the turbine. The transaction contains the modification applied to the turbine, with a complete list of parts modified, timestamp, a digital signature, and optionally additional evidence. The transaction payload comprises:
{Txn_ID, Engineer_ID, Modification_ID, Part_ID[], Turbine_ID, Evidence_hash, Timestamp, Sign}.

Where, TXD ID is the transaction identifier, engineer ID is the floor engineer or responder identifier, modification ID is type of modification identifier, part ID is related to unique identifier of specific part of asset, turbine ID is the asset identifier, timestamp information, and evidence hash is the information on evidence document.

Upon receiving the confirmation message, at step <NUM>, the computing system <NUM> requests the requestor device <NUM>, and the supervisor devices <NUM> and <NUM> to verify the confirmation message. The supervisor devices <NUM> and <NUM> reviews the confirmation message and at step 628a and 628b, sends the verified message to the requestor device <NUM>. The requestor device <NUM> also verifies such confirmation message and finally at step <NUM> sends a transaction or request complete message to the computing system <NUM>. For example, upon reviewing evidence submitted by the floor engineer, the floor supervisor issues this transaction or request complete message to change the status of the instruction from open to closed. This can be issued by one or more supervisors to validate the completion of the task, gaining rewards for quick resolution of issues or validating evidence submitted by floor engineers. The transaction payload comprises:
{Txn_ID, Supervisor_ID, Engineer_ID, Modification_Instruction_Txn_ID, Timestamp, Sign}.

Where, TXD ID is the transaction identifier, supervisor ID is the supervisor identifier, engineer ID is the floor engineer or responder identifier, modification instruction taxation ID is type of modification identifier, timestamp information and a digital signature.

Hence, using blockchain based validation method, it is easy to trace who raised a modification request, who approved the modification request, who executed the modification and who verified the modification. Hence, traceability of entire workflow is ensured.

<FIG> is a schematic representation of an exemplary workflow of securing asset data in a computing environment, according to an embodiment of the present invention. In <FIG>, different users of the system and their roles are described. More specifically, <FIG> highlights the different "participants" in the computing system, such as computing system <NUM> and the different "transactions" or requests they are authorized to perform. In a digital twin use case, different participants involved in a request are:.

The different contracts in the diagram represent the above-mentioned transactions and their message body.

The present invention can take a form of a computer program product comprising program modules accessible from computer-usable or computer-readable medium storing program code for use by or in connection with one or more computers, processors, or instruction execution system. For the purpose of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and optical disk such as compact disk read-only memory (CD-ROM), compact disk read/write, and DVD. Both processors and program code for implementing each aspect of the technology can be centralized or distributed (or a combination thereof) as known to those skilled in the art.

Claim 1:
A method (<NUM>) for securing industrial asset data in a computing environment (<NUM>), the method comprises:
receiving, by a processor (<NUM>), a request for modifying asset data, wherein the request comprises one or more parameters associated with the one or more assets (108A-N) deployed in a technical installation (<NUM>) and one or more parameters associated with a requestor profile;
validating, by the processor (<NUM>), the request for modifying the asset data based on pre-stored one or more parameters associated with the one or more assets (108A-N) deployed in the technical installation (<NUM>) and the pre-stored one or more parameters associated with the requestor profile using blockchain validation method;
modifying, by the processor (<NUM>), the pre stored asset data to generate a modified asset data based on the validated request;
generating, by the processor (<NUM>), a digital representation model of the modified asset data using a knowledge graph, wherein the digital representation model of the modified asset data comprises dynamic linking between the one or more parameters associated with the one or more assets (108A-N) deployed in the technical installation (<NUM>) and the one or more parameters associated with the requestor profile; and
outputting, by the processor (<NUM>), the generated digital representation model of the modified asset data on a user interface.