Field system

Abstract

A method may include operating a field system using a first partition as an active partition and a second partition as an inactive partition; in response to receiving the system update, changing the boot loader configuration from the first partition to a second partition; performing a root of trust measurement on the update, wherein the measurement takes into account at least a change in the boot loader configuration; in response to establishing trust via the measurement, accessing the encryption key; decrypting the at least second partition using the encryption key for use by the system; and in response to detecting the system update problem, using the second partition as an active partition and using the first partition as an inactive partition to restart the field system for system rollback.

Description

[0001] Related Applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 411,760, filed Sep. 30, 2022, which is hereby incorporated by reference in its entirety. Background Art

[0003] A field system can include one or more various types of field devices that can be used at a field site. For example, consider a flow meter that can measure the flow rate of a fluid at a well site. In such an example, the flow meter can include or be operably coupled to a microcontroller, such as a processor having an associated memory, that can store instructions for the microcontroller to execute to perform one or more tasks. Summary of the Invention

[0004] A method may include: operating a live system using a first partition as the active partition and a second partition as the inactive partition; in response to receiving a system update, changing the bootloader configuration from the first partition to the second partition; performing a root of trust measurement on the update, where the measurement takes into account at least the change in the bootloader configuration; in response to establishing trust via the measurement, accessing an encryption key; using the encryption key to decrypt at least the second partition for use by the system; and in response to detecting a system update problem, restarting the live system using the second partition as the active partition and the first partition as the inactive partition for system rollback. The system may include one or more processors; a memory accessible to at least one of the one or more processors; processor-executable instructions stored in the memory and executable to command the system to: operate a live system using a first partition as the active partition and a second partition as the inactive partition; in response to receiving a system update, change the bootloader configuration from the first partition to the second partition; perform a root of trust measurement on the update, where the measurement takes into account at least the change in the bootloader configuration; in response to establishing trust, access an encryption key; use the encryption key to decrypt at least the second partition for use by the system; and in response to detecting a system update problem, restart the live system using the second partition as the active partition and the first partition as the inactive partition for system rollback. One or more computer-readable storage media may include processor-executable instructions to command a computing system to: operate a live system using a first partition as the active partition and a second partition as the inactive partition; in response to receiving a system update, change the bootloader configuration from the first partition to the second partition; perform a root of trust measurement on the update, where the measurement takes into account at least the change in the bootloader configuration; in response to establishing trust, access an encryption key; use the encryption key to decrypt at least the second partition for use by the system; and in response to detecting a system update problem, restart the live system using the second partition as the active partition and the first partition as the inactive partition for system rollback. Various other devices, systems, methods, etc. are also disclosed.

[0005] The present invention content is provided to introduce a series of concepts that will be further described in the following detailed description. The present invention content is not intended to identify the key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The features and advantages of the described implementations can be more readily understood by reference to the following description in conjunction with the accompanying drawings.

[0007] Figure 1 An example of the system is shown;

[0008] Figure 2An example of the system is shown;

[0009] Figure 3 An example of the system is shown;

[0010] Figure 4 An example of the system is shown;

[0011] Figure 5 An example of the system is shown;

[0012] Figure 6 An example of the system is shown;

[0013] Figure 7 An example of the workflow is shown;

[0014] Figure 8 An example of the workflow is shown;

[0015] Figure 9 An example of the method is shown;

[0016] Figure 10 An example of the controller is shown; and

[0017] Figure 11 An example of the computer and network devices is shown. Detailed Description

[0018] The following description includes the best mode currently contemplated for practicing the described implementations. This description should not be construed in a limiting sense, but merely to describe the general principles of the implementations. The scope of the described implementations should be determined with reference to the published claims.

[0019] Figure 1 An example of a system 100 including a workspace framework 110 is shown, which can provide instantiation, presentation, interaction with the graphical user interface (GUI) 120, etc. In Figure 1 the example of, the GUI 120 can include graphical controls for a computing framework (e.g., an application) 121, a project 122, a visualization 123, one or more other features 124, data access 125, and data storage 126.

[0020] In Figure 1In the example, the workspace framework 110 can be customized for a specific geological environment (such as the example geological environment 150). For example, the geological environment 150 can include multiple layers (e.g., stratified), the multiple layers including a reservoir 151 and can intersect with a fault 153. As an example, the geological environment 150 can be equipped with various sensors, detectors, predictors, actuators, etc. For example, the device 152 can include communication circuitry for receiving and transmitting information relative to one or more networks 155. Such information can include information associated with downhole equipment 154, which can be equipment for obtaining information, assisting in resource recovery, etc. Other devices 156 can be located at positions remote from the well site and include sensing, detecting, predicting, transmitting, or other circuitry. Such devices can include storage and communication circuitry for storing and transferring data, instructions, etc. As an example, one or more satellites can be provided for purposes such as communication, data collection, etc. For example, Figure 1 A satellite communicating with the network 155 that can be configured for communication is shown. Note that the satellite can additionally or alternatively include circuitry for imaging (e.g., spatial, spectral, temporal, radioactive, etc.).

[0021] Figure 1 The geological environment 150 is also shown as optionally including equipment 157 and 158 associated with a well, the well including a substantially horizontal portion that can intersect with one or more fractures 159. For example, consider a well in a shale formation, which can include natural fractures, artificial fractures (e.g., hydraulic fractures), or a combination of natural and artificial fractures. As an example, a laterally extending reservoir can be drilled. In such an example, there can be lateral variations in properties, stresses, etc., where the assessment of such variations can assist in planning, operations, etc. to develop the laterally extending reservoir (e.g., via fracturing, injection, extraction, etc.). As an example, the equipment 157 and / or 158 can include multiple components, a system, or multiple systems for fracturing, seismic sensing, seismic data analysis, assessing one or more fractures, etc.

[0022] In Figure 1 the example, the GUI 120 shows some examples of computational frameworks, including the DRILLPLAN, DRILLOPS, PETREL, TECHLOG, PETROMOD, ECLIPSE, and INTERSECT frameworks (SLB, Houston, Texas).

[0023] The DRILLPLAN framework is used for digital well construction planning and includes multiple features for automating repetitive tasks and verification workflows, enabling the rapid generation of improved quality drilling programs (e.g., digital drilling plans, etc.) while ensuring consistency.

[0024] The DRILLOPS framework can execute digital drilling plans and ensure plan compliance while providing goal-based automation. The DRILLOPS framework can automatically generate activity plans for various operations, whether they are monitored and / or controlled on the rig or in the town. The automation can utilize data analysis and learning systems to assist and optimize tasks, such as, for example, setting the ROP to drill a stand. A preset menu of drillable tasks can be presented, and using data analysis and models, the plan can be executed in a way to achieve the specified goals, where, for example, measurements can be used for calibration. The DRILLOPS framework provides flexibility to dynamically modify and replan activities, for example, based on real-time assessments of various factors such as equipment, personnel, and supplies. Well construction activities (such as tripping, drilling, cementing, etc.) can be continuously monitored and dynamically updated using feedback from operational activities. The DRILLOPS framework can provide various levels of automation based on planning and / or replanning (e.g., via the DRILLPLAN framework), feedback, etc.

[0025] The PETREL framework can be part of the DELFI Cognitive Exploration and Production (E&P) environment (SLB, Houston, Texas, known as the DELFI environment) and is used, for example, in geoscience and geomechanics to analyze subsurface data from exploration to production of fluids from a reservoir.

[0026] One or more types of frameworks can be implemented within the DELFI environment or in a manner operatively coupled to the DELFI environment, which is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows using digital technologies such as artificial intelligence (AI) and machine learning (ML). As an example, such an environment can provide operations involving one or more frameworks. The DELFI environment can be referred to as the DELFI framework, which can be one of the multiple frameworks. As an example, the DELFI framework can include various other frameworks, which can include, for example, one or more types of models (e.g., simulation models, etc.).

[0027] The TECHLOG framework can handle and process field and laboratory data for various geological environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework can structure wellbore data for analysis, planning, etc.

[0028] The PIPESIM simulator includes a solver that can provide simulation results such as, for example, multiphase flow results (e.g., from the reservoir to the wellhead and beyond, etc.), flowline and surface facility performance, etc. The PIPESIM simulator can be integrated, for example, with the AVOCET production operations framework (SLB, Houston, Texas). As an example, one or more reservoirs can be simulated with respect to one or more enhanced recovery techniques (e.g., considering thermal processes such as steam-assisted gravity drainage (SAGD), etc.). As an example, the PIPESIM simulator can be an optimizer that can at least partially optimize one or more operating scenarios by simulating physical phenomena.

[0029] The ECLIPSE framework provides numerical solutions for reservoir simulators (e.g., as a computational framework) to quickly and accurately predict the dynamic behavior of various types of reservoirs and development scenarios.

[0030] The INTERSECT framework provides a high-resolution reservoir simulator for simulating detailed geological features and quantifying uncertainties. For example, by creating accurate production scenarios, and when integrating precise models of surface facilities and field operations, the INTERSECT framework can produce reliable results that can be continuously updated through real-time data exchange (e.g., data from one or more types of data acquisition devices in the field that can acquire data during one or more types of field operations, etc.). The INTERSECT framework can provide completion configurations for complex wells, where such configurations can be built in the field; can provide detailed chemical enhanced oil recovery (EOR) formulations, where such formulations can be implemented in the field; can analyze the application of steam injection and other thermal EOR techniques for advanced production control in reservoir connectivity and flexible field management in the field, and the flexibility to write custom solutions for improved modeling and field management control. Like other example frameworks, the INTERSECT framework can be used as part of the DELFI cognitive E&P environment, for example, for rapid simulation of multiple concurrent cases. For example, the workflow can utilize one or more of the DELFI on-demand reservoir simulation features.

[0031] The aforementioned DELFI environment provides various features for workflows related to subsurface analysis, planning, construction, and production, as shown, for example, in the workspace framework 110. As Figure 1 shown, the output from the workspace framework 110 can be used to guide, control, etc., one or more processes in the geological environment 150, and feedback 160 (e.g., data obtained regarding operating conditions, equipment conditions, environmental conditions, etc.) can be received via one or more forms of one or more interfaces.

[0032] As an example, the workflow can proceed to a geology and geophysics (“G&G”) service provider, which can generate a well trajectory, which may involve the execution of one or more G&G software packages.

[0033] In Figure 1 example, the visualization feature 123 can be implemented via the workspace framework 110, for example, to perform tasks associated with one or more of the subsurface area, planned operations, building a well and / or surface fluid network, and production from a reservoir.

[0034] As an example, the visualization process can implement one or more of a variety of features that can be suitable for one or more web applications. For example, the template may involve using JavaScript Object Notation format (JSON) and / or one or more other languages / formats. As an example, the framework can include one or more converters. For example, consider a JSON to Python converter and / or a Python to JSON converter. In this approach, one or more features of the framework implemented in one language may be accessible via the converter. For example, consider the Apache Spark framework, which can include features that can be implemented in a specific language, where the converter can convert code in another language to the specific language such that one or more of the features can be utilized. As an example, a production site can include various types of equipment that can be operated using various frameworks, etc., where one or more languages can be utilized. In such an example, the converter can provide feature flexibility and / or compatibility.

[0035] As an example, the visualization feature can provide visualization of various earth models, properties, etc. in one or more dimensions. As an example, the visualization feature can provide the presentation of information in multiple dimensions, which may optionally include multi-resolution presentation. In such an example, the information being presented may be associated with one or more frameworks and / or one or more data stores. As an example, the visualization feature can include one or more control features for controlling equipment, which can include, for example, downhole equipment that can perform one or more downhole operations. As an example, the workflow can utilize one or more frameworks to generate information that can be used to control one or more types of downhole equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).

[0036] While in Figure 1Several simulators are illustrated in the example, but additionally or alternatively, one or more other simulators may be utilized. For example, consider the VISAGE geomechanics simulator (SLB, Houston, Texas) or the PETROMOD simulator (SLB, Houston, Texas), etc. The VISAGE simulator includes a finite element numerical solver that can provide simulation results such as, for example, results regarding compaction and settlement of a geological environment, well and completion integrity in a geological environment, caprock and fault seal integrity in a geological environment, fracturing behavior in a geological environment, thermal oil recovery in a geological environment, CO 2 disposal, etc. The PETROMOD framework provides petroleum system modeling capabilities that can incorporate one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework can predict whether and how a reservoir is filled with hydrocarbons, including the source and timing of hydrocarbon generation, migration routes, amounts, and hydrocarbon types under subsurface or surface conditions. The MANGROVE simulator (SLB, Houston, Texas) optimizes stimulation designs (e.g., stimulation treatment operations such as hydraulic fracturing) in a reservoir-centered environment. The MANGROVE framework can combine scientific and experimental work to predict the geomechanical propagation of hydraulic fractures, reactivation of natural fractures, etc., as well as production predictions within a 3D reservoir model (e.g., production from the drainage area of a reservoir where fluid moves into and / or out of a well via one or more types of fractures). The MANGROVE framework can provide results related to the heterogeneous interaction between a hydraulic fracture network and a natural fracture network, which may help optimize the number and location of fracture treatment stages (e.g., stimulation treatments), for example, to improve perforation efficiency and production.

[0037] Figure 2 An example of a geological environment 210 including reservoirs 211-1 and 211-2, which may be faulted by faults 212-1 and 212-2; an example of an equipment network 230; an enlarged view of a portion of the equipment network 230 referred to as network 240; and an example of a system 250. Figure 2 Some examples of offshore equipment 214 for oil and gas operations related to reservoir 211-2 and onshore equipment 216 for oil and gas operations related to reservoir 211-1 are shown. In Figure 2 the example, the geological environment 210 may include fluids such as oil (o), water (w), and gas (g), which may be stratified in reservoirs 211-1 and 211-2.

[0038] In Figure 2In the example, devices 214 and 216 can include drilling equipment, cable equipment, production equipment, etc. For example, consider device 214 includes a drilling rig that can drill into a formation to reach a reservoir target where a well can be completed to produce hydrocarbons. As an example, device 216 can include production equipment such as wellheads, valves, pumping equipment, gas treatment equipment, separators, flow meters, etc. As an example, Figure 1 One or more features of system 100 can be used for operations in geological environment 210. For example, consider using a drilling or drilling planning framework, a drilling execution framework, a production framework, etc. to plan, execute, etc. one or more drilling operations, production operations, etc.

[0039] In Figure 2 the example, network 240 can be an example of a relatively small production system network. As shown, network 240 forms a kind of tree structure where the flowlines represent branches (e.g., segments) and the connection points represent nodes. As Figure 2 shown, network 240 provides the transportation of fluids (e.g., oil, water, and / or gas) from well locations along the flowlines interconnected at the connection points and ultimately to a central processing facility (CPF). In cases where the fluid includes solids (e.g., sand, etc.), one or more devices can be used for the removal, collection, etc. of the solids.

[0040] In Figure 2 the example, the various parts of network 240 can include pipelines. For example, consider a perspective view of a geological environment including two pipelines, which can be pipelines leading to Man1 and Man3 in network 240, where Man1, Man2, and Man3 are manifolds.

[0041] As Figure 2As shown, the example system 250 includes one or more information storage devices 252, one or more computers 254, one or more networks 260, and instructions 270 (e.g., organized as one or more sets of instructions). Regarding the one or more computers 254, each computer may include one or more processors (e.g., or processing cores) 256 and a memory 258 for storing the instructions 270 (e.g., one or more sets of instructions), which instructions are, for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc. As an example, images, such as surface images (e.g., satellite, geological, geophysical, etc.), may be stored, processed, transmitted, etc. As an example, data may include SAR data, GPS data, etc., and may be stored, for example, in one or more of the storage devices 252. As an example, information that may be stored in one or more of the storage devices 252 may include information about equipment, equipment location, equipment orientation, fluid characteristics, etc.

[0042] As an example, the instructions 270 may include instructions (e.g., stored in the memory 258) executable by at least one of the one or more processors 256 to command the system 250 to perform various actions. As an example, the system 250 may be configured such that the instructions 270 provide a framework for establishing, for example, a network modeling and / or other modeling (see, for example, Figure 1 the PIPESIM framework, etc., of the examples of Figure 2 ). As one example, one or more sets of instructions may be used to perform one or more methods, techniques, etc., which instructions may be, for example,

[0043] As an example, Figure 2 the various graphics in

[0044] Figure 3 may be part of a graphical user interface (GUI), which may be generated using executable instructions that may be executed locally and / or remotely using local and / or remote display devices (e.g., mobile devices, workstations, etc.).

[0044] Figure 3 An example of a portion of a geological environment 301 is shown, which may include various types of equipment. As Figure 3 shown, the environment 301 may include a well site 302 and a fluid network 344. In Figure 3 the example of

[0045] In Figure 3In the example, the wellbore production equipment 364 extends from the wellhead 366 of the well site 302 to the reservoir 311 to pump fluid to the surface. As shown, the well site 302 is operatively connected to the fluid network 344 via the transportation pipeline 361. As indicated by various arrows, the fluid can flow from the reservoir 311 through the wellbore 306 and onto the fluid network 344. Then, the fluid can flow from the fluid network 344 to, for example, one or more fluid treatment facilities.

[0046] In Figure 3 the example, the sensor (S) is positioned, for example, to monitor various parameters during operation. The sensor (S) can measure, for example, pressure, temperature, flow rate, composition, and other parameters of the reservoir, wellbore, collection network, treatment facility, and / or other parts of the operation. As an example, the sensor (S) is operatively connected to a surface unit (e.g., to command the sensor to acquire data, collect data from the sensor, etc.).

[0047] In Figure 3 the example, the surface unit can include computer facilities such as memory devices, controllers, one or more processors, and display units (e.g., for managing data, visualizing analysis results, etc.). As an example, data can be collected in the memory device and processed by the processor (e.g., for analysis, etc.). As an example, data can be collected from the sensor (S) and / or through one or more other sources. For example, the data can be supplemented with historical data collected from other operations, user inputs, etc. As an example, the analyzed data can be used in the decision-making process.

[0048] As an example, a transceiver can be provided to allow communication between the surface unit and one or more devices in the environment 301. For example, the controller can be used to optionally activate multiple mechanisms in the environment 301 via the transceiver based on one or more decisions of the decision-making process. In this way, the devices in the environment 301 can be selectively adjusted at least partially based on the collected data. Such adjustments can be made automatically, for example, based on computer protocols, manually by an operator, or both. As an example, one or more well plans can be adjusted (e.g., to select optimal operating conditions, avoid problems, etc.).

[0049] To facilitate data analysis, one or more simulators can be implemented (e.g., optionally via the surface unit or other units, systems, etc.). As an example, the data fed into one or more simulators may be historical data, real-time data, or a combination thereof. As an example, the simulation via one or more simulators can be repeated or adjusted based on the received data.

[0050] In Figure 3In an example, the simulator may include a reservoir simulator 328, a wellbore simulator 330, a surface network simulator 332, a process simulator 334, and an economic simulator 336. As an example, the reservoir simulator 328 may be configured to solve for hydrocarbon flow rates through a reservoir and into one or more wellbores. As an example, the wellbore simulator 330 and the surface network simulator 332 may be configured to solve for hydrocarbon flow rates through the wellbore and the surface collection network of pipelines. Regarding the process simulator 334, it may be configured to model a processing plant where a fluid containing hydrocarbons is separated into, for example, its components (e.g., methane, ethane, propane, etc.) and prepared for further distribution (e.g., transported via road, rail, pipe, etc.) and optionally sale. As an example, the economic simulator 336 may be configured to model costs associated with at least a portion of the operation. For example, consider the MERAK framework (Schlumberger, Houston, Texas), which may provide economic analysis.

[0051] As an example, the system may include and / or be operatively coupled to Figure 3 one or more of the simulators 328, 330, 332, 334, and 336. As an example, such simulators may be associated with a framework and / or may be considered tools (see, for example Figure 1 system 100, etc.). Figure 3 In an example geological environment 301, various devices may be operatively coupled to one or more systems, one or more frameworks, etc. As an example, one or more of the sensors (S) may be operatively coupled to one or more networks (e.g., wired and / or wireless) to transmit data, which, as explained, may include data indicative of production. As shown, the sensors (S) may be used to acquire downhole data and / or surface data, which may include data related to production (e.g., flow rate, temperature, pressure, composition, etc.). Such data may be used in a system (such as, for example Figure 1 system 100) for making operational decisions, etc.

[0052] As an example, the system may utilize one or more cloud services to perform various tasks, where the cloud services may communicate with local services at one or more well sites. As an example, various features may be local and / or remote. As an example, the system may include and / or utilize features of one or more cloud platforms (e.g., Google Cloud, Amazon Web Services Cloud, Azure Cloud, etc.). As an example, the DELFI Cognitive Exploration and Production (E&P) environment may be implemented at least in part in a cloud platform.

[0053] As an example, the system can provide various types of simulations, such as reservoir simulation, wellbore simulation, surface network simulation, integrated simulation, etc. As an example, field devices can include sensors that can acquire measurements, where such measurements can be utilized locally and / or remotely. For example, consider measurements such as derived flow rates, surrogate models, simulation models, etc. that can be obtained.

[0054] Figure 4 An example of the system 400 and an example of the architecture 401 are shown. As shown, the architecture 401 can serve one or more sites. For example, the architecture 401 can generate one or more results (e.g., control actions, etc.) that can be used for field operations. In such an example, the one or more results can be generated locally and / or remotely (e.g., depending on the number of sites, resources, etc.). As shown, the architecture 401 can include one or more models. The architecture 401 can include one or more physical models, one or more machine learning models, etc. As shown, the architecture 401 includes an interface for real-time data and optionally an interface for transient data and calibration components. The results component can include a results interface, where the output results can be control triggers, control instructions, etc., and these results can invoke one or more actions of one or more devices.

[0055] As shown, the system 400 can include a power source 402 (e.g., solar, generator, power grid, etc.), which can provide power to the edge framework gateway 410, and the edge framework gateway can include one or more computing cores 412 and one or more media interfaces 414. The one or more media interfaces can receive, for example, a computer-readable medium 440, and the computer-readable medium can include one or more data structures, such as an image 442, a framework 444, and data 446. In such an example, the image 442 can be an operating system image that can enable one or more of the one or more cores 412 to establish an operating system environment suitable for executing one or more applications. For example, the framework 444 can be an application suitable for execution in the operating system established in the edge framework gateway 410. As an example, the framework 444 can be suitable for executing tasks associated with the architecture 401. For example, consider tasks associated with utilizing one or more models, setting one or more parameters, generating one or more results at least partially based on one or more models, etc.

[0056] In Figure 4In the example, the Edge Frame Gateway 410 ("EF") can include one or more types of interfaces suitable for receiving and / or transmitting information. For example, consider one or more wireless interfaces that can provide local communication at a site (such as local communication with one or more of the local devices 432, 434, and 436) and / or remote communication with one or more remote sites 452 and 454. As an example, the local devices 432, 434, and 436 can include one or more sensors.

[0057] As an example, the EF 410 can be installed at a site at a certain distance from a city, town, etc. In such an example, the EF 410 can be accessed via a satellite communication network.

[0058] A communication satellite is an artificial satellite that relays and amplifies radio telecommunications signals via a transponder. A satellite communication network can include, for example, one or more communication satellites that provide one or more communication channels. As of 2021, there are approximately 2,000 communication satellites in Earth's orbit, some of which are geostationary satellites above the equator so that the satellite dish antennas of ground stations can permanently aim at the satellites rather than track them.

[0059] High-frequency radio waves for telecommunications links propagate through line of sight, which can be blocked by the curvature of the Earth. Communication satellites can relay signals around the curvature of the Earth, enabling communication between geographically distant locations. Communication satellites can use one or more frequencies (such as radio, microwave, etc.), and the frequency bands can be regulated and allocated.

[0060] Due to factors such as distance, equipment, deployment, and maintenance, satellite communication is often slower and more expensive than other types of electronic communication. For well sites with no other means of communication, satellite communication may be limited in one or more aspects. For example, when a controller needs to work in real-time or near real-time, cloud-based control methods may introduce excessive latency. As Figure 4 shown in the example, the EF 410 can be deployed where it can operate locally with one or more of the devices 432, 434, 436, etc., which can be used for control purposes.

[0061] As needed, communication may occur from time to time between the EF 410 and one or more remote sites 452, 454, etc., and such communication can be carried out via satellite communication with tolerable latency and cost. As an example, the CRM 440 can be a removable drive that can be brought to the site via one or more means of transportation. For example, consider airdropping, where people are transported via a helicopter, airplane, or ship, etc.

[0062] Regarding air drops, it may be considered to drop an electronic device that can be locally activated after landing or while descending towards the ground suspended on a parachute. Such an electronic device can communicate via a local communication system (such as, for example, a local WiFi, Bluetooth, cellular, etc. communication system). In such an example, one or more data structures can be transferred from the electronic device (e.g., including CRM) to the EF 410. This approach can provide local control where there may or may not be one or more people at the site. As an example, autonomous and / or manned control vehicles at the site can help locate the electronic device and help download its payload to the EF, such as the EF 410. For example, consider a local drone or a land vehicle that can locate the air-dropped electronic device and retrieve it, and transfer one or more data structures from the electronic device to the EF directly and / or indirectly. In such an example, the drone or land vehicle can establish communication with the electronic device and / or read data from the electronic device such that data can be transferred (e.g., to one or more EFs).

[0063] As an example, the system can include various resources and / or provide access to various resources that can be part of the environment, such as, for example, a DELFI environment (see, for example Figure 1 ). For example, consider the PIPESIM framework, which can be implemented locally and / or remotely (e.g., as a complete and / or customized framework). For example, the PIPESIM framework and / or other frameworks can be used for one or more purposes, which include calibration, generating results, etc. For example, a framework such as the PIPESIM framework can provide a comparison between the output of a semi-empirical model and the output of the PIPESIM framework.

[0064] As an example, the EF can include a license server, a semi-empirical model component, a framework simulation engine (e.g., a PIPESIM engine, etc.), and a REST API, where the REST API can receive one or more API calls, for example, as one or more model requests, calibration requests, simulation requests, etc. As an example, the EF can respond to the API call with an output, where such output can be provided to one or more edge applications, multiple devices, etc. (e.g., for individual and / or coordinated control of a group or multiple groups of devices, etc.).

[0065] Referring again to architecture 401, as explained above, one or more physics-based models can be deployed to the edge for implementation, for example, operating in response to real-time data for one or more types of device control. As an example, a fluid simulation framework such as the PIPESIM framework can be implemented at the edge. Such a fluid simulation framework can be a multiphase flow simulation framework suitable for handling multiphase flows that may occur in one or more types of oilfield and / or gasfield operations.

[0066] As an example, a virtual flowmeter (VFM) can utilize one or more types of frameworks. For example, the framework can include conservation equations that describe the mass momentum and energy of single-phase, two-phase, or three-phase flow (e.g., based on one or more of LEDAFLOW (Kongsberg Oil & Gas Technologies, Sandvika, Norway), OLGATM model (Schlumberger, Houston, TX), TUFFP unified mechanical model (Fluid Flow Project, University of Tulsa, Tulsa, OK), etc.). As an example, the framework can include a simulator such that flow simulations can be performed, which can be for multiphase fluid flow.

[0067] As Figure 4 As shown, the EF can be executed within a gateway (such as, for example, an AGORA gateway) (e.g., considering one or more processors, memories, etc., which can be deployed as a "box" that can be locally powered and locally communicate with other devices via one or more interfaces). As an example, the gateway can include one or more features of an AGORA gateway (e.g., v.202, v.402, etc.) and / or another gateway. For example, consider an INTEL ATOM E3930 or E3950 dual-core with DRAM and eMMC and / or SSD. Such a gateway may include a Trusted Platform Module (TPM), which can provide secure and measurable boot support (e.g., via hashing, etc.). The gateway can include one or more interfaces (e.g., Ethernet, RS485 / 422, RS232, etc.). Regarding power, the gateway may consume less than about 100W (e.g., considering less than 10W or less than 20W). As an example, the gateway can include an operating system (e.g., consider LINUX DEBIAN LTS). As an example, the gateway can include a cellular interface (e.g., 4G LTE with a global modem / GPS, etc.). As an example, the gateway can include a WIFI interface (e.g., 802.11a / b / g / n). As an example, the gateway can operate using AC 100 - 240V, 50 / 60Hz, or 24VDC. Regarding size, consider a gateway with a protective box having dimensions of approximately 10 inches × 8 inches × 4 inches (e.g., approximately 25cm × 20.3cm × 10.2cm).

[0068] Figure 5An example of system 500 is shown, which includes components for data acquisition 510, data preprocessing 520, optional data visualization 525, and generating an output (e.g., one or more results) 530, which can be implemented using a containerized application programming interface (API) 532 to access a model 534 (e.g., a physics-based model, a trained machine learning model, etc.). As shown, an edge application architecture can be utilized, in which one or more suitable languages (e.g., JSON, etc.) can be implemented. In Figure 5 In an example, system 500 can preprocess data, where the API call can take the form of a JSON request, and a JSON response can be received. In Figure 5 In an example, system 500 can include one or more edge applications and one or more types of components (e.g., containerized, etc.), which can be accessed using one or more APIs.

[0069] As an example, Figure 4 one or more features of system 400, Figure 5 system 500, etc. may be suitable for updates, where, for example, the updates can be delivered to system 400 or system 500 via one or more techniques, one or more arts, etc. As an example, one or more security techniques and / or one or more security arts can be used to provide the updates. For example, the updates can be encrypted, transmitted via a secure network, etc. As an example, the updates can be subject to multi-factor authentication (MFA), which can be layered with respect to access to the field system, transmission to the field system, decryption of the encrypted updates at the field system, etc. As an example, the updates can have one or more associated metrics (e.g., hashes, certificates, etc.).

[0070] As an example, the updates can be for a single system (e.g., a single field gateway) and / or multiple systems (e.g., multiple field gateways). As an example, if the field includes multiple systems that can be associated with multiple wells, the updates can be deployed to the multiple systems in a coordinated manner. For example, consider parallel, serial, parallel and serial deployments, etc. For example, the updates can be deployed to one or more field systems, and after successful installation, the updates can be deployed to one or more additional field systems. As an example, status reports from multiple systems can be utilized to coordinate the updates.

[0071] As described above, a field device may include computing resources that can provide instruction execution. Such instructions may include BIOS instructions, operating system (OS) instructions, application instructions, and the like. As described above, a field device such as a gateway may include a TPM, which can provide secure and measurable boot support. Since field devices may be located in remote locations where an operator may not frequently access, the field device can provide some assurance for robust operation. For example, consider enclosures or shelters used to protect the device from environmental conditions such as rain, snow, sunlight, sand, lightning, and wind. Robust operation may be expected to reduce non-production time (NPT), enabling tasks to be reliably performed in a continuous, periodic, and / or on-demand manner.

[0072] In various cases, downtime of the gateway may occur due to an update that may be intended to update instructions, which may include instructions such as parameter updates, model updates, BIOS updates, OS updates, application updates, API updates, container updates, and the like. Additionally, if the update is not successful, additional downtime may occur, which may result in undesirable field operations, such as fluid production being lower than planned, lack of data collection and / or processing, and the like.

[0073] As described above, the gateway may be part of an IoT infrastructure that can be deployed at a wellsite to interact with field devices. As described above, the gateway may be part of the infrastructure for acquiring data and transmitting such data (whether raw or processed) to a cloud backend, which can provide data analysis, remote monitoring, remote control, and the like.

[0074] When the gateway is operatively coupled to one or more networks, cybersecurity issues may arise. For example, if the gateway is compromised via malicious network activity, it may have an impact on field operations. Regarding cybersecurity protection, procedures may be intended to meet various security requirements. For example, consider requirements such as system integrity, data confidentiality, and the ability to perform secure updates with fail-safe rollback.

[0075] Regarding system integrity, industrial IoT (IIoT) gateways may be deployed in remote areas where physical security protection is not available. This may lead to system tampering attacks, where someone with physical access to the IIoT gateway can maliciously modify its instructions in a way that has a negative impact on field operations. Operational integrity may focus on system integrity protection, where the system has the ability to detect and prevent system tampering attacks. As described above, a circuit such as a TPM may be included in the gateway that can provide a hardware-based root of trust operation.

[0076] Regarding data confidentiality, the IIoT gateway can connect to field devices to obtain data and transmit such data (whether raw or processed) to a cloud backend. In various scenarios, the data can be stored in encrypted form on the gateway storage device. For example, the TPM can provide one or more encryption techniques to encrypt and (optionally) decrypt the data.

[0077] Regarding security updates with a fail-safe rollback mechanism, to maintain the security posture of the IIoT gateway, the system can periodically provide the delivery and application of security patches (e.g., updates) on the IIoT gateways deployed in the field, which may be aimed at meeting system requirements, improvements, and / or identified and / or potential security vulnerabilities. As mentioned above, the security updates can be provided with a fail-safe rollback mechanism, for example, which can be aimed at reducing the downtime associated with a corrupted system, e.g., the downtime that may occur for an update failure.

[0078] For example, the gateway can include features that can implement appropriate network security measures, especially security updates and fail-safe rollback.

[0079] Regarding various aspects of system integrity and data confidentiality, the publicly available U.S. patent application titled "Industrial internet of things gateway boot methods" with publication number US2021 / 0011734 A1, published on January 14, 2021, is incorporated herein by reference and is referred to herein as the '734 application.

[0080] As mentioned above, the gateway can include a TPM as an encryption processor to securely store one or more algorithms, artifacts, etc. that can be used for one or more purposes. For example, the TPM can be utilized to authenticate the hardware platform for a measured boot process and / or a secure boot process. For security artifacts, these can include passwords, certificates, and / or one or more encryption keys. As an example, the TPM can be used to store measurements that help ensure the system remains trustworthy.

[0081] As an example, the TPM can provide measurements of certain code and / or activities of the system. For example, the measurements can be the following: calculating the hash of a code snippet, measuring the speed of performing certain operations, calculating a hash via an algorithm that uses certain characteristic values from different specific items of the machine such as serial numbers, MAC addresses, etc. As an example, the TPM can include a coprocessor that handles encryption operations such as asymmetric key generation (RSA), asymmetric encryption / decryption (RSA), hashing operations (e.g., Secure Hash Algorithm (SHA-1), etc.), and random number generation (RNG).

[0082] As an example, a TPM can include a hardware random number generator, a facility for the secure generation of cryptographic keys for restricted use, features for remote attestation (e.g., creating a hash digest of the hardware and software configuration, which can be used to verify that the hardware and software have not changed), features for binding (e.g., encrypting data using a binding key, which is a unique RSA key derived from a storage key, where the primary wrapping key - called the storage root key - can be stored in the TPM) and features for sealing (e.g., specifying the TPM state for data to be decrypted (unsealed)).

[0083] As an example, the system can include a user-level RSA key container, which can be stored with the OS user profile of a specific user and used to encrypt and decrypt information for applications running under that specific user identity.

[0084] As an example, a TPM can include platform configuration registers (PCRs) that can store measurements, which can take the form of digests generated by an associated hashing algorithm.

[0085] As described above, a TPM can be utilized to perform a root of trust (RoT) process that can help ensure integrity. For example, the RoT process can help ensure that the boot process starts with a trusted combination of hardware and software and continues until the OS is fully booted and applications are running.

[0086] As an example, the boot process can utilize a hardware platform that includes a processor and a TPM, where the TPM includes PCRs as security registers. During the boot process, the RoT measurement code and BIOS code components can be executed under the assurance of the TPM. For example, the TPM can "measure" code by storing values in the PCRs. One method can utilize a so-called "extend" function that hashes the stored values and the code values and stores the result in the PCR. For example, the PCR can store SHA-1(value1||value2), where value1 is the SHA-1 hash of the code value and value2 is the code value concatenated with value1. The concatenated values are hashed with SHA-1 and stored in the PCR. A log can also be generated corresponding to the operations performed by the TPM, e.g., when the TPM code calls a measurement of the BIOS code component, when the BIOS code component calls a measurement of another code component, etc.

[0087] In various TPMs, the PCRs can be changed via a restart function, which clears the PCRs, and via an extend function, which can concatenate a number with the hash stored in the PCR, hash the concatenation, and store the resulting hash in the PCR. Generally, there is no other way for the system to change the value of the PCRs.

[0088] As described above, the TPM may include Platform Configuration Registers (PCRs) that can store hashes that can be read, where these hashes are written to the PCRs via an extended functionality that, as described above, can depend on previous hash values to form a kind of blockchain. The PCRs can be used to initiate integrity checks between the platform's hardware and software (e.g., to prevent Evil Maid attacks). The PCRs can also be used to unlock one or more encryption keys and prove that the correct OS has been booted.

[0089] One or more of various different TPM specifications can be utilized (e.g., 1.2, 2.0, etc.). As an example, BIOS-based systems can use the TPM 1.2 specification. As an example, the TPM 2.0 specification can operate with the Unified Extensible Firmware Interface (UEFI) to use the TPM to form a root of trust. As described above, the TPM can be utilized in a manner in which the PCRs allow for the secure storage and reporting of security-related metrics, where such metrics can be used to detect changes in a previous configuration and, for example, decide how to proceed.

[0090] For LINUX systems, the Linux Unified Key Setup (LUKS), which is a disk encryption specification, can be utilized. LUKS can be used to encrypt block devices. The content of the encrypted device can be arbitrary, and thus any file system (fs or FS) can be encrypted. According to LUKS, there can be an unencrypted header at the beginning of the encrypted volume that can allow up to eight (LUKS1) or thirty-two (LUKS2) encryption keys to be stored along with encryption parameters such as password type and key size.

[0091] As an example, a method can include using the TPM to unlock a LUKS volume (e.g., considering Clevis, #systemd-cryptenroll, etc.). As an example, one or more keys stored in the TPM can be used to unlock one or more encrypted volumes, which, for example, can occur automatically at boot depending on one or more conditions. For example, in some cases, manual methods can be utilized after boot. Using the TPM for this purpose can help ensure that one or more drives (e.g., one or more partitions) will not be unlocked unless certain conditions are met. The conditions can be code (e.g., instruction) conditions, configuration conditions, etc.

[0092] As an example, one or more drives, one or more volumes, and / or one or more partitions can be utilized. The term "volume" can be used to describe a storage device such as a drive, but it can also be used to refer to a portion of a storage device (e.g., by dividing the storage into chunks). The system can make the storage accessible via a file system in a process called mounting. As an example, one or more mounted volumes can be one or more devices (e.g., hard disk drive, USB drive, DVD-RW, SD card, other media, etc.). If a volume is currently mounted, the volume can be read from and written to. As an example, the term partition can refer to a physical area of storage that can be located on a single storage device; however, as described above, partitions can be utilized in a way where a partition is located on multiple storage devices (e.g., one partition on one storage device and another partition on another storage device). As an example, a partition can be mounted and the partition can be referred to as a volume where the information on the partition can be accessed.

[0093] As an example, a method can include using one or more utilities (e.g., fdisk, gparted, etc.) to create one or more partitions. As an example, a method can include creating a file system on the partition (e.g., mkfs command, ext4, default file system, etc.). As an example, a method can include creating a directory as a mount point, where a method can mount the partition to the mount point.

[0094] As an example, a Logical Volume Manager (LVM) can be utilized, where a Physical Volume (PV) is a disk or partition that is available to the LVM as potential storage capacity. In this approach, a PV can have an identifier and metadata that describe each PV. In contrast to RAID, PVs do not have to be the same size or be on disks with the same speed. As an example, the system can include multiple drive types to create PVs. As an example, the system can include Logical Volumes (LVs) that can actually be partitions and can be managed similar to partitions. For example, an LV can utilize a file system and a mount point and be appropriately configured as explained above (e.g., considering standard LINUX partition management methods).

[0095] As an example, the system can utilize one or more virtual machines and / or one or more other types of virtualization. A virtual machine (VM) can utilize a virtual environment created on a physical hardware system that serves as virtual computing resources, such as having its own processor, memory, network interface, and storage. As an example, a hypervisor can be utilized to separate machine resources from the hardware and appropriately allocate resources for use by one or more virtual machines. For example, the VM approach can be used for one or more purposes, which can include redundancy, scaling services on a single field gateway, quality control, testing, etc. For example, one or more methods can utilize virtualization. As an example, a field gateway can establish a virtual TPM that is compatible with one or more TPM specifications, such that a virtual hardware module that supports the TPM is created for use, for example, by a VM. As an example, a kernel-based VM can be used for one or more purposes. For example, a paravirtualized clock (pvclock) can be provided for one or more virtual machines, and this paravirtualized clock can provide a stable timing source for kernel-based VM (KVM) guests. Since VMs can have several problems caused by inaccurate clocks and counters, such as the clock being out of sync with the actual time (e.g., this can invalidate sessions and affect the network) and a VM with a slower clock may have migration issues, the pvclock method can be utilized. For example, a field gateway can use virtualization for one or more purposes, where the pvclock or other suitable methods can be used to stabilize the clock and timing, for example, for one or more of data collection, control, network operations, security, etc. For example, pvclock can assist with time adjustments that may be required after a guest runs in a sleep or suspend state.

[0096] As an example, in a pvclock type of method, a guest can reserve pages of its RAM and ask the host (e.g., using a model-specific register (MSR)) to write the time to that page. In such an example, the structure that is written can include the time at the moment it is written, plus the guest's timestamp counter (TSC) at that moment, plus the current ratio of the TSC relative to real time (e.g., which can change). In such an example, the guest can later read its own TSC, calculate the difference between the current TSC and the TSC when the host measured it, scale it to seconds, and add it to the time in the structure to obtain an estimate of the wall clock time. As long as the host does not allow too much time to pass between updates and does not perform operations such as adjusting the processor speed or migrating the guest without updating the structure, the guest can optionally obtain an estimate of the wall clock time without involving the hypervisor.

[0097] Figure 6illustrates an example of system 600 and various processes that can be used to ensure integrity, data confidentiality, and update security with rollback protection. As shown, system 600 includes a TPM 602 and a disk encryption key 604 that can be provided by the TPM 602. System 600 illustrates a series of blocks 612, 614, 622, 624, 632, and 634 involved in the boot process, where interactions with the TPM 602 can occur, for example, for measurements associated with the RoT. As shown, measurement and extension operations can be performed to provide one or more results that can be evaluated by the TPM. As an example, the PCRs of the TPM can be used to store various values, which can include hashes.

[0098] In Figure 6 the example of, block 612 is a BIOS block, and block 614 is a BIOS configuration block. Thus, if a BIOS change and / or a BIOS configuration change occurs, the measured value will change. Therefore, tampering and / or other corruption of the BIOS or BIOS configuration can be detected.

[0099] Regarding block 622, it is a bootloader block. A bootloader or boot manager is a relatively small program that performs the operation of placing an operating system (OS) into memory. For example, when a computing device is powered on or restarted, the BIOS can perform some initial tests and then transfer control to the master boot record (MBR) where the bootloader resides. For LINUX, the bootloader can include one or more of LILO (LInux LOader), LOADLIN (LOAD LINux), and GRUB (GRand Unified Bootloader). As Figure 6 the example of shows, the bootloader block 622 can include parameters 624 or otherwise operate based on the parameters 624. For example, the parameters 624 can include partition parameters that specify a particular partition, and the partition parameters can be specified as a location. Thus, if one or more of the parameters 624 of the bootloader block 622 change, the measured value in the RoT will change.

[0100] Regarding GRUB, it can be executed in stages. The first stage can utilize a part of GRUB that resides in the MBR or the boot sector of another partition or drive. On the other hand, the main part of GRUB is often too large to fit into a byte - restricted (e.g., 512 - byte limit, etc.) boot sector. The first stage can be used to transfer control to subsequent stages, which can be referred to as stage 1.5 or stage 2. If the hardware requires it, stage 1.5 is loaded by the first stage. Stage 1.5 is file - system - specific; that is, there are different versions for each file system that GRUB can load. The name of the file system is part of the file name (e2fs_stage1_5, fat_stage1_5, etc.). Then, stage 1.5 loads stage 2. Stage 2 runs the main part of GRUB, which can provide a selection of the OS to run, etc., and then can continue with the process of booting the selected OS. If the device name is omitted, it can be assumed to be the GRUB root device, where the GRUB root device can be the disk or partition in which the kernel image is stored (e.g., set using the root command). As an example, a system can include multiple OSs, which can include multiple instances of the same OS and / or instances of different OSs. As an example, updates can be provided with the OS, e.g., as an OS image and one or more executable files.

[0101] As described above, a method can include using a boot loader configuration that includes one or more parameters that can specify the partition to be used when establishing an OS environment, where the partition can be one of multiple partitions. As described above, the RoT process can measure code, which can include measuring the boot loader code that includes one or more parameters and associated parameter values. Thus, if there is a change in the boot loader configuration regarding the partition, the measurement or result based on this may be different from the metrics stored in one or more PCRs of, for example, a TPM. As an example, a method can execute one or more processes that can adapt the change in the boot loader configuration for a system update when the system update is authorized; however, an unauthorized attempt to change the system through an update may result in using a known - good partition and / or known - good associated boot components to ensure the robust operation of the system. In this method, non - production time (NPT) in on - site installation can be reduced. For example, a good partition and / or good components can be utilized to facilitate robust operation.

[0102] In Figure 6In the example, block 632 is the kernel block, and block 634 is the initial ram filesystem (initramfs) block, where blocks 622, 624, 632, and 634 can reside on the common partition 620. As shown, other partitions can include encrypted partition A 650, encrypted partition B 660, and encrypted data partition 680, and note that more partitions can be included.

[0103] In the context of various operating systems, except for the operating systems developed by Microsoft Corporation (Redmond, Washington), the system partition and the boot partition are defined as follows: The boot partition is the primary partition that contains the boot loader, which is the software responsible for booting the operating system (e.g., in the standard LINUX directory layout (Filesystem Hierarchy Standard (FHS)), the boot files (such as the kernel, initial ram disk (initrd), and boot loader (GRUB)) are mounted at / boot / ); and the system partition is the disk partition that includes the operating system folder, called the system root (e.g., by default, in LINUX, the operating system files are mounted at / (root directory)). As an example, in LINUX, if both / boot / and the root directory are on the same partition, then a single partition can be both the boot partition and the system partition.

[0104] In Figure 6 In the example, the kernel block 632 can include the LINUX kernel, which can obtain control of the system 600 after being loaded by the boot loader block 622, where the kernel block 632 is used to prepare its memory structure and drivers.

[0105] In the case where the / usr partition is on a separate file system, tools and drivers that store files within / usr cannot be used unless / usr is available. If these tools are needed to make / usr available, then the system cannot boot. If the root file system is encrypted, then the LINUX kernel will not be able to find the init application, resulting in the system not being able to boot. One way to handle this situation is to use initrd (initial root device).

[0106] The initrd is a memory disk structure (ram disk) that includes the appropriate tools and scripts to mount the file system before control is handed over to the init application on the root file system. The LINUX kernel can trigger the setup script (e.g., linuxrc) on this root disk, which prepares the system, switches to the real root file system, and then calls init. Although the initrd method can be sufficient, it has some drawbacks. For example, it is a full-fledged block device that requires the overhead of the entire file system (it has a fixed size), and since it is a real static device, it consumes cache memory in the LINUX kernel and is vulnerable to memory and file management methods in use (such as paging), which makes the memory consumption of initrd even greater. If needed, to address such drawbacks, as an example, the initramfs method can be utilized.

[0107] The initramfs is an initial ram file system based on tmpfs (a memory lightweight file system with flexible size) that does not use a separate block device. Similar to initrd, the initramfs includes tools and scripts to mount the file system before calling the init binary on the real root file system. These tools can be a decryption abstraction layer (for encrypted file systems), a logical volume manager, software raid, a file system loader based on a Bluetooth driver, etc.

[0108] The content of the initramfs can be created by creating a cpio archive (e.g., a file archiving utility and its associated file format). Files, tools, libraries, configuration settings (if applicable), etc. can all be placed in the cpio archive, and the archive can be compressed using a utility such as the gzip utility (e.g., a file format and software application for file compression and decompression) and stored with the LINUX kernel. In such an example, the boot loader can provide it to the LINUX kernel at startup so that the kernel knows that the initramfs is needed.

[0109] Once the initramfs is detected, the LINUX kernel can create a tmpfs file system, extract the archive content on it, and then start the init script located at the root of the tmpfs file system. Then, this script can mount the real root file system (e.g., after ensuring that it can be mounted, such as by loading additional modules, preparing the decryption abstraction layer, etc.) and one or more other key file systems (e.g., such as / usr and / var).

[0110] Once the root file system and other critical file systems are mounted, the init script from the initramfs can switch the root to the real root file system and then call the / sbin / init binary on that system to continue the boot process.

[0111] In Figure 6 the example of, as shown in the figure, if the measured result is acceptable according to the TPM 602, the disk encryption key 604 can be used to decrypt one or more of the partitions 650, 660, and 680. In Figure 6 the example of, the partitions 650 and 660 can be root file system (rfs) partitions, which can be located on a common disk and / or on separate disks (e.g., see the partition examples above). As described above, in a LINUX-based system, LUKS can be utilized in combination with the TPM.

[0112] As described above, the system can provide secure updates with rollback protection. In Figure 6 the example of, using multiple partitions (such as partitions 650 and 660 for example) can provide rollback protection; note that the boot loader block 622 is to include parameters in the parameter block 624 to indicate which of the partitions 650 and 660 is to be utilized, where one can be the current partition and the other can be the updated partition.

[0113] As an example, a fail-safe software update solution can utilize an update method based on A and B images, where the system can be updated as a whole rather than incrementally, where the system can have at least two partitions dedicated to running the system, where one partition can be the active partition running the appropriate software, and where the other partition can be the inactive partition, which will become the active partition after a successful software update.

[0114] As an example, during a wireless (OTA) update, the active partition (referred to as partition A) can be running, and the new software image can be applied to the inactive partition (referred to as partition B). After successfully verifying the new image, the bootstrap can set partition B as the next active partition (e.g., see the parameter block 624). In this way, the next time the system restarts, partition B will become the new active partition, and partition A will become the inactive partition.

[0115] If an error occurs during the update, the active partition will remain unchanged, and the system can roll back to its current working state that existed before the update operation, thus making the operation fail-safe.

[0116] As an example, the multi-partition method can be implemented in a way that provides system integrity protection to meet the HRoT requirements and data confidentiality requirements.

[0117] As an example, the system can provide a trusted boot design and implementation methods and procedures for the IIoT gateway to provide system integrity protection, data confidentiality protection, and reliable / fail-safe system security update mechanisms based on HRoT.

[0118] As an example, the system can include a security design with the following features: trusted system boot objects that are measured each time the IIoT gateway boots, and these measurements are stored in the TPM, where during system boot, if software tampering is detected, the boot process is stopped; a TPM that serves as a hardware root of trust (HRoT) for reporting; enabling full disk encryption for the root file system partition and data partitions (e.g., on a common disk or two or more disks); a disk encryption key that is stored inside the TPM and sealed with a known good system state (based on system boot); a disk partition layout for use in conjunction with trusted system boot and system rollback capabilities; instructions for a method to detect system boot failures during software updates, and a fail-safe mechanism to roll back to a backup root file system partition and kernel while still maintaining system integrity protection and data confidentiality protection.

[0119] As an example, the system can include procedures to implement the following: trusted boot; full disk encryption where the encryption key is sealed inside the TPM with known good system measurements; disabling trusted boot features for system maintenance; and preparing a software update package for the target IIoT gateway, which allows for fail-safe system rollback in case of update failures.

[0120] As explained regarding Figure 6 system 600, the IIoT system can provide integrity and data confidentiality protection. Such a system can measure system boot components (e.g., BIOS, BIOS configuration, boot loader, OS kernel, initrd, initramfs, etc.), where these measurements are recorded into the TPM, and the TPM serves as a hardware root of trust (HRoT) for reporting. Such a system can provide full disk encryption on the root file system (rootfs or rfs) partition and data partitions. Such a system can provide a disk encryption key stored inside the TPM and protected by known good boot component measurements.

[0121] Regarding system startup, initrd and / or initramfs can attempt to unlock the encryption key from the TPM using system measurements. If the boot object has been tampered with, this process will result in different system measurements, and initrd and / or initramfs will not have the encryption key to decrypt the encrypted partition, and the system startup will be stopped. As an example, during a system update process where the trusted boot feature is disabled, a specific situation may occur where initrd loads the encryption key in an unencrypted / boot partition.

[0122] As an example, a security update with a fail-safe rollback mechanism can be performed by a system with a customized partition layout. For example, consider a layout with the following partitions: an unencrypted and boot partition to hold the active and rollback kernels as well as the initrd file (e.g., or initramfs), where the bootloader is configured to switch back and forth between the active and rollback kernels / initrd during the system update state; encrypted active and inactive rootfs partitions for the root file system, where the bootloader can be configured to switch back and forth between the active and inactive partitions during the system update state; and an encrypted data partition for storing operational data and persistent system update data and status.

[0123] As an example, the system can provide various workflows to handle different scenarios. For example, consider different modes, which include the IIoT gateway initial setup mode, the IIoT gateway in the operation mode, and the IIoT gateway in the maintenance / update mode. As an example, the IIoT gateway can include features for monitoring the performance of one or more applications, where, for example, one or more triggers can be issued, which can, for example, call for an update such that the update can be driven by local monitoring. For example, consider a machine learning model (ML model) that may experience a certain degree of drift, where an update to the machine learning model via training can be called, which can include retraining using additional data that is more representative of the behavior, conditions, etc. at the field site. As an example, the update cycle can be driven locally and / or remotely, where the update can occur in a secure manner to ensure system integrity, data confidentiality, and rollback in appropriate cases (e.g., to reduce downtime, NPT, etc.).

[0124] Figure 7 An example workflow 700 including an initial installation mode workflow 710 and an operation mode workflow 730 is shown. As shown, the initial system installation block 712 provides for starting the initial system installation, where the measurement block 714 provides the measurement of the boot object and the storage of the resulting digest in the TPM (e.g., the metric in the PCR). As shown, the partition block 716 can provide encrypted active and inactive root file partitions (e.g., Figure 6Partitions 650, 660, and 680) in the example, as well as an encrypted data partition, where the encryption key can be stored on an unencrypted partition (e.g., / boot or partition 620 as in the example of Figure 6 . The activation block 718 can provide activation of the trusted boot feature.

[0125] Regarding the operation mode workflow 730, the operation block 732 provides IIoT gateway operation. At various times and in various situations, the system startup block 734 can be utilized to perform system startup. As shown, the decision block 736 determines whether an unauthorized system modification has been detected. As shown, when such an unauthorized modification has been detected, the operation mode workflow 730 can proceed to the stop block 738, stopping the startup process, where the data on the system remains encrypted. As explained in the example of Figure 6 , various partitions can be encrypted, where decryption depends on the occurrence of an authorized boot. As shown, when no unauthorized modification has been detected, the operation mode workflow 730 can proceed to the decryption block 740, where the keys stored in the TPM (e.g., see the TPM 602 of Figure 6 ) can be used to decrypt the active and inactive root file systems and data partitions. In such an example, the operation block 732 can continue with the processing of the OS startup.

[0126] As described above, an IIoT gateway initial setup mode can be implemented, where during OS installation (instantiation), the startup object measurements are recorded into the TPM PCRs along the chain from the BIOS to the OS kernel. These measurements depend on the startup object state and configuration. As an example, depending on the specific circumstances of the implementation, configuration measurements may or may not be considered during startup control. Regarding the OS root partition, like other data partitions, it can be encrypted during initial installation. In such an example, an encryption key can be randomly generated and stored, for example, in plain text on an unencrypted partition.

[0127] As Figure 7 shown, the block 718 can activate the trusted boot feature at the end of the initial system setup process. Such features can store the disk encryption key into the TPM, seal it with the current TPM PCR value, and delete the plain text key from the partition. The block 718 can be a task to complete the initial system setup, enabling the IIoT gateway to move to the operation mode.

[0128] Regarding the IIoT gateway in the operating mode, during the system startup process, measurement values of each startup component (such as BIOS, BIOS configuration, bootloader, OS kernel, etc.) can be recorded into the TPM PCR. In such an example, initrd (or initramfs) will attempt to use the current system measurement values to unlock the disk encryption key from the TPM (for example, see Figure 6 ). In this method, if there are unauthorized changes to one or more of the system startup components, the disk encryption key cannot be unlocked, and the system startup will stop, as shown by stop block 738. As described above, when the measurement values are correct, once initrd (or initramfs) has the disk encryption key, initrd (or initramfs) can decrypt the active rootfs partition, the inactive rootfs partition, and one or more data partitions. In such an example, once the OS is fully loaded (for example, the OS environment is fully established), data encryption / decryption is completely transparent to one or more applications and services running at the OS level.

[0129] Figure 8 An example of the IIoT gateway maintenance mode workflow 800 is shown. The workflow starts at maintenance block 810, which proceeds to system startup 812, where decision block 814 determines via the bootloader (BL) whether a system update (UD) is in progress. According to the "no" branch, setup block 816 can set the bootloader environment variable to start using the current active rootfs partition; while according to the "yes" branch, verification block 818 can verify the new kernel and initrd files (or initramfs), and set the bootloader variable to start using the new inactive rootfs partition. In such an example, if the new kernel and / or initrd files (or initramfs) are corrupted, the maintenance mode workflow 800 can roll back (RB) to the old kernel and initrd (or initramfs) and set the bootloader variable to start using the active partition.

[0130] As shown, from any branch, the workflow 800 can proceed to the unlock block 820, which is used to unlock the encryption key from the TPM or / boot / key.bin to decrypt the active and inactive root file systems and one or more data partitions. As shown, a series of decision blocks 830, 850, and 870 can then be executed, where each of the decision blocks 830, 850, and 870 includes "no" and "yes" branches, and where the "yes" branch of decision block 830 causes the workflow 800 to proceed to decision block 850, and where the "yes" branch of decision block 850 causes the workflow to proceed to decision block 870. As shown, the "no" branch of decision block 830 indicates that the OS has not been loaded, so the system watchdog (WD) block 832 causes the system WD to start to reboot the system, where the system WD block 832 can continue to the system startup block 812.

[0131] As described above, decision block 850 can follow the "yes" branch of decision block 830. Decision block 850 determines whether a system update (UD) is in progress, where if not, then according to the "no" branch, the workflow 800 proceeds to the extraction block 852 that extracts a new kernel, initrd (or initramfs), and / or rootfs image from the update package. As an example, the maintenance mode workflow can accommodate updates to the kernel, initrd (or initramfs), and / or rootfs image. In Figure 8 the example of, the workflow 800 can continue from the extraction block 852 to the disable block 853, which can disable the trusted boot feature so that the apply block 854 can apply the new root file system (RFS or rootfs or rfs) image to the inactive rootfs partition and make a backup (BU) of the kernel and initrd files (or initramfs) in the / boot partition (e.g., see Figure 6 partition 620 of), where the workflow 800 can save the new kernel and initrd files (or initramfs) to the / boot partition. In such an example, the update block 856 can update the boot loader (BL) environment variables to reflect the system upgrade status and switch to the new inactive rootfs partition. As shown, the workflow 800 can then proceed to the system startup block 812.

[0132] As described above, decision block 870 can follow the "Yes" branch of decision block 850. Decision block 870 determines whether the system update is successful, where according to the "Yes" branch, workflow 800 can proceed to system reboot block 874, which can provide for enabling trusted boot and reporting the completion of the update (e.g., update completion status). Regarding the "No" branch, workflow 800 can enter setup block 872, which sets the bootloader environment variables to boot using an inactive rootfs partition and roll back to a backup kernel and initrd file (or initramfs). As shown, workflow 800 can proceed to the system reboot block, enabling trusted boot and reporting an update failure. As described above, decision block 870 can handle scenarios where the update is successful or unsuccessful, where the operation of the IIoT gateway can effectively be uninterrupted such that downtime (e.g., NPT) does not occur or is otherwise minimized.

[0133] As described above, at system startup, the bootloader can check one or more environment variables to determine whether there is an ongoing system update, where if there is no "ongoing" update, the bootloader can use the active rootfs partition to boot. However, if there is an "ongoing" update, the bootloader can use the new kernel and initrd file (or initramfs) and an inactive rootfs partition to boot. If there are issues when booting with the new updated kernel and initrd file (or initramfs) and the new rootfs partition, the bootloader can reset one or more of the environment variables to use the previous partition and the previous kernel and initrd file (or initramfs) on the next reboot. In Figure 8 the example of, an encrypted partition can be decrypted by the initrd (or initramfs) using a key from the TPM or a key copy stored on an unencrypted boot partition (e.g., / boot).

[0134] As an example, when the OS is fully loaded, the data encryption / decryption task can be completely transparent to applications running at the OS level. In such an example, the workflow can check for ongoing system updates, where if there are no ongoing system updates, the workflow can extract the new kernel, initrd (or initramfs), and / or rootfs image from the software update package and disable the trusted boot on the system, which provides for the extraction of the disk encryption key from the TPM and the storage of the key on the unencrypted boot partition. In such an example, a backup of the current kernel and initrd (or initramfs) can be saved to / boot (e.g., the boot partition) along with the new kernel and initrd files (or initramfs). In this approach, the workflow can apply the new rootfs image to the inactive rootfs partition and can update one or more bootloader environment variables to reflect the status of the ongoing system update and switch to the new inactive rootfs partition on the next reboot.

[0135] However, if there are ongoing system updates, the workflow can verify whether the update task was successful. In such an example, if the task was not successful, the workflow can set the bootloader environment variables to use the previous rootfs partition while also rolling back to the backup kernel and initrd files (or initramfs). The workflow can then reboot the system, re-enable the trusted boot, and report a system update failure. In the case where the task was successful, the workflow can reboot the system, re-enable the trusted boot, and report the system update completion status.

[0136] Figure 9 An example of method 900 is shown, which may include: an operation block 910 for operating the system using a first partition as the active partition and a second partition as the inactive partition; a change block 920 for changing the bootloader configuration from the first partition to the second partition in response to receiving a system update; an execution block 930 for performing a trust root measurement on the update, where the measurement at least considers the change in the bootloader configuration; an access block 940 for accessing the encryption key in response to establishing trust via the measurement; a decryption block 950 for using the encryption key to decrypt at least the second partition for use by the system; and a reboot block 960 for rebooting the system using the second partition as the active partition and the first partition as the inactive partition in response to detecting a system update issue, such as for system rollback.

[0137] Figure 9Also shown are various computer-readable media (CRM) blocks 911, 921, 931, 941, 951, and 961. Such blocks may include instructions executable by one or more processors, which may be one or more processors of a computing framework, system, computer, etc. The computer-readable medium may be a non-signal, non-carrier, and non-transitory computer-readable storage medium. For example, the computer-readable medium may be a physical memory component that can store information in digital format.

[0138] As described above, the system may include features of updated fail-safe attributes. Such a system may provide a reliable rollback mechanism. As described above, adding file system encryption and allowing components that can perform decryption during an update may have serious consequences if not executed properly. As described above, the method may help ensure that the system ultimately becomes a functional system under reasonable operating conditions.

[0139] As described above, the TPM can be used to perform a RoT process (e.g., a root of trust measurement (RTM) process), which measures at least one boot loader configuration of a specified partition among multiple partitions. Such a RoT process may measure each boot object in the boot chain including the BIOS, BIOS configuration, boot loader binary, boot loader configuration, kernel, and initramfs (e.g., or initrd, etc.).

[0140] Figure 10 An example of a controller 1000 that can be part of a field system is shown. In Figure 10 the example, the controller 1000 may include one or more components, such as one or more of a gas lift component 1010, an electric submersible pump component 1020, a processing component 1030, a service component 1040, a valve selection component 1050, a well selection component 1060, and one or more other components 1070. As described above, information collected via control according to one or more methods can be utilized to determine one or more actions, which may be aimed at increasing production, improving the operation of equipment (e.g., valves, flow meters, etc.), and improving the utilization of one or more resources (e.g., natural gas, ESP power, chemical injection, etc.).

[0141] As an example, the controller 1000 may include Figure 4 one or more features of the system 400 of Figure 7 and Figure 8 one or more workflows such as Figure 9 and / or the method 900 of

[0142] As an example, a method may include: operating a field system using a first partition as the active partition and a second partition as the inactive partition; in response to receiving a system update, changing the bootloader configuration from the first partition to the second partition; performing a trust root measurement on the update, where the measurement takes into account at least the change in the bootloader configuration; in response to establishing trust via the measurement, accessing an encryption key; using the encryption key to decrypt at least the second partition for use by the system; and in response to detecting a system update problem, using the second partition as the active partition and the first partition as the inactive partition to restart the field system for system rollback. In such an example, the method may include: in response to a system update problem, changing the bootloader configuration from the second partition to the first partition. For example, consider the system update problem to be potentially associated with tampering, corruption, etc. of one or more components of the system update. In such an example, the first partition may be a fallback partition that becomes the active partition again when needed. Such methods can provide more robust field operation of the field system, where the integrity and information confidentiality of the field system can be maintained. As described above, for example, a field system such as a field gateway may include features that provide system integrity, information confidentiality, and update security with a fail-safe rollback mechanism.

[0143] As an example, the method may include using a trusted platform module to perform the trust root measurement.

[0144] As an example, a field system may include various partitions, which may include data partitions. As described above, one or more partitions may be protected via encryption, which may utilize one or more encryption keys, which may include one or more TPM encryption keys (e.g., TPM-stored, generated, etc.).

[0145] As an example, a field system may include a boot partition that stores at least one bootloader. As an example, a system update may include an update to one or more of the BIOS, bootloader, operating system kernel, initial files, and applications.

[0146] As an example, the method may include extracting one or more of the kernel, initial files, and root file system image from the system update. In such an example, the method may include applying the root file system image to the second partition, storing a backup of the existing kernel to the boot partition, and saving the kernel of the system update to the boot partition.

[0147] As an example, a bootloader configuration can include variables that specify a boot partition or a boot device. For example, consider a variable that indicates an active partition for boot purposes, where an inactive partition can be maintained, for example, as a fallback partition for the purpose of a rollback that can be triggered by detecting one or more events (e.g., one or more system update issues, etc.). As an example, a method can include: in response to a lack of trust, operating the system using a first partition as the active partition, where, for example, the first partition was previously an inactive partition.

[0148] As an example, a method can include accessing an encryption key from a trusted platform module and / or a bin file.

[0149] As an example, a method can include enabling a trusted boot feature after rebooting a live system.

[0150] As an example, a live system can include satellite communication circuitry, where, for example, a method can include receiving a system update via the satellite communication circuitry.

[0151] As an example, a live system can be operatively coupled to one or more devices at a well site, where, for example, a system update can include instructions for the control of at least one of the one or more devices at the well site.

[0152] As an example, a system can include one or more processors; a memory accessible to at least one of the one or more processors; processor-executable instructions stored in the memory and executable to command the system to: operate a live system using a first partition as the active partition and a second partition as the inactive partition; in response to receiving a system update, change the bootloader configuration from the first partition to the second partition; perform a trust root measurement on the update, where the measurement takes into account at least the change in the bootloader configuration; in response to establishing trust, access an encryption key; use the encryption key to decrypt at least the second partition for use by the system; and in response to detecting a system update issue, use the second partition as the active partition and the first partition as the inactive partition to reboot the live system for a system rollback.

[0153] As an example, one or more computer-readable storage media may include processor-executable instructions that command a computing system to: operate a live system using a first partition as the active partition and a second partition as the inactive partition; change a boot loader configuration from the first partition to the second partition in response to receiving a system update; perform a trust root measurement on the update, where the measurement at least considers the change in the boot loader configuration; access an encryption key in response to establishing trust; decrypt at least the second partition using the encryption key for use by the system; and restart the live system for system rollback using the second partition as the active partition and the first partition as the inactive partition in response to detecting a system update problem.

[0154] As an example, a computer program product may include one or more computer-readable storage media, the one or more computer-readable storage media may include processor-executable instructions, and the processor-executable instructions are used to command a computing system to perform one or more methods and / or one or more parts of a method.

[0155] In some implementations, one or more methods may be performed by a computing system. Figure 11 An example of system 1100 is shown, which may include one or more computing systems 1101-1, 1101-2, 1101-3, and 1101-4, and the computing systems may be operatively coupled via one or more networks 1109, and the networks may include wired networks and / or wireless networks.

[0156] As an example, the system may include a separate computer system or an arrangement of distributed computer systems. In Figure 11 the example, computer system 1101-1 may include one or more modules 1102, and the modules may be or may include, for example, processor-executable instructions that can be executed to perform various tasks (such as receiving information, requesting information, processing information, simulation, outputting information, etc.).

[0157] As an example, the modules may be executed independently or in cooperation with one or more processors 1104, and the one or more processors are operatively coupled (such as via wired, wireless, etc.) to one or more storage media 1106. As an example, one or more of the one or more processors 1104 are operatively coupled to at least one of one or more network interfaces 1107; note that one or more other components 1108 may also be included. In such examples, computer system 1101-1 may transmit and / or receive information (such as considering one or more of the Internet, private networks, cellular networks, satellite networks, etc.) via one or more networks 1109, for example.

[0158] As an example, computer system 1101-1 may receive information from and / or transmit information to one or more other devices, which may be or may include, for example, one or more of those in computer system 1101-2. The devices may be located at a physical location different from that of computer system 1101-1. As an example, the location may be, for example, a processing facility location, a data center location (e.g., a server farm, etc.), a rig location, a well site location, a downhole location, etc.

[0159] As an example, the processor may be or may include a microprocessor, a microcontroller, a processor module or subsystem, a programmable integrated circuit, a programmable gate array, or another control or computing device.

[0160] As an example, storage medium 1406 may be implemented as one or more computer-readable or machine-readable storage media. As an example, the storage may be distributed within and / or between multiple internal and / or external enclosures of the computing system and / or additional computing systems.

[0161] As an example, one storage medium or multiple storage media may include one or more different forms of memory, including: semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed disks, floppy disks, and removable disks; other magnetic media including magnetic tape; optical media such as compact disc (CD) or digital video disc (DVD), BLUERAY disc, or other types of optical storage devices; or other types of storage devices.

[0162] As an example, one storage medium or multiple storage media may be located in a machine running machine-readable instructions, or at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0163] As an example, various components of a system (such as, for example, a computer system) may be implemented in hardware, software, or a combination of both hardware and software (e.g., including firmware), including one or more signal processing circuits and / or application-specific integrated circuits.

[0164] As an example, a system may include a processing device, which may be or include a general-purpose processor or a special-purpose chip (e.g., or a chipset), such as an ASIC, FPGA, PLD, or other suitable device.

[0165] As an example, the device can be a mobile device that includes one or more network interfaces for communicating information. For example, the mobile device can include a wireless network interface (e.g., operable via IEEE 802.11, ETSI GSM, BLUETOOTH, satellite, etc.). As an example, the mobile device can include multiple components such as a main processor, memory, display, display graphics circuitry (e.g., optionally including touch and gesture circuitry), SIM slot, audio / video circuitry, motion processing circuitry (e.g., accelerometer, gyroscope), wireless LAN circuitry, smart card circuitry, transmitter circuitry, GPS circuitry, and battery. As an example, the mobile device can be configured as a cellular phone, tablet computer, etc. As an example, the method can be implemented (e.g., in whole or in part) using the mobile device. As an example, the system can include one or more mobile devices.

[0166] As an example, the system can be a distributed environment, such as the so-called "cloud" environment, where various devices, components, etc. interact for purposes of data storage, communication, computing, etc. As an example, the device or system can include one or more components for communicating information via one or more of the Internet (e.g., in cases of communicating via one or more Internet protocols), cellular network, satellite network, etc. As an example, the method can be implemented (e.g., in whole or in part as a cloud-based service) in a distributed environment.

[0167] As an example, information can be input from a display (e.g., considering a touch screen), output to a display, or both. As an example, information can be output to a projector, laser device, printer, etc. such that the information can be viewed. As an example, the information can be output stereoscopically or holographically. Regarding printers, 2D or 3D printers are considered. As an example, a 3D printer can include one or more substances that can be output to build a 3D object. For example, data can be provided to the 3D printer to build a 3D representation of a subsurface formation. As an example, layers (e.g., ground planes, etc.) can be built in 3D, geological bodies can be built in 3D, etc. As an example, wellbores, fractures, etc. can be built in 3D (e.g., as positive structures, as negative structures, etc.).

[0168] Although only a few example embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications can be made to the example embodiments. Accordingly, it is intended that all such modifications be included within the scope of the present disclosure as defined in the appended claims. In the claims, the means-plus-function clauses are intended to cover the structures described herein as performing the recited functions, and cover not only structural equivalents but also equivalent structures. Thus, although a nail and a screw may not be structural equivalents because a nail uses a cylindrical surface to fasten wooden parts together while a screw uses a helical surface, in the context of fastening wooden parts, a nail and a screw can be equivalent structures.

Claims

1. A method (900) that includes: operating a live system (910) using a first partition as the active partition and a second partition as the inactive partition; changing a boot loader configuration from the first partition to the second partition in response to receiving a system update (920); performing a root of trust measurement on the update, where the measurement at least takes into account the change in the boot loader configuration (930); accessing an encryption key in response to establishing trust via the measurement (940); using the encryption key to decrypt at least the second partition for use by the system (950); and restarting the live system for system rollback using the second partition as the active partition and the first partition as the inactive partition in response to detecting a system update problem (960).

2. The method according to claim 1, which includes: changing the boot loader configuration from the second partition to the first partition in response to a system update problem.

3. The method according to claim 1 or 2, wherein performing the root of trust measurement includes using a trusted platform module.

4. The method according to any one of the preceding claims, wherein the live system includes a data partition.

5. The method according to any one of the preceding claims, wherein the live system includes a boot partition that stores at least the boot loader.

6. The method according to any one of the preceding claims, wherein the system update includes an update of one or more of a BIOS, a boot loader, an operating system kernel, initial files, and applications.

7. The method according to any one of the preceding claims, which includes extracting one or more of a kernel, initial files, and a root file system image from the system update, and optionally includes applying the root file system image to the second partition and / or storing a backup of an existing kernel to the boot partition and saving the kernel of the system update to the boot partition.

8. The method according to any one of the preceding claims, wherein the boot loader configuration includes a variable that specifies a boot partition or a boot device.

9. The method according to any one of the preceding claims, which includes: operating the live system using the first partition as the active partition in response to a lack of trust.

10. The method according to any one of the preceding claims, wherein accessing the encryption key accesses the encryption key from a trusted platform module or from a bin file.

11. The method according to any one of the preceding claims, which includes enabling a trusted boot feature after restarting the live system.

12. The method according to any one of the preceding claims, wherein the live system includes satellite communication circuitry, and optionally includes receiving the system update via the satellite communication circuitry.

13. The method according to any one of the preceding claims, wherein the live system is operatively coupled to one or more devices at a well site, and optionally wherein the system update includes instructions for controlling at least one of the one or more devices at the well site.

14. A system (250) that includes: One or more processors (256); A memory (258) accessible by at least one of the one or more processors; Processor-executable instructions (270) stored in the memory and executable to command the system: Operate a live system (911) using a first partition as the active partition and a second partition as the inactive partition; In response to receiving a system update, change the boot loader configuration from the first partition to the second partition (921); Perform a root of trust measurement on the update, wherein the measurement takes into account at least the change in the boot loader configuration; In response to establishing trust via the measurement, access an encryption key (941); Use the encryption key to decrypt at least the second partition for use by the system (951); And In response to detecting a system update problem, restart the live system using the second partition as the active partition and the first partition as the inactive partition for system rollback (961).

15. A computer program product comprising computer-executable instructions for commanding a computing system to perform the method according to any one of claims 1 to 13.

Images