WO2019117852A1

WO2019117852A1 - System and method for semantics assisted asset onboarding for industrial digital services

Info

Publication number: WO2019117852A1
Application number: PCT/US2017/065570
Authority: WO
Inventors: Dan Yu; John HODGES JR.; Simon Mayer
Original assignee: Siemens Aktiengesellschaft
Priority date: 2017-12-11
Filing date: 2017-12-11
Publication date: 2019-06-20

Abstract

A digital service platform includes a model matching computer processor receiving an actual asset model based on a physical asset device. The model matching computer processor retrieves a plurality of pre-determined asset models a repository, compares each of the asset models to the actual asset model, and associates a matching score to each asset model. A method for onboarding assets in a digital service platform includes storing a plurality of asset models. An agent retrieves data and metadata from a physical device and creates an actual device model from the retrieved data and metadata. The agent presents the actual device model to a matching engine processor that retrieves pre-determined asset models from the asset model repository. The model matching processor assigns each pre-determined asset model of the plurality of pre-determined asset models a matching score based on a comparison of each pre-determined asset model with the actual device model.

Description

SYSTEM AND METHOD FOR SEMANTICS ASSISTED ASSET ONBOARDING

FOR INDUSTRIAL DIGITAL SERVICES

TECHNICAL FIELD

[0001] This application relates to a digital service platform that digitalize, generate model and provide digital service for assets and their components in an industrial setting.

BACKGROUND

[0002] As technology has progressed, the number of devices that are connected to a remote network such as the Internet has increased rapidly. While the use of networks was once limited to traditional computer workstations, miniaturization and Moore’s Law have created an environment where devices that traditionally operated in an isolated stand-alone state are now capable of networked communications. These devices range from things like home appliances, to toys and games and all manners of devices in between. In industrial settings, devices like drive motors, controllers and sensors have the capability to communicate and share their inputs or outputs. The result of this new level of connectivity is a collection of data representing the operation of millions of devices and commonly connected via the Internet.

[0003] The data produced by these devices can provide insight into the operation of the source devices or assets. This information may include normal operations data, as well as information relating to failures or abnormal operation states. In combination with a control, service or maintenance system, this information may be used to identify and remediate problems before they happen. When used in a community setting, a first configuration of a manufacturing plant may operate more efficiently than a second plant having a similar configuration. By analyzing data provided by components within the first and second plants, efficiencies or best practices may be identified that may increase overall production and efficiency, providing the benefits of timely production of goods in the most efficient manner, increasing revenues through increased sales at lower production costs.

[0004] To fully exploit the potential advantages of data from connected devices, the devices must be connected to a centralized data processing system. All devices capable of communicating their data must be connected to the system. Additionally, as part of a larger system, connected components should further provide information that is representative of relationships and / or context of the data from the perspective of the overarching system. For example, in an air conditioning system, a water pump may provide cooling to a heating unit via a heat exchanger. A temperature sensor may be installed on or near the heating unit. The temperature sensor is configured to observe a temperature and produce a data signal that is representative of the heating unit temperature value. To use the information in the temperature signal, the control system must understand the context of the temperature value. That is, there must be some correlation between the temperature reading, the sensor from which the reading originated, and the component (e.g., the heating unit near the sensor) associated with the reading, as well as other components (e.g. the water pump) that function in cooperation with the monitored component. In this example, a high temperature reading may provide a signal to the water pump to increase its volumetric flow rate. An explicit description of the adjacency relationship between the temperature sensor and the heating unit must be established when system grows to industrial scale where there are thousands of sensors. It would be very hard or impossible to pinpoint the specific temperature sensor, not to say using the temperature reading to effectively control or fine tune the air condition system.

[0005] Accordingly, each component in the system must at some point be connected and registered to the management system. The management system may be a cloud- based computing system configured to receive data from connected devices through a communication network such as the Internet. When individual devices are interconnected in this manner, the devices are called edge devices. The ability for edge devices to be connected and communicate via the Internet is known as the Internet of Things (loT). Other non-cloud based system may also be used where devices are interconnected on a local or wide area network.

[0006] Challenges exist when trying to connect and coordinate disparate devices in a central control system. This is particularly evident in brown field applications, where new devices or software are added to a pre-existing system, and need to be connected and integrated with the existing or legacy devices and systems. As new devices are added, they must be identified, their data must be characterized, and interrelationships between the new device and existing or additional new devices must be determined. Presently, the onboarding of new assets requires the manual interaction of a subject matter expert. Experts with knowledge of the devices and their associated data, along with knowledge of the system environment, must define the identifying information of assets and their components and their relationships, align them to existing system model or build a new system model, then manually input all the relevant information into a user interface (Ul) of the control management system. The added effort, time and cost negates the potential benefits that can be reaped from digitalization of the assets. Improved systems and methods for onboarding assets for digital industrial systems is desired to address these challenges.

SUMMARY

[0007] According to aspects of embodiments described in this disclosure, a digital service platform includes a model matching computer processor receiving an actual asset model based on a physical asset device, and in communication with an asset model repository. The model matching computer processor is configured to retrieve a plurality of pre-determined asset models from the asset model repository, compare each of the plurality of pre-developed asset models to the received actual asset model, and associate a matching score to each of the plurality of pre-developed asset models based on the comparison.

[0008] The digital service platform may further include a digital service agent processor, the digital service agent processor in communication with at least one actual asset device and the model matching computer processor. The digital service agent processor is configured to receive sensor data values and information relating to a conceptual model relating to at least one physical asset device, and construct an actual asset model based on the received data values and metadata.

[0009] The received sensor data includes at least one time-series stream of data values associated with at least one sensor. The information relating to a conceptual model includes information about the sensor(s) and data series (e.g. unit of reading, type of sensor and etc.), and may contain a relationship between a first sensor data value of a first sensor and a second sensor data value of a second sensor.

[0010] Further, the information relating to the conceptual model may include information relating to a relationship between a data value associated with a first physical asset device and a data value associated with a second physical asset device.

[0011] The digital service system includes an asset repository for storing a plurality of actual asset models, each of the plurality of actual asset models are bound to one of the plurality of pre-developed asset models based on the matching score of the one of the plurality of pre-developed asset models exceeds a pre-determined threshold. The assets represented in the asset repository are specifically machine processable assets, which allow interaction between the asset and other assets as well as control and service systems that work in communication with assets within the asset project. Throughout this specification, the term asset will refer to a machine processable asset and the terms may be used interchangeably.

[0012] In determining a matching score, the matching score may be based on one or more of a number of factors which identify a property of the actual asset model with a corresponding property of a pre-developed asset model. The comparison may be a direct comparison of one value to another. In other embodiments, the match may be analyzed with respect to what can be inferred from the data values in the corresponding models. The inference may be based on a relationship between a first data value in the actual asset model and a second data value in the pre-developed asset model.

[0013] Additionally, a user interface (Ul) may be included where the Ul receives the actual device model and a candidate asset model having a matching score exceeding a pre-determined threshold, displays the actual device model and the candidate asset model to a user, receives a command from the user indicating a confirmation that the candidate asset model corresponds to the actual device model, transmits the confirmation command to the model matching computer processor.

[0014] In a method for onboarding an asset in a digital service platform, the method includes storing a plurality of asset models in an asset model repository, in an asset agent processor, retrieving sensor data and meta data from a physical asset device, in the asset agent processor, creating an actual device model from the retrieved sensor data and metadata, presenting, by the asset agent, the actual device model to a matching engine processor, retrieving by the model matching processor, a plurality of pre-developed asset models from the asset model repository, and assigning each pre- developed asset model of the plurality of pre-developed asset models a matching score based on a comparison of each pre-developed asset model with the actual device model.

[0015] Additionally, the method may include displaying, by the model matching processor in a user interface, a pre-developed asset model with a highest matching score and the associated actual device model to a user. Further, on a condition that the user confirms a match between the pre-developed asset model with a highest matching score and the associated actual device model, storing the actual device model in an asset repository.

[0016] For each actual device model stored in the asset repository, the actual device model is bound with the pre-developed asset device model having the highest matching score with respect to the actual device model. According to embodiments, the asset agent processor retrieves the sensor data and information relating to the conceptual model from the physical asset device by subscribing to the existing asset registry service, actively polling the physical asset device for the sensor data and metadata, or through sniffing the data exchange between sensors / actuators and the controller.

[0017] In an embodiment, the model matching computer processor is configured to retrieve a fingerprint of each of the plurality of pre-developed asset models, the fingerprints are a set of compiled and / or indexed rules which can be executed on the acquired actual asset models to quickly derive a score of matching exposing some, but not all the data and relationships between data points contained in the pre-developed asset model.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the invention, there is shown in the drawings embodiments that are presently preferred, it being understood, however, that the invention is not limited to the specific instrumentalities disclosed. Included in the drawings are the following Figures:

[0019] FIG. 1 is an illustration for a user interface for manually entering device onboarding data according to a conventional data service system.

[0020] FIG. 2 is an illustration of a conventional hierarchical device management application. [0021] FIG. 3 is an illustration of a conventional device properties management system.

[0022] FIG. 4 is a block diagram of an automated asset onboarding system according to aspects of embodiments of this disclosure.

[0023] FIG. 5 is a block diagram of another embodiment of an automated asset onboarding system according to aspects of embodiments of this disclosure.

[0024] FIG. 6 is a block diagram of an application ecosystem for connected devices which may be used according to aspects of embodiments of this disclosure.

[0025] FIG. 7 is a process flow diagram for a method of automatically onboarding assets to a control management system according to aspects of embodiments of this disclosure.

[0026] FIG. 8 is a block diagram of a computer system that may be used to implement aspects of embodiments described in this disclosure.

DETAILED DESCRIPTION

[0027] One of the first steps in digitalization involves the onboarding of assets into a digital service platform. One example of a digital service platform is MINDSPHERE®, available from Siemens, AG of Munich Germany. For most projects, including those involving brown field projects, asset onboarding is an important first step to gain a holistic picture and to assess the performance of the systems in question. Unfortunately, this step demands tremendous engineering effort to recover/reconstruct the missing knowledge, though it does not necessarily generate immediate revenue for the digital service platform provider. The missing knowledge to be the original information that was known by the entity that created the associate data at its onset. When first taken into service, the person installing the asset has knowledge to factors such as, what the device is, how it is used, its intended use, along with the data generated due to these identifying factors. Asset onboarding may become especially costly when involving brown field projects commissioned years prior. These projects frequently lack complete documentation, may include information possessed by third party partners who have since left the project, or involve devices not sufficiently administered by the system owner. These gaps in information frequently lead to bottlenecks for many industrial loT platforms and delays the widespread adoption of these systems to a broader audience.

[0028] During interaction with a typical graphical user interface (GUI), it may require up to a minute or more to onboard a single data point from an existing automation project to an existing digital service installation. This represents a substantial amount of time in systems where there may be thousands of data points in communication with the digital service system.

[0029] FIG. 1 is an illustration of the MINDSPHERE GUI according to a conventional manual method for onboarding assets in a cloud-based control management system. To add an additional data point, a name of the object 110 must be entered. A type of unit for the measurement 120 must be selected for the data point. Additionally, the nodelD must be manually typed in, for example, if using an indicator according to the standard OLE for Process Control (OPC) Unified Architecture (OPC-UA), the expert may have to enter the following string:“nodelD:ns=4;s=Dermo.BoilerDermo.Boiler1.FNILevelSetPoint” 130, and finally, select a data type 140 for the value. As discussed above, assuming all the required data is known, it is expected that it will take a substantial amount of time and effort to onboard the machine-readable assets for a given project for each data point to be added. When this is multiplied by hundreds to thousands of data points, it represents a significant delay in achieving the full capabilities of the digital service platform, as well as an inefficient use of the time of the experts involved.

[0030] Presently, the onboarding process may be partially performed programmatically, or otherwise performed manually. When performed programmatically, many industrial domains already have some directory service in place, where a server may publish some available data. Conventionally, engineers have spent considerable effort to develop domain-specific tools to digitalize assets from legacy installations. One example is to use a discovery tool to extract data from an existing automation system. However, in many real world implementation or legacy installations, only bare minimum context information is retained in the existing runtime system.

[0031] FIG. 2 is an illustration of a Ul screen showing attributes for an asset in an OPC-UA client for retrieving directory information relating to the asset. The description of the object“TemperatureSensor” 205 is rich in content, however the relations between the temperature sensor and the data point“TemperatureSetPoint” 209 is lost. Only an engineer or expert with domain knowledge about this system could deduce from the names that these two objects are related to each other. In this actual example, for Boilerl 203 in BoilerDemo 201 , the TemperatureSetPoint 209 sets the target value for TemperatureSensor’s 205 Temperature property 207.

[0032] FIG. 3 provides another illustration for a visualization of Building Automation and Control (BACnet) data. The BACnet data may be acquired directly from a BACnet server. Although we have a list of all the sensor readings, the meaning and relationship of the sensors is lost. Without additional information, a service engineer has no way of knowing which zone the space temp sensor 301 is monitoring. Further the engineer does not have any insight into whether this sensor is monitoring the same zone as the fan sensor 303 listed next to it. These gaps become increasingly problematic for a large project involving thousands of data points.

[0033] In most legacy projects the organized data as shown in FIGs. 2 and FIG. 3 is unavailable or inaccessible. This situation becomes even more challenging. Typically, service engineers must resort to one or more of the following approaches:

• experimenting with existing systems;

• consulting system operators or system engineers (if any can be found);

• refer to system documentation such as an operation manual;

• use sniffing tools;

• reverse engineer the existing system; and / or

• install additional sensors. in order to decipher the system operation and to recover or reconstruct the meaning and relationships of the data.

[0034] While existing programmatic or manual processes may be applied to brown field systems, these methodologies are not scalable. These methods are also labor intensive and require domain experts with advanced knowledge and extensive project experience to correctly identify and digitalize the assets. Due to human error, the data acquired from the system may be tainted and render the final analysis results inaccurate and less useful. Moreover, service applications must be tailored from one project to another to handle inconsistencies in data labeling, naming, formatting, and units definitions among other factors. The required intervention makes effective service programs labor intensive and resistant to scalability. The onboarding systems and methods now described provide automatic, and unlimited scalability in bringing large systems, or existing systems undergoing rounds of inconsistent upgrade, onboard for management by a digital service platform.

[0035] FIG. 4 is a block diagram for an architecture for automatically onboarding assets in a digital service platform. An asset entity 410 is a physical or virtual entity that is to be digitalized. The asset entity 410 may include one or more sensors 401. The sensors 401 produce sensor readings 405 as a time-series stream of measurement values that describe the status of the asset entity 410. The readings may be published as a directory service directly, for example OPC-UA, or the values may be made available implicitly and may need to be acquired with an explicit query or with the assistance of a protocol sniffer. Sensor 401 may be considered in its broadest meaning and may be a real physical sensor for measurement of physical properties like temperature, air pressure, force, voltage, electric current, speed among other characteristics. In addition, or in the alternative sensor 401 may be a virtual sensor for reporting the status of an asset, for example an error message and error code, a target set point of the temperature control in OPC-UA and BACnet, a memory occupied by the OS in a computer, number of interrupts in a CPU, up-time in a programmable logic controller (PLC) or Windows Management Instrumentation (WMI). Further, a sensor 401 may comprise a plurality of single sensors to form a composite sensor. Each sensor 401 has a unique access address within the context of the Asset Entity 410 and a single sensor 401 reading may take on a number of forms including a single numerical, Boolean or string value, or a complex object of additional metadata to describe the value (e.g., range, unit label, description, etc.).

[0036] The asset entity’s 410 time series stream of data and other conceptual model data 415 relating to the sensor data 405 is provided to an Agent 420. The Agent 420 is responsible for the retrieval of sensor readings and metadata 415. Depending on the nature of the Asset Entity 410, the retrieval of the time series stream of data and metadata 415 may be performed by subscribing to the directory service published by the Asset Entity 410 or by actively exploring the Asset Entity 410 using mechanisms like query or a sniffing mechanism. After the available sensors 401 and associated sensor data 405 is found at the Asset Entity 410, the Agent 420 constructs and presents an actual Asset Model 425 to Matching Engine 440. The actual Asset Model 425 may not comprise a complete description of the Asset Entity 410. For example, in an actual boiler as shown in FIG. 1 , the actual Asset Model 425 may be missing the property HeaterStatus due to a malfunction in the heater readings.

[0037] A model repository 430 is a repository of pre-developed semantic Asset Models that are arranged and stored in a semantic repository. For example, a model of a boiler may be configured as a semantic model that describes all the boiler types used in the project. Each model may be described using a semantic modeling language such as Resource Description Framework (RDF) or javascript object notation for linked data (JSON-LD). The model may contain information including a list of all possible components/sensors of the asset (e.g., a temperature sensor, T), as well as the functional relationships between these components and sensors (e.g., it may contain a basic statement saying that for a specific boiler, Temperature must be higher than a given TemperatureSetPoint.}

[0038] The Matching Engine 440 takes a list of candidate asset models 435 from Model Repository 430. The Matching Engine 440 tries to match each model in the list of model candidates 435 with the actual Asset model 425 extracted by Agent 420. After matching, a score is assigned according to the fit of the candidate model 435 to the actual Asset model 425. There are many possible approaches to associate the score with a match. By tapping into the power of semantics, high accuracy may be achieved and the manual effort of assigning the meaning of sensors and the relationships is greatly reduced. For example, we can use these heuristic hints (e.g., fingerprint) to score the match. Examples of heuristic hints include:

• Unit: an asset with sensor readings in Celsius (for temperature) and percentage (for fill level) matches a Boiler model better than an asset with reading in Newton meter and Ampere. The latter looks more like a motor’s torque and electric current sensor reading;

• Sensor name: an asset with a sensor labelled / noted“Torque” is more likely to match a Boiler Template than an asset a sensor labelled / noted“FillLevel”;

• Number of sensors: an asset with a thousand sensors matches a Gas Turbine model better than a thermostat for room temperature monitoring; • Rule defined in the model: an asset with Temperature higher than TemperatureSetPoint is more likely to match a Boiler model than an asset with Temperature significantly lower than TemperatureSetPoint.

• Application domain / use / function: two assets sharing the same property description may be used for different domains / functions, therefore such kind of semantic hints may still be used;

• Range of the data point: a thermostat used for building room temperature control will have different temperature range of a thermostat used for metal production furnace;

• other possibilities may be derived from semantic models and fall within the scope of this disclosure.

[0039] A User Interface 450 is used to accommodate limited data and metadata extracted from Asset Entity 410, which may cause Matching Engine 440 to make some mistakes. Ul 450 is used to present the matching engine output 459 in a sorted list. Various visual hints may be used to indicate a rank of the candidate models 435 matching the Asset Entity 410, (e.g. different colors, font, position in the Ul, or size of the suggestion). After an engineer makes the selection, the binding 465 of the asset model in the Model Repository 430 and the Asset Entity 410 is created and stored in the Asset Repository 460. This is a critical step in finalizing the meaning of data and the relationship the sensors generating the data. In addition, the feedback 457 from Ul 450 may be used by an optional machine learning algorithm residing in Matching Engine 440, to further increase the accuracy of matching. [0040] For most cases, the above architecture would be simpler than existing programmatic and manual processes. To onboard new assets, an engineer would merely need to connect a new device to a digital service platform using an available Agent 420. Additionally, the digital service platform may present the user with questions via a Ul to determine the domain or nature of the new device. For example, questions that may provide desired information may ask the user if the project is a factor related project or a building management related project. In some embodiments, the engineer may configure the network parameters and permissions and launch the Agent to discover the new device. The Agent will automatically detect the new device and ask the user for confirmation. In this way, non-experts with limited knowledge of specific field protocols may still confirm the matches of the model candidates and the actual Asset model.

[0041] Referring now to FIG. 5, a block diagram for an architecture of semantic based on boarding of assets to a digital control platform is shown. The structure and components of FIG. 5 are similar to those of FIG. 4. In the architecture of FIG. 4, the data normally flows in one direction from Asset Entity 410 to Agent 420. However, it may also be configured that the Asset Entity 410 may expose additional data point for Agent 420. For example, in an OPC-UA model of the boiler depicted in FIG. 2,“heat” and

“fill” control points are write-only without any time series stream of data to read from. It is conceivable that some developers focusing on semantic asset models, may not want all details of the semantic model to be accessible to everyone. Accordingly, the model repository 430 may offer an API to only service a fingerprint representation of the Asset Model 535 to the Matching Engine 440. A fingerprint representation of the actual Asset Model 525, containing only a subset of identifying information in the actual Asset Model. Thus, proprietary information contained in the model may be obscured from third parties, only providing necessary information to the third party to carry out selected additional algorithms on the model data and features.

[0042] According to other embodiments, a digital service platform according to this disclosure may provide an ecosystem for app development relating to data provide by a multitude of Asset Entities. The meaning and relationships of data from the sensor readings are aligned with the common asset models pre-defined in the Model Repository. In this way, developers can concentrate on algorithms to provide value from the data.

[0043] FIG. 6 is a diagram of an application ecosystem according to aspects of embodiments described in this disclosure. An Asset Entity is described with respect to an electric motor 610. The motor 610 will have inputs including voltage 611 applied to the motor leads and an amount of current 613 that runs through the motor during operation. The operating state of the motor 610 may be indicated in part by the temperature of the motor as it runs. A temperature sensor associated with the motor 610 may be configured to detect and measure the temperature 615 of the motor 610. The sensor may be configured to produce a signal indicative of the motor temperature in degrees Celsius (°C). During operation, the motor 610 generates output including torque 617 in newton-meters and speed of the motor shaft 619 in revolutions per minute (RPM). The motor’s inputs, states and outputs provide data associated with the Asset Entity representing the motor 610. An actual Asset Model of motor 610 may be constructed from these data values. The data values may be stored as a time-series or stream of data values. Inter-relationships between the data values of the motor 160, as well as interactions of the data values with other Assets, define the semantics of the actual Asset Model.

[0044] By using pre-developed semantic models from the model repository of FIG. 4 and FIG. 5, the data values and their relationships are pre-defined and made available to third party developers. For example, classes and methods relating to the data values and their relationships may be defined in an application programming interface (API). The API provides pre-defined functionality for the asset and its data or properties. A third-party developer may use the data values and their associated relationships to develop more complex algorithms that leverage the meanings in the data to produce improved functionality for the digital control system. The third-party applications (Apps) may be used a part of an ecosystem 620 where multiple apps from different sources may be developed. For example, App1 621 is developed by a first developer and checks that the motor temperature 615 falls within a specified limit denoted Motor.Temperature_Max, which was defined in the asset model beforehand. The app accesses the asset model and retrieves the value associated with the temperature sensor of the motor as well as a value or property of the asset model which indicates a maximum allowable temperature for the motor. App1 compares the measured temperature 615 with the allowable maximum temperature to ensure the measured temperature 615 is less than the specified maximum temperature. If App1 determines that the maximum temperature is exceeded for the motor 610, App1 may be configured to produce an alarm or warning signal. The alarm or warning signal may be passed back to the asset model for pre-defined error handling. For example, a motor asset model may have functionality for transmitting a warning signal to an indicator lamp. The indicator lamp is another asset with an associated asset model with relationships defined between the input of the indicator lamp and a received warning signal.

[0045] Other application developers may use the asset model independently. Referring again to FIG. 6, App2 is configured to retrieve the motor speed and check to determine the motor is operating within its specification. Likewise, App3 calculates a power loss for the motor by subtracting the output power of the motor calculated from the motor’s torque 617 and speed 619 from the input power determined by the input voltage 61 1 and current 613.

[0046] FIG. 7 is a process flow diagram of a method for onboarding assets in a digital service platform according to aspects of embodiments of this disclosure. A repository of pre-defined asset device models is stored in a memory of the digital service platform 710. A device agent retrieves sensor data from an asset entity and using the data and metadata, the agent produces an actual device model 720. The agent presents the actual device model to a matching engine that is in communication with the asset device model repository 730. Asset device models from the repository are compared to the actual device model and each asset device model is assigned a matching score based on the asset device model’s similarity to the actual device model. The highest scoring asset device model is presented to a user through a Ul 740. When the user confirms the asset device model matches the actual asset, the actual asset is bound to the asset device model in the repository and stored in an asset repository 750. The asset repository contains all the matched asset device models corresponding to each actual asset and provide the addresses and relationships of the data values and relationships pertaining to the actual asset device.

[0047] FIG. 8 illustrates an exemplary computing environment 800 within which embodiments of the invention may be implemented. Computers and computing environments, such as computer system 810 and computing environment 800, are known to those of skill in the art and thus are described briefly here.

[0048] As shown in FIG. 8, the computer system 810 may include a communication mechanism such as a system bus 821 or other communication mechanism for communicating information within the computer system 810. The computer system 810 further includes one or more processors 820 coupled with the system bus 821 for processing the information.

[0049] The processors 820 may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as used herein is a device for executing machine-readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0050] Continuing with reference to FIG. 8, the computer system 810 also includes a system memory 830 coupled to the system bus 821 for storing information and instructions to be executed by processors 820. The system memory 830 may include computer readable storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 831 and/or random access memory (RAM) 832. The RAM 832 may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The ROM 831 may include other static storage device(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 830 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors 820. A basic input/output system 833 (BIOS) containing the basic routines that help to transfer information between elements within computer system 810, such as during start-up, may be stored in the ROM 831. RAM 832 may contain data and/or program modules that are immediately accessible to and/or presently being operated on by the processors 820. System memory 830 may additionally include, for example, operating system 834, application programs 835, other program modules 836 and program data

837. [0051] The computer system 810 also includes a disk controller 840 coupled to the system bus 821 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 841 and a removable media drive 842 (e.g., floppy disk drive, compact disc drive, tape drive, and/or solid state drive). Storage devices may be added to the computer system 810 using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire).

[0052] The computer system 810 may also include a display controller 865 coupled to the system bus 821 to control a display or monitor 866, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. The computer system includes input interface 860 and one or more input devices, such as a keyboard 862 and a pointing device 861 , for interacting with a computer user and providing information to the processors 820. The pointing device 861 , for example, may be a mouse, a light pen, a trackball, or a pointing stick for communicating direction information and command selections to the processors 820 and for controlling cursor movement on the display 866. The display 866 may provide a touch screen interface which allows input to supplement or replace the communication of direction information and command selections by the pointing device 861. In some embodiments, an augmented reality device 867 that is wearable by a user, may provide input/output functionality allowing a user to interact with both a physical and virtual world. The augmented reality device 867 is in communication with the display controller 865 and the user input interface 860 allowing a user to interact with virtual items generated in the augmented reality device 867 by the display controller 865. The user may also provide gestures that are detected by the augmented reality device 867 and transmitted to the user input interface 860 as input signals.

[0053] The computer system 810 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 820 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 830. Such instructions may be read into the system memory 830 from another computer readable medium, such as a magnetic hard disk 841 or a removable media drive 842. The magnetic hard disk 841 may contain one or more datastores and data files used by embodiments of the present invention. Datastore contents and data files may be encrypted to improve security. The processors 820 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 830. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0054] As stated above, the computer system 810 may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term“computer readable medium” as used herein refers to any medium that participates in providing instructions to the processors 820 for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 841 or removable media drive 842. Non-limiting examples of volatile media include dynamic memory, such as system memory 830. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 821. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0055] The computing environment 800 may further include the computer system 810 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 880. Remote computing device 880 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 810. When used in a networking environment, computer system 810 may include modem 872 for establishing communications over a network 871 , such as the Internet. Modem 872 may be connected to system bus 821 via user network interface 870, or via another appropriate mechanism.

[0056] Network 871 may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or any other network or medium capable of facilitating communication between computer system 810 and other computers (e.g., remote computing device 880). The network 871 may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RJ-6, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks may work alone or in communication with each other to facilitate communication in the network 871.

[0057] An executable application, as used herein, comprises code or machine- readable instructions for conditioning the processor to implement pre-determined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine-readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

[0058] A graphical user interface (GUI), as used herein, comprises one or more display images, generated by a display processor and enabling user interaction with a processor or other device and associated data acquisition and processing functions. The GUI also includes an executable procedure or executable application. The executable procedure or executable application conditions the display processor to generate signals representing the GUI display images. These signals are supplied to a display device which displays the image for viewing by the user. The processor, under control of an executable procedure or executable application, manipulates the GUI display images in response to signals received from the input devices. In this way, the user may interact with the display image using the input devices, enabling user interaction with the processor or other device.

[0059] The functions and process steps herein may be performed automatically or wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

[0060] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. As described herein, the various systems, subsystems, agents, managers and processes can be implemented using hardware components, software components, and/or combinations thereof. No claim element herein is to be construed under the provisions of 35 U.S.C. 1 12, sixth paragraph, unless the element is expressly recited using the phrase“means for.”

Claims

CLAIMS What is claimed is:

1. A digital service platform comprising: a model matching processor receiving an actual asset model based on a physical asset device, and in communication with an asset model repository, wherein the model matching processor is configured to: retrieve a plurality of pre-developed asset models from the asset model repository; compare each of the plurality of pre-developed asset models to the received actual asset model; and associate a matching score to each of the plurality of pre-determined asset models based on the comparison.

2. The digital service platform of Claim 1 , further comprising: a digital service agent processor, the digital service agent processor in communication with at least one actual asset device and the model matching processor, the digital service agent processor configured to: receive sensor data values and conceptual model information relating to the at least one physical asset device; and construct an actual asset model based on the received data values and metadata.

3. The digital service platform of Claim 2, wherein the received sensor data comprises at least one time-series stream of data values associated with at least one sensor.

4. The digital service platform of Claim 2, wherein the conceptual model information comprises information about the data point and the generated data stream.

5. The digital service platform of Claim 2, wherein the metadata comprises information relating to a relationship between the first physical asset device and the rest of the system.

6. The digital service platform of Claim 1 , further comprising an asset repository for storing a plurality of actual asset models, each of the plurality of actual asset models are bound to one of the plurality of pre-developed asset models based on the matching score of the one of the plurality of pre-developed asset models exceeding a pre- determined threshold.

7. The digital service platform of Claim 1 , wherein the matching score is based at least in part on a direct comparison of a data value in the actual asset model, and a data value in the pre-determined asset model under consideration.

8. The digital service platform of Claim 1 , wherein the matching score is based at least in inference derived from a data value in the actual asset model, and a data value in the pre-determined asset model under consideration.

9. The digital service platform of Claim 8, wherein the inference is based on a potential relationship between first data value of the actual device model and the second data value of the pre-developed device model under consideration.

10. The digital service platform of Claim 1 , further comprising a user interface (Ul) that receives the actual device model and a candidate asset model having a matching score exceeding a pre-determined threshold and displays the actual device model and the candidate asset model to a user, and receives a command from the user indicating a confirmation that the candidate asset model corresponds to the actual device model and transmits the confirmation command to the model matching computer processor.

11. A method for onboarding an asset in a digital service platform comprising: storing a plurality of asset models in an asset model repository; in an asset agent processor, retrieving sensor data and meta data from a physical asset device; in the asset agent processor, creating an actual device model from the retrieved sensor data and metadata; presenting, by the asset agent, the actual device model to a matching engine processor; retrieving by the model matching processor, a plurality of pre-determined asset models from the asset model repository; and assigning each pre-determined asset model of the plurality of pre-determined asset models a matching score based on a comparison of each pre-developed asset model with the actual device model.

12. The method of Claim 11 , wherein the matching score is based at least in part on a direct comparison of a data value in the actual device model, and a corresponding data value in the pre-developed device model under consideration.

13. The method of Claim 1 1 , wherein the matching score is based at least in part on an inference derived from a data value in the actual device model, and a data value in the pre-developed device model under consideration.

14. The method of Claim 13, wherein the inference is based on a potential relationship between first data value of the actual device model and the second data value of the pre-developed device model under consideration.

15. The method of Claim 1 1 , further comprising: displaying, by the model matching processor in a user interface, a pre- determined asset model with a highest matching score and the associated actual device model to a user.

16. The method of Claim 15, further comprising: on a condition that the user confirms a match between the pre-determined asset model with a highest matching score and the associated actual device model, storing the actual device model in an asset repository.

17. The method of Claim 16, further comprising: for each actual device model stored in the asset repository, binding the actual device model with the pre-determined device model having the highest matching score with respect to the actual device model.

18. The method of Claim 1 1 , wherein the asset agent processor retrieves the sensor data and metadata from the physical asset device through polling the physical asset device for the sensor data and metadata.

19. The method of Claim 1 1 , wherein the asset agent processor retrieves the sensor data and metadata from the physical asset device through a sniffing protocol.

20. The method of Claim 1 1 , wherein the model matching computer processor is configured to retrieve a fingerprint of each of the plurality of pre-determined asset models, the fingerprint exposing some, but not all of the data and relationships between data points contained in the pre-determined asset model.