CN111758094A

CN111758094A - System and method for dynamic geospatial referenced cyber-physical infrastructure inventory

Info

Publication number: CN111758094A
Application number: CN201980014811.8A
Authority: CN
Inventors: 杰森·克拉布特里; 安德鲁·塞勒斯
Original assignee: Kempleux Co ltd
Current assignee: Kempleux Co ltd; Qomplx Inc
Priority date: 2018-02-23
Filing date: 2019-02-25
Publication date: 2020-10-09
Also published as: WO2019165384A1; EP3756108A4; EP3756108A1

Abstract

A system and method for dynamic geospatially referenced cyber-physical infrastructure inventory and asset management includes a business operating system, a parameter evaluation engine, at least one cyber-physical asset, at least one cryptographic ledger, a network, and the ability to represent data in a Markov state model and finite state machines.

Description

System and method for dynamic geospatial referenced cyber-physical infrastructure inventory

Cross Reference to Related Applications

The present application is PCT application entitled "system and method for dynamic geospatially referenced information physical infrastructure inventory and asset management," U.S. patent application No. 15/904,006, filed on 23.2.2018, and claiming priority thereto, the specification of which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates to the field of asset tracking and management, and more particularly to the field of cryptographic ledger or blockchain techniques, and the use of such techniques in managing inventory assets.

Background

It is now possible for businesses and individuals to track certain of their assets in some manner, thereby ensuring the security of the assets and ensuring efficient operation. For example, tracking packages being shipped by multiple carriers is possible, as is temperature control and temperature monitoring in certain environments such as libraries and cellars. However, the breadth and depth achieved using informative physical assets for sensor monitoring is low, and the cost and obstacles to such practice are often quite high. Moreover, in some cases, the package in transit is picked up and tracked, and people do not rely on sensors to obtain a location report of the package; instead, people rely on operators to reliably obtain reports of the presence of items at various facilities. In many such and more cases, for example, contractual obligations involving the physical condition or area of an item, which obligations must be fulfilled by others, there is human error caused by human interaction, whereby business transactions will be involved in an agnostic variable factor.

There is a need for a system and method for autonomic sensor data monitoring of a variety of different forms of informative physical assets to improve supply chain risk management and to integrate these assets into the use of self-fulfilling intelligent contracts.

Disclosure of Invention

Thus, in a preferred embodiment of the present invention, the inventors contemplate and simplify a system and method for dynamic geospatially referenced cyber-physical infrastructure inventory and asset management. The following non-limiting summary of the invention is provided for clarity of explanation and should be construed in accordance with the examples set forth in the detailed description below.

To address the problem of remote monitoring and intelligent contract systems not having access to assets, a system and method for dynamic geospatially referenced cyber-physical infrastructure inventory and asset management is designed that includes a business operating system, a parameter evaluation engine, at least one cyber-physical asset, at least one cryptographic ledger, a network, and the ability to represent data in a Markov (Markov) state model and finite state machine. The systems and methods provided herein may also be applied to use cases for mobile or fixed processing facilities that may process items and send status updates about the items they are processing to a remotely or locally hosted operating system for ongoing monitoring.

Drawings

The drawings illustrate several aspects and together with the description serve to explain the principles of the invention in terms of these aspects. Those skilled in the art will appreciate that the particular arrangements shown in the drawings are illustrative only and should not be taken as limiting the scope of the invention or the claims in any way.

FIG. 1 illustrates an exemplary architecture of a system for capturing and storing time series data from sensors with uneven reporting material, according to a preferred aspect of the present invention.

FIG. 2 illustrates an exemplary architecture of a business operating system in accordance with a preferred aspect of the present invention.

FIG. 3 illustrates an exemplary architecture of an auto-planning service cluster and correlation module in accordance with a preferred aspect.

FIG. 4 is a system diagram illustrating the connections between the inventive core components for geo-locating and tracking informational physical asset conditions, according to a preferred aspect.

FIG. 5 is a method diagram illustrating key steps in communication between an informative physical asset and a remote server according to a preferred aspect.

FIG. 6 is a method diagram illustrating the key steps in an enterprise operating system to interact with data received from an cyber-physical asset in a database to validate an update in a cryptographic ledger in accordance with a preferred aspect.

FIG. 7 is a method diagram illustrating several steps for using smart contracts in conjunction with cyber-physical assets in accordance with a preferred aspect.

FIG. 8 is a method diagram illustrating key steps in the function of a parameter evaluation engine in accordance with a preferred aspect.

Fig. 9 is a block diagram illustrating an exemplary hardware architecture of a computing device.

Fig. 10 is a block diagram illustrating an exemplary logical architecture of a client device.

FIG. 11 is a block diagram illustrating an exemplary architectural arrangement of clients, servers, and external services.

FIG. 12 is another block diagram illustrating an exemplary hardware architecture of a computing device.

Detailed Description

The inventors contemplate and simplify a system and method for dynamic geospatially referenced information physical infrastructure inventory and asset management.

One or more different aspects may be described in this application. Further, many alternative arrangements may be described for one or more aspects described in this application; it should be understood that these are provided for illustrative purposes only and are not intended to limit in any way the aspects encompassed by the present application or the claims provided by the present application, as will be apparent from the present disclosure. One or more of these arrangements may be broadly applicable in a variety of respects. In general, the various arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it is to be understood that other arrangements may be utilized and that structural, logical, software, electrical, and other changes may be made without departing from the scope of the specific aspects. Particular features of one or more aspects described in this disclosure may be described with reference to one or more particular aspects or drawings that form a part hereof, and in which particular arrangements of one or more aspects are shown by way of illustration. It should be understood, however, that these features are not limited to the manner of use in one or more particular aspects or figures described with reference thereto. This disclosure is neither a complete written description of the arrangement of one or more aspects nor a listing of features of one or more aspects that must be present in all arrangements.

The section headings provided in this patent application and the title of this patent application are for convenience only and should not be construed to limit the disclosure in any way.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. Further, devices that are in communication with each other may communicate directly or indirectly through one or more communication devices or media (logical or physical).

The description of aspects of several components in communication with each other does not imply that all such components are required. Rather, various optional components may be described to illustrate various possible aspects and to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders unless specifically stated to the contrary. In other words, any sequence or order of steps described in this patent application is not itself indicative of a requirement that the steps be performed in that order. The steps of the described processes may be performed in any practical order. Further, although described or implied as occurring non-concurrently (e.g., because one step is described after another), some steps may be performed concurrently. Furthermore, the description of a process, by virtue of its being depicted in a figure, does not imply that the described process does not preclude other variations and modifications, does not imply that the described process or any of its steps is essential to one or more of the aspects and does not imply that the described process is preferred. Moreover, aspects generally describe a step once, but do not imply that a step must occur once, nor that a step occurs only once each time a process, method, or algorithm is performed or executed. Some steps may be omitted in some aspects or in some occurrences, or some steps may be performed multiple times in a given aspect or occurrence.

When a single device or article is described herein, it will be clearly understood that a plurality of devices or articles may be used in place of a single device or article. Similarly, where multiple devices or articles are described herein, it will be readily apparent that a single device or article may be used in place of the multiple devices or articles.

Alternatively, the functionality or the features of a device may be embodied by one or more other devices which are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.

For purposes of clarity, techniques and principles described or referenced herein will sometimes be described in the singular. However, it should be appreciated that, unless otherwise indicated, particular aspects may include multiple iterations of the techniques or multiple instantiations of the principles. The process descriptions or blocks in the figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternative implementations are included within the scope of the various aspects in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art.

Definition of

As used herein, a "swimlane" refers to a communication channel between a time series sensor data receiving and dispensing device and a data store for holding dispensed data time series sensor data. A swimlane is capable of moving a specific, limited amount of data between two devices. For example, a single lane may reliably carry and incorporate into the data store, which is its capacity, data corresponding to a 5 second value of data from 10 sensors within 5 seconds. Attempting to place a 5 second worth of data received from 6 sensors using one lane will result in data loss.

As used herein, a "meta-lane" refers to an on-demand logical combination of the transfer capabilities of two or more real lanes that is transparent to the requesting process. A sensor study in which the amount of data received per unit time is expected to be highly non-uniform over time may be initiated to use the metal lanes. Using the foregoing example, a single real swimlane may transmit and bind 5 second value data for 10 sensors without data loss, and suddenly receiving sensor data input from 13 sensors during a 5 second interval will cause the system to create a meta-swimlane of two swimlanes, containing the standard 10 sensor data in one real swimlane and 3 sensor data in a second transparently added real swimlane, however, no change in data reception logic is required since the data reception and distribution device will transparently add additional real swimlanes.

Concept architecture

FIG. 1 illustrates an exemplary architecture of a system for capturing and storing time series data from sensors with uneven reporting material, according to a preferred aspect of the present invention. In this embodiment, a plurality of sensor devices 110a-n stream data to a collection device, which in this case is a network server acting as a network gateway 115. These sensors 110a-n may take several forms, including but not limited to the following examples: physical sensors that measure humidity, pressure, temperature, orientation, and the presence of gases; or virtually, such as programming that measures network traffic levels, memory usage in the controller, and the number of times the word "refill" is used in the flow of email messages on a particular network segment, examples of which are a small number of different forms known in the art. In the present embodiment, the sensor data is passed to the data management engine 120 without transformation, where the sensor data is aggregated and sorted in the data management engine 120 for storage in a particular type of data store 125, the particular type of data store 125 being designed to process multi-dimensional time series data derived from the sensor data. Raw sensor data can exhibit very different transmission characteristics. Some sensor groups may continuously transmit low to medium amounts of data. Storing data to a data store in this continuous manner is not feasible because attempting to distribute identification keys and store real-time data from multiple sensors can always result in significant data loss. In this case, the data stream management engine 120 would store the input data in memory, only the important parameters or "dimensions" in the larger sensor stream, and the instructions sent from the management device 112 to store these parameters or "dimensions". The data stream management engine 120 will then aggregate data from multiple individual sensors and distribute the data at predetermined intervals (e.g., every 10 seconds), using a timestamp as a key when storing the data to the multidimensional time series data repository on a single swimlane of sufficient size. This very ordered transfer of predictable amounts of data per unit time is particularly suitable for data capture and storage, but where the transfer of data from the sensors occurs irregularly, and patterns of very uneven amounts of data are very common. In these cases, the data stream management engine cannot successfully use a strict single time interval on the data storage mode of a single swimlane. In addition to the single time interval approach, the present invention may also use event-based storage triggers, where a predetermined number of data reception events are set at the management device 112, triggering the transmission of a data block that includes the number of events assigned as one dimension and the number of sensor ids as another dimension. In this embodiment, the system time at commit or a timestamp that is part of the received sensor data is used as a key for the data block value of the "value-key pair". The present invention may also accept an original data stream where the commit occurs when the accumulated stream data reaches a predetermined size set at the management device 112.

It is also possible that when large reports are made from medium to large sensor arrays, the instantaneous load of data to be submitted will exceed the load that can be reliably transmitted on a single lane. If the capture parameters are preset at the management device 112, embodiments of the present invention may combine the data movement capacity of two or more swimlanes, the combined bandwidth being referred to as a meta-swim lane, which is transparent to the commit process to accommodate the influx of data that needs to be committed. All sensor data, regardless of the transmission environment, is stored in a multi-dimensional time series data store 125, which multi-dimensional time series data store 125 is designed to achieve extremely low overhead and fast data storage, with minimal maintenance requirements on resources. This embodiment uses "key-value pair" data stores, examples of which are Riak, Redis and Berkeley DB, due to their low overhead and speed, but the present invention is not particularly tied to a single data store type, in addition to other data stores known in the art, in case another data store with better responsiveness and characteristic characteristics occurs. Due to factors that are easily guessed by those skilled in the art, data storage commit reliability depends on data storage data size under the intrinsic conditions of time series sensor data analysis. For the purposes disclosed herein, the number of data records must be kept relatively low. For example, a team of developers limits the size of their multidimensional time series "key-value pair" data store to about 8.64 × 104 records, equivalent to 24 hours of 1 second interval sensor readings or 60 days of 1 minute interval readings. In the development system, the oldest data is deleted and lost from the data store. Such data loss is acceptable under development conditions, but in a production environment, the loss of old data is almost always severe and unacceptable. The present invention addresses this need to preserve old data by specifying that old data be placed in long-term storage. In this embodiment, an archival memory 130 is included. The archival memory may be provided locally by the user, may be cloud-based, such as provided by amazon cloud services (AWS) or Google, or may be any other available ultra-large capacity storage method known to those skilled in the art.

Reliably capturing and storing sensor data and providing longer term, offline storage of the data, while important, is only a drill down without a method of repeatedly retrieving and analyzing the most likely different, but specific data sets over time. The present invention provides a robust query language for this requirement that provides both a direct language for retrieving a data set delimited by a plurality of parameters and a number of transformations on the data set that are invoked prior to output. In an embodiment, the isolation of the desired data set and the transformation applied to the data occurs using predefined query commands issued from the management device 112 and acted upon within the database by the structured query interpreter 135. The following is a very simplified example statement that illustrates a way in which a very small number of options can be accessed, which can be obtained using structured query interpreter 135.

Where "data _ spec" can be replaced by a series of individual sensors from a larger sensor array, and each sensor in the series can be given a human-readable identifier formatted as a "sensora s identifier". "unit" allows the researcher to specify periods of sensor data, e.g., seconds(s), minutes (m), hours (h). One or more transformation filters may be applied, including but not limited to: the mean, median, variance, standard deviation, standard linear interpolation, or kalman filtering and smoothing, and the data may then be formatted in one or more formats, such as text format, JSON, KML, GEOJSON, and TOPOJSON formats, depending on the intended use of the data.

FIG. 2 illustrates an exemplary architecture of a business operating system 200 in accordance with a preferred aspect of the present invention. For system control and interaction with system outputs (such as automated predictive decision and planning and alternate path simulation), client access to the system 205 occurs through a highly distributed, very high bandwidth cloud interface 210 of the system, the cloud interface 210 being through the use of the Scale/Lift development Environment and by AWS ELASTIC BEASTALK^TMMediated Web interaction is driven by applications, both for standards compliance and ease of development. Most of the business data from the customer business-wide sources and cloud-based sources analyzed by the system also enters the system through the cloud interface 210, and the data is passed to the analysis and transformation components of the system, the directed computation graph module 255, the high-volume Web crawling module 215, and the multidimensional time-series database 220. The directed computation graph retrieves one or more data streams from a plurality of sources including, but in no way limited to, physical sensors, Web-based questionnaires and surveys, monitoring of electronic infrastructure, crowd-sourcingActivities, and human input device information. In directed computational graphs, data can be split into two identical streams, where one sub-stream can be sent for batching and storage, while the other sub-stream can be reformatted for transform pipeline analysis. The data is then passed as part of the analysis to a general transformation service 260 for linear data transformation, or to a decomposable transformation service 250 for branched or iterative transformation. The directed computation graph 255 represents all data as a directed graph, where the transformations are nodes and result messages between the transformation edges of the graph. These maps containing a significant amount of intermediate transformation data are stored and further analyzed within the graph stack module 245. The high volume Web crawling module 215 uses a plurality of server-hosted pre-programmed Web crawlers to find and retrieve data of interest from Web-based sources that are not well-tagged by traditional Web crawling techniques. The multidimensional time series database module 220 receives data from a large number of sensors, which may be of several different types. The module is designed to process incoming data by dynamically allocating network bandwidth and server processing channels to accommodate irregularities and large surges. The data retrieved by the multidimensional time series database 220 and the high volume Web crawling module 215 may be further analyzed and transformed into task optimization results by the directed computational graph 255 and associated generic transformation service 250 and resolvable transformation service 260 modules.

The results of the transformation analysis process and other customer instructions, additional business rules and practices associated with the analysis, and situational information outside the already available data may then be combined in the auto-planning service module 230, which auto-planning service module 230 also runs powerful predictive statistical functions and machine learning algorithms to allow rapid prediction of future trends and results based on the results derived by the current system, and selection of each of a plurality of possible business decisions. Using all available data, the auto-planning service module 230 may present business decisions with a high level of certainty available that are most likely to contribute to the best business result. In close relation to the situation where the automated planning service module uses the system derived results, in conjunction with possible externally provided additional information, to assist the end user in making business decisions, a business result simulation module 225, coupled with the end user oriented observation and state estimation service 240, allows the business decision maker to investigate what the results might be if one pending action were selected and another were not selected based on an analysis of the currently available data. For example, pipeline operations have reported that there is very little pressure drop in the crude oil in the pipeline sections of very remote territories. Many believe that the problem is entirely due to a contaminated, potentially failing flow sensor, and others believe that there may be foreign material trapped in the proximal upstream pump. A corrective measure for both possible situations is to increase the output of the affected pump to desirably clean the pump of foreign matter or clean the contaminated sensor. The impending failure sensor must be replaced on the next maintenance cycle. However, some believe that the pressure drop is due to a break in the pipeline, which may be small at this time, but even then the crude oil is leaking, and the option of remediating the contaminated sensor or pump may cause the leak to be worse and much time to be wasted later. The company does own the contractor, is 8 hours away from the failure site, or can rent a satellite to view, but both of these approaches are expensive if a sensor problem occurs, but are much cheaper than cleaning up a spill and then confronting a severe negative public exposure. These sensor problems have occurred before and the business operating system 200 has data obtained from these problems, however, because of the large number of histograms, no one has actually studied these data, and therefore

alternative actions

225, 240 are run. The system predicts that a contaminated sensor or pump is unlikely to be the root cause of this failure based on all available data, as other available data would otherwise indicate that a contractor should be dispatched. The contractor finds a small break in the pipeline. Requiring small scale cleaning and requiring the shutting down of the pipe for repairs, but saving tens of millions of dollars. This is just one example of many possible uses of a business operating system, and those skilled in the art can readily formulate more.

Fig. 3 illustrates an exemplary architecture of an auto-planning service clustering and correlation module 300 according to an embodiment of the invention. Seen here is a more detailed view of the auto-planning service module 230 as shown in figure 2. The module functions by receiving business decisions or business risk candidates, along with relevant data currently available and any activity analysis modification commands that are of interest, via the client interface 305. This module may also be used to provide transformed data or operating parameters to the action result simulation module 225 to preset the simulation prior to execution or to transform intermediate result data isolated from one or more actors executing in the action result simulation module 225 during execution of the simulation. Extensive supporting information such as, but not limited to, current business conditions, infrastructure, ongoing risk status, financial status, market conditions, and global events that may affect current decisions or risks, which has been collected by the business operating system as a whole and stored in a data store such as the multidimensional time series database 220, the analysis capabilities of the directed computational graph module 255 and the retrieval capabilities of the Web-based data of the high-volume Web crawler module 215 (all of which may be stored in one or more data stores 320, 325) may also be used during simulation of alternative business decision processes, which may result in the need for example, but not limited to: the method of implementing the timing, ending the change, the order and timing of completion of the components, or selecting another goal without selecting the impact of the currently analyzed action, among other variables.

The action considered may be decomposed into a plurality of constituent events that either tend to fulfill the risk analyzed or the absence of each event is represented by a discrete event simulation module 311, and each of these events is then made available for statistical analysis 312 based on information theory, which makes it possible to analyze the current decision event from similar events under varying dissimilarity conditions using machine learning criteria obtained from previous data; the uncertainty estimation module 313 may analyze the results of this analysis, as well as other factors, to further adjust the confidence level included in the final analysis. The confidence level will be a weighted calculation of the distribution of random variables assigned to each event analyzed. From the perspective of customer business success, the impact of at least a portion of events involved in business risk analyzed within a system that is as small in complexity as the operating microenvironment in which the customer business is located, as large as the area of regional economy, or more, is predicted as calculated in dynamic system extraction and inference module 314, which dynamic system extraction and inference module 314 uses tool algorithms based on Shannon (Shannon) entropy, Hartley (Hartley) entropy, and mutual information dependence theory, among other tool algorithms.

Of great importance in any business decision or new business risk is the amount of business value at risk that results from selecting one decision and not another. Typically, the value is money, but may also be competitive placement, operational efficiency, or based on customer relationships, such as: this may be the effect that may be achieved by maintaining an older, possibly slightly malfunctioning customer relationship management system for an additional quarter instead of replacing it with 1400 thousand dollars and a subscription fee. The automated planning service module has the ability to predict the outcome of such decisions, corresponding to values per unit to be at risk, using programming based on a Monte Carlo (Monte Carlo) heuristic model 316 that allows a single "state" estimation of the value at risk. The amount of computing power required to complete one or more of these business decision analyses is difficult to predict, may vary widely among individual needs, and typically runs simultaneously with several alternatives. Thus, the present invention is designed to run on scalable clusters 315 in a distributed, modular, and scalable manner, such as, but not limited to, that provided by AWS of Amazon corporation. Similarly, these analysis efforts may have to run for many hours to complete, and it is expected that many clients may have to wait long for the simple "how if … …" option, which does not affect their recent business operations, while other clients may have already come to an urgent decision situation that they need to get alternatives as quickly as possible. This is accommodated by: there is a job queue that sets a low to urgent priority that allows analysis jobs to be performed at one of the plurality of priorities. In the event of a change from a more hypothetical analysis job to a more urgent analysis job, the priority-based job queue 318 may also be used to change job priority during run-time without losing progress.

The structured plan analysis results data may be stored in a general purpose automated planning engine executing action symbol modeling language (ANML) scripts for modeling, which may be used to prioritize human and machine oriented tasks to maximize reward functions over a limited time horizon 317, or may be stored by a graph-based data store 245, depending on the details of the analysis in terms of complexity and time running.

The results of the analysis may be sent to one of two presentation modules facing the customer-action result simulation module 225 or more visually simulation capable observation and state estimation module 240, depending on the customer's need for data and the intended use.

FIG. 4 is a system diagram illustrating the connections between the inventive core components for geo-locating and tracking informational physical asset conditions, according to a preferred aspect. The business operating system 410 operates the optimization engine 411, the parameter evaluation engine 412, and reads, modifies, and aggregates operational data using an abstract data representation 413 that includes a Markov State Model (MSM)414 and an abstract representation of a finite state machine 415. Such a business operating system 410 is connected to a network 450, and the network 450 may be an intranet, the internet, a local area network connection, or any of a number of other network configurations. Also connected to the network 450 is at least one database 420 holding information including an encrypted ledger 421, an implementation of blockchain data structures, as will be explained in later figures. At least one of the

cyber-physical assets

430, 440 is connected to the network 450, and the

cyber-physical assets

430, 440 may hold any number of sensors or data depending on the particular implementation and have geoJSON431, 441 data used to record their geo-physical location. The

cyber-physical assets

430, 440 may be transportation crates, to which there may be a plurality of sensors and computers embedded or attached in some manner, or may be items within the crate, such as research equipment, which communicates with the business operating system 410 during transportation, or may be stationary items such as research equipment, computer systems, etc., which are capable of sending status updates including at least geoJSON431, 441 information about their geo-physical location over the network 450. According to a preferred aspect, the business operating system may use a Markov State Model (MSM)414 as a data representation tool for sending the informational physical asset state of the status update in this manner, and may or may not reduce the MSM to a finite state machine representation 415 with or without stochastic elements. These data representations 413 can be used to visualize and analyze the current, previous, and likely future states of the

assets

430, 440 connected to the operating system 410 over the network 450.

FIG. 5 is a method diagram illustrating the key steps in communication between an

cyber-physical asset

430, 440 and a remote server running a business operating system 410, according to a preferred aspect. Any relevant sensors or sensing devices and software must first be installed on the asset before sending the relevant data to business operating system 410 (step 510). Such sensors may include a variety of implementations including temperature sensors, GPS tracking software, accelerometers, or any other sensor, as well as accompanying hardware and software as needed or desired by a user when implementing the system. The

cyber-physical assets

430, 440 will use blockchain technology to maintain the private key and software necessary for the implementation of the cryptographic ledger 421 as part of their software participation in the system (step 520). Blockchain technology is essentially a method of sending secure messages between network connected devices using asymmetric encryption, typically for the purpose of transaction ledgers and intelligent contracts. According to a preferred aspect, the cyber-physical assets will communicate with the business operating system 410 continuously or at set intervals, depending on the implementation (step 530). During these communications, the asset will send a status update based on any sensors installed on the asset using asymmetric encryption in the blockchain encryption ledger (step 530). The business operating system receiving these updates will then validate them with the previous status updates in the database (step 540) to ensure that the received updates are legitimate, not forged, or come from a suspicious source. If the contents of the public key, signature, or encrypted message cannot be properly verified, the ledger maintained in the at least one database is not updated (step 560). If they are properly verified and indicate that they are from a real asset and that the status update is legitimate, any database holding a copy of the encrypted ledger 421 is updated with the new status of the asset (step 550). It will be clear to those skilled in the art that the additionally used update validation process may be a partial update (e.g., where some data is not sent to the server) and that with this partial observability, machine learning techniques may be used to infer missing data between condition updates. To this end, a rules engine may be implemented to determine which rules to apply to infer missing data, depending on the implementation of the system.

FIG. 6 is a method diagram illustrating the key steps in the enterprise operating system 410 to interact with data received from the

cyber-physical assets

430, 440 in the database 420 to validate updates in the cryptographic ledger 421, in accordance with a preferred aspect. Any asset must generate a public key and a private key according to the specification of asymmetric encryption (step 610), which is well known in the art. The asset must be prepared for updating (step 620), which may mean formatting the data received from any installed sensors, performing any relevant calculations or modifications to the raw data, and preparing any network devices for sending data over the network 450. The

cyber-physical asset

430, 440 must sign any updates with its private key (step 630), which encrypts the updates in a way that can only be decrypted using either the private or public key. When the asset connects to the network 450, the asset can send the prepared and encrypted updates to any "node" or computer system running the business operating system 410 to be validated before being added to the ledger 421 (step 640). Any node running the business operating system 410 will attempt to verify the asset status update (step 650) and then verify with the ledger maintained in the at least one database 420 and any other relevant nodes or computer systems using such business operating system 410 that the asset update is legitimate, valid, and should be added to the status update ledger from the asset (step 660). For continuous updates, the system and method may be implemented in an ongoing identification and authentication service, rather than discrete authentication and verification of discrete updates.

FIG. 7 is a method diagram illustrating several steps for using smart contracts in conjunction with cyber-physical assets in accordance with a preferred aspect. As a result of implementing blockchain techniques, such intelligent contracts may not only track and validate entries in the encrypted ledger 421, but also store and execute distributed programs with the goal of implementing "self-enforcing contracts," also known as "intelligent contracts. In this implementation, the intelligent contract is implemented in a Domain Specific Language (DSL), which may be provided by the system provider or specified by the user of the system (step 710). According to a preferred aspect, DSL can be considered a customized programming language and, depending on the implementation, other unmodified implementations of the programming language as well. The condition of the smart contract in the system may be based on the past, present, or future state of the cyber-physical asset monitored by the system (step 720). According to a preferred aspect, the contract program executes upon completion of any conditions programmed into the intelligent contract, and any number of tasks programmed into the computer may be performed, including withdrawing funds, depositing funds, sending a message over the network 450, or other similar results of the executed program (step 730). These parameter-triggered reward agreements are wide and varied in their implementation depending on the needs of the user.

FIG. 8 is a method diagram illustrating key steps in the function of the parameter evaluation engine 412 according to a preferred aspect. The parameter evaluation engine 412 can query the at least one database 420 for a ledger 421, the ledger 421 containing previous or current status updates for the at least one cyber-physical asset 430, 440 (step 810). According to a preferred aspect, the query can be performed across network 450 from a business operating system 410 running on a computer system, and can beIn any database query format, including, for example, MONGODB^TMNOSQL of^TMDatabases, or including MICROSOFT SOLERVER^TMAnd MYSQL^TMSQL of database^TMA database, depending on the desired implementation of the database in the system. The asset condition history may be returned to the parameter valuation engine 412, which is listed in a basic user interface that enables listing and searching of such asset condition update histories (step 820). According to one aspect, to record and examine trends in asset conditions, if desired, asset conditions may be viewed as a temporally continuous history rather than listed separately from one another (step 830).

Hardware architecture

In general, the techniques disclosed herein may be implemented on hardware or a combination of software and hardware. For example, the techniques may be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, on an Application Specific Integrated Circuit (ASIC), or on a network interface card.

A software/hardware hybrid implementation of at least some aspects disclosed herein may be implemented on a programmable network-resident machine (understood to include an intermittently connected network-aware machine) selectively activated or reconfigured by a computer program stored in memory. Such a network device may have multiple network interfaces that may be configured or designed to employ different types of network communication protocols. A general architecture for some of these machines may be described herein to illustrate one or more exemplary devices that may implement a given functional unit. According to particular aspects, at least some features or functions of the various aspects disclosed herein may be implemented on one or more general-purpose computers associated with one or more networks, such as end-user computer systems, client computers, network servers or other server systems, mobile computing devices (e.g., tablet computing devices, mobile phones, smart phones, laptops or other suitable computing devices), consumer electronics devices, music players or any other suitable electronic devices, routers, switches or other suitable devices, or any combination thereof. In at least some aspects, at least some of the features or functionality of the various aspects disclosed herein may be implemented in one or more virtualized computing environments (e.g., a network computing cloud, virtual machines hosted on one or more physical computers, or other suitable virtual environment).

Referring now to fig. 9, there is shown a block diagram depicting an exemplary computing device 10 suitable for implementing at least a portion of the features or functionality disclosed herein. Computing device 10 may be, for example, any of the computers listed in the preceding paragraph, or indeed any other electronic device capable of executing software-or hardware-based instructions according to one or more programs stored in memory. Computing device 10 may be configured to communicate with a plurality of other computing devices, such as clients or servers, over a communication network, such as a wide area network, a metropolitan area network, a local area network, a wireless network, the internet, or any other network, using known protocols for wireless or wired communication.

In one embodiment, computing device 10 includes one or more Central Processing Units (CPUs) 12, one or more interfaces 15, and one or more buses 14, such as a Peripheral Component Interconnect (PCI) bus. When acting under the control of appropriate software or firmware, the CPU12 may be responsible for implementing specific functions associated with the functions of a particular configured computing device or machine. For example, in at least one embodiment, computing device 10 may be configured or designed to function as a server system that employs CPU12, local memory 11 and/or remote memory 16, and interface 15. In at least one embodiment, the CPU12 may be caused to perform one or more of various types of functions and/or operations under the control of software modules or components, which may include, for example, an operating system and any appropriate application software, drivers, and the like.

The CPU12 may include one or more processors 13, such as a processor from one of the Intel, ARM, high pass, and AMD microprocessor families. In some embodiments, theProcessor 13 may include specially designed hardware, such as an Application Specific Integrated Circuit (ASIC), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Field Programmable Gate Array (FPGA), or the like, for controlling the operation of computing device 10. In particular embodiments, local memory 11 (e.g., non-volatile Random Access Memory (RAM) and/or Read Only Memory (ROM), including, for example, one or more levels of cache memory) may also form part of CPU 12. However, there are many different ways in which memory may be coupled to system 10. Memory 11 may be used for various purposes such as, for example, caching and/or storing data, programming instructions, etc. It should also be understood that the CPU12 may be one of a variety of system-on-a-chip (SOC) type hardware, which may include additional hardware, such as a memory or graphics processing chip, such as a QUALCOMM SSNAPPARDAGON^TMOr SAMSUNG EXYNOS^TMCPUs, which are becoming more and more common in the art, for example for mobile devices or integrated devices.

As used herein, the term "processor" is not limited to just those integrated circuits referred to in the art as a processor, a mobile processor, or a microprocessor, but broadly refers to a microcontroller, a microcomputer, a programmable logic controller, an application specific integrated circuit, and any other programmable circuit.

In one embodiment, the interface 15 is provided as a Network Interface Card (NIC). Generally, a NIC controls the transmission and reception of data packets over a computer network; other types of interfaces 15 are, for example, other peripheral devices that may be supported for use with computing device 10. Among the interfaces that may be provided are ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, graphics interfaces, and the like. In addition, various types of interfaces may be provided, such as Universal Serial Bus (USB), Serial, Ethernet, FIREWIRE^TM、THUNDERBOLT^TMPCI, parallel, Radio Frequency (RF), BLUETOOTH^TMNear field communication (e.g., using near field magnetism), 802.11(WiFi), frame relay, TCP/IP, ISDN, fast Ethernet interface, gigabit Ethernet interface, Serial ATA (SATA) or External SATA (ESATA) interface, High Definition Multimedia Interface (HDMI), Digital Video Interface (DVI), analog or digital audio interface, asynchronousTransmission Mode (ATM) interfaces, High Speed Serial Interface (HSSI) interfaces, point of sale (POS) interfaces, Fiber Data Distribution Interfaces (FDDI), and the like. Generally, such an interface 15 may comprise a physical port adapted to communicate with an appropriate medium. In some cases, they may also include a separate processor (e.g., a dedicated audio or video processor, as is common in the art for high fidelity a/V hardware interfaces), and in some cases, volatile and/or non-volatile memory (e.g., RAM).

Although the system shown in fig. 9 illustrates one particular architecture of a computing device 10 for implementing one or more of the inventions described herein, this is by no means the only device architecture on which at least a portion of the features and techniques described herein may be implemented. For example, an architecture having one or any number of processors 13 may be used, and such processors 13 may reside in a single device or be distributed among any number of devices. In one embodiment, a single processor 13 handles both communication and routing computations, while in other embodiments separate dedicated communication processors may be provided. In various embodiments, different types of features or functions may be implemented in a system according to the present invention, including a client device (e.g., a tablet device or smartphone running client software) and a server system (e.g., a server system described in more detail below).

Regardless of network device configuration, the inventive system may employ one or more memories or memory modules (e.g., remote memory block 16 and local memory 11) configured to store data, programming instructions for the general-purpose network operations, or other information relating to the functionality of the embodiments described herein (or any combination thereof). For example, the programming instructions may control the execution of or include an operating system and/or one or more application programs. Memory 16 or memories 11, 16 may also be configured to store data structures, configuration data, encryption data, historical system operating information, or any other specific or general purpose non-program information described herein.

Because such information and programming instructions may be employed to implement one or more systems or methods described herein, at least some network device embodiments may include a non-transitory machine-readable storage medium, which may be configured or designed, for example, to store programming instructions, state information, etc. for performing various operations described herein. Examples of such non-transitory machine-readable storage media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media, such as CD-ROM disks; magneto-optical media, such as optical disks, and hardware devices specially configured to store and execute programming instructions, such as read-only memory devices (ROMs), flash memory (as is common in mobile devices and integrated systems), Solid State Drives (SSDs), and "hybrid SSD" storage drives that can combine the physical components of a solid state drive and a hard disk drive in a single hardware device (as is becoming increasingly common in the art for personal computers and the like), memristor memory, Random Access Memory (RAM), and the like. It should be understood that such storage devices may be integrated and non-removable (e.g., RAM hardware modules that may be soldered onto a motherboard or otherwise integrated into an electronic device), or they may be removable, e.g., exchangeable flash memory modules (such as "thumb drives" or other removable media designed for fast swap physical storage devices), "hot swappable" hard or solid state drives, removable optical storage disks, or other such removable media, and that such integrated and removable storage media may be used interchangeably. Examples of programming instructions include object code, such as may be generated by a compiler, machine code, such as may be generated by an assembler or linker, and programming instructions, such as may be generated by, for example, JAVA^TMA compiler generated bytecode, and may use a Java virtual machine or equivalent, or use a file containing higher level code that may be executed by the computer using an interpreter (e.g., a script written in Python, Perl, Ruby, Groovy, or any other scripting language) to execute the programming instructions.

In some embodiments, a system in accordance with the present invention may be on a stand-alone computing systemAnd (5) realizing. Referring now to fig. 10, there is shown a block diagram depicting a general exemplary architecture of one or more embodiments, or components thereof, on a stand-alone computing system. Computing device 20 includes a processor 21 that may run software that performs one or more functions or applications of embodiments of the present invention (e.g., client application 24). The processor 21 may execute computing instructions under the control of an operating system 22, such as MICROSOFT WINDOWS, the operating system 22^TMOperating system, APPLE OSX^TMOr iOS^TMVersion of operating system, Linux operating system, and ANDROID^TMSome modification of the operating system, etc. In many cases, one or more shared services 23 may operate in system 20 and may be used to provide common services to client applications 24. The service 23 may be WINDOWS, for example^TMA service, a user space common service in a Linux environment, or any other type of common service architecture used with the operating system 21. The input device 28 may be of any type suitable for receiving user input, including, for example, a keyboard, a touch screen, a microphone (e.g., for voice input), a mouse, a touchpad, a trackball, or any combination thereof. Output device 27 may be of any type suitable for providing output to one or more users remote or local to system 20, and may include, for example, one or more screens for visual output, speakers, printers, or any combination thereof. The memory 25 may be a random access memory having any structure and architecture known in the art for use by the processor 21, such as to run software. The storage device 26 may be any magnetic, optical, mechanical, memristor, or electrical storage device for storing data in digital form (such as those described above with reference to FIG. 9). Examples of storage device 26 include flash memory, magnetic hard drives, CD-ROMs, and the like.

In some embodiments, the system of the present invention may be implemented on a distributed computing network, such as a distributed computing network having any number of clients and/or servers. Referring now to FIG. 11, there is shown a block diagram depicting an exemplary architecture 30 for implementing at least a portion of a system in accordance with embodiments of the invention on a distributed computing network. Any number of clients 33 may be provided according to this embodiment. Each client 33 may run software for implementing the client-side portion of the present invention; the client may include a system 20 such as that shown in fig. 10. In addition, any number of servers 32 may be provided to handle requests received from one or more clients 33. The client 33 and server 32 may communicate with each other via one or more electronic networks 31, and in various embodiments, the electronic network 31 may be any of the internet, a wide area network, a mobile telephone network (e.g., a CDMA or GSM cellular network), a wireless network (e.g., WiFi, WiMAX, LTE, etc.), or a local area network (virtually any network topology known in the art; none of which is preferred by the present invention). Network 31 may be implemented using any known network protocol, including for example wired and/or wireless protocols.

Additionally, in some embodiments, the server 32 may invoke the external service 37 when additional information needs to be obtained or additional data about a particular invocation is referenced. Communication with external services 37 may occur, for example, via one or more networks 31. In various embodiments, the external services 37 may include Web services or functions associated with or installed on the hardware device itself. For example, in embodiments where client application 24 is implemented on a smartphone or other electronic device, client application 24 may obtain information stored within server system 32 in the cloud or on external services 37 deployed within one or more business residences of a particular enterprise or user.

In some embodiments of the invention, client 33 or server 32 (or both) may employ one or more dedicated services or devices that may be deployed locally or remotely over one or more networks 31. For example, one or more embodiments of the invention may use or reference one or more databases 34. It will be appreciated by those of ordinary skill in the art that the database 34 may be provided in a variety of architectures and using a variety of data access and manipulation devices. For example, in various embodiments, one or more of databases 34 may comprise a relational database system using the structured query language (SQL language), while other databases may comprise alternative data storage techniquesFor example, referred to in the art as "NoSQL" (e.g., HADOOP casasandra)^TM、GOOGLE BIGTABLE^TMEtc.). In some embodiments, different database architectures may be used in accordance with the present invention, such as column-oriented databases, in-memory databases, clustered databases, distributed databases, or even flat file databases. One of ordinary skill in the art will appreciate that any combination of known or future database technologies may be used as appropriate, unless a particular database technology or a particular arrangement of components is specified for a particular embodiment herein. Further, it should be understood that the term "database" as used herein may refer to a physical database machine, a cluster of machines as a single database system, or a logical database within an overall database management system. Unless a specific meaning is specified for a given use of the term "database," it should be construed as meaning any of those meanings of the word, all of which are understood by those of ordinary skill in the art as the ordinary meaning of the term "database.

Similarly, most embodiments of the invention may utilize one or more security systems 36 and configuration systems 35. Security and configuration management is a conventional Information Technology (IT) and Web function, and a certain amount of security or configuration management is typically associated with any IT or Web system. It should be understood by those of ordinary skill in the art that any configuration or security subsystem now known in the art or in the future may be used in conjunction with embodiments of the present invention without limitation, unless the description of a particular embodiment specifically requires a particular security system 36, configuration system 35, or method.

FIG. 12 shows an exemplary overview of the computer system 40, which computer system 40 may be used in any of a variety of locations throughout the system. Which is an example of any computer that can execute code to process data. Various modifications and changes may be made to computer system 40 without departing from the broader scope of the systems and methods disclosed herein. A Central Processing Unit (CPU)41 is connected to a bus 42, and a memory 43, a nonvolatile memory 44, a display 47, an input/output (I/O) unit 48, and a Network Interface Card (NIC)53 are also connected to the bus 42. The I/O unit 48 may typically be connected to a keyboard 49, a pointing device 50, a hard disk 52 and a real time clock 51. NIC 53 is connected to a network 54, network 54 may be the internet or a local network, which may or may not have a connection to the internet. In this example, a power supply unit 45 is also shown as part of the system 40, the power supply unit 45 being connected to a main Alternating Current (AC) power supply 46. Not shown are batteries that may be present, as well as many other devices and modifications that are well known but not suitable for the particular novel functionality of the present systems and methods disclosed herein. It should be appreciated that some or all of the illustrated components may be combined, for example, in various integrated applications, such as a system-on-a-chip (SOC) device from the university or samsung corporation, or, where appropriate, multiple capabilities or functions may be combined into a single hardware device (e.g., in a mobile device, such as a smartphone, video game console, in an in-vehicle computer system, such as a navigation or multimedia system for a car, or in other integrated hardware devices).

In various embodiments, the functionality for implementing the systems or methods of the present invention may be distributed among any number of client and/or server components. For example, various software modules may be implemented to perform various functions associated with the present invention and may be implemented in various ways to run on server and/or client components.

Those skilled in the art will appreciate the scope of possible modifications to the various embodiments described above. Therefore, the invention is defined by the claims and their equivalents.

Claims

1. A system for dynamic geospatially referenced information physical infrastructure inventory and asset management, comprising:

at least one cyber-physical asset, the cyber-physical asset comprising at least a processor, a memory, and a first plurality of programming instructions stored in the memory and executed on the processor, wherein the programming instructions, when executed on the processor, cause the processor to:

executing the software kernel;

wherein the software kernel can execute other software according to the requirement;

receiving an input;

sending the output over a network;

a database comprising at least a processor, a memory, and a second plurality of programming instructions stored in the memory and executed on the processor, wherein when executed on the processor, the second programming instructions cause the processor to:

receiving data over a network;

recording the relation data;

receiving a query over a network;

wherein the query is output data derived from the query;

a parameter evaluation engine comprising at least a processor, a memory, and a third plurality of programming instructions stored in the memory and executed on the processor, wherein when executed on the processor, the third programming instructions cause the processor to:

querying a database through a network; and

and displaying the data obtained by the query on a user interface.

2. The system of claim 1, wherein the parameter evaluation engine is hosted on a remote server.

3. The system of claim 1, wherein the database is a multidimensional time series database capable of asynchronously receiving data from a plurality of sources over a period of time and building graph sequence data structures using the received data.

4. The system of claim 1, wherein the encrypted ledger is stored in a database containing records of previous informational physical asset status updates.

5. A method for dynamic geospatially referenced information physical infrastructure inventory and asset management, comprising the steps of:

installing a sensor on the cyber-physical asset;

generating a public key and a private key for encrypting the ledger using the cyber-physical assets;

communicating with the business operating system using the business operating system and the cyber-physical asset to obtain an initial asset condition;

using the business operating system, the information physical assets and the network, sending a status update to the business operating system;

verifying asset condition updates using a database and a business operating system; and is

And recording the verified status update by using the database, the business operating system and the information physical assets.

6. The method of claim 5, wherein the parameter evaluation engine is hosted on a remote server.

7. The method of claim 5, wherein the database is a multi-dimensional time series database capable of asynchronously receiving data from multiple sources over a period of time and building graph sequence data structures using the received data.

8. The method of claim 5, wherein the encrypted ledger is stored in a database containing a record of previous informational physical asset status updates.